20 Amazon AWS Network Interview Questions: What Architects Are Really Asked
AWS networking interviews at the senior or architect level go well beyond knowing what a VPC is or that a Security Group is stateful. Interviewers are testing whether you understand the networking primitives that underpin every AWS deployment — how traffic actually flows, where isolation boundaries sit, how hybrid connectivity is designed for resilience, and which network control is enforced at which layer of the stack.
This guide covers the 20 most important network-centric AWS interview questions — from VPC fundamentals and Transit Gateway to Direct Connect, Route 53, PrivateLink, and hybrid design — each answered with the architectural reasoning that separates strong candidates from the rest.
① VPC Architecture & Subnet Design
Q1
What are the key constraints when designing a large-scale AWS VPC for an enterprise workload across multiple Availability Zones?
The most critical constraint is non-overlapping CIDR blocks across all VPCs that will ever need to be peered or connected via Transit Gateway. Overlapping address space cannot be resolved after VPC peering is established — always allocate from a dedicated corporate supernet before creating any VPCs. AWS reserves five IP addresses per subnet (first four and last), so a /24 yields only 251 usable addresses — a fact that trips up sizing calculations in interviews. Design with at least three subnets per tier (public, private, data) spread across three AZs minimum for production workloads. Each AZ should be independently functional — a loss of one AZ must not require cross-AZ traffic for core workloads. The secondary constraint is the VPC CIDR size limit — a VPC supports a minimum /28 and maximum /16. For large enterprises planning hundreds of subnets, a /16 per region fills quickly; plan secondary CIDR associations (each VPC supports up to five associated CIDRs) into your IP address management strategy from day one.
Q2
What is the difference between a Public Subnet and a Private Subnet in AWS, and how does the Internet Gateway enable outbound connectivity?
A Public Subnet has a route table entry pointing 0.0.0.0/0 to an Internet Gateway (IGW), allowing resources with a public IP or Elastic IP to communicate directly with the internet. A Private Subnet has no IGW route — its default route points to a NAT Gateway (for outbound-only internet) or remains internal-only. The Internet Gateway performs a 1:1 NAT between an instance's Elastic IP and its private IP — the EC2 instance itself never sees the public IP in its network configuration, only the private IP. A common interview trap: the IGW is not the device that needs to be in the path for inbound traffic to private instances — that requires a load balancer or NAT in a public subnet forwarding to the private instance. The IGW is highly available and scales automatically — it is not a bandwidth bottleneck, but VPC flow logs should be enabled on the IGW for traffic visibility.
Q3
What is VPC Peering and what are its key limitations compared to Transit Gateway?
VPC Peering creates a direct private connection between two VPCs — traffic stays on the AWS backbone without traversing the public internet. The most important limitation is that peering is non-transitive: if VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. Each pair requires its own peering connection. This creates an O(n²) mesh problem at scale — 50 VPCs require 1,225 peering connections. Transit Gateway solves this by acting as a regional hub where all VPCs attach and routing is managed centrally. The second limitation is that peered VPCs cannot have overlapping CIDR blocks. Choose VPC Peering for simple two-VPC connectivity or when cross-account private DNS resolution is the primary requirement. Choose Transit Gateway for any multi-VPC topology, centralized inspection, or hybrid connectivity aggregation.
② Security Groups, NACLs & Network Controls
| # | Question | Architect-Level Answer |
|---|---|---|
| Q4 | What is the difference between a Security Group and a Network ACL, and when do you need both? | Security Groups are stateful, instance-level firewalls — return traffic is automatically permitted without an explicit outbound rule. They support allow rules only and are evaluated at the ENI level. NACLs are stateless, subnet-level filters — you must explicitly allow both inbound and outbound directions for every flow, including ephemeral ports (1024–65535) for return traffic. NACLs are evaluated before traffic reaches an instance and support both allow and deny rules in numbered order. Use Security Groups as your primary access control layer for all instance-to-instance policy. Add NACLs as a subnet-level defense layer to block known malicious IP ranges or enforce compliance boundaries between subnet tiers — the combination creates defense-in-depth. |
| Q5 | How do Security Group references work and why are they more scalable than CIDR-based rules? | Instead of specifying a CIDR range in a Security Group rule, you reference another Security Group ID as the source or destination. This means "allow traffic from any ENI that belongs to Security Group sg-0abc123." When instances are added to or removed from the referenced group, the rule automatically applies to them without any manual rule updates. This is dramatically more scalable than CIDR-based rules in dynamic environments where instance IPs change — such as Auto Scaling groups or ECS container deployments. A three-tier application (web, app, DB) should use SG references: the DB tier's SG allows inbound on port 5432 from the app tier's SG ID only — independent of any IP addresses. |
| Q6 | What is AWS Network Firewall and how does it differ from a Security Group? | AWS Network Firewall is a managed, stateful L4–L7 firewall deployed in a dedicated firewall subnet — it provides deep packet inspection, IPS/IDS with Suricata-compatible rule groups, TLS inspection, domain-based filtering, and centralized logging. Security Groups are L3/L4 instance-level controls with no application-layer inspection. Network Firewall sits in the traffic path via Gateway Load Balancer or VPC route table steering — typically in a centralized inspection VPC attached to Transit Gateway. Use Security Groups for all instance-level microsegmentation. Use Network Firewall for north-south internet traffic inspection, east-west lateral movement detection between VPCs, or when compliance requires stateful L7 logging across all flows. |
③ Transit Gateway & Centralised Routing
Q7
How does Transit Gateway route traffic between VPCs and what are Transit Gateway Route Tables used for?
Transit Gateway (TGW) acts as a regional hub router — VPCs, VPNs, and Direct Connect gateways attach to it as attachments. Each attachment is associated with a TGW Route Table that controls which destinations the attachment can reach. By default, all attachments share a single route table and full any-to-any routing is enabled. The power of TGW Route Tables is segmentation — you can create multiple route tables and associate different attachments to different tables, creating isolated routing domains. For example: production VPCs associate to the prod route table (which propagates only prod VPC routes), and shared services VPCs are added to both tables so all VPCs can reach shared services but prod and dev cannot route to each other. This achieves network segmentation without VPC Peering mesh complexity and without a separate Transit VPC architecture.
Q8
How do you force all VPC-to-VPC traffic through a centralised firewall using Transit Gateway?
Deploy a dedicated Inspection VPC with AWS Network Firewall or a third-party NVA. Attach the Inspection VPC to Transit Gateway. Configure the TGW Route Tables so that traffic from VPC-A destined for VPC-B is sent to the Inspection VPC first — not directly to VPC-B. This requires a spoke route table with a default route (0.0.0.0/0) pointing to the Inspection VPC attachment, and a firewall route table with specific routes pointing back to each spoke VPC attachment. The Inspection VPC uses a Gateway Load Balancer to transparently forward traffic through the firewall appliance and return it to the TGW for final delivery. The critical operational concern is asymmetric routing — ensure inbound and outbound flows for the same session traverse the same firewall instance, or use Gateway Load Balancer's flow-stickiness feature to guarantee session symmetry.
④ Direct Connect & Hybrid Connectivity
| # | Question | Architect-Level Answer |
|---|---|---|
| Q9 | What are the three Direct Connect virtual interface types and when is each used? | Private VIF connects on-premises directly to a single VPC via a Virtual Private Gateway — used when all traffic targets a specific VPC. Public VIF connects on-premises to all AWS public endpoints (S3, DynamoDB, API Gateway) over private routing — traffic does not traverse the internet but reaches public AWS service IPs. Transit VIF connects on-premises to a Direct Connect Gateway which then connects to one or more Transit Gateways — the correct choice for enterprises with multiple VPCs across multiple regions, as a single DX connection can reach hundreds of VPCs. Always use Transit VIF in enterprise designs — Private VIF requires one VIF per VPC and does not scale. |
| Q10 | How do you design Direct Connect for high availability and what does a dual-location, active-active design look like? | A single DX circuit has two physical ports at the same DX location — a location failure takes both down. True HA requires two circuits from two separate DX locations, each connected to the same Direct Connect Gateway and Transit Gateway. Use BGP AS Path prepending or community tags to prefer one circuit as primary and the other as standby, or allow both to be active for load sharing. For mission-critical designs, combine a primary DX circuit with a Site-to-Site VPN as backup — VPN activates automatically when BGP routes from DX are withdrawn. The VGW/TGW prefers DX routes over VPN routes by default when both are advertised. Always use Hosted Connections or Dedicated Connections at 10 Gbps+ for enterprise traffic — 1 Gbps shared Hosted Connections are insufficient for bulk data migration or DR failover scenarios. |
| Q11 | What is the difference between a Site-to-Site VPN and Direct Connect for hybrid connectivity? | Site-to-Site VPN uses IPsec tunnels over the public internet — it is encrypted, quickly deployable (minutes), and costs significantly less than DX. Its limitations are variable latency (internet-dependent), bandwidth cap of 1.25 Gbps per tunnel, and no SLA on path quality. Direct Connect is a dedicated private connection with consistent sub-10ms latency, bandwidth options up to 100 Gbps, and no data traversing the public internet — but it requires weeks or months to provision and carries significantly higher monthly costs. Use VPN for: backup paths, development environments, quick connectivity, or sites with low bandwidth requirements. Use Direct Connect for: production hybrid workloads, bulk data transfer, latency-sensitive applications, compliance requirements prohibiting internet transit, and any workload where network performance directly impacts business outcomes. |
⑤ Route 53, PrivateLink & VPC Endpoints
Q12
How do you design DNS resolution for AWS Private Endpoints so both VPC resources and on-premises clients resolve the private IP?
When an Interface VPC Endpoint is created for an AWS service (e.g. S3, Secrets Manager), AWS creates private DNS entries in a Route 53 Private Hosted Zone linked to the VPC — EC2 instances in that VPC automatically resolve the service endpoint to the private ENI IP. The challenge is on-premises clients using corporate DNS — they have no knowledge of the Route 53 Private Hosted Zone. The solution is a Route 53 Resolver with an Inbound Endpoint in the VPC: on-premises DNS conditionally forwards the *.amazonaws.com domain to the Resolver Inbound Endpoint IP. Route 53 Resolver returns the private ENI IP, ensuring on-premises clients reach the service privately via Direct Connect or VPN rather than over the public internet.
Q13
What is the difference between a Gateway VPC Endpoint and an Interface VPC Endpoint?
Gateway Endpoints are available only for S3 and DynamoDB — they are free, add a route in the VPC route table pointing the service prefix list to the gateway endpoint, and do not create an ENI. Traffic is redirected at the route table level and does not leave the AWS network. Interface Endpoints (PrivateLink) create an Elastic Network Interface with a private IP in your subnet for any supported AWS service or third-party SaaS — they support private DNS, are accessible from on-premises via Direct Connect, and are available for 100+ AWS services. Interface Endpoints incur hourly and data processing charges. The design decision: always use Gateway Endpoints for S3 and DynamoDB (free, no latency penalty). Use Interface Endpoints for all other services where private access is required, especially when on-premises connectivity to PaaS services is needed.
Q14
How does Route 53 Resolver support split-horizon DNS in a hybrid AWS environment?
Split-horizon DNS allows the same domain name to resolve to different IPs depending on the query source. In AWS, this is achieved by creating a Private Hosted Zone in Route 53 for an internal domain (e.g. app.corp.internal) with private IP records, and associating it with specific VPCs. Queries from within those VPCs resolve to private IPs. Queries from outside those VPCs — including the public internet — resolve to public IPs via the public hosted zone. Route 53 Resolver Outbound Endpoints enable VPC resources to query on-premises DNS for corporate domain resolution, while Inbound Endpoints allow on-premises systems to query Route 53 Private Hosted Zones. This bidirectional resolver architecture is the foundation of all enterprise hybrid DNS designs on AWS.
⑥ Load Balancing, Flow Logs & Network Monitoring
| # | Question | Architect-Level Answer |
|---|---|---|
| Q15 | What is the difference between ALB, NLB, and GWLB — when do you use each? | Application Load Balancer (ALB) operates at L7 — HTTP/HTTPS with host-based and path-based routing, WAF integration, sticky sessions, and WebSocket support. Use for all web application traffic requiring URL-based routing. Network Load Balancer (NLB) operates at L4 — TCP/UDP/TLS with ultra-low latency, static IP support, and the ability to preserve the client source IP. Use for non-HTTP workloads, high-throughput TCP/UDP services, or when a static IP address is required for whitelisting. Gateway Load Balancer (GWLB) operates at L3 — it transparently passes all traffic through third-party virtual appliances (firewalls, IDS/IPS) using the GENEVE protocol. Use for centralised inline traffic inspection in security architectures. A key interview point: NLB supports Elastic IPs on each AZ, making it the only AWS load balancer type with a static, predictable IP — critical for financial services firewall whitelisting requirements. |
| Q16 | What do VPC Flow Logs capture and what do they not capture? | VPC Flow Logs capture accepted and rejected IP traffic at the ENI, subnet, or VPC level — recording source IP, destination IP, ports, protocol, packet count, byte count, start/end time, and accept/reject action. They are essential for security analysis, compliance auditing, and troubleshooting connectivity issues. What they do not capture: DNS queries (use Route 53 Resolver query logging), application payload content, traffic to instance metadata service (169.254.169.254), Amazon DNS server traffic (169.254.169.253), DHCP traffic, and Windows license activation traffic. Flow logs have a delivery delay of several minutes — they are not a real-time packet capture tool. For real-time analysis, use Traffic Mirroring to replicate packets to a monitoring instance running an IDS or packet analyser. |
| Q17 | How do you troubleshoot a connectivity issue between two EC2 instances in different VPCs connected via Transit Gateway? | Use a structured approach: first verify the TGW route tables — confirm both VPC attachments are associated to a route table that propagates or has static routes for each other's CIDR. Second, check the VPC route tables in each VPC — the subnet route table must have a route pointing the destination CIDR to the TGW attachment ID. Third, verify Security Groups on both instances allow the required ports. Fourth, check NACLs for both subnets — remember NACLs are stateless and ephemeral ports (1024-65535) must be explicitly allowed for return traffic. Use VPC Reachability Analyzer to automatically trace the path and identify the specific blocking element — it produces a hop-by-hop analysis without sending actual traffic. |
| Q18 | What is AWS Global Accelerator and how does it differ from CloudFront for global application delivery? | AWS Global Accelerator provides two static Anycast IP addresses that route user traffic through the AWS global network to the nearest healthy endpoint (ALB, NLB, EC2, or Elastic IP) — it improves TCP/UDP latency by entering the AWS backbone as close to the user as possible rather than traversing the public internet. It supports non-HTTP protocols (TCP, UDP) and provides instant failover between regions. CloudFront is a content delivery network that caches HTTP/HTTPS content at 450+ edge locations worldwide — ideal for static assets, video streaming, and cacheable API responses. Choose Global Accelerator for dynamic, non-cacheable traffic requiring consistent low latency and deterministic IP addresses (gaming, VoIP, real-time APIs). Choose CloudFront when content caching reduces origin load and improves response times for static or semi-static workloads. |
| Q19 | What is AWS PrivateLink and how does it enable secure SaaS service consumption without VPC Peering? | AWS PrivateLink exposes a service from a provider VPC to consumer VPCs via an Interface VPC Endpoint — without peering the VPCs or exposing any part of the provider's network. The provider creates a VPC Endpoint Service backed by a Network Load Balancer. Consumers create an Interface Endpoint in their VPC, which provisions an ENI with a private IP. Traffic flows from the consumer ENI through AWS's internal fabric to the provider NLB — entirely within the AWS network, with no route table overlap concerns and no risk of the consumer accessing any resource in the provider VPC beyond the exposed service. This is the architectural pattern used by all AWS managed services, third-party SaaS providers on AWS Marketplace, and internal platform teams sharing microservices across VPC boundaries without full network peering. |
Q20 — The Architect Closer
A financial services company has 40 AWS accounts across 3 regions, needs private connectivity from their data centre, wants all outbound internet traffic inspected, and must prevent any two business units from routing to each other. Design the full network architecture.
Foundation — AWS Organizations & Network Account: Create a dedicated Network Services account. Deploy a Transit Gateway per region. Use AWS RAM to share TGWs across all 40 accounts. Segmentation: Create separate TGW Route Tables per business unit — BU-A's VPCs associate to TGW-RT-BUA and only see routes for BU-A VPCs and Shared Services. BU-A and BU-B route tables have no routes to each other — enforcing hard network isolation. Centralised inspection: Deploy an Inspection VPC in the Network account with AWS Network Firewall. Route all egress traffic from spoke VPCs to TGW, then to Inspection VPC, then to a NAT Gateway with an Elastic IP. All east-west inter-VPC traffic routes through Network Firewall for L7 inspection. Hybrid connectivity: Two Direct Connect circuits from two separate DX locations, both using Transit VIFs to a Direct Connect Gateway attached to all three regional TGWs — single DX connection reaches all 40 accounts. VPN backup on TGW for circuit failover. DNS: Central Route 53 Resolver in Network account with Inbound Endpoints shared via RAM — all on-premises conditional forwarding targets the shared resolver. Private Hosted Zones associated with all VPCs via Resource Access Manager.
Key Principles to State in Any AWS Network Interview
| VPC Peering is non-transitive | Use Transit Gateway for any multi-VPC topology at scale |
| Security Groups are stateful | NACLs are stateless — always allow ephemeral ports for return traffic |
| Gateway Endpoint = free for S3/DDB | Interface Endpoint = PrivateLink with ENI, supports on-premises access |
| Plan IP space before VPCs | Overlapping CIDRs cannot be peered or connected via TGW |
| NLB for static IP requirement | Only AWS LB type with Elastic IP — essential for firewall whitelisting |
Approaching the AWS Network Interview
The 20 questions above share one consistent pattern: every answer requires understanding the boundary between one AWS networking construct and the next — when a Security Group is the right tool versus a NACL, when VPC Peering is sufficient versus Transit Gateway, when Direct Connect is justified versus VPN. AWS gives you many ways to solve each problem; interviewers are listening for whether you know the trade-offs.
Lead with the constraint that drives the design choice. Name the alternative you did not choose and why. State what you give up with each approach. That architectural reasoning — more than any console screenshot or CloudFormation template — defines an AWS network architect in every interview room.
AWS networking services and pricing evolve frequently. Always validate design decisions against current AWS documentation and Well-Architected Framework guidance for your target region and compliance requirements.
