Core Services
VPC — Networking Fundamentals
A Virtual Private Cloud (VPC) is a logically isolated virtual network that allows you to launch AWS resources in a defined virtual environment. It provides granular control over your networking environment, including IP address ranges, subnets, route tables, and network gateways. You reach for a VPC whenever you need to deploy cloud infrastructure that requires secure isolation, specific connectivity requirements, or internal communication protocols.
The Virtual Private Cloud Foundation
A Virtual Private Cloud acts as the fundamental boundary for all your cloud networking. When you create a VPC, you are effectively defining a private network address space, represented by a Classless Inter-Domain Routing (CIDR) block. Think of this as your organization's private office building in the cloud. By segmenting your network into subnets, you gain the ability to group resources based on their sensitivity and function. The reason this architecture is necessary is that it enables the enforcement of strict security boundaries; by default, no traffic enters or leaves a VPC unless you explicitly configure routing paths. This abstraction layer separates your operational requirements from the underlying physical hardware, allowing AWS to scale while maintaining strict logical isolation for your data and services. Every resource you launch, from compute instances to databases, resides within this defined virtual perimeter, ensuring that communication remains contained and controllable according to your security posture.
# Example VPC creation using AWS CLI
# Defining a CIDR block of /16 provides 65,536 private IP addresses
aws ec2 create-vpc --cidr-block 10.0.0.0/16Subnetting and Availability Zones
Subnets are the subdivisions of your VPC, and they are inextricably linked to specific Availability Zones (AZs). An AZ is a physically distinct location within a region, providing fault tolerance. By creating subnets across different AZs, you build a resilient architecture that survives the failure of a single data center. The logic here is simple: if you place all your resources in a single subnet tied to one AZ, a localized power or cooling issue could take your entire application offline. By distributing subnets, you ensure that if one zone experiences an outage, your application can continue serving requests from other zones. The CIDR block for a subnet must be a subset of the parent VPC CIDR block. This hierarchical structure allows for efficient address allocation, enabling you to keep your infrastructure organized. It is crucial to remember that subnets act as the primary security boundary for resources, as you can apply distinct routing logic to each subnet, effectively separating public-facing traffic from internal data processing.
# Create a subnet in the first availability zone
# The subnet must be within the 10.0.0.0/16 VPC CIDR range
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.1.0/24 --availability-zone us-east-1aRoute Tables and Traffic Flow
Route tables act as the central nervous system for your VPC, containing a set of rules, known as routes, that determine where network traffic from your subnets is directed. Every subnet must be associated with a route table, which contains a destination CIDR block and a target, such as an Internet Gateway. The logic is deterministic: when a packet is sent, the VPC looks at the route table to find the most specific route matching the destination IP address. If no route exists, the traffic is dropped. This mechanism is why a newly created subnet is private by default; it lacks a route to an Internet Gateway. By modifying the route table, you gain control over the flow of traffic, directing it toward virtual private gateways, peering connections, or NAT devices. This allows for complex network topologies where you can inspect traffic, mask public IPs, or route internal requests through specific security appliances before they reach their final destination within your private network.
# Create a route table for the VPC
aws ec2 create-route-table --vpc-id vpc-12345678
# Add a route to the Internet Gateway for public access
aws ec2 create-route --route-table-id rtb-12345 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-12345Internet Gateways and Public Accessibility
An Internet Gateway is a horizontally scaled, redundant, and highly available component that allows communication between your VPC and the public internet. Simply attaching an Internet Gateway to your VPC does not automatically make your subnets public; it merely provides the capability for that connection. To actually make a subnet 'public,' you must specifically update the subnet's route table to point the 0.0.0.0/0 route toward the Internet Gateway. The reason this separation exists is for safety and granular control. If you have sensitive database instances, you should keep them in a subnet without this route, preventing them from being reachable from the internet. This design ensures that you have a clear, enforceable boundary between components that need to be public-facing—like load balancers or web servers—and those that must remain isolated. By managing these gateways and routes, you orchestrate exactly how your environment interacts with the external world, minimizing your attack surface while maintaining necessary connectivity.
# Attach an Internet Gateway to the VPC
aws ec2 attach-internet-gateway --vpc-id vpc-12345678 --internet-gateway-id igw-12345
# Associate the route table with the public subnet
aws ec2 associate-route-table --subnet-id subnet-12345 --route-table-id rtb-12345Network Access Control Lists
Network Access Control Lists (NACLs) provide a stateless firewall layer at the subnet level, acting as a traffic gatekeeper. Unlike stateful firewalls that track the connection, NACLs evaluate each packet independently, regardless of whether it is an inbound request or an outbound response. This means you must define rules for both directions. The logic here is sequence-based: rules are evaluated in order starting from the lowest rule number. Once a match is found, the rule is applied, and further rules are ignored. This is a powerful tool for blocking specific malicious IP addresses or restricting traffic types across entire subnets. While Security Groups provide a stateful layer around individual instances, NACLs add a second, broader defensive layer. Because they are stateless, they require careful configuration to ensure return traffic is allowed. They are best utilized as a 'bulk' filter for your network, providing an additional safeguard that operates before traffic even reaches your instances or security groups.
# Create a network ACL for the VPC
aws ec2 create-network-acl --vpc-id vpc-12345678
# Add an inbound rule to allow HTTP traffic (port 80) from anywhere
aws ec2 create-network-acl-entry --network-acl-id acl-12345 --ingress --rule-number 100 --protocol tcp --port-range From=80,To=80 --cidr-block 0.0.0.0/0 --rule-action allowKey points
- A VPC is a logically isolated virtual network with a defined CIDR block.
- Subnets are mapped to specific Availability Zones to ensure high availability and fault tolerance.
- Route tables contain the logic that determines where network traffic is directed within the VPC.
- An Internet Gateway is required for a subnet to enable communication with the public internet.
- Subnets remain private by default unless a route to an Internet Gateway is explicitly configured.
- NACLs provide a stateless firewall layer that evaluates packets at the subnet boundary.
- Security for VPC resources relies on both subnet-level NACLs and instance-level security groups.
- Designing a VPC requires careful planning of IP address ranges to ensure future scalability and connectivity.
Common mistakes
- Mistake: Assuming a VPC is public by default. Why it's wrong: VPCs are logically isolated; resources are private unless explicitly configured with an IGW and route table. Fix: Understand that VPCs start as private silos.
- Mistake: Overlapping CIDR blocks across peered VPCs. Why it's wrong: IP conflicts prevent routing between VPCs. Fix: Use non-overlapping private address spaces when planning architecture.
- Mistake: Configuring Security Groups as Deny rules. Why it's wrong: Security Groups are stateful and allow-only by default. Fix: Use Network ACLs for granular Deny requirements.
- Mistake: Forgetting to update the Route Table after creating an IGW. Why it's wrong: An IGW alone does not route traffic; the subnet must point to it. Fix: Ensure a 0.0.0.0/0 route is explicitly added to the route table associated with the public subnet.
- Mistake: Assuming NACLs are stateful. Why it's wrong: NACLs are stateless, meaning return traffic must be explicitly allowed in the outbound rules. Fix: Remember to open ephemeral port ranges (1024-65535) for inbound/outbound responses.
Interview questions
What is an Amazon VPC, and why is it considered a foundational component of your AWS networking architecture?
An Amazon VPC, or Virtual Private Cloud, is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. It is foundational because it provides you with complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. Without a VPC, you cannot deploy instances like EC2 in a private or public segment, meaning you would lack the necessary segmentation to secure your infrastructure from the public internet.
Can you explain the difference between a public subnet and a private subnet within a VPC?
The primary difference lies in the routing configuration and the internet gateway access. A public subnet is defined by having a route table entry that points 0.0.0.0/0 to an Internet Gateway (IGW), allowing resources within it to have direct inbound and outbound internet connectivity. A private subnet does not have a route to an IGW. Instead, if resources in a private subnet need to reach the internet for updates, they must route traffic through a NAT Gateway or NAT Instance located in a public subnet. This separation is essential for security, ensuring sensitive backend components remain isolated from direct public access.
How do Security Groups and Network ACLs differ, and when would you use one over the other?
Security Groups and Network ACLs both provide security, but they operate at different levels. Security Groups act as a virtual firewall for your instances and are stateful, meaning that if you send a request out, the response is automatically allowed regardless of inbound rules. Network ACLs operate at the subnet level and are stateless, meaning return traffic must be explicitly allowed by rules. You should use Security Groups for fine-grained, instance-level control, while Network ACLs are best used as a secondary, broad-range defense mechanism to block entire IP address blocks or subnets from communicating.
Compare VPC Peering with AWS PrivateLink. In what scenarios would you choose one over the other?
VPC Peering connects two VPCs using private IP addresses, allowing them to route traffic as if they were in the same network. This is great for simple, low-latency connectivity between two owned VPCs. AWS PrivateLink, however, provides private connectivity between VPCs and services, but without requiring VPC Peering. PrivateLink is superior when you want to expose a service to many VPCs without complex routing or IP address overlap issues, as it uses interface endpoints. Choose Peering for full bi-directional access, but choose PrivateLink for secure, unidirectional service consumption at scale.
What is the function of a NAT Gateway, and why might you choose it over a NAT Instance?
A NAT Gateway enables instances in a private subnet to connect to the internet or other AWS services but prevents the internet from initiating a connection with those instances. You would choose a NAT Gateway over a NAT Instance because the gateway is a managed service provided by AWS, offering higher availability and higher bandwidth without needing to manually patch or scale EC2 instances. NAT Instances require you to manage the underlying server, including configuration and failover, whereas NAT Gateways are highly available and highly performant by design, simplifying your administrative burden.
Describe the process of designing a VPC with overlapping IP addresses in mind; how does this impact VPC Peering?
Designing a VPC requires careful IP address planning using CIDR blocks. If you plan to implement VPC Peering, you must ensure that your VPCs do not have overlapping or contiguous CIDR blocks, because the AWS routing tables will not be able to distinguish which VPC to send traffic to if the address spaces are the same. To solve this, you would need to use PrivateLink or a Transit Gateway, which acts as a hub-and-spoke router to manage complex routing logic. Without proper planning, you essentially create a network deadlock where traffic cannot be routed effectively between the peering participants.
Check yourself
1. A web server in a private subnet needs to download security patches from the internet. Which component must be configured to allow this while keeping the instance private?
- A.Internet Gateway
- B.NAT Gateway
- C.Egress-only Internet Gateway
- D.Virtual Private Gateway
Show answer
B. NAT Gateway
A NAT Gateway allows instances in private subnets to reach the internet while blocking unsolicited inbound connections. An IGW is for public subnets, an Egress-only gateway is for IPv6, and a VPG is for VPN connections.
2. You have a security group with an inbound rule allowing port 80. You notice that traffic is being blocked. Why might this happen?
- A.The Network ACL associated with the subnet has a deny rule for port 80.
- B.Security Groups are stateless and require a corresponding outbound rule.
- C.The instance needs a public IP address to process inbound security group rules.
- D.The security group needs an explicit allow for the return traffic on the ephemeral ports.
Show answer
A. The Network ACL associated with the subnet has a deny rule for port 80.
NACLs are evaluated before Security Groups. If an NACL denies the traffic, the Security Group setting is ignored. Security Groups are stateful (option B is false), instances do not need public IPs for internal security (option C is false), and return traffic is automatic for SGs (option D is false).
3. Two instances in the same VPC but different subnets cannot communicate, despite both being in the same security group. What is the most likely cause?
- A.The Route Table lacks a route between subnets.
- B.The VPC doesn't have an Internet Gateway attached.
- C.The Network ACL is blocking the communication.
- D.Instances in different subnets cannot communicate by default.
Show answer
C. The Network ACL is blocking the communication.
Subnets within the same VPC can communicate by default via the local route. NACLs are the only component that can block this intra-VPC traffic. The Route Table is not needed for internal traffic (option A), and an IGW is for external traffic (option B).
4. You are designing a VPC and need to ensure that your database tier is not accessible from the internet, even if a resource is accidentally assigned a public IP. How can you best enforce this?
- A.Place the database in a subnet with no route to an Internet Gateway.
- B.Use a Security Group to deny all traffic from 0.0.0.0/0.
- C.Attach an Egress-only Internet Gateway to the database subnet.
- D.Disable DNS hostnames for the VPC.
Show answer
A. Place the database in a subnet with no route to an Internet Gateway.
Without a route to an IGW, a subnet is physically incapable of reaching or being reached by the internet. Security groups cannot 'deny' traffic (option B), an Egress-only gateway is for IPv6 (option C), and DNS settings do not restrict routing (option D).
5. What happens when you add an instance to a Security Group?
- A.The instance inherits the rules of the new group and loses all previous rules.
- B.The instance can belong to only one security group.
- C.The instance's rules are the union of all security groups it is assigned to.
- D.The instance must be rebooted for the new security group rules to take effect.
Show answer
C. The instance's rules are the union of all security groups it is assigned to.
Security groups are additive; the effective policy is the union of all rules from all assigned groups. You can assign multiple groups (option B is false), rules are cumulative (option A is false), and changes take effect immediately without a reboot (option D is false).