Networking

Your EC2 instances in a private subnet need to reach S3 and a third-party API, but must never be reachable from the internet. Design the networking.

Outbound-only access comes from a NAT Gateway in a public subnet, but S3 traffic should skip it entirely through a VPC endpoint, which is free and never leaves the AWS network. Nothing can reach in because there's no route for it to take, not because a rule is blocking it, and that distinction is usually the real follow-up question.

Your application needs to feel fast for users spread across multiple continents. What would you put in front of it, and why?

Amazon CloudFront is a CDN that terminates connections and caches content at edge locations close to the user, so most requests never travel back to the origin region at all. It helps static content the most, but modern CloudFront also improves dynamic requests through TCP/TLS termination at the edge and origin connection reuse.

Design the subnets and routing for a standard three-tier web application: a public web layer, a private application layer, and a private database layer.

Three tiers, three subnet groups, each with a route table that only grants the access that tier actually needs. The database subnet shouldn't be able to reach the internet at all, the app subnet gets outbound-only through NAT, and only the web subnet has a real route to the internet gateway. Everything else follows from that one rule.

You have a dozen VPCs that all need to reach each other and a shared-services VPC. Would you use VPC Peering or Transit Gateway, and why?

Peering connects two VPCs directly and doesn't scale past a handful of them, since connections grow quadratically and traffic can't transit through a peered VPC to reach a third. Transit Gateway is a central routing hub that turns the same problem into one connection per VPC, and it's the right call anywhere past three or four VPCs.

How would you securely connect an on-premises data center to a VPC, and when would you reach for Direct Connect instead of a Site-to-Site VPN?

A Site-to-Site VPN is fast to set up, encrypted by default, and runs over the public internet, which is also its ceiling: bandwidth and latency aren't guaranteed. Direct Connect is a dedicated physical link with predictable performance, but it takes weeks to provision and isn't encrypted on its own. Most serious hybrid setups end up running both.

A subnet holds your most sensitive data. Design the Network ACL rules around it as a second layer of defense behind Security Groups.

A NACL earns its place by doing the one thing a Security Group can't: an explicit, subnet-wide deny that survives a misconfigured Security Group rule. The design is a default-deny rule set with narrow, numbered exceptions, remembering that NACLs are stateless, so return traffic on ephemeral ports needs its own explicit allow.

Two EC2 instances in the same VPC can't reach each other over a port that should be open. Walk through how you'd find out why.

Work outward from the instance rather than guessing at the network: confirm the app is actually listening, then check Security Groups, then NACLs, then the route table, then Flow Logs to see what AWS's own network actually did with the packet. Each layer either clears itself or points straight at the next thing to check.

Design layered protection for a public-facing web application against DDoS attacks and common web exploits.

No single AWS service handles both problems, since a volumetric DDoS attack and a targeted web exploit look nothing alike at the network layer. CloudFront and Shield absorb and dilute volume before it reaches your origin, and WAF inspects individual requests for exploit patterns. Both sit in front of the origin, stacked, not swapped for each other.