Top 50 AWS Networking and VPC Interview Questions 2026
AWS networking questions show up in almost every cloud loop: solutions architect, cloud engineer, DevOps, SRE, platform, security, and increasingly backend roles where the service you own lives in a private subnet behind a load balancer. The questions sound like trivia ("what is a NAT gateway?") but the interviewer rarely stops at the definition. They want to know whether you can trace a packet from an instance to the internet and back, name every hop, and say which hop is broken.
The 50 questions below escalate the way a real round does, from VPC and CIDR fundamentals through routing, security, private and hybrid connectivity, DNS and load balancing, to the "design or debug this" scenarios that live rounds are built on. Each answer gives the gotcha and the follow-up, because the follow-up is where the points are.
Practice alongside this post. The same ground is drilled as timed multiple-choice in the AWS question bank and the networking question bank; keep the networking essentials cheat sheet open for the subnetting and protocol material. If you are studying for a certification at the same time, the AWS Solutions Architect track and the Advanced Networking Specialty practice exam cover this ground in exam format. The free daily challenge gives you one question a day with no account needed, and the broader Top 50 AWS interview questions covers the rest of the platform.
Part 1: VPC and CIDR Fundamentals (1-8)
1. What is a VPC, and what does it actually isolate?
A Virtual Private Cloud is a logically isolated virtual network in one AWS Region. It spans every Availability Zone in that Region; subnets are what pin resources to a single AZ. A VPC gives you your own IP address space, route tables, gateways and security controls. Nothing gets in or out unless you attach something that allows it: an internet gateway, a NAT gateway, a VPN, a peering connection, an endpoint.
The follow-up is usually "is a VPC a security boundary?" It is a network boundary, not an identity boundary: a resource in a private subnet can still call AWS APIs if it has a path (NAT or endpoint) and IAM credentials. Good designs use both layers.
2. How big can a VPC be, and how do you choose its CIDR?
An IPv4 VPC CIDR must be between /16 (65,536 addresses) and /28 (16 addresses). AWS recommends RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
How to choose:
- Never overlap with on-premises networks, other VPCs you might ever connect, or partner networks. Overlap is the single most expensive networking mistake to undo (see question 45).
- Allocate from a plan, not ad hoc. Large organisations carve a
/8 or a few /12s into per-Region and per-environment blocks, ideally managed in Amazon VPC IP Address Manager (IPAM).
- Avoid
172.17.0.0/16. AWS documents that some services use it, and it is Docker's default bridge network.
- Size for growth. EKS with the VPC CNI gives every pod a VPC IP.
3. How many IP addresses can you use in a /24 subnet?
251, not 256. AWS reserves five addresses in every IPv4 subnet. For 10.0.0.0/24:
| Address | Reserved for |
|---|
10.0.0.0 | Network address |
10.0.0.1 | VPC router |
10.0.0.2 | Amazon DNS server (VPC base +2; each subnet's +2 is also reserved) |
10.0.0.3 | Reserved for future use |
10.0.0.255 | Broadcast (not supported in a VPC, so reserved) |
So a /28 gives you 11 usable addresses. Interviewers like this because it catches people who size subnets on paper and then wonder why a load balancer or an EKS node group cannot launch.
4. What makes a subnet "public" versus "private"?
Only its route table. A public subnet has a route to an internet gateway (usually 0.0.0.0/0 -> igw-...). A private subnet does not; its default route, if any, points at a NAT gateway, a transit gateway, or nothing.
"Public" is not a checkbox. The setting people confuse it with, "auto-assign public IPv4 address", only controls whether instances get a public IP. An instance needs both a public IP (or Elastic IP) and a route to an IGW to be reachable from the internet.
5. Walk me through a standard three-tier VPC layout.
A typical production VPC spans at least two, often three, Availability Zones with one subnet per tier per AZ:
- Public subnets (one per AZ): load balancers and, with zonal NAT gateways, the NAT gateways. Little else should live here.
- Private application subnets: EC2, ECS tasks, EKS nodes, Lambda ENIs. Default route to NAT for outbound, plus VPC endpoints.
- Private data subnets: RDS, ElastiCache, OpenSearch. Often no default route at all.
Security groups chain the tiers: the database SG allows the app SG, the app SG allows the load balancer SG. Why not one subnet per AZ? Because route tables are per subnet, and separate tiers are how you give the database no internet path at all.
6. Can you resize a VPC or a subnet after creation?
You cannot change an existing CIDR block, in either the VPC or a subnet. What you can do:
- Add secondary IPv4 CIDR blocks to the VPC (also
/16 to /28, non-overlapping, subject to a per-VPC quota). AWS adds a local route for each one automatically, then you create new subnets in the new range.
- Add IPv6 to the VPC and subnets for dual-stack.
- For subnets, the only option is create new, migrate, delete old.
A frequent EKS answer: when pods exhaust the primary range, add a secondary CIDR (often from 100.64.0.0/10) and use custom networking so pods draw from it.
7. What is the default VPC, and should production use it?
Every Region in an account has a default VPC with a /16 (172.31.0.0/16), a default subnet in each AZ, an internet gateway, and public IP auto-assignment on. It exists so a new user can launch an instance without thinking about networking.
Production should not use it. Every default VPC in every account has the same CIDR, so they can never be connected cleanly, and every subnet is public. Many organisations delete default VPCs in every Region through account-vending automation; real workloads go in a VPC from the IP plan.
8. What is VPC IPAM and why would you use it?
Amazon VPC IP Address Manager is a managed IP plan. You define a top-level pool (say 10.0.0.0/8), split it into Regional and environment pools, attach allocation rules (allowed netmask lengths, required tags), and share pools across the organisation with AWS RAM. When a team creates a VPC, it requests a CIDR from the pool instead of picking one, which is how you stop overlaps happening in the first place.
IPAM also flags overlapping or non-compliant CIDRs across accounts. It is the answer to "how do you stop 200 teams each picking 10.0.0.0/16?"
Part 2: Routing, Gateways and NAT (9-15)
9. How does a VPC route table decide where a packet goes?
By longest prefix match: the most specific route that contains the destination wins. Every route table has a local route for each VPC CIDR, which handles traffic inside the VPC.
| Destination | Target |
|---|
10.0.0.0/16 | local |
10.20.0.0/16 | tgw-0abc... |
pl-63a5400a (S3 prefix list) | vpce-0def... |
0.0.0.0/0 | nat-0123... |
A packet to 10.20.4.7 matches both 10.20.0.0/16 and 0.0.0.0/0; the /16 wins. Each subnet is associated with exactly one route table; a subnet with no explicit association uses the VPC's main route table. The gotcha: leaving the main route table with a route to an IGW means any new subnet someone creates without thinking is silently public. Keep the main table private and associate explicitly.
10. What does an internet gateway do?
An internet gateway is a horizontally scaled, highly available VPC component that routes internet traffic and performs one-to-one NAT between an instance's private IPv4 address and its public IPv4 address. No bandwidth to manage, no AZ, one per VPC. IPv6 needs no translation, which is why outbound-only IPv6 needs the egress-only internet gateway (question 15).
11. How does a NAT gateway work, and what are its limits?
A NAT gateway lets resources without public IPs start outbound connections while blocking unsolicited inbound ones. A public zonal NAT gateway sits in a public subnet with an Elastic IP; private subnets route 0.0.0.0/0 to it. Facts from the AWS docs:
- Supports TCP, UDP and ICMP. Starts at 5 Gbps of bandwidth and scales automatically to 100 Gbps; 1 million packets per second scaling to 10 million.
- Each IPv4 address supports up to 55,000 simultaneous connections to each unique destination (destination IP, port and protocol). Add secondary IPs (up to 8 per zonal NAT gateway) if you hit
ErrorPortAllocation.
- No security groups on a NAT gateway; filter with NACLs on its subnet.
- Private NAT gateways translate to a private IP for routing between networks - useful for overlapping CIDRs.
12. How should you design NAT gateways across Availability Zones, and what does that cost?
A zonal NAT gateway lives in one AZ. If every private subnet in three AZs routes to a single NAT gateway in AZ-a, then an AZ-a outage cuts internet access for all three AZs, and every packet from AZ-b and AZ-c crosses an AZ boundary, which costs inter-AZ data transfer on top of NAT processing.
The standard design is one NAT gateway per AZ, each AZ's route table pointing at its local NAT: more hourly charges, but AZ independence and in-zone traffic. NAT gateways bill per hour and per GB processed, and the per-GB charge is usually the surprise (question 46). In dev, one NAT gateway is a fair trade-off if everyone knows it is a single point of failure.
13. What is a regional NAT gateway?
A newer availability mode for NAT gateways. Instead of creating a zonal NAT gateway in a public subnet in each AZ and wiring per-AZ route tables, you create one NAT gateway with --availability-mode regional, pick the VPC, and it expands automatically into every AZ where you have workloads (and contracts when they leave).
aws ec2 create-nat-gateway --vpc-id vpc-12345678 --availability-mode regional
Per the AWS docs it needs no public subnet, ships with its own route table wired to the IGW, supports more IPs per AZ than a zonal NAT gateway, and runs in automatic or manual mode. Limits: no private NAT, and it can take up to 60 minutes to expand into a newly used AZ, with that traffic handled cross-zone meanwhile.
14. NAT gateway versus NAT instance?
| NAT gateway | NAT instance |
|---|
| Managed | Yes, AWS-operated | You patch, scale and fail it over |
| Availability | Redundant within its AZ (or regional mode) | Single instance unless you script failover |
| Bandwidth | Scales automatically to 100 Gbps | Limited by instance type |
| Security groups | Not supported | Supported |
| Source/dest check | N/A | Must be disabled |
NAT instances are legacy; the remaining reason is cost in tiny dev accounts.
15. How does outbound-only internet access work for IPv6?
With an egress-only internet gateway. Because IPv6 addresses are public, there is no NAT to hide behind. An egress-only IGW is stateful: instances can start outbound IPv6 connections and receive the replies, but the internet cannot start connections to them. You route ::/0 to it from private subnets.
For IPv6-only subnets that need to reach IPv4-only destinations, use DNS64 on the Route 53 Resolver plus NAT64 on a NAT gateway: DNS64 synthesises an address in 64:ff9b::/96 for IPv4-only names, the subnet routes that prefix to the NAT gateway, and the NAT gateway translates to IPv4.
Part 3: Security Groups, NACLs and Network Security (16-21)
16. Security groups versus network ACLs?
The single most-asked AWS networking question.
| Security group | Network ACL |
|---|
| Applies to | ENI (instance, task, endpoint, load balancer) | Subnet |
| State | Stateful: return traffic is allowed automatically | Stateless: return traffic must be explicitly allowed |
| Rules | Allow only | Allow and deny |
| Evaluation | All rules evaluated together | Numbered rules in ascending order; first match wins |
| Default (new) | No inbound, all outbound | Default NACL allows all; a custom NACL denies all until you add rules |
| Can reference | Other security groups, prefix lists | CIDRs only |
Security groups are the primary control. NACLs are a coarse subnet-level guardrail, mostly used for explicit denies.
17. What does "stateless" mean in practice for NACLs?
A NACL evaluates each packet independently, with no memory of the connection. If you allow inbound TCP 443 to a web subnet, the reply packets leave from port 443 to the client's ephemeral port, and the outbound NACL rules must allow that. Clients choose ephemeral ports from OS-dependent ranges (Linux commonly uses 32768-60999; AWS NAT gateways use 1024-65535), so the usual outbound rule allows TCP 1024-65535.
The classic bug: a NACL locked to "443 in, 443 out" makes connections hang because replies are dropped. Outbound calls likewise need inbound ephemeral ports allowed. Security groups never have this problem because they track connections.
18. Why reference a security group instead of a CIDR?
"Allow TCP 5432 from sg-app" means "from any ENI with sg-app attached", whatever its IP. Instances scale and IPs change, and the rule stays correct and documents intent.
Where referencing works: within a VPC, across VPC peering in the same Region, and across VPCs attached to the same transit gateway once you enable security group referencing on both the transit gateway and the attachments (inbound rules only). It does not work across transit gateway peering, for PrivateLink endpoints, or through Gateway Load Balancer or Network Firewall in an inspection VPC. The follow-up "how would you allow the app tier in another Region?" has the answer "a CIDR or a managed prefix list."
19. When would you actually use a NACL deny?
Use cases that security groups cannot express, because security groups have no deny:
- Blocking a specific abusive IP or range at the subnet edge quickly.
- Hard tier separation as a guardrail: the data subnets' NACL denies everything except the app subnets' CIDRs, so a misconfigured security group cannot open the database to the world.
- Compliance controls that require a subnet-level boundary independent of instance configuration.
Rules are evaluated lowest number first and the first match wins, so a deny needs a lower number than the allow it overrides; number in steps of 10 or 100. Every NACL ends with an unchangeable * deny. For blocking web traffic at scale, AWS WAF is usually the better tool.
20. What is VPC Block Public Access?
A Region-level, account-wide (or organisation-wide) control that blocks internet traffic through internet gateways and egress-only internet gateways, regardless of route tables and security groups. Two modes: bidirectional (block in and out) and ingress-only (block inbound from the internet, still allow outbound through NAT or egress-only IGW). You then create exclusions for the specific VPCs or subnets that should be public, in allow-bidirectional or allow-egress mode.
It is a preventive guardrail: a developer can attach an IGW and a public IP, and the traffic still does not flow. Mention it when asked "how do you stop accidental public exposure across 100 accounts?"
21. How do you inspect traffic between VPCs or to the internet?
Use AWS Network Firewall (managed stateful firewall, Suricata-compatible rules, domain lists) or a Gateway Load Balancer in front of third-party appliances (GENEVE on port 6081). The common architecture is a centralised inspection VPC on a transit gateway, with route tables forcing spoke-to-spoke and egress traffic through it. The gotcha: enable appliance mode on the inspection VPC's transit gateway attachment so both directions of a flow go through the same AZ's firewall. Without it, asymmetric routing breaks stateful inspection.
Part 4: VPC Endpoints and PrivateLink (22-25)
22. Gateway endpoints versus interface endpoints?
| Gateway endpoint | Interface endpoint (PrivateLink) |
|---|
| Services | S3 and DynamoDB only | Most AWS services, partner services, your own services |
| Mechanism | Route table entry pointing a prefix list at the endpoint | ENI with private IPs in your subnets |
| Cost | No additional charge | Per-hour per-AZ plus per-GB processed |
| Security groups | No (use endpoint policies) | Yes |
| Reachable from on-premises, peered VPCs, other TGW spokes | No | Yes |
| DNS | Uses the service's public names, routed privately | Private DNS names resolve to the endpoint's private IPs |
Rule of thumb: add the free S3 and DynamoDB gateway endpoints to every VPC with private subnets. Use interface endpoints for other services, or when callers outside the VPC (on-premises, other spokes) need access.
23. How do you lock an S3 bucket to traffic from your VPC endpoint?
Two layers. An endpoint policy on the VPC endpoint controls which buckets and actions callers in the VPC can reach through it - this is how you stop data exfiltration to someone else's bucket. A bucket policy with a condition restricts the bucket to requests arriving through your endpoint:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
"Condition": {
"StringNotEquals": { "aws:SourceVpce": "vpce-0abc1234" }
}
}
The gotcha: this also blocks console and admin access that does not come through the endpoint, so production versions add a break-glass exception on aws:PrincipalArn.
24. What does "private DNS" do on an interface endpoint?
With private DNS enabled, the service's normal public hostname (for example sqs.us-east-1.amazonaws.com) resolves inside the VPC to the interface endpoint's private IPs, through a Route 53 private hosted zone that AWS manages for you. Your code and SDKs change nothing; traffic just goes private.
It requires enableDnsSupport and enableDnsHostnames on the VPC. Hybrid gotcha: on-premises clients do not use the VPC resolver, so they need forwarding to a Resolver inbound endpoint (question 36). With centralised endpoints in a hub, you disable private DNS and associate your own private hosted zones with every spoke.
25. How would you expose your own service privately to other accounts?
Create a VPC endpoint service (AWS PrivateLink) in front of a Network Load Balancer. Consumers create interface endpoints to your service name; you allow their principals and can require acceptance. Why it is the right answer:
- Overlapping CIDRs do not matter. The consumer talks to an ENI in its own VPC; there is no routing between the two networks.
- One-directional. The consumer can reach your service; you cannot reach into their VPC.
- No peering mesh. Hundreds of consumers each get their own endpoint.
Trade-offs: it exposes one service, not a network, and consumers pay endpoint charges. PrivateLink now also supports cross-Region connectivity for endpoint services and selected AWS services, which used to need inter-Region peering as a workaround.
Part 5: Connecting VPCs and On-Premises (26-32)
26. What are the rules of VPC peering?
A peering connection is a one-to-one private route between two VPCs, same or different account, same or different Region. The rules interviewers expect:
- Not transitive. If A peers with B and B peers with C, A cannot reach C through B.
- No overlapping CIDRs between the two VPCs.
- No edge-to-edge routing. A cannot use B's internet gateway, NAT gateway, VPN or Direct Connect.
- Both sides must add routes to the peer's CIDR, and security groups must allow the traffic.
- No hourly charge for the connection; you pay data transfer.
At scale a full mesh needs n(n-1)/2 connections - 190 for 20 VPCs - which is why the follow-up is always Transit Gateway.
27. What is a Transit Gateway and how does it route?
A Transit Gateway is a Regional network hub. You attach VPCs, Site-to-Site VPNs, Direct Connect gateways, Connect attachments (GRE plus BGP for SD-WAN appliances) and peering connections to other transit gateways. Routing is controlled by transit gateway route tables:
- An attachment is associated with exactly one route table, which decides where traffic from that attachment can go.
- An attachment propagates its routes into one or more route tables, which advertises how to reach it.
Each VPC still needs subnet routes pointing at the transit gateway. Pricing is per attachment-hour plus per GB processed. To connect Regions, peer transit gateways or move to Cloud WAN.
28. Peering versus Transit Gateway versus Cloud WAN?
| VPC peering | Transit Gateway | Cloud WAN |
|---|
| Topology | Point to point | Hub and spoke, per Region | Global network, many Regions |
| Transitive routing | No | Yes | Yes |
| Scope | Two VPCs | One Region (peer TGWs across Regions) | Multi-Region by design |
| Segmentation | Per connection | Route tables | Segments defined in a core network policy |
| Cost | Data transfer only | Attachment hours + data processing | Core network edge hours, attachments + data processing |
| Fits | A few VPCs, highest throughput, lowest cost | Most single-Region multi-VPC estates | Global estates that want one policy for routing and segmentation |
A strong answer adds that they coexist: peering for a hot, high-volume pair of VPCs where TGW processing charges would hurt, TGW or Cloud WAN for everything else.
29. How do you segment environments on a Transit Gateway?
With multiple transit gateway route tables. A common pattern:
- Prod route table: associated with prod VPC attachments; contains propagated routes from prod VPCs and the shared-services VPC.
- Dev route table: associated with dev VPCs; propagations from dev and shared services only.
- Shared-services route table: propagations from every environment, so shared tooling (CI runners, DNS, directory) can reach all of them.
- On-premises route table: associated with the VPN or Direct Connect attachment.
Because prod never receives dev routes, dev cannot reach prod through the shared hub. Add blackhole routes for explicit denies. In Cloud WAN the same idea is expressed as segments.
30. How does AWS Site-to-Site VPN work, and how fast is it?
An IPsec connection between your customer gateway device and a virtual private gateway (one VPC), a transit gateway or Cloud WAN. Every connection has two tunnels in different AZs - configure both. Use BGP for automatic failover between them.
Bandwidth per AWS docs: standard tunnels support up to 1.25 Gbps each; large bandwidth tunnels support up to 5 Gbps each but only on transit gateway or Cloud WAN attachments. To go beyond one tunnel, use ECMP across multiple VPN connections on a transit gateway - a virtual private gateway does not do ECMP.
VPN rides the public internet, so it is the quick start or the backup; Direct Connect is the primary for heavy hybrid traffic.
31. What is Direct Connect, and how do you make it resilient?
Direct Connect is a private physical connection to an AWS Direct Connect location. Dedicated connections come in 1, 10, 100 and 400 Gbps port speeds; hosted connections from partners range from 50 Mbps to 25 Gbps.
You run virtual interfaces over it:
- Private VIF - to a virtual private gateway or a Direct Connect gateway, for VPC private IPs.
- Transit VIF - to a Direct Connect gateway associated with transit gateways.
- Public VIF - to AWS public endpoints (S3, DynamoDB public IPs and so on) without the internet.
Resilience: one connection is a single point of failure. AWS's guidance runs up to separate connections on separate devices in at least two locations; a cheaper pattern is Direct Connect primary with VPN backup, using BGP attributes so the VPN is only preferred when Direct Connect is down.
Gotcha: Direct Connect is private, not encrypted. Use MACsec where supported or run IPsec VPN over it.
32. What is VPC sharing with AWS RAM?
AWS Resource Access Manager lets a central networking account own a VPC and share its subnets with other accounts in the organisation. Participants launch their own resources into the shared subnets; the owner keeps the route tables, NACLs, gateways and endpoints. That means fewer VPCs to plan, connect and pay NAT and endpoint charges for, and a clean split: app teams own their resources, network teams own routing.
RAM also shares transit gateways, Resolver rules, IPAM pools and prefix lists. The trade-off: a shared VPC is a shared blast radius and quota, so most designs share per environment, not one VPC for everything.
Part 6: DNS, Load Balancing and the Edge (33-40)
33. What Route 53 routing policies exist, and when do you use each?
| Policy | Use it when |
|---|
| Simple | One resource, or several values returned in random order, no health checks |
| Weighted | Split traffic by ratio: canary releases, blue/green |
| Latency | Send users to the Region with the lowest measured latency |
| Failover | Active-passive: primary until its health check fails, then secondary |
| Geolocation | Route by user's continent, country or US state (compliance, localisation) |
| Geoproximity | Route by distance, with a bias to grow or shrink a Region's share |
| IP-based | Route by the client's source IP CIDR (for example, a specific ISP's users) |
| Multivalue answer | Return up to several healthy records; a simple form of client-side load balancing |
Follow-ups: geolocation needs a default record or unmatched users get no answer, and DNS TTLs plus resolver caching mean DNS failover is never instant.
34. Alias record versus CNAME?
A CNAME maps a name to another name and cannot exist at the zone apex (example.com), because the DNS standard does not allow a CNAME alongside the SOA and NS records there. A Route 53 alias record is a Route 53 extension that points a name, including the apex, at an AWS resource: a load balancer, CloudFront distribution, API Gateway, S3 website endpoint, VPC interface endpoint, or another record in the same zone.
Alias works at the apex, tracks the target's IPs automatically, supports "evaluate target health", and queries to alias records for AWS resources are not charged. Use a CNAME for non-AWS targets on a subdomain.
35. What is a private hosted zone?
A Route 53 hosted zone that answers only for queries from the VPCs associated with it. You use it for internal names like db.internal.example.com or for split-horizon DNS (the same name resolving to different answers inside and outside).
It can be associated with VPCs in other accounts (authorise from the zone's account, associate from the VPC's account). If a private and a public zone both match a name, VPC clients get the private answer, and if the private zone has no record for that exact name, the query does not fall back to the public zone - a common "why does api.example.com return NXDOMAIN inside the VPC?" bug.
36. How do you do hybrid DNS between AWS and on-premises?
With Route 53 Resolver endpoints and rules:
- Inbound endpoint: ENIs in your VPC that on-premises DNS servers forward to, so on-premises clients can resolve private hosted zones and interface endpoint private DNS names.
- Outbound endpoint plus forwarding rules: the VPC resolver forwards queries for, say,
corp.example.com through the outbound endpoint to on-premises DNS servers.
Use at least two AZs. In multi-account estates, build the endpoints once in a shared-services VPC and share the forwarding rules with AWS RAM. Resolver DNS Firewall adds a cheap exfiltration control by blocking unapproved domains.
37. What are the Elastic Load Balancing types?
| ALB | NLB | GWLB | CLB |
|---|
| Layer | 7 (HTTP/HTTPS, gRPC, WebSocket) | 4 (TCP, UDP, TLS) | 3 (IP packets via GENEVE) | 4/7, legacy |
| Routing | Host, path, header, query string, method | Port | Flow hash to appliances | Basic |
| Targets | Instance, IP, Lambda | Instance, IP, ALB | Instance, IP (appliances) | Instance |
| Static IP | No | Yes, one per AZ (Elastic IP optional) | N/A | No |
| Client IP | X-Forwarded-For header | Preserved (configurable), or proxy protocol v2 | Preserved | X-Forwarded-For |
| Typical use | Web apps, microservices | Extreme throughput, non-HTTP, static IPs, PrivateLink | Firewalls and inspection | Do not use for new work |
Pick ALB unless you need what it cannot do: non-HTTP protocols, static IPs, PrivateLink.
38. What changed with security groups on NLBs, and why does it matter?
Network Load Balancers historically had no security groups; targets had to allow the client CIDRs directly, because the NLB preserves client IPs. NLBs now support security groups, which lets you allow the internet (or specific CIDRs) on the NLB and then allow only the NLB's security group on the targets.
Gotcha from the AWS docs: an NLB created without security groups cannot have one added later; you must replace it. In infrastructure-as-code, always create NLBs with at least one security group so you keep the option.
39. How does CloudFront fit into a VPC design?
CloudFront is the CDN at the front: TLS at the edge, caching, WAF and Shield integration, and origin connections over the AWS network. Two design questions follow:
- How do you stop users bypassing CloudFront? For S3, use Origin Access Control and a bucket policy that only allows the distribution. For a load balancer, the modern answer is CloudFront VPC origins, which let CloudFront reach an ALB, NLB or EC2 instance in a private subnet, so the origin has no public exposure at all. The older pattern is a public ALB that allows only the CloudFront managed prefix list plus a secret header.
- What is cached? The cache key (path plus whichever headers, cookies and query strings you include) sets the hit ratio; too much in the key is the usual reason for a poor one.
40. CloudFront versus Global Accelerator?
| CloudFront | Global Accelerator |
|---|
| Protocols | HTTP and HTTPS (WebSocket too) | Any TCP or UDP |
| Caching | Yes | No |
| Entry point | DNS name, many edge IPs | Two static anycast IPv4 addresses |
| Failover | Origin groups for failover | Health-check-based shift between Regional endpoints in seconds, no DNS TTL |
| Typical use | Websites, APIs, video, static assets | Gaming, VoIP, IoT, non-HTTP, clients that need allow-listed static IPs |
If a customer must allow-list your IPs, the answer is Global Accelerator (or an NLB with Elastic IPs).
Part 7: Observability and IPv6 (41-43)
41. What do VPC Flow Logs capture, and what do they miss?
Flow Logs record metadata about IP traffic on ENIs, subnets or VPCs: addresses, ports, protocol, packets, bytes, time window and ACCEPT or REJECT, delivered to CloudWatch Logs, S3 or Data Firehose. Custom formats add fields such as tcp-flags, flow-direction and pkt-srcaddr / pkt-dstaddr (packet-level addresses, useful for traffic through a NAT gateway).
2 123456789012 eni-0a1b2c3d 10.0.1.25 10.0.2.40 49152 5432 6 10 840 1700000000 1700000060 REJECT OK
What they do not capture: packet contents (use Traffic Mirroring), traffic to the Amazon DNS server, instance metadata (169.254.169.254), Amazon Time Sync, DHCP, and Windows license activation traffic. And a REJECT does not say whether a security group or a NACL dropped it; a rejected return packet usually points at a NACL.
42. Reachability Analyzer versus Network Access Analyzer?
- Reachability Analyzer answers "can A reach B, and if not, why?" It analyses configuration - route tables, security groups, NACLs, gateways, peering, transit gateway routes - and returns the hop-by-hop path or the component that blocks it. It sends no packets, so it is safe in production.
- Network Access Analyzer answers "what paths exist that should not?" You define scopes such as "nothing in the data subnets reachable from an internet gateway", and it finds every path that violates them.
Reachability Analyzer's limit: it reads configuration, so it will not catch an OS firewall or an app listening on the wrong port.
43. What is your IPv6 strategy on AWS, and why does it matter in 2026?
Two drivers. First, AWS charges for all public IPv4 addresses, including ones auto-assigned to running instances and in-use Elastic IPs, not just idle ones; at fleet scale that is a visible line item. Second, private IPv4 exhaustion in big estates, especially with EKS pod IPs.
A practical answer: go dual-stack first (an IPv6 /56 on the VPC, a /64 per subnet, IPv6 rules in security groups and NACLs, ::/0 to an IGW or egress-only IGW); make load balancers dual-stack so targets can stay IPv4; use IPv6-only subnets for new workloads, with DNS64 and NAT64 for IPv4-only dependencies; and hunt down unneeded public IPv4 addresses.
The gotcha: many teams add IPv6 to subnets and forget the security groups, so IPv6 clients time out while IPv4 works.
Part 8: Design and Debug Scenarios (44-50)
44. "An EC2 instance in a private subnet can't reach the internet." Walk me through it.
Trace the packet out and back, hop by hop:
- DNS: does
dig example.com resolve? A resolution failure looks like a network failure.
- Instance: OS firewall, proxy settings, and has someone tightened the security group's outbound rules?
- Subnet route table: is there
0.0.0.0/0 -> nat-...? Is the subnet associated with the table you think, or silently with the main table?
- NAT gateway: state
available? In a public subnet? Does the NAT's subnet route table have 0.0.0.0/0 -> igw-...? This is the most-missed hop.
- NACLs on both the private subnet and the NAT subnet: outbound allowed, and inbound ephemeral ports allowed for replies.
- Guardrails: VPC Block Public Access, a Network Firewall rule, or a transit gateway route that sends
0.0.0.0/0 to an inspection VPC.
- Prove it: run Reachability Analyzer from the instance ENI to the IGW, and check Flow Logs for
REJECTs and NAT gateway ErrorPortAllocation or PacketsDropCount metrics.
If the instance is in a public subnet instead, the usual cause is that it has no public IP or Elastic IP.
45. "We acquired a company and their VPCs overlap ours (both 10.0.0.0/16). How do we connect them?"
Overlapping CIDRs cannot be routed directly; peering refuses them. Options, from least to most effort:
- PrivateLink for the specific services that need to talk. The consumer reaches an endpoint ENI in its own VPC, so overlap is irrelevant. Best when integration is a handful of APIs.
- Private NAT gateways: give each side a small non-overlapping "routable" secondary CIDR, put a private NAT gateway there, and route through a transit gateway. It works, but it is one-directional per NAT and complicates troubleshooting.
- Re-IP: migrate the acquired workloads into new VPCs carved from your IPAM plan. Slow, but the only option that removes the problem permanently.
A strong answer picks by integration depth ("PrivateLink now for the three day-one APIs, re-IP the rest") and puts their accounts under your IPAM.
46. "Our NAT gateway bill doubled. What do you look at?"
- Who is sending the bytes? NAT gateway byte metrics plus Flow Logs aggregated by destination.
- AWS service traffic through NAT is the usual culprit: S3, DynamoDB, ECR image pulls, CloudWatch Logs. Add the free gateway endpoints, and interface endpoints where they cost less than the NAT processing they remove.
- Cross-AZ traffic to a NAT gateway in another AZ pays inter-AZ transfer on top.
- Behaviour changes: images pulled on every task start, debug logging, a job downloading a dataset hourly.
Then alarm on NAT bytes, so the next spike is a page, not a bill.
47. "Two peered VPCs can't talk to each other." What do you check?
- Peering state is active, not pending acceptance in the other account.
- Routes on both sides to the peer CIDR via
pcx-.... A missing return route is the classic cause.
- Security groups on the destination allow the source CIDR (or the peer SG, if same Region).
- NACLs on both subnets, including ephemeral ports.
- DNS: enable DNS resolution over the peering, and associate private hosted zones with both VPCs.
- Transitive assumption: are they really trying to reach a third network through the peer? That never works.
48. "On-premises users can't resolve our internal AWS service names." Diagnose it.
On-premises DNS servers do not use the VPC resolver, so they know nothing about private hosted zones. Check, in order:
- Is there a Route 53 Resolver inbound endpoint, in at least two AZs, in a VPC associated with the private hosted zone?
- Do on-premises DNS servers have a conditional forwarder for the zone (for example
internal.example.com or sqs.us-east-1.amazonaws.com) pointing at the inbound endpoint IPs?
- Network path: UDP and TCP 53 allowed through Direct Connect or VPN routes, the endpoint's security group, and NACLs. UDP-only rules cause intermittent failures on large responses.
- Is the private hosted zone associated with the VPC that hosts the inbound endpoint?
Test with dig @<inbound-endpoint-ip> name from on-premises to split "forwarding is wrong" from "the zone is wrong".
49. "Our ALB returns 502s and 504s intermittently." Where do you look?
- 502 Bad Gateway: the target responded badly - closed the connection, sent a malformed response, or a Lambda target errored. A frequent cause is a target keep-alive timeout shorter than the ALB's idle timeout, so the target closes a connection the ALB reuses.
- 504 Gateway Timeout: the target did not respond within the idle timeout, or the ALB could not connect. Check the target security group allows the ALB's, target saturation, and slow downstream calls.
Evidence: ALB access logs (elb_status_code, target_status_code, target_processing_time), HTTPCode_ELB_5XX_Count versus HTTPCode_Target_5XX_Count, and whether errors cluster in one AZ.
50. "Design the network for an organisation with 60 AWS accounts, two Regions and a data center."
A good answer covers each layer and says why:
- IP plan: VPC IPAM with a top-level pool split per Region and environment; no overlap with the data center; every VPC allocated from the pool.
- Account structure: a network account owns the transit gateways (or Cloud WAN core network), Direct Connect, Resolver endpoints and shared VPCs, shared out with AWS RAM.
- Connectivity: a transit gateway per Region with route tables for prod, non-prod, shared services and on-premises; transit gateway peering between Regions, or Cloud WAN with segments if the estate is growing to more Regions.
- Hybrid: Direct Connect at two locations with transit VIFs to a Direct Connect gateway, VPN as backup over BGP; MACsec or IPsec if encryption in transit is required.
- Egress and inspection: centralised egress VPC with NAT gateways and Network Firewall, appliance mode on the attachment; VPC Block Public Access with explicit exclusions.
- Private access and DNS: gateway endpoints everywhere; centralised interface endpoints and Resolver endpoints in shared services, with private hosted zones and forwarding rules shared to spokes.
- Observability: Flow Logs to a central log archive account; Network Access Analyzer scopes as guardrail checks.
Finish with the trade-off: centralised egress saves NAT and endpoint costs but adds transit gateway processing charges and a shared blast radius. Naming it is what separates a senior answer from a diagram.
How to practice for an AWS networking interview
- Build it once by hand. A two-AZ VPC with public and private subnets, NAT, an S3 gateway endpoint and an ALB - then break each piece on purpose and fix it.
- Then build it as code, so you can tear it down and the NAT gateway stops billing overnight.
- Narrate the packet path. ENI, security group, NACL, route table, gateway, return path. Interviewers score the narration as much as the answer.
- Do subnet math without a calculator. Usable IPs in a
/26, how many /24s fit in a /20, whether two ranges overlap.
- Know the costs. NAT processing, transit gateway attachments, interface endpoints, cross-AZ transfer and public IPv4 are what senior questions turn on.
- Timebox scenarios to ten minutes, ending with what you would check next if your first guess were wrong.
Keep going
- Drill it under pressure: the AWS, networking and cloud architecture question banks, plus the free daily challenge.
- Keep the references open: the networking essentials cheat sheet and the AWS CLI cheat sheet.
- Follow a track: AWS Solutions Architect or cloud architect prep. For certification, the Advanced Networking Specialty goes deepest, and the Solutions Architect Associate practice exam is the usual first step.
- Go deeper: the DNS system and load balancer internals walkthroughs explain what Route 53 and ELB do under the hood.
- Round out the loop: Top 50 AWS, Terraform, Kubernetes, DevOps and system design interview questions.
- Practise the follow-ups: the chat-based AI mock interview asks the "and what if that AZ goes down?" questions a real round runs on.
- Related guides: Top 50 Solutions Architect Interview Questions 2026, Top 40 AWS CDK Interview Questions 2026, Top 50 AWS Lambda and Serverless Interview Questions 2026.
#aws #networking #vpc #cloud #interviews #solutionsarchitect #career