AWS Network Design and Security for Exam Scenarios

Mastering network design is not just about passing your AWS certification; it's about building the secure, resilient, and efficient foundation upon which every cloud application runs. The exam will present you with complex, multi-layered scenarios requiring you to choose the correct architecture that balances connectivity, isolation, and cost. Success hinges on a deep, practical understanding of Virtual Private Cloud (VPC) components and their interplay.

VPC and Subnet Design: Laying the Foundation

Every secure AWS network begins with a Virtual Private Cloud (VPC), your logically isolated section of the AWS Cloud. Your first critical decision is CIDR planning. You must select an IP address range (like 10.0.0.0/16) that is large enough to accommodate all current and future resources but does not overlap with any networks you intend to connect to, such as your corporate data center or other VPCs. A common exam trap involves conflicting CIDR blocks that prevent VPC peering or VPN connectivity.

Within your VPC, you create subnets to group resources by function (e.g., web servers, databases) and to distribute them for high availability. A best practice is to create subnets in multiple Availability Zones (AZs). For a resilient two-tier application, you would place public web-tier subnets in, for example, us-east-1a and us-east-1b, and private application-tier subnets in the same zones. Each subnet is associated with a route table, which controls traffic flow. The default route table allows local VPC communication. For public subnets, you add a route (0.0.0.0/0) pointing to an Internet Gateway, making them publicly accessible. For private subnets, you either have no internet route or route traffic through a NAT Gateway for outbound-only internet access, a classic exam scenario for backend servers that need to download patches but must not be directly reachable.

Security Layers: Stateful Security Groups vs. Stateless NACLs

AWS provides two fundamental, complementary network security layers. Understanding their distinct behaviors is a frequent exam focus point.

Security Groups (SGs) act as stateful virtual firewalls for Elastic Network Interfaces (ENIs) attached to resources like EC2 instances. Stateful means that if you allow an inbound rule (e.g., TCP port 80 from 0.0.0.0/0), the corresponding outbound response traffic is automatically permitted, regardless of outbound rules. SGs are evaluated before traffic reaches the instance. Key exam concepts: SGs operate at the instance level, you can reference other SGs as sources (enabling easy intra-tier communication), and they deny all by default—you must explicitly add allow rules.

Network Access Control Lists (NACLs) are stateless firewall rules associated with subnets. Stateless means inbound and outbound rules are evaluated independently. If you allow an inbound port, you must also explicitly allow the corresponding outbound ephemeral ports for the response. NACLs process rules in numerical order, starting with the lowest-numbered rule, until a match is found. The default NACL allows all traffic. You can create custom NACLs to, for example, explicitly block a specific IP range from accessing an entire subnet—a task better suited for NACLs than SGs. Exam questions often test your ability to diagnose connectivity failures by asking you to evaluate both SG and NACL rules in sequence.

Private Connectivity: VPC Endpoints and PrivateLink

For scenarios requiring resources in a private subnet to access AWS services (like S3 or DynamoDB) without traversing the public internet, you use VPC endpoints. There are two types, and choosing the correct one is a common exam objective. Gateway endpoints are used only for S3 and DynamoDB. You create a gateway endpoint and update your private subnet's route table with a route to the service's prefix list, directing traffic through the endpoint. No public IP, IGW, or NAT device is needed.

For over 100 other AWS and supported SaaS services, you use interface endpoints, which are powered by AWS PrivateLink. An interface endpoint provisions an Elastic Network Interface (ENI) with a private IP address in your chosen subnet. Your instances communicate with this ENI as if the service were inside your VPC. PrivateLink is also the mechanism for securely exposing your own service to other VPCs or AWS accounts. Instead of using VPC Peering or public load balancers, you create a Network Load Balancer (NLB) for your service and then create a VPC Endpoint Service. Consumers create an interface endpoint in their VPC to connect to your service privately. Exam scenarios frequently involve designing a multi-account architecture where a central team provides a shared service (like a payment API) that must be consumed by applications in other accounts without public exposure or complex peering mesh.

Common Pitfalls

1. Misapplying Security Groups and NACLs: Using a NACL to implement instance-level, stateful rules is inefficient and complex. Conversely, trying to block a specific IP across an entire subnet using only SGs requires modifying every instance's SG. Remember: SGs for instance-level protection (allow rules only); NACLs for subnet-level, coarse-grained allow/deny rules.
2. Overlooking Ephemeral Ports in NACLs: A classic failure scenario. Your web server in a private subnet receives a request on port 80 (inbound rule allowed). It sends its response back using a random ephemeral port (e.g., 1024-65535). If your NACL outbound rules only allow port 80, the response is blocked. Always ensure NACL outbound rules permit the ephemeral port range of the initiating client.
3. Choosing the Wrong VPC Endpoint Type: Attempting to create a Gateway Endpoint for AWS Lambda or an SQS queue will fail. Gateway endpoints are only for S3 and DynamoDB. For all other AWS services, you must provision an Interface Endpoint (powered by PrivateLink).
4. Ignoring Route Table Propagation in Multi-AZ Designs: When using a NAT Gateway or Virtual Private Gateway, you must ensure the route to these gateways (0.0.0.0/0 -> nat-gw-id) is present in the route tables of all private subnets across all AZs that require it. A subnet can only be associated with one route table at a time, so carefully plan your table associations.

Summary

• Plan your VPC CIDR meticulously to avoid conflicts, and design subnets with high availability in mind by spreading them across multiple Availability Zones, using route tables to control internet access via Internet Gateways or NAT Gateways.
• Security Groups are stateful, operate at the instance level, and are the primary tool for allowing traffic. **NACLs are stateless, operate at the subnet level, and are best for deny rules affecting entire subnets, requiring explicit rules for both inbound traffic and outbound responses.
• Use Gateway VPC Endpoints for private access to only S3 and DynamoDB. For all other AWS and partner services, use Interface VPC Endpoints, which leverage AWS PrivateLink for secure, private connectivity without internet traversal.
• PrivateLink is also the key technology for securely exposing your own services to other VPCs and accounts, eliminating the need for public endpoints or complex VPC peering meshes in hub-and-spoke or multi-account architectures.
• Always analyze exam scenarios by tracing the path of traffic: from subnet route tables, through NACL rules (inbound/outbound), to Security Group rules, ensuring every layer is correctly configured for the required isolation and connectivity.