Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
AWS Virtual Private Cloud (VPC) and Subnetting are foundational concepts for anyone building on Amazon Web Services. A VPC provides a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. Subnetting then allows you to segment this VPC into smaller, manageable networks, dictating how resources within them can communicate with each other and the internet. Mastering VPC and subnetting is crucial for designing secure, scalable, and highly available cloud architectures. Interviewers frequently test these concepts to gauge a candidate's understanding of network isolation, routing, and security within a cloud environment. For junior roles, a basic understanding of public/private subnets and security groups is expected. Senior engineers, however, must demonstrate deep knowledge of advanced routing, NAT gateway configurations, Network ACLs, VPC peering, and complex network troubleshooting, understanding the implications for performance, cost, and security in production systems.
AWS VPC and Subnetting form the bedrock of any secure and performant cloud infrastructure. Without a solid grasp of these concepts, engineers risk deploying insecure, inefficient, or non-compliant applications. For instance, correctly segmenting resources into public and private subnets ensures that sensitive backend databases or application servers are never directly exposed to the internet, reducing attack surfaces significantly. Misconfigurations in route tables or security groups can lead to critical data breaches or complete service outages, costing companies millions in downtime and reputational damage. A strong understanding of VPC design allows engineers to optimize network traffic flow, implement robust security controls, and manage IP address allocation efficiently. For example, using a NAT Gateway in a public subnet allows instances in private subnets to initiate outbound connections to the internet (e.g., for patching or accessing third-party APIs) without exposing them to inbound internet traffic. This setup is fundamental for compliance with standards like PCI DSS or HIPAA, where strict network isolation is mandated. Interviewers use VPC questions as a high-signal indicator because a candidate's ability to articulate these concepts demonstrates not just theoretical knowledge but also practical experience in building resilient, secure, and cost-effective cloud solutions. A weak answer often reveals a lack of hands-on experience or a superficial understanding of cloud security principles. In 2026, with the increasing complexity of microservices, serverless architectures, and AI/ML workloads, the demand for finely-tuned and highly secure network environments within AWS has only grown, making VPC and subnetting expertise more critical than ever.
An AWS VPC provides a customizable virtual network infrastructure. At its core, a VPC is defined by a CIDR block. Within this VPC, you create subnets, which are ranges of IP addresses from the VPC's CIDR. Subnets are typically deployed across different Availability Zones for high availability. Each subnet must be associated with a route table, which dictates how traffic leaving the subnet is routed. For internet connectivity, an Internet Gateway (IGW) is attached to the VPC, and public subnets have routes to this IGW. Private subnets, to access the internet for updates or external APIs without being directly exposed, route their outbound traffic through a NAT Gateway (deployed in a public subnet). Security is enforced at two layers: Network ACLs (NACLs) operate at the subnet level, acting as stateless firewalls, while Security Groups (SGs) act as stateful firewalls for individual instances or ENIs. Traffic flows from an instance, through its Security Group, then through its subnet's Network ACL, and finally is directed by the subnet's route table.
Traffic originates from an EC2 instance, passes through its associated Security Group (stateful), then through the Network ACL of its subnet (stateless), and is finally directed by the subnet's route table. Depending on the destination, traffic might go to an Internet Gateway (for public subnets to internet), a NAT Gateway (for private subnets to internet), or stay within the VPC.
[Internet]
↑
↓
[Internet Gateway (IGW)]
↑
↓
[VPC (e.g., 10.0.0.0/16)]
↓
┌──────────────────────────────────┴──────────────────────────────────┐
↓ ↓
[Public Subnet AZ1 (10.0.1.0/24)] [Private Subnet AZ1 (10.0.2.0/24)]
[NACL Public] [NACL Private]
↓ ↑
↓ ↓
[Route Table Public] [Route Table Private]
(0.0.0.0/0 -> IGW) (0.0.0.0/0 -> NAT GW)
↓ ↑
↓ ↓
[EC2 Web Server] [NAT Gateway] ←─────── [EC2 App Server]
[Security Group Web] [Security Group NAT] [Security Group App]
↑ ↓
└───────────────────────────────────────────────────┘
↓
[Database (e.g., RDS)]
[Security Group DB]Deploying public and private subnets across multiple Availability Zones (typically 2-3) within a single VPC. This ensures that if one AZ becomes unavailable, your application can continue to run in another AZ. Public subnets host internet-facing load balancers and web servers, while private subnets host application servers and databases. Each AZ's private subnet routes outbound internet traffic through a dedicated NAT Gateway in its respective public subnet to maintain high availability for outbound connectivity. Implemented by creating subnets in different AZs and configuring ELB and Auto Scaling Groups to distribute instances across these subnets.
Trade-offs: Increases cost due to multiple NAT Gateways and cross-AZ data transfer. Provides significantly higher fault tolerance and resilience. Adds complexity in managing resources across AZs.
Placing all sensitive backend resources (e.g., databases like RDS, application servers, internal APIs) in private subnets. These subnets do not have direct routes to an Internet Gateway. Internet access for these resources is only outbound, typically through a NAT Gateway in a public subnet, or via VPC Endpoints for specific AWS services. Inbound access is strictly controlled via Security Groups and NACLs, often limited to other instances within the VPC or via a VPN/Direct Connect connection. Implemented by creating subnets with no direct IGW route and configuring route tables to use a NAT Gateway or VPC Endpoint for external access.
Trade-offs: Enhances security by minimizing attack surface. Adds complexity for troubleshooting outbound connectivity. Introduces NAT Gateway costs. Requires careful management of Security Group rules.
Connecting two VPCs directly using a VPC peering connection, enabling instances in either VPC to communicate with each other as if they were within the same network. This is useful for connecting applications in different VPCs within the same AWS account or across different AWS accounts. It's a one-to-one connection and does not support transitive routing. Implemented by creating a peering connection request, accepting it, and then updating route tables in both VPCs to direct traffic for the peered VPC's CIDR block to the peering connection.
Trade-offs: Simplifies direct communication between two VPCs. Does not support transitive routing (VPC A cannot reach VPC C via VPC B). Requires non-overlapping CIDR blocks. Can become complex to manage with many peering connections.
Designating a central VPC to host common services like Active Directory, logging, monitoring tools, or shared security appliances (e.g., firewalls). Other 'spoke' VPCs (e.g., for different applications or teams) connect to this central 'hub' VPC using VPC peering or, more commonly in 2026, AWS Transit Gateway. This centralizes management, reduces operational overhead, and can optimize costs for shared infrastructure. Implemented using VPC peering or Transit Gateway to connect multiple application VPCs to a dedicated shared services VPC.
Trade-offs: Reduces duplication of services and costs. Centralizes security and management. Adds a single point of failure if the shared services VPC is not highly available. Increases network complexity with more routing rules.
| Reliability | Achieve high reliability by deploying resources across multiple Availability Zones (AZs) within the VPC. This includes creating public and private subnets in at least two AZs and deploying a NAT Gateway in each public subnet for private subnet outbound internet access. Use Elastic Load Balancers (ELBs) in public subnets to distribute traffic across instances in multiple private subnets. Implement redundant VPN/Direct Connect connections for hybrid cloud setups. |
| Scalability | Design VPCs with sufficiently large CIDR blocks (e.g., /16 or /18) to accommodate future growth. Use appropriately sized subnets (e.g., /24 for application tiers) to prevent IP exhaustion. Leverage Auto Scaling Groups to dynamically scale instances within subnets. For inter-VPC communication, use AWS Transit Gateway instead of VPC peering for complex hub-and-spoke topologies, as it scales better with many VPCs. |
| Performance | Optimize network performance by placing resources in the same AZ where possible to minimize cross-AZ latency and data transfer costs. Use VPC Endpoints for direct, private connectivity to AWS services like S3 or DynamoDB, bypassing the internet and NAT Gateway, reducing latency and improving throughput. Ensure Security Group and NACL rules are optimized to avoid unnecessary processing overhead. |
| Cost | Minimize costs by consolidating resources into fewer VPCs where appropriate, reducing NAT Gateway deployments (one per AZ, only if needed), and using VPC Endpoints instead of NAT Gateways for AWS service access. Be mindful of cross-AZ data transfer costs, which can be significant. Regularly review VPC Flow Logs to identify and optimize unnecessary traffic. |
| Security | Implement a defense-in-depth strategy using both Network ACLs (subnet-level, stateless, allow/deny) and Security Groups (instance-level, stateful, allow). Place sensitive resources in private subnets. Use dedicated subnets for different tiers (web, app, DB). Implement strict IAM policies for VPC resource management. Enable VPC Flow Logs for auditing and intrusion detection. Use AWS WAF with Application Load Balancers for web application protection. |
| Monitoring | Monitor VPC Flow Logs for traffic patterns, anomalies, and security events. Use Amazon CloudWatch for monitoring network metrics (e.g., NAT Gateway connection counts, packet drops). Set up alarms for critical events such as high network traffic, connection errors, or unauthorized access attempts detected via Flow Logs. Integrate with AWS Security Hub for centralized security posture management. |
A VPC is a logically isolated virtual network within the AWS cloud, offering scalability, elasticity, and managed services without physical hardware. An on-premises network requires physical infrastructure, manual scaling, and self-management of all components, but offers complete physical control.
Subnets are designed to be AZ-specific to ensure high availability and fault tolerance. If an AZ fails, only resources in that AZ's subnets are affected, while resources in other AZs remain operational, preventing a single point of failure at the network segment level.
Use public subnets for resources that need direct internet access, like Elastic Load Balancers, web servers, or NAT Gateways. Use private subnets for sensitive backend resources like databases, application servers, or internal APIs that should not be directly exposed to the internet.
You cannot change the primary CIDR block of a VPC after creation. However, you can add one or more secondary CIDR blocks to a VPC, which allows you to expand its IP address space without creating a new VPC. These secondary blocks must not overlap with existing CIDRs.
When a subnet is deleted, its IP address range is released back to the VPC's available IP address pool. These IP addresses can then be used to create new subnets or be assigned to network interfaces in other subnets within the same VPC.
Not always. For many AWS services (e.g., S3, DynamoDB, SQS), you can use VPC Endpoints to establish private connectivity directly from your private subnets, bypassing the NAT Gateway and the internet, which can reduce costs and improve performance.
An Internet Gateway enables direct internet access for resources in public subnets, allowing both inbound and outbound connections. A NAT Gateway enables instances in private subnets to initiate outbound connections to the internet but prevents unsolicited inbound connections from the internet, acting as a one-way street.
NACLs are evaluated first at the subnet boundary (stateless, allow/deny rules by number), then Security Groups are evaluated at the instance level (stateful, allow rules only). Both must permit traffic for it to reach or leave an instance. NACLs provide a coarse-grained, subnet-level defense, while SGs offer fine-grained instance-level control.
AWS reserves the first four and the last IP address in every subnet's CIDR block. These are: network address (.0), VPC router (.1), DNS server (.2), future use (.3), and network broadcast address (last IP, e.g., .255 for a /24). These cannot be assigned to instances.
Yes, you can associate an IPv6 CIDR block with your VPC and then assign IPv6 CIDR blocks to your subnets. Instances launched in these subnets can then be assigned IPv6 addresses. You would typically use an Egress-Only Internet Gateway for IPv6 outbound internet access from private subnets.
VPC Flow Logs capture metadata about IP traffic flowing to and from network interfaces in your VPC. They are crucial for network monitoring, security analysis, troubleshooting connectivity issues, and identifying suspicious traffic patterns for compliance and auditing purposes.
Careful IP planning prevents overlapping CIDR blocks, which would block future VPC peering or VPN connections. It also ensures sufficient IP addresses for growth within subnets, avoiding costly and complex re-architecture due to IP exhaustion.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.