AWS VPC Interview Questions for DevOps Engineers: 20 Questions You Must Know Before Your Next Interview 🚀
AWS VPC Interview Questions for DevOps Engineers: 20 Questions You Must Know Before Your Next Interview 🚀
If you are preparing for a DevOps Engineer interview, there is one AWS topic you cannot afford to learn through definitions alone: Amazon VPC (Virtual Private Cloud).
You might know how to launch an EC2 instance, create a subnet, or configure a security group. But what happens when an application running in a private subnet cannot download packages? Why can one EC2 instance connect to another while a different instance cannot? Why does an application suddenly stop responding after someone changes a route table?
These are the questions that separate someone who has memorized AWS services from an engineer who can troubleshoot production infrastructure.
In real-world DevOps, networking is not just about making resources communicate. It is about controlling access, isolating workloads, designing for high availability, reducing unnecessary exposure, and diagnosing failures without making the incident worse.
In this guide, we will cover 20 AWS VPC interview questions using a practical, interview-focused approach:
🧠 Simple Concept
❓ Why Do We Need It?
⚙️ How Does It Work?
🏢 Production Example
💻 Commands or Configuration
🚨 Common Interview Trap
🎯 Candidate-Style Answer
🧠 Memory Trick
No memorization marathon required. The goal is to understand how the network behaves and explain your decisions like a production DevOps engineer.
Document 1 of 3: VPC Fundamentals and Network Traffic Flow
1. What Is a VPC in AWS, and Why Is It Used?
🧠 Simple Concept
An Amazon VPC, or Virtual Private Cloud, is a logically isolated virtual network where you launch AWS resources such as EC2 instances, load balancers, and other supported services.
Think of a VPC as a private office campus. The campus has boundaries, internal roads, entry gates, and separate areas for different teams. AWS gives you networking components to build a similar environment in the cloud.
A VPC allows you to define:
IP address ranges using CIDR blocks.
Subnets distributed across Availability Zones.
Route tables that determine where traffic goes.
Security groups and network ACLs that control traffic.
Connectivity to the internet, other VPCs, corporate networks, and AWS services.
❓ Why Do We Need It?
Imagine running your public-facing application, application servers, and database in a network without carefully planned boundaries.
The application might work, but the database could be exposed unnecessarily, internal communication could be difficult to control, and troubleshooting could become painful.
A VPC gives you control over network segmentation, routing, and connectivity.
⚙️ How Does It Work?
Consider a typical three-tier application:
INTERNET
|
Internet Gateway
|
PUBLIC SUBNET
|
Application Load Balancer
|
PRIVATE APP SUBNETS
|
Application Servers
|
PRIVATE DB SUBNETS
|
RDS DATABASEThe VPC contains the subnets and routing configuration. Security controls determine which connections are permitted.
🏢 Production Example
You deploy an e-commerce application on EC2.
The load balancer accepts HTTPS traffic.
Application instances run in private subnets.
The database does not need a public IP address.
Application instances access required AWS services through suitable network paths.
When the database connection fails, you investigate routes, security groups, network ACLs, and database configuration rather than randomly changing firewall rules.
💻 Useful Commands
Inspect your VPCs:
aws ec2 describe-vpcs \
--query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,State:State}'Inspect your subnets:
aws ec2 describe-subnets \
--query 'Subnets[*].{SubnetId:SubnetId,VpcId:VpcId,CIDR:CidrBlock,AZ:AvailabilityZone}'🚨 Common Interview Trap
A VPC does not automatically make every resource private. Resources may have public IP addresses, and their connectivity depends on routing, addressing, and security controls.
A VPC’s CIDR block also does not provide security by itself.
🎯 Candidate-Style Answer
“An AWS VPC is a logically isolated virtual network where we deploy AWS resources. It allows us to define IP ranges, subnets, routing, and network security. In production, I use public subnets for necessary internet-facing components and private subnets for application and database workloads to improve isolation and control connectivity.”
🧠 Memory Trick
VPC = Network boundary. Subnets = Network segments. Routes = Traffic direction. Security controls = Allowed communication.
2. What Are Subnets, and What Are the Types of Subnets?
🧠 Simple Concept
A subnet is a smaller IP address range inside a VPC. Each subnet belongs to one Availability Zone.
Subnets help organize workloads according to their purpose, security requirements, and routing needs.
The two common categories are:
Public subnet: Has a route to an Internet Gateway for IPv4 internet connectivity. Resources still need appropriate addressing and security configuration to be reachable from the internet.
Private subnet: Does not have a direct route to an Internet Gateway for general internet access. It may use a NAT Gateway for outbound IPv4 internet access or VPC endpoints for supported AWS services.
A subnet is not inherently public or private because of its name. Its routing configuration determines its classification.
❓ Why Do We Need It?
Subnets help separate different application tiers.
For example, internet-facing load balancers do not need to share the same network segment as databases. Separating them makes access control, routing, and troubleshooting easier.
⚙️ How Does It Work?
Imagine a VPC using the CIDR block 10.0.0.0/16.
VPC: 10.0.0.0/16
|
+-- Public Subnets
| +-- Load Balancer
| +-- NAT Gateway
|
+-- Private Application Subnets
| +-- EC2 / EKS workloads
|
+-- Private Database Subnets
+-- RDS / database workloadsFor high availability, create corresponding subnets in multiple Availability Zones.
For example:
Application Subnet AZ-A: 10.0.11.0/24
Application Subnet AZ-B: 10.0.12.0/24These ranges do not overlap and fit inside the VPC CIDR.
🏢 Production Example
An EKS platform can place worker nodes in private subnets and expose applications through an appropriately configured load balancer.
The worker nodes do not need public IP addresses simply because users need to access the application.
🚨 Common Interview Trap
A private subnet does not mean the resources have no network connectivity. It means the subnet lacks a direct route to an Internet Gateway for ordinary internet access.
Private resources may still communicate with other VPC resources, connected networks, and AWS services.
🎯 Candidate-Style Answer
“Subnets divide a VPC into smaller network segments, with each subnet belonging to one Availability Zone. I normally place internet-facing load balancers in public subnets and application and database workloads in private subnets. For high availability, I distribute critical workloads across multiple Availability Zones.”
🧠 Memory Trick
Public = Internet Gateway route. Private = No direct Internet Gateway route.
3. What Is the Difference Between a Public and a Private Subnet?
🧠 Simple Concept
The key difference is the subnet’s route table, not the subnet’s name.
A typical public subnet contains a route such as:
Destination: 0.0.0.0/0
Target: Internet GatewayA private subnet might instead have:
Destination: 0.0.0.0/0
Target: NAT GatewayOr it may have no default internet route at all.
⚙️ How Does It Work?
When an instance sends traffic, AWS routing determines the next hop based on the destination address and the applicable route table.
A public subnet can support direct internet connectivity when the required route, public addressing, and security controls are configured.
A private subnet can use a NAT Gateway for outbound IPv4 internet access without allowing arbitrary unsolicited inbound connections through that NAT Gateway.
🏢 Production Example
Your application runs in private subnets, while an internet-facing Application Load Balancer receives user requests.
If users can reach the load balancer but the application is unavailable, investigate target health, application ports, security group relationships, network ACLs, and routing.
Do not immediately move application servers into public subnets. That is the networking equivalent of removing the lock because the key is inconvenient.
🚨 Common Interview Trap
A public subnet does not mean every resource inside it is publicly accessible.
An instance still needs appropriate public addressing, routing, and permissive security controls. The application must also be listening and able to process the request.
Likewise, a private subnet does not guarantee complete isolation from every other network.
🎯 Candidate-Style Answer
“The primary distinction is routing. A public subnet has a route to an Internet Gateway, while a private subnet does not have that direct route. In production, I keep application and database workloads private where possible and expose only the necessary entry points through a load balancer.”
🧠 Memory Trick
Subnet classification follows routing, not naming.
4. What Is an Internet Gateway, and How Does It Work?
🧠 Simple Concept
An Internet Gateway, or IGW, is an AWS-managed component that enables internet connectivity for a VPC when routing and addressing are configured correctly.
For IPv4, an Internet Gateway also performs one-to-one address translation for instances using public IPv4 addresses.
⚙️ How Does It Work?
For a typical inbound IPv4 request:
A user connects to an instance’s public IPv4 address.
The subnet route table directs internet traffic through the Internet Gateway.
The Internet Gateway maps the public IPv4 address to the associated private address.
Security groups, network ACLs, and the host’s application determine whether the connection succeeds.
The response returns through the appropriate route.
The Internet Gateway must be attached to the VPC, and the relevant subnet route table must contain the required route.
💻 Example Route
Destination Target
10.0.0.0/16 local
0.0.0.0/0 igw-0123456789abcdef0Inspect Internet Gateways:
aws ec2 describe-internet-gatewaysInspect route tables:
aws ec2 describe-route-tables🏢 Production Example
An internet-facing Application Load Balancer is deployed across public subnets in multiple Availability Zones.
The subnet route tables direct internet traffic to the Internet Gateway. The load balancer security group allows HTTPS from intended clients, while the application targets are protected by separate security rules.
🚨 Common Interview Trap
Attaching an Internet Gateway does not automatically provide internet access to every resource in the VPC.
You must also configure routing, addressing, security controls, and the destination service.
IPv6 also has different connectivity considerations from IPv4. Do not assume every IPv6 architecture needs a NAT Gateway.
🎯 Candidate-Style Answer
“An Internet Gateway connects a VPC to the internet. For IPv4, it supports internet connectivity and public IPv4 address translation. To troubleshoot connectivity, I verify the IGW attachment, route table, public addressing, security groups, network ACLs, and whether the destination service is listening.”
🧠 Memory Trick
IGW = Internet path, not automatic permission.
5. What Is a NAT Gateway, and Why Is It Used?
🧠 Simple Concept
A Network Address Translation Gateway allows resources in private subnets to initiate connections to external IPv4 destinations without allowing those destinations to initiate new connections directly to the private resources through the NAT Gateway.
A public NAT Gateway is deployed in a public subnet and uses an Elastic IP address.
❓ Why Do We Need It?
Private application servers may need to download operating system updates, retrieve software dependencies, pull artifacts, or call third-party APIs.
Giving every server a public IP address is often unnecessary.
A NAT Gateway provides an outbound path for private IPv4 workloads.
⚙️ How Does It Work?
Private EC2 Instance
|
Private Route Table
|
NAT Gateway
(Public Subnet)
|
Internet Gateway
|
InternetThe private subnet might contain:
0.0.0.0/0 -> nat-0123456789abcdef0The public subnet containing the NAT Gateway needs a route to the Internet Gateway.
The NAT Gateway translates the source address for outbound traffic and tracks connection state so responses can return to the initiating workload.
💻 Useful Command
aws ec2 describe-nat-gateways \
--filter Name=state,Values=available🏢 Production Example
An EKS node in a private subnet needs to download a package from an external repository.
The request follows the private subnet’s default route to the NAT Gateway, then reaches the internet through the Internet Gateway. The response returns through the established connection.
If the node only needs supported AWS services such as S3, a VPC endpoint may reduce NAT traffic and associated costs.
🚨 Common Interview Trap
A NAT Gateway does not provide unrestricted inbound connectivity to private instances.
Also, a NAT Gateway is deployed in a specific Availability Zone. For resilient architectures, a common design uses one NAT Gateway per Availability Zone and routes private subnets to the NAT Gateway in the same zone.
A single shared NAT Gateway can create an Availability Zone dependency and cross-zone data-transfer costs.
🎯 Candidate-Style Answer
“I use a NAT Gateway when private IPv4 workloads need outbound internet access without being directly exposed to inbound internet connections. In production, I consider one NAT Gateway per Availability Zone for resilience and use VPC endpoints where appropriate to reduce unnecessary NAT traffic.”
🧠 Memory Trick
NAT Gateway = Private workloads initiate outbound IPv4 connections.
6. What Is the Difference Between a NAT Gateway and a NAT Instance?
🧠 Simple Concept
A NAT Gateway is an AWS-managed NAT service. A NAT instance is an EC2 instance configured to perform network address translation.
With a NAT Gateway, AWS manages the underlying service infrastructure. With a NAT instance, you are responsible for operating the EC2 instance and maintaining its NAT configuration.
⚙️ How Does It Work?
A NAT Gateway provides a managed solution for supported NAT use cases.
A NAT instance requires you to configure the instance appropriately, including disabling source/destination checks where required, configuring operating system forwarding and NAT rules, and managing its security and routing.
🏢 Production Example
A production platform needs reliable outbound access from private application subnets.
A NAT Gateway is usually the simpler operational choice. A NAT instance might be considered for specialized networking requirements or a legacy environment, but it introduces patching, monitoring, capacity, and failover responsibilities.
🚨 Common Interview Trap
Do not claim that NAT Gateways have unlimited capacity or that a NAT instance automatically provides high availability.
Both designs must account for throughput, connections, routing, monitoring, and failure scenarios.
🎯 Candidate-Style Answer
“A NAT Gateway is a managed AWS service, while a NAT instance is an EC2 instance that we manage ourselves. For most production workloads, I prefer NAT Gateways because they reduce operational overhead. I would consider a NAT instance only when its additional flexibility justifies the maintenance and availability responsibilities.”
🧠 Memory Trick
NAT Gateway = Managed. NAT Instance = You operate it.
7. What Are Route Tables in a VPC?
🧠 Simple Concept
A route table contains rules that determine where network traffic is directed.
A route has a destination, usually an IP prefix, and a target such as:
localfor communication within the VPC’s associated CIDR ranges.An Internet Gateway.
A NAT Gateway.
A VPC peering connection.
A Transit Gateway.
A virtual private gateway.
A VPC endpoint, where supported.
Each subnet is associated with one route table. If you do not explicitly associate a subnet with a custom route table, it uses the VPC’s main route table.
⚙️ How Does Routing Work?
Imagine this route table:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 nat-0123456789abcdef0Traffic for the VPC’s local CIDR uses the local route. Traffic for destinations not matched by a more specific route follows the default route to the NAT Gateway.
AWS uses the most specific matching route, known as longest-prefix match, when multiple routes match a destination.
🏢 Production Example
A private application subnet cannot reach an external package repository.
You inspect the route table and discover that its default route points to a deleted NAT Gateway. The security group is correct, but the traffic has no usable outbound path.
The fix is to restore the correct route target or replace the missing network component, then validate connectivity.
💻 Useful Command
aws ec2 describe-route-tables \
--query 'RouteTables[*].{Id:RouteTableId,Associations:Associations,Routes:Routes}'🚨 Common Interview Trap
Security groups do not decide the destination of a packet. Route tables do.
A route can exist and still fail to deliver traffic because a security group, network ACL, firewall, endpoint policy, or destination service rejects it.
🎯 Candidate-Style Answer
“A route table defines the next hop for traffic leaving a subnet or network interface. During troubleshooting, I verify the source subnet’s route table, the most specific matching route, the target’s state, and the return path before modifying security rules.”
🧠 Memory Trick
Routes decide where traffic goes. Security controls decide whether it is allowed.
Document 2 of 3: Network Security, Private Connectivity, and Architecture
8. What Are Security Groups, and How Do They Work?
🧠 Simple Concept
A security group is a stateful virtual firewall associated with supported resources or network interfaces.
Security groups contain allow rules for inbound and outbound traffic. They do not support explicit deny rules.
Because they are stateful, return traffic for an allowed connection is automatically permitted, regardless of whether an explicit reverse-direction rule exists.
⚙️ How Does It Work?
Consider a web application:
Internet
|
| HTTPS 443
v
Load Balancer SG
|
| Application Port 8080
v
Application SG
|
| Database Port 5432
v
Database SGA sensible security group design might allow:
The load balancer security group to accept inbound HTTPS from approved client ranges.
The application security group to accept inbound traffic on port 8080 from the load balancer security group.
The database security group to accept inbound traffic on port 5432 from the application security group.
This limits access to the intended communication paths.
🏢 Production Example
A developer reports that an application cannot connect to PostgreSQL.
Instead of opening port 5432 to 0.0.0.0/0, inspect the database security group and allow the database port from the application’s security group, if that is the intended architecture.
This is easier to maintain than relying on a list of changing private IP addresses.
💻 Useful Command
aws ec2 describe-security-groups \
--query 'SecurityGroups[*].{Id:GroupId,Name:GroupName,Ingress:IpPermissions,Egress:IpPermissionsEgress}'🚨 Common Interview Trap
Security groups are stateful, but network ACLs are stateless.
Security groups also cannot explicitly deny traffic. If you need a deny policy, consider the network control that supports it.
🎯 Candidate-Style Answer
“Security groups are stateful firewalls that control inbound and outbound traffic for associated resources. I use security group references to express relationships between application tiers, such as allowing database traffic only from the application security group.”
🧠 Memory Trick
Security group = Stateful allow rules.
9. What Are Network ACLs, and How Are They Different from Security Groups?
🧠 Simple Concept
A Network Access Control List, or network ACL, is a stateless traffic filter applied at the subnet boundary.
Network ACLs support allow and deny rules. Rules are evaluated in ascending rule-number order, and the first matching rule determines the outcome.
⚙️ How Does It Work?
Because network ACLs are stateless, return traffic must be permitted separately.
For TCP connections, that commonly means accounting for ephemeral ports as well as the application port.
Security groups, in contrast, are stateful and automatically allow response traffic for permitted connections.
🏢 Production Example
A network ACL is changed during a security hardening exercise. Suddenly, application requests time out even though the security groups appear correct.
The ACL allows the inbound application port but blocks the ephemeral ports required for response traffic.
The correct investigation checks both directions instead of repeatedly changing security groups.
🚨 Common Interview Trap
A network ACL is not automatically a better security group. Both controls have different purposes.
Security groups are generally the primary resource-level control. Network ACLs can provide an additional subnet-level control when the architecture requires it.
🎯 Candidate-Style Answer
“Security groups are stateful and apply to resources or network interfaces, whereas network ACLs are stateless and apply at the subnet level. With network ACLs, I explicitly validate inbound and outbound rules, including ephemeral return ports.”
🧠 Memory Trick
SG = Stateful. NACL = Stateless.
10. What Is VPC Peering, and How Does It Work?
🧠 Simple Concept
VPC peering creates a network connection between two VPCs so resources can communicate using private IP addresses, subject to routing and security configuration.
The VPCs can be in the same or different AWS accounts and Regions, subject to AWS-supported configurations.
⚙️ How Does It Work?
Imagine two VPCs:
VPC A: 10.0.0.0/16
|
Peering Connection
|
VPC B: 10.1.0.0/16To communicate successfully:
The peering connection must be accepted and active.
Relevant route tables must contain routes to the peer CIDR through the peering connection.
Security groups and network ACLs must allow the required traffic.
The CIDR ranges must not overlap.
🏢 Production Example
A development VPC needs to connect to a shared services VPC containing internal tooling.
VPC peering may be suitable for a small number of VPCs with straightforward connectivity requirements.
When an organization grows to dozens or hundreds of VPCs, managing individual peering connections and routes can become cumbersome.
🚨 Common Interview Trap
VPC peering does not support transitive routing.
If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot automatically use VPC B as a router to reach VPC C.
🎯 Candidate-Style Answer
“VPC peering provides private connectivity between two VPCs. I configure the peering connection, routes in both directions, and security rules. For a small number of VPCs, peering can be simple, but for large-scale connectivity I would evaluate Transit Gateway.”
🧠 Memory Trick
Peering = Direct VPC-to-VPC connection, without automatic transit.
11. What Are VPC Endpoints?
🧠 Simple Concept
VPC endpoints allow resources in a VPC to connect privately to supported AWS services without requiring an Internet Gateway, NAT Gateway, or VPN for that particular service path.
They are especially useful for workloads that need access to AWS services while remaining in private subnets.
❓ Why Do We Need Them?
Consider an EC2 instance that needs to retrieve objects from Amazon S3.
Without an appropriate endpoint, the workload might send traffic through a NAT Gateway or another configured network path. An S3 gateway endpoint can provide a private path to the service and may reduce NAT Gateway usage and associated costs.
⚙️ Main Endpoint Types
Gateway endpoint: Supported for Amazon S3 and Amazon DynamoDB. Routing is configured through route tables.
Interface endpoint: Uses AWS PrivateLink and creates endpoint network interfaces in selected subnets for supported services.
Gateway Load Balancer endpoint: Used for supported architectures involving virtual appliances and Gateway Load Balancers.
🏢 Production Example
A private EKS workload needs to access Amazon ECR, S3, CloudWatch, and other AWS services.
Depending on the services and operations required, you can configure suitable interface endpoints and gateway endpoints. This can reduce dependency on general internet egress.
Do not assume one endpoint covers every AWS API call or every dependency. Check the full list of services used by the workload.
🚨 Common Interview Trap
A VPC endpoint does not automatically grant permission to access the service. IAM policies, endpoint policies where applicable, resource policies, security groups, DNS, and service configuration can still block requests.
🎯 Candidate-Style Answer
“VPC endpoints provide private connectivity from a VPC to supported AWS services. I use gateway endpoints for S3 or DynamoDB where appropriate and interface endpoints for supported services through AWS PrivateLink. I also validate IAM permissions, endpoint policies, DNS, and security rules.”
🧠 Memory Trick
VPC endpoint = Private path to a supported service, not automatic authorization.
12. What Is the Difference Between Interface Endpoints and Gateway Endpoints?
🧠 Simple Concept
Both are VPC endpoint types, but they implement private connectivity differently.
An interface endpoint uses AWS PrivateLink and endpoint network interfaces. A gateway endpoint uses route-table entries for supported services.
⚙️ How Does It Work?
Interface endpoint:
Creates endpoint network interfaces with private IP addresses in selected subnets.
Uses AWS PrivateLink for supported services.
Can have security groups associated with its endpoint network interfaces.
Supports private DNS for eligible services and configurations.
Gateway endpoint:
Is configured as a route-table target.
Is supported for Amazon S3 and Amazon DynamoDB.
Does not attach security groups directly to the endpoint.
Depends on the relevant route tables and endpoint policies.
🏢 Production Example
Your private EC2 instances need access to S3 and CloudWatch APIs.
You may configure an S3 gateway endpoint for S3 traffic and a CloudWatch Logs interface endpoint for the relevant logging APIs, subject to service support and the required configuration.
This can reduce unnecessary internet egress and improve network isolation.
🚨 Common Interview Trap
Not all VPC endpoints use network interfaces. Gateway endpoints do not.
An interface endpoint is also not a universal replacement for every possible network path to an AWS service.
🎯 Candidate-Style Answer
“An interface endpoint uses AWS PrivateLink and endpoint network interfaces, while a gateway endpoint adds routes for supported services such as S3 and DynamoDB. I select the endpoint type based on service support, routing requirements, security controls, and cost.”
🧠 Memory Trick
Interface = ENI. Gateway = Route table.
13. How Do Instances in a Private Subnet Access the Internet?
🧠 Simple Concept
For outbound IPv4 internet access, instances in a private subnet commonly use a NAT Gateway deployed in a public subnet.
However, not every private workload needs general internet access. VPC endpoints, proxies, private service connections, and centralized egress architectures may be better choices.
⚙️ How Does It Work?
Private EC2
|
Private Route Table
|
| 0.0.0.0/0
v
NAT Gateway
|
Public Route Table
|
v
Internet Gateway
|
InternetThe return traffic follows the established connection back through the NAT Gateway.
🏢 Production Example
A private application instance must call a third-party payment API.
You confirm that the private subnet routes outbound IPv4 traffic to a working NAT Gateway, the NAT Gateway’s subnet has a route to the Internet Gateway, and the workload’s security controls allow the connection.
You also check DNS resolution, TLS configuration, and the third-party API’s response.
🚨 Common Interview Trap
A NAT Gateway does not automatically fix every connectivity issue. DNS failures, incorrect routes, security rules, service restrictions, and TLS problems can still prevent a successful request.
For IPv6, the appropriate design may use an egress-only Internet Gateway for outbound-only internet connectivity or another IPv6-capable network pattern. An IPv4 NAT Gateway is not the universal solution for IPv6.
🎯 Candidate-Style Answer
“For outbound IPv4 internet access, private instances commonly use a NAT Gateway in a public subnet. I verify both route tables, the NAT Gateway’s availability, DNS, security controls, and the destination service. For AWS services, I also evaluate VPC endpoints to avoid unnecessary internet egress.”
🧠 Memory Trick
Private IPv4 internet access = Private route → NAT Gateway → Internet Gateway.
14. How Do You Design a Highly Available VPC Architecture?
🧠 Simple Concept
A highly available VPC design avoids depending on a single Availability Zone for critical network components and workloads.
The architecture should tolerate an Availability Zone failure without making the entire application unavailable, subject to the application’s replication and recovery capabilities.
⚙️ Example Architecture
INTERNET
|
Internet Gateway
|
+-------------+-------------+
| |
PUBLIC SUBNET AZ-A PUBLIC SUBNET AZ-B
Load Balancer node Load Balancer node
NAT Gateway A NAT Gateway B
| |
v v
PRIVATE APP AZ-A PRIVATE APP AZ-B
| |
+-------------+-------------+
|
MULTI-AZ DATABASE DESIGNIn a production design, use:
Public and private subnets across multiple Availability Zones.
A supported load-balancing configuration spanning the relevant zones.
NAT Gateways in multiple Availability Zones where resilient outbound IPv4 access is required.
Database services with appropriate Multi-AZ or replication configuration.
Carefully planned CIDR ranges.
Least-privilege security rules.
VPC endpoints for suitable AWS service traffic.
Flow Logs, monitoring, and tested recovery procedures.
🏢 Production Example
A business-critical application runs in two Availability Zones. Each zone has application capacity, and the load balancer distributes requests across healthy targets.
If one zone becomes unavailable, the surviving zone must have enough capacity to serve the remaining traffic. Network redundancy alone does not guarantee application availability.
🚨 Common Interview Trap
Deploying subnets across multiple Availability Zones does not automatically make an application highly available.
The compute layer, database, load balancer, outbound connectivity, dependencies, and operational procedures must also support the failure scenario.
🎯 Candidate-Style Answer
“I design the VPC across multiple Availability Zones with separate public and private subnets, redundant application capacity, appropriate Multi-AZ database configuration, and resilient outbound connectivity. I also test what happens when an Availability Zone or network dependency fails instead of assuming the architecture is highly available just because it has two subnets.”
🧠 Memory Trick
High availability = Redundancy + Capacity + Correct routing + Tested recovery.
Document 3 of 3: CIDR, Troubleshooting, Monitoring, and Production Best Practices
15. What Is a CIDR Block in a VPC?
🧠 Simple Concept
CIDR stands for Classless Inter-Domain Routing. It represents an IP address range using an address and prefix length.
For example:
10.0.0.0/16The /16 indicates that the first 16 bits identify the network portion of the IPv4 range.
A /16 contains 65,536 total IPv4 addresses. A /24 contains 256 total IPv4 addresses.
AWS reserves five IPv4 addresses in each subnet, so a subnet’s usable address count is lower than its total address count.
⚙️ Example
Consider this VPC:
VPC: 10.0.0.0/16
|
+-- Public AZ-A: 10.0.1.0/24
+-- Public AZ-B: 10.0.2.0/24
+-- App AZ-A: 10.0.11.0/24
+-- App AZ-B: 10.0.12.0/24
+-- DB AZ-A: 10.0.21.0/24
+-- DB AZ-B: 10.0.22.0/24The subnets are non-overlapping and fit within the VPC’s CIDR range.
🏢 Production Example
A company later needs to connect its AWS VPC to an on-premises network using VPN or Direct Connect.
If both networks use overlapping CIDR ranges, routing and connectivity can become difficult or impossible without redesign or additional network translation.
That is why CIDR planning matters before launching production workloads.
🚨 Common Interview Trap
Do not choose subnet sizes based only on the number of instances you currently run.
Consider future scaling, load balancers, EKS pod and node addressing, endpoint network interfaces, IP address consumption, and expansion requirements.
Avoid overlapping address ranges between VPCs and connected networks whenever possible.
🎯 Candidate-Style Answer
“A CIDR block defines an IP address range. I plan VPC and subnet CIDRs so they do not overlap, leave room for future growth, and support connectivity with other VPCs and on-premises networks. For AWS subnets, I also account for the five IPv4 addresses AWS reserves in each subnet.”
🧠 Memory Trick
CIDR = Address range + prefix length.
16. How Do You Troubleshoot Connectivity Issues in a VPC?
🧠 Simple Concept
VPC troubleshooting is about following the traffic path and identifying the exact layer where it fails.
A timeout, a connection refusal, and an HTTP 403 are different symptoms. Treating them as the same networking problem wastes time and can introduce new security risks.
⚙️ Step-by-Step Troubleshooting Process
Step 1: Identify the source and destination.
Record the source workload, destination IP or hostname, port, protocol, and expected traffic direction.
Step 2: Check DNS.
nslookup example.comOr:
dig example.comIf the hostname resolves to the wrong address, route and firewall checks may be irrelevant until DNS is corrected.
Step 3: Check routes.
Verify the source subnet’s route table, destination route, target state, and return path.
Step 4: Check security groups.
Confirm that the relevant inbound and outbound rules permit the traffic. For traffic between application tiers, inspect the actual security group associations.
Step 5: Check network ACLs.
Review inbound and outbound rules and, where applicable, ephemeral ports needed for stateless return traffic.
Step 6: Check the destination service.
Is the application listening on the expected port? Is the service healthy? Does the operating system firewall block traffic?
Step 7: Check AWS network diagnostics.
Use VPC Flow Logs, Reachability Analyzer, and relevant service logs where appropriate.
🏢 Production Example
An EC2 instance cannot connect to a database on port 5432.
You verify:
DNS resolves to the expected private address.
The source and destination are in the expected VPCs or connected networks.
Routes exist in both directions.
The database security group allows TCP 5432 from the intended application security group.
Network ACLs permit the connection and return traffic.
The database is listening and accepts connections.
This process narrows the problem down without opening the database to the whole internet.
💻 Useful Commands
Test TCP connectivity:
nc -vz db.internal.example 5432Test DNS:
dig db.internal.exampleInspect security groups:
aws ec2 describe-security-groupsInspect routes:
aws ec2 describe-route-tablesInspect VPC Flow Logs:
aws ec2 describe-flow-logs🚨 Common Interview Trap
Do not immediately change security groups to allow all traffic.
First identify the source, destination, protocol, port, and failing network layer. A broad rule can hide the original problem while creating a security incident of its own.
🎯 Candidate-Style Answer
“I troubleshoot VPC connectivity layer by layer. I verify DNS, source and destination addressing, route tables, security groups, network ACLs, and the destination service. I use VPC Flow Logs and Reachability Analyzer where applicable, and I make the smallest change that fixes the verified root cause.”
🧠 Memory Trick
DNS → Routes → Security Groups → NACLs → Service → Logs.
17. What Are VPC Flow Logs?
🧠 Simple Concept
VPC Flow Logs capture information about IP traffic to and from network interfaces, subnets, or VPCs.
They are useful for diagnosing network connectivity problems, understanding traffic patterns, and investigating unexpected communication.
Flow Logs can publish records to supported destinations such as Amazon CloudWatch Logs, Amazon S3, and Amazon Data Firehose, depending on the configuration.
⚙️ What Can They Tell You?
Depending on the configured fields, records can include:
Source and destination addresses.
Source and destination ports.
Protocol.
Packet and byte counts.
Traffic direction and interface information.
A traffic disposition such as
ACCEPTorREJECT.
Flow Logs are not packet captures. They do not provide the full contents of application requests, and records are not guaranteed to appear instantly.
🏢 Production Example
An application team reports intermittent connection failures between application servers and a database.
You inspect the relevant Flow Logs and discover rejected traffic associated with the database destination port.
That evidence helps narrow the investigation to network filtering, but you still need to determine which rule or component caused the rejection.
💻 Useful Command
aws ec2 describe-flow-logs \
--query 'FlowLogs[*].{Id:FlowLogId,Resource:ResourceId,Status:FlowLogStatus,Destination:LogDestination}'🚨 Common Interview Trap
Do not treat ACCEPT as proof that the application request succeeded. It indicates that the traffic was accepted by the relevant network controls represented in the flow record, not that the destination application processed it successfully.
Similarly, a Flow Log record does not automatically identify the exact security group rule responsible for a failure.
🎯 Candidate-Style Answer
“VPC Flow Logs provide metadata about IP traffic for a VPC, subnet, or network interface. I use them to investigate accepted and rejected traffic, analyze communication patterns, and support security investigations. I correlate them with application logs, security rules, and route configuration to identify the root cause.”
🧠 Memory Trick
Flow Logs = Traffic metadata, not full packet capture.
18. What Is AWS Transit Gateway?
🧠 Simple Concept
AWS Transit Gateway is a network transit hub that connects multiple VPCs and supported external networks through a centralized architecture.
Instead of managing a large mesh of individual VPC peering connections, organizations can connect VPCs to a Transit Gateway and control connectivity through its route tables and attachment configuration.
⚙️ How Does It Work?
ON-PREMISES NETWORK
|
VPN / DIRECT CONNECT
|
TRANSIT GATEWAY
/ | \
/ | \
VPC A VPC B VPC CEach VPC connects through a Transit Gateway attachment. Routes in VPC route tables and Transit Gateway route tables must direct traffic to the correct destination.
Transit Gateway can support centralized network patterns, including shared services and controlled inter-VPC connectivity.
🏢 Production Example
A company has separate production, development, security, and shared services VPCs.
Rather than creating a growing number of individual peering connections, the organization can use Transit Gateway to simplify network connectivity and centralize routing controls.
The design still needs careful route segmentation. Connecting every VPC to one hub does not mean every VPC should be able to communicate with every other VPC.
🚨 Common Interview Trap
Transit Gateway does not eliminate the need for routing, security controls, or network planning.
You must configure VPC routes, Transit Gateway route tables, attachment associations and propagations where applicable, and security controls at the destination.
🎯 Candidate-Style Answer
“Transit Gateway provides hub-and-spoke connectivity for multiple VPCs and supported external networks. I use it when an organization needs scalable connectivity and centralized routing. I also separate routing domains where necessary and verify the return path and security rules.”
🧠 Memory Trick
VPC Peering = Direct connection. Transit Gateway = Network hub.
19. What Are the Best Practices for VPC Design?
🧠 Simple Concept
Good VPC design is not about using every available AWS networking service. It is about choosing a clear, secure, resilient, and maintainable architecture.
A network that nobody understands is a future incident waiting for a calendar invitation.
🏗️ Production Best Practices
1. Plan CIDR ranges early.
Choose non-overlapping CIDRs for VPCs and connected networks. Leave room for growth, EKS networking requirements, and additional subnets.
2. Use multiple Availability Zones.
Distribute critical workloads across Availability Zones and ensure that network dependencies can tolerate failures.
3. Keep application and database workloads private where possible.
Expose only the necessary entry points. Use load balancers, security groups, and private connectivity to limit direct access.
4. Apply least-privilege security rules.
Allow only the required ports and source ranges. Use security group references for tier-to-tier communication where appropriate.
5. Choose NAT architecture deliberately.
Use NAT Gateways where general outbound IPv4 connectivity is needed. Consider per-AZ NAT Gateways for resilience, and evaluate VPC endpoints for supported AWS services.
6. Use VPC endpoints for suitable service traffic.
They can improve private connectivity and reduce dependence on NAT-based egress. Validate endpoint coverage, IAM permissions, DNS, and policies.
7. Use Transit Gateway when the network topology justifies it.
For many VPCs and connected networks, a centralized hub can simplify connectivity and route management. Use VPC peering when direct connections are sufficient.
8. Enable VPC Flow Logs where appropriate.
Choose the right scope, destination, retention period, and access permissions. Ensure logs are useful during incident investigation without creating unnecessary storage costs.
9. Use Infrastructure as Code.
Manage VPCs, subnets, routes, endpoints, and security groups with Terraform or AWS CloudFormation. Review changes before applying them and avoid untracked manual modifications.
10. Monitor address capacity.
Keep an eye on available subnet addresses, particularly for EKS and workloads that create many network interfaces.
11. Test failure scenarios.
Validate what happens when an Availability Zone, NAT Gateway, route target, or external dependency becomes unavailable.
12. Document the traffic paths.
Maintain a diagram showing VPCs, CIDRs, subnet tiers, route tables, connectivity, and security boundaries. A clear diagram often saves more troubleshooting time than another meeting.
🏢 Production Example
A company operates multiple EKS clusters across several VPCs.
The networking team plans non-overlapping CIDRs, uses private subnets for worker nodes, configures the required VPC endpoints, limits security group access, and enables Flow Logs for troubleshooting.
Terraform manages the network configuration, and changes are reviewed through a CI/CD pipeline.
This makes the environment more consistent and reduces the risk of configuration drift.
🚨 Common Interview Trap
Do not assume that using private subnets, multiple Availability Zones, or Infrastructure as Code automatically guarantees security and availability.
The design still needs correct routing, appropriate permissions, sufficient capacity, monitoring, and tested recovery procedures.
🎯 Candidate-Style Answer
“My VPC design priorities are non-overlapping CIDRs, multi-AZ resilience, private application and database tiers, least-privilege security groups, appropriate NAT and endpoint architecture, centralized connectivity where required, Flow Logs, and Infrastructure as Code. I also test failure scenarios and monitor subnet IP capacity.”
🧠 Memory Trick
Plan → Segment → Secure → Connect → Monitor → Test.
20. How Would You Explain Your VPC Architecture in a DevOps Interview?
🧠 Simple Concept
Interviewers often want to know whether you can connect individual AWS networking components into a working architecture.
You should be able to explain not only what each service does, but also why you chose it and how you would troubleshoot it.
⚙️ Example Architecture
Imagine a production application hosted on AWS:
USERS
|
Internet Gateway
|
+------------+------------+
| |
PUBLIC AZ-A PUBLIC AZ-B
Load Balancer Load Balancer
NAT Gateway A NAT Gateway B
| |
v v
PRIVATE APP AZ-A PRIVATE APP AZ-B
| |
+------------+------------+
|
PRIVATE DATABASE
MULTI-AZThe design may also use:
VPC endpoints for supported AWS services.
Security groups to control communication between tiers.
Network ACLs for additional subnet-level filtering where needed.
VPC Flow Logs for traffic analysis.
Transit Gateway for connectivity to other VPCs or corporate networks.
Terraform to provision and manage the network.
🏢 Production Example
Suppose the application becomes unavailable after a network change.
You identify the affected source and destination, inspect route tables, verify the security groups and network ACLs, review Flow Logs, and check application health.
After finding the root cause, you make the smallest safe correction, validate the traffic path, and document the incident.
This demonstrates engineering judgment, not just familiarity with AWS terminology.
🚨 Common Interview Trap
Do not simply list services:
“I used VPC, subnets, NAT Gateway, security groups, and route tables.”
That tells the interviewer which services you have heard of. It does not explain how you designed or operated the system.
🎯 Candidate-Style Answer
“In my production VPC design, I separate internet-facing components from application and database workloads using public and private subnets across multiple Availability Zones. I configure route tables for the required traffic paths, use security groups for least-privilege access, and use NAT Gateways or VPC endpoints based on the workload’s connectivity needs. I enable suitable logging and manage the configuration through Infrastructure as Code. During incidents, I trace traffic from source to destination and verify routing, security controls, and application health.”
🧠 Memory Trick
Explain the requirement, architecture, traffic path, security controls, and failure recovery.
Final Takeaways: What You Should Remember Before the Interview 🎯
AWS VPC interview questions become much easier when you understand the relationships between the components.
Here are the concepts worth revising before your next interview:
VPC: Your logically isolated AWS network.
Subnets: IP address ranges within a VPC, each belonging to an Availability Zone.
Internet Gateway: Enables appropriate internet connectivity when routing, addressing, and security are configured.
NAT Gateway: Enables private IPv4 workloads to initiate outbound internet connections.
Route tables: Determine where traffic goes.
Security groups: Stateful allow rules for associated resources or network interfaces.
Network ACLs: Stateless subnet-level filters with ordered allow and deny rules.
VPC peering: Direct private connectivity between two VPCs, without automatic transitive routing.
VPC endpoints: Private connectivity to supported AWS services.
Transit Gateway: A central connectivity hub for multiple VPCs and supported external networks.
CIDR: Defines IP address ranges.
VPC Flow Logs: Provide traffic metadata for troubleshooting and analysis.
The Most Important Troubleshooting Principle
When a connection fails, do not randomly open ports or replace network components.
Follow the traffic path:
DNS Resolution
|
Source Address
|
Route Table
|
Security Group
|
Network ACL
|
Destination Route
|
Application / Service
|
Logs and DiagnosticsThe exact sequence depends on the symptom and network architecture, but the discipline remains the same: identify the failing layer, gather evidence, make a targeted change, and validate the result.
That is how a DevOps engineer approaches networking in production.
You do not need to memorize every AWS networking feature on day one. You need to understand the fundamentals, know how traffic flows, and develop the habit of verifying assumptions before changing production infrastructure.
Because in a real incident, the interviewer is not interested in how confidently you can define a NAT Gateway. They want to know whether you can restore connectivity without accidentally exposing the database to the internet. 🙂
Hashtags
#AWS #AmazonWebServices #AWSSolutionsArchitect #AWSVPC #VPC #DevOps #DevOpsEngineer #CloudComputing #CloudNetworking #Networking #EC2 #AmazonEKS #Kubernetes #Terraform #InfrastructureAsCode #IaC #CloudSecurity #AWSNetworking #PlatformEngineering #SRE #SiteReliabilityEngineering #CloudArchitecture #InterviewPreparation #DevOpsInterview #TechnicalInterview
Follow Me
If you enjoyed this article and would like more practical DevOps, Cloud, Kubernetes, AWS, Terraform, CI/CD, and Software Engineering content, feel free to connect with me on LinkedIn.
Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104