Episode 11: VPC Architecture Deep Dive - Subnets, NAT Gateway & Security Groups vs NACLs | SAA-C03

Hey everyone, Paulo here, welcome back to Tech Talk with Balu, your complete guide to async the AWS Solutions Architect Associate Exam. If you're an episode 11, and today we're diving into VPC, Virtual Private Cloud. This is networking in AWS and it's absolutely fundamental. You cannot build anything significant in AWS without understanding what VPCs are. Here's why VPC matters. When you launch AWS resources, they need to live in a network. VPC is that network, your own private, isolated section of the AWS cloud. You control everything, IP addresses, subnets, routing and security. Understanding VPC is critical for the exam and for real world AWS work. Questions about VPC architecture appear constantly on the exam. So today we are covering what a VPC is and a CIDR blocks, subnets that's public versus private, route tables, that's how traffic flows, internet gateway for public internet access, not gateway for private instances to access the internet, security groups versus network ACLs, the critical distinction, VPC purring for connecting VPCs, VPC endpoints for private AWS service access, VPC flow logs for monitoring. By the end of this episode, you will understand how to design secure, scalable VPC architectures. This is core AWS networking knowledge. So let's dive straight in. Let's start with the basics. What is a VPC? VPC stands for virtual private cloud, it's a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. Think of VPC as your own private data center in AWS, except it's virtual. You control the IP address range, create subnets, configure route tables and set up network gateways. Every AWS region lets you create multiple VPCs, you can have as many VPCs as you need, that is completely isolated from each other. Now when you create an AWS account, AWS provides a default VPC in each region. This default VPC is ready to use immediately. You can launch EC2 instances into it right away without any configuration needed. However, for production workloads, you typically create custom VPCs with your own IP address ranges and subnet design. Let's talk about CIDR blocks. CIDR stands for classless interdomain routing, it's a way to specify IP address ranges. When you create a VPC, you must specify a CIDR block, the range of IP addresses that your VPC will use, for example, 10.0.0.0/16. Now let me explain what this means. The slash 16 is the subnet mask, it means the first 16 bits are fixed and the remaining 16 bits can vary. This gives you 65536 IP addresses in total. The allowed block size in AWS is between slash 16.65536 addresses and slash 26.16 addresses. Typically you use slash 16 for VPCs to have plenty of addresses. An important thing to note is that you cannot change the CIDR block after creating the VPC. Well, you can add secondary CIDR blocks, but the primary one is permanent, so you want to choose very carefully. Now there are a list of private IP ranges that's defined by RFC1918, there is 10.0.0.0/8, there is 172.16.0.0/12, there is 192.168.0.0/16. These are private IP ranges not routable on the public internet, your VPC should use addresses from these ranges. For the exam, remember, VPC equals your private network in AWS. You define the IP range with CIDR notation and you want to choose slash 16 for flexibility. Now let's talk about subnets. Subnets divide your VPC into smaller networks. A subnet is a range of IP addresses within your VPC. You create subnets in specific availability zones, so here's a key point. It's a tie to a specific availability zone. A subnet in US East 1A cannot span to US East 1B. One subnet, remember, is 1AZ. Now why do you want to create multiple subnets? This is for organization, security and high availability. Let's say your VPC uses 10.0.0.0/16, you might create three subnets. 110.0.1.0/24 in US East 1A with 256 addresses, subnet 210.0.2.0/24 in US East 1B, that's another 256 addresses, and finally subnet 310.0.3.0/24 in US East 1C, that's another 256 addresses. Now let's discuss public versus private subnets. This is critical. A public subnet is a subnet with a route to the internet gateway. Instances in public subnets can communicate directly with the internet if they have public IP addresses. A private subnet on the other hand has no direct route to the internet gateway. Instances in private subnets cannot be accessed directly from the internet. They can only access the internet through a NAT gateway or NAT instance. So what makes a subnet private or public? It's the route table. If the route table has a route to an internet gateway, it's public. If not, it's private. The subnet itself doesn't have a public flag. It's all about the routing. A common architecture pattern is to use public subnets for web servers, load balancers, well things that need direct internet access, and you would use private subnets for your application servers or databases, things that should not directly be accessible from the internet. OK, now here is an important detail about IP addresses. AWS reserves five IP addresses in every subnet. For a subnet with CIDR10.0.1.0/24, that is, remember 256 addresses, AWS reserves a network address, a VPC route to address, a DNS server address, a network broadcast address, and an address reserved for future use. So out of 256 addresses, you can only use 256.1. So if your use case needs to run 250 instances in a subnet, then you want the plan for slash 24 at minimum. For the exam, remember, subnets are AZ specific, one subnet in one AZ only. Public subnet has a route to internet gateway, whereas private subnet does not have a route to the internet gateway, AWS reserves five IP addresses per subnet. All right, now let's talk about internet gateway. This is how resources in your VPC access the internet. An internet gateway is a horizontally scaled, redundant and highly available VPC component that allows communication between your VPC and the internet. So it mainly serves two purposes. First, it provides a target in your VPC route tables for internet routeable traffic. Number two, it performs network address translation or NAT for instances that have been assigned public IP addresses. Here's how it works. You create an internet gateway and attach it into your VPC. One VPC can have only one internet gateway attached, one IGW per VPC. Then you update the route table for your public subnets to add a route that 0.0.0.0/0 points to the internet gateway, 0.0.0/0 means all IP addresses. Any traffic not destined for local VPC goes to the internet gateway. Now instances in those subnets can reach the internet and the internet can reach them too, assuming they all have public IP addresses and security groups allow that traffic. An important thing to note is that the internet gateway by itself doesn't make instances publicly accessible. You also need a public IP address or elastic IP on your instance, a route table pointing to that IP which is 0.0.0/0 to the IGW, security group rules allowing the traffic, network ACL rules allowing the traffic. All the four components must be configured correctly. So for the exam, remember, one internet gateway per VPC, IGW allows bidirectional internet communication. It requires a route in route table and the instance needs public IP to communicate through the IGW. Now let's discuss NAT gateway. This is for private instances that need to access the internet without being accessible from the internet. NAT stands for network address translation. The scenario I want to take you through is that you have database servers in a private subnet. They need to download security updates from the internet, but you don't want them to have public IP addresses or to be directly accessible from the internet. The solution here is to use a NAT gateway. A NAT gateway allows instances in private subnets to initiate outbound connections to the internet but prevents the internet from initiating connections to those instances. Now, here's how it works. You create a NAT gateway and place it in a public subnet. The NAT gateway itself gets an elastic IP address. Then you update the route table for your private subnets to point to 0.0.0/0 to the NAT gateway. Now when a private instance tries to reach the internet, traffic goes to the NAT gateway. The NAT gateway then translates the private IP to its own public IP and forwards the traffic to the internet gateway. Just come back through the same path. From the internet's perspective, all traffic appears to be coming from the NAT gateway's IP address. The private instances IP is always hidden. Critically this is unique directional. Private instances can initiate connections outbound but the internet cannot initiate connections to them. That is the security benefit right there. NAT gateway is managed by AWS. It's highly available within an availability zone and it automatically scales up to 45GPPS and requires minimal maintenance. For high availability across Asis, you create one NAT gateway per Asi. If an Asi goes down, instances in that Asi lose internet access but other Asis are unaffected. Here's an important cost consideration. NAT gateway charges are based on an hourly usage and data process charge. It is one of the more expensive VPC components charges around $0.045 per hour plus $0.045 per GB process. For very cost sensitive environments, you can use a NAT instance instead, an EC2 instance that you manage yourself configured for the NAT, but NAT gateway is recommended for simplicity and high availability. So let's compare internet gateway and NAT gateway. An internet gateway is used for public subnets, it's bidirectional, that's inbound and outbound traffic. There is no hourly charge, it's free, it's managed by AWS and it's one per VPC. And NAT gateway on the other hand is for private subnets to access internet, it's unidirectional, that's outbound traffic only, it costs money, there's hourly plus data. Managed by AWS, one per Asi for high availability. For the exam, remember, NAT gateway allows private instances to access the internet. Traffic is outbound only, internet cannot initiate connections to private instances. NAT gateway goes in a public subnet and needs an elastic IP, private subnet's route table points to 0.0.0/0 to NAT gateway, for high availability deploy one NAT gateway per Asi. Right, now let's talk about route tables. Route tables control where network traffic is directed, a route table contains a set of rules called routes, that determine where network traffic from your subnet is directed. Every subnet must be associated with a route table, if you don't explicitly associate a subnet within a route table, it uses the main route table. Each VPC has a main route table that you can modify, you can also create custom route tables. Now, let me show you what a route table looks like. For a VPC with CIDR 10.0.0/16, the route table might have destination 10.0.0/16 target local. This route is automatic and cannot be deleted. It says traffic destined for any IP in the VPC stays within the VPC. Now for a public subnet, you add destination 0.0.0/0 and target IGW12345678, let's say. This says all other traffic goes to the internet gateway. For a private subnet, you add destination 0.0/0 and target goes to NAT 875321, let's say. This says all other traffic goes to the NAT gateway. Routes are evaluated from most specific to least specific, the longest prefix match wins. Example, if you had route 1, 10.0.1.0/204 going to local, route 2, 10.0.0.0/16 going also to the local, and route 3, 0.0.0/0 going to IGW XYZ, so now if the traffic is destined for 10.0.1.5, it matches route 1 first, that's most specific and it stays local. If traffic is destined for 10.0.5.5, it matches route 2 and stays local. If traffic is destined for 8.8.8, it doesn't match route 1 or route 2, so it matches route 3 here and goes to the internet gateway. I want you to take away some best practices for creating route tables. You want to create separate route tables for public and private subnets. Don't use the main route table for anything, create explicit custom route tables and associate them with your subnets. And this is the reason why you would do that, if you accidentally launch a subnet without specifying a route table, it gets the main route table. If your main route table has a route to the internet, now you've just accidentally created a public subnet when you've meant it all to be private, it's a big security risk. If you should leave the main route table with no internet route, then create custom route tables for both public and private subnets. For the exam, remember, route tables control traffic flow. Every subnet must have a route table, routes are evaluated, most specific to least specific. Public subnet route table has 0.0.0.0/0, routed to the IGW, private subnet route table has 0.0.0.0.0/0, routed to the NAD gateway, and the best practice don't use the main route table, create explicit custom route tables. Okay, now we get on to one of the most important topics, security groups versus network ACLs. This comparison appears on every exam. Both security groups and network ACLs control traffic, but they work differently. Let's start with security groups. A security group acts as a virtual firewall for you instances. It controls inbound and outbound traffic at the instance level. Security groups are stateful, this is critical. Stateful means if you allow inbound traffic, the response is automatically allowed outbound, regardless of the outbound rules. The security group tracks connections. An example is you allow inbound HTTP on port 80, a user connects to your web server on port 80. When your server responds, that response is automatically allowed out, even if you haven't got any outbound rules. The security group remembers the connection. So a security group rules are you can only specify allow rules, there are no deny rules. We spoke about this earlier, all inbound traffic is denied by default and all outbound traffic is allowed by default. Security group rules reference either IP addresses, CIDR blocks or other security groups. An example rule is allow inbound traffic on port 22, that's SSH, from an IP address, or allow inbound traffic on port 3306, that's MySQL, from SG12345678, the web server security group. This second approach is normally more powerful, it says allow MySQL connections from any instance that has the web server security group attached. You don't need to know the IP addresses, security groups automatically track this for you. Security groups are attached to elastic network interfaces or eonis for short, which means they are attached at the instance level. Okay now let's talk about network ACLs. Initial stands for network access control list, a network ACL is a stateless firewall that controls traffic at the subnet level. The key difference is that stateless means inbound and outbound traffic are evaluated separately. If you have allowed inbound traffic, you must explicitly allow the outbound response. The initial doesn't track connections. An example is you allow inbound HTTP on port 80, a user connects on port 80. When your server now tries to respond, the response goes out as an ephemeral port, let's say port 52,000. Now if you haven't allowed the outbound traffic on port 52,000, the response is blocked. The connection fails. This makes initials harder to configure than security groups. So the network ACL rules have numbers from 1 to 32,766, lower numbers are evaluated first. You can have both allow and deny rules. Default initial allows all inbound and outbound traffic. Custom initial denies all inbound and outbound traffic by default until you add rules. Network ACLs apply to all instances in a subnet. One initial per subnet but one initial can be associated with multiple subnets. Some examples of initial rules are, let's say allow inbound HTTP port 80 from an IP address, or allow inbound HTTPS from a particular port on another IP address, so and so forth. But then you will also need outbound rules accordingly, so that your incoming traffic isn't blocked. Now let's just compare security groups and network ACL side by side. Security groups operate at instance level, support allow rules only. It is stateful, that means it returns traffic automatically. All rules are evaluated together, applies to an instance only if associated with that instance. Whereas network ACLs operate at subnet level, it supports both allow and deny rules. It's stateless, that means return traffic. It must be explicitly allowed, rules are evaluated in number order and it automatically applies to all instances in the subnet. Now which one should you use? You want to use security groups as your primary defense, they are easier to manage and stateful behavior matches how connections work. You use initials as an additional layer of defense, they provide subnet level protection and support deny rules which security groups cannot. An example is to block a specific malicious IP address attacking your infrastructure. You want to add a deny rule in the NACLs, remember security groups cannot deny specific IPs, they can only allow. For the exam, this distinction is critical. So once again let's look at the difference between security groups and network ACLs, security groups are instance level, whereas network ACLs are subnet level. Security groups are stateful, that means return traffic is auto allowed, whereas network ACLs are stateless, return traffic must be explicitly allowed. Security groups only have allow rules, whereas network ACLs have both allow and deny rules. Security groups evaluate all the rules, network ACLs evaluate the rules in number order. Okay, now let's go on to the next topic, VPC peering. This is how you connect two VPCs together. VPC peering allows you to route traffic between two VPCs using private IP addresses. Users in either VPC can communicate with each other as if they were in the same network. So VPC peering works between VPCs in the same AWS account. It works between VPCs in different AWS accounts also, and can also work between VPCs in different regions, that's in the region VPC peering. So here's how you set it all up. First you want to create a VPC peering connection. One VPC is the requester and the other is the acceptor. Second, the acceptor must accept the peering connection. And third, this is very critical. You want to update the route tables in both the VPCs to route traffic to the other VPC through the peering connection. For example, VPC A has CIDR of 10.0.0.0/16, VPC B has CIDR of 172.31.0.0/16, and in VPC A's route table, you want to add that VPC A's CIDR address to a peering connection ID. And similarly, in VPC B's route table, you want to add that VPC CIDR to the same peering connection. Now instances in VPC A can reach instances in VPC B using private IPs. But there is an important limitation I want you to remember about VPC peering. First, VPC peering is not transitive. If VPC A is peered with VPC B and VPC B is peered with VPC C, VPC A cannot communicate with VPC C through VPC B. If you wanted to connect A and C to communicate with each other, you must create a direct peering connection between them. Second, CIDR blocks cannot overlap. If both VPCs use 10.0.0.0/16, you cannot peer them. They need to have non-overlapping IP ranges. Number three, you can only have one peering connection between the same two VPCs. Some of the use cases for using VPC peering are when you want to connect your production VPC to development VPC, allow shared services VPC to be accessed by multiple application VPCs, and connect to partner companies VPC. For the exam, remember VPC peering connects two VPCs using private IPs. It works across accounts and regions. It's non-transitive which means you must create direct peering for each VPC pair. CIDR blocks must not overlap IP address and you must update route tables in both the VPCs. Now let's talk about VPC endpoints. Notice how you privately access AW services without going through the internet. Normally when an EC2 instance in your VPC needs to access S3 or DynamoDB, traffic goes out through the internet gateway or NAT gateway to the public AWs endpoints. Now this has two problems. First it uses bandwidth. If you're transferring large amounts of data to S3, you're paying for NAT gateway data processing. Number two, traffic leaves your VPC, even though it's encrypted, some organizations prefer traffic never leaves AWs' private network for compliance reasons. VPC endpoints solve both these problems. They allow you to connect to AW services using private IP addresses, keeping traffic within the AWs network. There are two types of VPS endpoints. The first one is called gateway endpoints. Gate endpoints are for S3 and DynamoDB only. You create a gateway endpoint and specify which route tables should use it. When you add the gateway endpoint, a route is automatically added to the route table, pointing S3 or DynamoDB traffic to that endpoint. Gate endpoints are free, there's no hourly charge, and there is no data processing charge. That's great. The second type of VPC endpoint is called interface endpoints. Interface endpoints use AWs' private link and work with many AW services like CloudWatch SMS, SQS, Kindness system managers and dozens more, an interface endpoint creates an elastic network interface, also called ENI, in your subnet with a private IP address. You access the service through this ENI. Interface endpoints cost money, hourly charge plus data processing charge applies very similar to NAT gateway pricing. Now let me give you a common exam scenario here. You have easy-to-instances in a private subnet with no internet access. Now they need to access S3. How do you do this without adding a NAT gateway? The answer is to create a gateway endpoint for S3 and associate it with the private subnet route table. Now the instances can access S3 using the private AWs network connections. Cool, here's another scenario. You have Lambda functions in a VPC that need to call the system manager parameter store API. What's the most secure way of doing that? The answer is to create an interface endpoint for systems manager in the VPC, Lambda functions access system manager through the private endpoint, instead of going out onto the internet. So for the exam, remember, gateway endpoints support S3 and DynamoDB only, whereas interface endpoints support many AW services, gateway endpoints are free, interface endpoints are the other hand-cost money, for gateway endpoints you need to modify the route tables, interface endpoints you create ENIs in your subnet and it uses AWS's private link. Both keep traffic within AWS network and it never goes to the public internet to remember that. Right, let me quickly now cover VPC flow logs. This is for monitoring and troubleshooting network traffic. VPC flow logs capture information about the IP traffic going to and from network interfaces within your VPC flow log data can be published to cloud watch logs or S3. You can create flow logs at three different levels. You can create it at VPC level, subnet level and the network interface level. Let's look at it one by one, VPC level capture traffic for all ENIs within the VPC, subnet level capture traffic for all the ENIs in the subnet and the network interface level capture traffic for a specific ENI. And what do they capture? What do the flow logs capture? Each log entry contains the source IP and the destination IP, the source port and the destination port, the protocol number of packets and bytes being sent, the action that is done whether it's an accept or reject and the timestamp. And for a use case, your troubleshooting connectivity issues. And if you can't reach an instance, you check flow logs. You will find out if the packets are reaching the instances, are they being accepted or rejected. Well, this all tells you if it's a security group issue, it's an initial issue or a routing issue. Another common use case is for security analysis. It can help you monitor unusual traffic patterns, like if there is a connection attempt from an unexpected IP address, so and so forth. Another use case is compliance, because some regulations require logging all the network traffic. There's an important thing to know that flow logs do not capture all the traffic. They don't log certain things like traffic to AWS DNS servers. They don't log traffic to AWS Windows license activation. They don't log the traffic to instance metadata or the DHCP traffic. But for the exam, remember, flow logs capture IP traffic metadata. It's published to CloudWatch or to S3. It's available at VPC, Subnet or at the ENI level. Now onto our favourite section, exam traps and gotchas. Let's cover some common VPC exam traps. Trapped number one, security groups are stateful, whereas initials are stateless. The question is, an instance in a private subnet can't access the internet through NAT gateway. Security group allows all outbound, but now what's wrong? Many people think security group allows outbound, so it should work. Well, that's the wrong approach. You want to check the initials, initials are stateless. You need to allow both outbound traffic on port, 4.4.3, that's HTTPS and inbound traffic on ephemeral ports. that's between 1024 to 65535 for the response. Trap number two, VPC peering is not transitive. Question, VPCA pears with VPCB. VPCB pears with VPCC. Can VPCA communicate with VPCC? We looked at the same question earlier. The answer is no. Peering is not transitive. You must create direct peering connection between VPCA in this case and VPCC. Okay, trap number three, subnets cannot span availability zones. The question is, you create a subnet that spans US East 1A and US East 1B for high availability. Can you do that? Now it's impossible. One subnet lives in exactly one AZ. For high availability, you create separate subnets in each AZ. Trap number four. Internet gateway alone doesn't provide internet access. Question is, you attach an internet gateway to VPC but instances can't reach the internet. Why is that? Well, the answer is multiple things must be configured here. Route table must have 0.0.0/0. That's map two IGW. Instance must have public IP or elastic IP. Security group must allow outbound traffic. Any seal must also allow outbound traffic and inbound return traffic explicitly. All the four must be correct. Trap number five, NAT gateway must be in a public subnet. The question is, then you configure NAT gateway in a private subnet. No, you can't. NAT gateway must be in a public subnet because it needs a route to the internet gateway. Private instances route to NAT gateway which then routes to the IGW. Trap number six, default initial allows all traffic. Question is, can a default initial block all traffic? No, it can't. Custom initials on the other hand deny all by default so don't confuse between both of them. Trap number seven, you cannot change VPC, CIDR block. Question is, VPC is running out of IP addresses. Can you expand CIDR from slash 16 to slash eight? No, you cannot change the primary CIDR block. We spoke about this earlier. You can add secondary CIDR blocks but the primary once configured is permanent. So you want to plan your CIDR carefully at your creation time. Trap number eight, security group rules are evaluated as a whole. Question, security group has 50 rules. Are they evaluated in the order like NACL? No, they aren't. Security groups evaluate all the rules together unlike NACLs. There is no rule ordering. So if any rule allows the traffic, it's allowed. Trap number nine, gateway and points are free, interface and points cost money. Question, you want to minimize cost accessing S3 from private subnet. You want to use gateway and point or an interface and point. The answer is gateway and point it's free, interface and points cost hourly charges plus data processing charges. Trap number 10, VPC puring CIDR blocks must not overlap. Question is, both VPCs use 10.0.0.0/16. Can they be here? The answer is no, they are overlapping CIDR IP addresses and that will block puring. This is why planning your VPC CIDR blocks matters a lot. Trap number 11, AWS reserves five IPs per subnet. Question is, subnet is slash 28.16 addresses. How many instances can you launch? The answer is 11, because remember, AWS reserves five IPs leaving 11 only usable. And finally, for Trap number 12, flow logs don't capture all traffic. Question is, can you enable flow logs to capture DNS queries to AWS DNS server? No, you can't. Flow logs don't capture traffic to AWS DNS. Remember that? They also don't capture Windows license activation, instance metadata or DHCP traffic for that matter. All right, so on to some rapid fire VPC exam tips now. Tip number one, one subnet, one AZ always, subnets don't span AZs. Remember that? Tip number two, public subnet has route to IGW, private subnet on the other and does not. Tip number three, security groups are stateful and instance level. Initials on the other hand are stateless and subnet level. Tip number four, VPC peering is not transitive. Direct peering is required for each pair. Tip number five, gateway and points for S3 and DynamoDB can be used and they are completely free. For other AWS services, you use interface and points, but you remember it costs money. Tip number six, not gateway allows private instances to access internet outbound only. Tip number seven, route tables control traffic flow, most specific route wins in this case. Tip number eight, default an ACL allows all custom an ACL denies all by default. Tip number nine, IGW provides bidirectional internet access, not gateway provides outbound only. And finally for tip number 10, flow logs capture IP traffic metadata, they don't log AWS DNS, instance metadata or DHCP. So I want you to remember this decision flow chart. If you need internet access for public resources, then think internet gateway. If you need internet access for private resources, then I want you to think not gateway. If you need to connect to VPCs together, then think VPC peering. If you need private access to AWS services, then think VPC and points. So gateway for S3 or DynamoDB and interface for the others. And if you need to monitor traffic, then think about VPC flow logs. So all right, everyone, that's episode 11 on VPC architecture. We covered a lot of ground today. We started with VPC fundamentals, what a VPC is, CIDR blocks and IP address planning. We explored subnets, the difference between public and private, how they're tied to availability zones and the five reserved IP addresses. We learned about internet gateways for bidirectional internet access and not gateways for private instances to access the internet outbound only. We do deep into route tables and how they control traffic flow in your VPC. We covered the critical distinction between security groups and network ACLs that is stateful versus stateless, instance level versus subnet level, allow only versus allow and deny and so and so forth. We then explored VPC peering for connecting VPCs together and the non-transitive nature of peering connections. We learned about VPC endpoints for private access to AWS services. That's gateway endpoints for S3 and DynamoDB interface endpoints for everything else. We discussed flow logs for monitoring network traffic and we finally finished with 12 exam traps that appear constantly on the test. So the key takeaway is that VPC is the foundation of AWS networking, understanding subnets, routing and securities critical for designing secure, scalable AWS architecture. This was episode 11. We have now covered EC2, IAM, global infrastructure, ELB, auto scaling, S3, storage architectures, databases, route 53 and here you are with VPC. You have a solid foundation in core AWS services well done now. In our next episodes, we will continue on that momentum building on this foundation with more advanced AWS services. Now if this episode helped you master VPC architecture, please do leave a five star rating on Spotify and consider subscribing to my channel. Until next time, keep studying, keep practicing and keep building. This is Balu signing off by.