AWS Solutions Architect Associate Certification Guide
Advanced VPC Networking
Architecting Your VPC
Think of your Virtual Private Cloud (VPC) as the digital property line for your application in AWS. A solid design is non-negotiable. The most common and effective strategy is to separate your resources into public and private subnets, creating a multi-tier architecture. This isn't just for organization; it's a fundamental security practice.
Public subnets are for resources that need direct access to and from the internet, like your web servers. Private subnets are for your backend, like databases or application servers, which should be shielded from direct public access. Users interact with the web servers, and those servers, in turn, communicate with the databases. This setup drastically reduces your application's attack surface.
Controlling Traffic Flow
Subnets are just containers. The real control comes from route tables. Every subnet is associated with a route table, which acts like a traffic cop, directing packets where to go. For a public subnet to be truly public, its route table must have a route to an Internet Gateway (IGW). The IGW is the doorway for all inbound and outbound internet traffic to your VPC.
But what about instances in a private subnet? They can't receive inbound traffic from the internet, but they often need to initiate outbound connections—for example, to download software updates or patches. This is where Network Address Translation (NAT) comes in.
You have two options for NAT in AWS: a or a NAT Instance. A NAT Gateway is a managed AWS service. You create it in a public subnet, and it handles the rest. A NAT Instance is just an EC2 instance you configure yourself with specific software. For the exam, knowing the trade-offs is key.
| Feature | NAT Gateway | NAT Instance |
|---|---|---|
| Management | AWS Managed | Self-Managed |
| Availability | Highly available within an AZ | Must be manually configured for HA |
| Bandwidth | Bursts up to 45 Gbps | Depends on EC2 instance type |
| Cost | Per hour + data processing fee | EC2 instance cost + data transfer |
| Security | No Security Group | Requires Security Group management |
| Use Case | Most production workloads | Cost-sensitive or custom routing needs |
To provide internet access to a private subnet, you create a NAT Gateway in a public subnet and add a route to it from the private subnet's route table. The target for traffic destined for the internet (0.0.0.0/0) should be the NAT Gateway.
Layered Security
Your VPC has two primary firewalls: Network Access Control Lists (NACLs) and Security Groups. They operate at different levels and have one crucial difference.
Security Groups act as a firewall at the instance level. They are , which means if you allow inbound traffic on a certain port, the return traffic is automatically allowed out, regardless of outbound rules. This simplifies rule management significantly.
NACLs, on the other hand, are a firewall at the subnet level. They are stateless. This means you must explicitly define rules for both inbound and outbound traffic. If you allow inbound traffic on port 80, you must also create an outbound rule to allow the return traffic on the appropriate ephemeral ports.
| Feature | Security Group | Network ACL (NACL) |
|---|---|---|
| Scope | Instance Level | Subnet Level |
| State | Stateful | Stateless |
| Rules | Allow rules only | Allow and Deny rules |
| Rule Evaluation | All rules are evaluated | Rules are evaluated in order |
| Default | Denies all inbound, allows all outbound | Allows all inbound and outbound |
Best practice is to rely primarily on Security Groups for fine-grained control and use NACLs as a broader, second layer of defense, like blocking a known malicious IP address at the subnet boundary.
Connecting Networks
As your cloud footprint grows, you'll need to connect multiple VPCs. The classic way is with VPC Peering. A peering connection is a 1-to-1 link between two VPCs that allows them to communicate using private IP addresses as if they were on the same network. However, peering is not transitive. If VPC A is peered with B, and B is peered with C, A cannot talk to C through B. For many VPCs, this creates a complex and hard-to-manage mesh of connections.
The modern solution is the (TGW). A TGW acts as a cloud router or a regional hub. You connect all your VPCs to the central TGW, and it handles the routing between them. This hub-and-spoke model simplifies network management dramatically. If you want to connect a new VPC, you just connect it to the TGW instead of creating multiple new peering connections.
Finally, how do you securely access AWS services like S3, DynamoDB, or SQS from within your VPC without sending traffic over the public internet? The answer is VPC Endpoints. They create a private connection between your VPC and supported AWS services, powered by . Traffic never leaves the Amazon network, which is a huge win for security and can also reduce data transfer costs.
There are two types of VPC endpoints:
- Gateway Endpoints: This is the older style and only supports S3 and DynamoDB. They are free to use. You modify your route table to point traffic destined for these services to the gateway endpoint.
- Interface Endpoints: These use an Elastic Network Interface (ENI) with a private IP address in your subnet. They support most AWS services and are powered by AWS PrivateLink. They have an hourly cost and a data processing fee.
What is the key difference between an AWS Security Group and a Network Access Control List (NACL)?
An application running on an EC2 instance in a private subnet needs to download critical security patches from the internet. How can this be achieved without exposing the instance to inbound traffic from the internet?
Mastering these VPC concepts is crucial. A well-architected network is the foundation for a secure, scalable, and resilient application on AWS.