Exploring AWS VPC Features｜From Network Architecture to Connectivity Troubleshooting
When you open the AWS VPC console, you see many items: VPCs, subnets, route tables, NAT gateways, security groups, and more.
Knowing what each item is called does not necessarily make it clear how they work together.
This article walks through the main VPC features in an order you can follow when examining an existing network.
VPC and IP addresses
↓
Subnets and routes
↓
Connections to other networks
↓
Traffic controls
↓
Logs and path analysis
The screenshots in this article are examples from an official AWS blog. What you see in your own console will depend on your Region and resources.
Check the Region and VPC First
Open the AWS VPC console and check the selected Region in the upper-right corner.
VPCs and subnets are managed by Region. If you cannot find the VPC you are looking for, check the Region first.
From Your VPCs in the left navigation, select a VPC and review:
- VPC ID
- IPv4 CIDR
- Whether an IPv6 CIDR is assigned
- DNS resolution
- DNS hostnames
- Associated DHCP option set
The CIDR defines an IP address range available to the VPC. For example, you can divide a VPC range such as 10.0.0.0/16 into smaller ranges for subnets.
Image source: AWS News Blog: VPC resource map
Use the Resource Map to See the Overall Layout
After selecting a VPC, open the Resource map tab.
It shows relationships among subnets, route tables, internet gateways, NAT gateways, and other supported resources.
Check:
- How many subnets are in the VPC?
- Which route table is associated with each subnet?
- Is there a route to an internet gateway?
- Is there a route to a NAT gateway?
- Is there a gateway VPC endpoint?
You can select a resource in the map to open its details.
The resource map does not display every type of VPC resource. Check security groups, VPC peering connections, transit gateways, and other resources in their respective console pages.
Explore the VPC Creation Screen
To create a VPC, choose Create VPC.
Selecting VPC and more lets you configure a VPC along with subnets and other network resources. Before creating anything, use the preview to check what will be created.
Image source: AWS News Blog: VPC creation screen
The main choices include:
- VPC CIDR
- Availability Zones
- Number of public and private subnets
- NAT gateway placement
- Whether to create an Amazon S3 gateway endpoint
Some resources, including NAT gateways, incur charges after creation. Review the preview before choosing Create VPC.
Check the Subnets
In Subnets, you can see how the VPC’s IP address range is divided.
Select a subnet and check:
- Subnet ID
- VPC ID
- Availability Zone
- IPv4 CIDR
- Available IP address count
- Auto-assign public IP setting
- Associated route table
A subnet belongs to one Availability Zone. If you want to place an application across multiple zones, you need subnets in those zones.
A subnet is not public simply because its name contains public. Check whether its route table has a route to an internet gateway.
Image source: AWS News Blog: Availability Zone and subnet configuration
Check the Route Tables
In Route tables, you can see where traffic is sent based on its destination.
For example:
| Destination | Target | Meaning |
|---|---|---|
10.0.0.0/16 |
local |
Traffic within the VPC |
0.0.0.0/0 |
igw-... |
Traffic sent to an internet gateway |
0.0.0.0/0 |
nat-... |
Traffic sent to a NAT gateway |
Check both the routes and the subnets associated with the route table.
If a subnet has no explicit route table association, it uses the VPC’s main route table.
Image source: AWS News Blog: Route table relationships
When troubleshooting, check two separate questions: “Does the route exist?” and “Does this route table apply to the subnet I am investigating?”
Check Internet Gateways and NAT Gateways
In Internet gateways, check whether the internet gateway is attached to the intended VPC.
Attaching an internet gateway alone does not give an EC2 instance internet access. Its route table, public IP address, security group, and other settings also matter.
In NAT gateways, check the gateway used to handle outbound connections initiated from private subnets.
Review:
- NAT gateway status
- Public or private connectivity type
- Zonal or regional availability mode
- Subnet, if applicable
- Elastic IP address, if applicable
- Routes from private subnets to the NAT gateway
In a setup using a public NAT gateway, the private subnet’s default route points to the NAT gateway.
Private subnet → NAT gateway
Public subnet → Internet gateway
Image source: AWS News Blog: VPC resource map after creation
Check Security Groups and Network ACLs
Security groups and network ACLs are two ways to control traffic.
| Item | Security group | Network ACL |
|---|---|---|
| Applies to | Network interfaces used by resources such as EC2 instances | Subnets |
| Rules | Allow rules | Allow and deny rules |
| Return traffic | Stateful | Stateless |
For example, if an ALB must reach an application on EC2, the EC2 security group can allow the application port from the ALB’s security group.
In Security groups, check both inbound and outbound rules.
In Network ACLs, check the associated subnets and both inbound and outbound rules. Because network ACLs are stateless, you also need to account for return traffic.
Check VPC Endpoints
In Endpoints, you can review private connections from the VPC to supported services and resources.
Common types include:
- Gateway endpoints: Used with services such as Amazon S3 and DynamoDB
- Interface endpoints: Provide private connectivity to supported services
- Other endpoint types: Used according to the destination and connection requirements
For example, an EC2 instance in a private subnet does not always need to use a NAT gateway to access Amazon S3. An S3 gateway endpoint is another option.
When reviewing an endpoint, check its service name, VPC, and applicable route tables, subnets, or security groups. The relevant settings depend on the endpoint type.
Check Connections to Other VPCs and On-Premises Networks
A VPC may also communicate with networks other than the internet.
| Feature | Common use |
|---|---|
| VPC peering | Connect two VPCs |
| Transit Gateway | Connect multiple VPCs and networks through a central hub |
| Site-to-Site VPN | Connect a remote network over a VPN |
| Direct Connect | Connect using a dedicated network connection |
If your environment uses one of these options, check more than whether the connection exists. Review the route tables on both sides as well.
Also check whether the IP address ranges overlap between networks you intend to connect.
Check DNS and IP Address Management
A connection can fail even when the network route is correct if the instance cannot resolve a DNS name.
Start with the VPC’s DNS resolution and DNS hostnames settings. If your organization uses its own DNS servers, also check the DHCP option set and relevant Route 53 Resolver configuration.
For IP address planning across multiple VPCs, review VPC IP Address Manager (IPAM).
IPAM helps plan, allocate, and monitor CIDR ranges. If you expect to connect multiple environments, checking for overlapping ranges before creating VPCs can prevent problems later.
Use VPC Flow Logs to Inspect Traffic Records
You can check Flow Logs from a VPC, subnet, or network interface.
VPC Flow Logs capture information about IP traffic to and from network interfaces.
When investigating a connection problem, examine:
- Whether the traffic appears in the logs
- Source and destination IP addresses
- Port numbers
- Records showing accepted or rejected traffic
Flow Logs alone may not explain every failure. Compare them with application logs, routes, and security group rules.
Use Reachability Analyzer to Investigate a Path
Reachability Analyzer examines whether your network configuration permits a path from a specified source to a destination.
For example, if an EC2 instance cannot reach an RDS database, you can specify the source, destination, and destination port.
If the destination is unreachable, the analysis can help identify the configuration that blocks the path. This is a configuration analysis tool; it does not send application traffic or guarantee that the application works.
Use Network Access Analyzer to Find Unintended Paths
Reachability Analyzer checks a path you specify. Network Access Analyzer searches for paths that match your chosen conditions.
For example, you can investigate whether an unintended path from an external network to your resources exists.
It can also help you review network access after changing your VPC configuration.
Where Should You Start?
Choose a starting point based on what you need to investigate.
| Question | Start here |
|---|---|
| What does the overall VPC look like? | Your VPCs → Resource map |
| What IP ranges are in use? | Your VPCs, Subnets, IPAM |
| Is a subnet public or private? | Subnets → Route table |
| How does internet access work? | Route tables, Internet gateways, NAT gateways |
| Which traffic is allowed? | Security groups, Network ACLs |
| How does the VPC access AWS services privately? | Endpoints |
| How does it connect to other networks? | Peering connections, Transit gateways, VPN |
| Why is DNS resolution failing? | VPC DNS settings, DHCP option sets, Route 53 Resolver |
| What traffic was recorded? | Flow Logs |
| Where is a network path blocked? | Reachability Analyzer, Network Access Analyzer |
Summary
When examining a VPC, start with the resource map to understand how its main components are connected.
Then follow the traffic path:
Which VPC?
↓
Which subnet?
↓
Which route table?
↓
Where does the route lead?
↓
Do the security group and network ACL allow the traffic?
↓
What do the logs and analysis tools show?
VPC has more detailed settings and connection options than a single article can cover. Start with the main features involved in the traffic path, then investigate individual features as needed.
Top comments (0)