# AWS VPC Basics for Azure Engineers: Subnets, Routes and Security Groups

> Map Azure VNet concepts to AWS VPC: subnets and availability zones, route tables and internet gateways, security groups versus NSGs, and network ACLs.

Source: https://www.epifive.com/blog/aws-vpc-basics-for-azure-engineers · Published 2026-10-25 · EpiFive

## Key takeaways

- An AWS subnet resides in one Availability Zone, so you build a subnet per zone, whereas Azure virtual networks and subnets span all zones in a region.
- In AWS a public subnet is defined by a route to an internet gateway in its route table, not by a setting on the subnet.
- AWS security groups are stateful allow-only rules attached to resources, while network ACLs are stateless subnet-level rules with allow and deny, evaluated by rule number.
- A new AWS VPC has a main route table with a local route for in-VPC traffic, and a subnet uses the main table unless you associate another.
- AWS routing uses longest prefix match, like Azure, but Azure also adds system routes automatically and lets user-defined routes override them.

An AWS VPC is the equivalent of an Azure virtual network: a private address space divided into subnets, with route tables to steer traffic and filters to allow or block it. The main differences for an Azure engineer are that AWS subnets live in a single Availability Zone, internet access depends on an explicit route to an internet gateway, and security groups are allow-only and attach to resources rather than to subnets.

## Who this is for and what you will have at the end

This guide is for engineers who know Azure virtual networking and need to read, design or troubleshoot an AWS VPC. It maps each Azure concept to the AWS component and highlights the behaviors that differ.

At the end you will have:

- A side-by-side concept map from VNet to VPC.
- An understanding of subnets, route tables, gateways, security groups and network ACLs in AWS.
- A reading of the "public subnet" idea, which has no Azure counterpart.
- A troubleshooting table for the first connectivity problems Azure engineers hit in AWS.

## Concept map

| Azure | AWS | Notes |
|---|---|---|
| Virtual network (VNet) | VPC | Logically isolated virtual network you define |
| Subnet (spans all zones in the region) | Subnet (resides in one Availability Zone) | AWS needs a subnet per zone for zone resilience |
| System routes plus route table (UDR) | Route tables with a local route | AWS has a main route table plus custom ones |
| Default outbound access (existing virtual networks) or explicit outbound method such as NAT gateway or public IP | Internet gateway plus route plus public IP | Nothing is routed to the internet until you add it |
| NAT gateway | NAT gateway | AWS public NAT gateway lives in a public subnet |
| Network security group (NSG) | Security group, plus network ACL | Security groups are allow-only, NACLs are subnet-level |
| VNet peering | VPC peering connection | Routes traffic between the resources in two VPCs |
| VPN gateway, ExpressRoute | Virtual private gateway, Direct Connect | Site-to-Site VPN connects VPCs to on-premises |
| Hub-and-spoke with Virtual WAN or gateways | Transit gateway | Central hub for VPCs, VPNs and Direct Connect |
| Private endpoint, service endpoint | VPC endpoint | Private access to AWS services without an internet gateway or NAT |
| NSG flow logs, VNet flow logs | VPC Flow Logs | Capture IP traffic to and from network interfaces |

Both Azure Virtual Network and Amazon VPC are free to use. In AWS there are charges for some components, such as NAT gateways, and for public IPv4 addresses.

## Subnets and availability zones

This is the first structural difference. In Azure, virtual networks and subnets span all availability zones in a region, so a zonal VM doesn't depend on the subnet. In AWS, a subnet is a range of IP addresses in the VPC and must reside in a single Availability Zone.

Practical effects:

- For resilience across zones, create at least one subnet per zone you use, and place instances or load balancer nodes in each.
- Route tables, network ACLs and subnet tags are per subnet, so a three-zone design repeats those settings, usually with a shared route table for subnets with the same role.
- Your AWS account includes a default VPC in each Region, set up so that you can launch and connect to EC2 instances immediately. You can also create additional VPCs with the subnets, IP addresses, gateways and routing that you need. Treat the default VPC as a convenience and build deliberate VPCs for real workloads.

AWS VPCs can have both IPv4 and IPv6 addresses assigned, and a VPC with both gets a local route for each.

## Route tables

A route table holds routes. Each route has a destination (a CIDR block or prefix list) and a target, such as an internet gateway, NAT gateway, VPC peering connection or VPN connection.

Key terms:

| Term | Meaning |
|---|---|
| Main route table | Comes with the VPC. Controls routing for every subnet that isn't explicitly associated with another table. |
| Custom route table | One you create. |
| Local route | A default route for communication within the VPC. One for IPv4, and one for IPv6 if the VPC has IPv6. |
| Subnet route table | A route table associated with a subnet. |
| Gateway route table | A route table associated with an internet gateway or virtual private gateway (edge association). |
| Propagation | With a virtual private gateway attached and propagation enabled, VPN routes are added to subnet route tables automatically. |

### Route selection

AWS directs traffic using the most specific route that matches, the longest prefix match, as Azure does. If routes tie, further rules apply: static routes (internet gateway, NAT gateway, peering, transit gateway, gateway endpoints) win over propagated routes with the same destination, and among propagated routes Direct Connect routes come before VPN routes. A route table such as the following sends most traffic to the internet, one range to a peering connection, and VPC traffic locally:

```text
Destination        Target
10.0.0.0/16        local
172.31.0.0/16      pcx-11223344556677889
0.0.0.0/0          igw-12345678901234567
```

Compare this with Azure. In Azure, each subnet automatically gets a route table with system routes (the virtual network prefix with next hop "Virtual network", `0.0.0.0/0` to "Internet", and a set of private ranges with next hop "None"). You only create a route table to override them with user-defined routes, and each subnet has zero or one table. In AWS every subnet has exactly one route table, either the main one or an explicit association, and the only route you don't write yourself is the local route.

## Public and private subnets

AWS has no "public" flag on a subnet. The terms come from routing:

- A subnet associated with a route table that has a route to an internet gateway is a **public subnet**.
- A subnet associated with a route table that does not have a route to an internet gateway is a **private subnet**.

The internet gateway is a horizontally scaled, redundant, highly available VPC component. It provides a target in route tables for internet-routable traffic and, for IPv4, performs one-to-one NAT between an instance's private address and its public IPv4 or Elastic IP address.

For an instance to be reachable from the internet over IPv4, all of these must be true:

1. An internet gateway is attached to the VPC.
2. The instance's subnet route table has a route (often `0.0.0.0/0`) to the internet gateway.
3. The instance has a public IPv4 address or an Elastic IP address.
4. Security group and network ACL rules allow the traffic.

An instance in a private subnet can't communicate with the internet even if it has a public IP address, because the route is missing. A nondefault VPC doesn't come with an internet gateway or the route, which differs from a default VPC and from the default outbound access that existing Azure virtual networks can still provide. New Azure virtual networks created with API versions released after March 31, 2026 use private subnets by default, which is closer to the AWS behavior. See /blog/azure-default-outbound-access-nat-gateway for the Azure side of that behavior.

### NAT gateway

A NAT gateway lets instances in a private subnet connect to services outside the VPC, while external services can't initiate connections to them. The default type is **public**: you create it in a public subnet and associate an Elastic IP address at creation. Private subnets then have a route (for example `0.0.0.0/0`) to the NAT gateway, and the NAT gateway routes to the internet gateway. A **private** NAT gateway connects to other VPCs or on-premises networks through a transit gateway or virtual private gateway and can't have an Elastic IP address. Connections must always be initiated from within the VPC that contains the NAT gateway.

## Security groups versus NSGs

Both are stateful, but they differ in important ways.

| Feature | AWS security group | Azure NSG |
|---|---|---|
| Rule types | Allow rules only | Allow and deny |
| Rule ordering | No priority numbers; you specify source or destination, port range and protocol for each rule | Priority 100 to 4096, lowest number first, processing stops at a match |
| Attached to | Resources such as EC2 instances (via network interfaces); multiple groups per resource | A subnet or a network interface |
| New or default behavior | Only traffic allowed by a rule reaches the resource. The default group allows inbound from members of itself and all outbound. | Default rules: allow VNet inbound, allow load balancer inbound, deny all other inbound, allow VNet and internet outbound, deny all else |
| Source or destination | CIDR, prefix list or another security group | Any, IP, CIDR, service tag or application security group |
| Stateful | Yes | Yes |

Detail worth knowing:

- A security group controls traffic allowed to reach and leave its resources. The only traffic that reaches an instance is traffic allowed by the group's rules. If no rule allows SSH, you can't SSH in.
- Responses to allowed traffic are allowed regardless of rules in the other direction.
- Security groups can reference other security groups, which makes rules such as "app tier accepts traffic from the web tier group" independent of IP addresses. That plays the role of Azure application security groups.
- Security groups do not filter traffic to and from Amazon DNS, DHCP, EC2 instance metadata, ECS task metadata, Windows license activation, the Time Sync Service and the reserved addresses used by the default VPC router.
- Each security group's name must be unique within the VPC and can't start with `sg-`. A VPC's default security group is named "default", can be edited but can't be deleted, and is attached to any resource launched without a specified group. Create purpose-specific groups instead.
- Best practice from AWS: when you open ports 22 or 3389, authorize specific address ranges rather than `0.0.0.0/0` or `::/0`, and don't open large port ranges.

In Azure you can add a deny rule to block a source. In AWS security groups you can't, so blocking a specific address needs a network ACL.

## Network ACLs

A network ACL allows or denies traffic at the subnet level. There's no direct Azure equivalent, since an NSG can be applied to a subnet and supports deny rules, but a NACL has differences:

- Each subnet must be associated with a network ACL. Without an explicit association, it uses the default network ACL. A subnet has one network ACL at a time, and one NACL can serve many subnets.
- Rules are numbered 1 to 32766 and evaluated from the lowest number. The first match applies and no further rules are evaluated. Use gaps such as 10 or 100 between rule numbers.
- Rules are evaluated when traffic enters or leaves the subnet, not for traffic routed within a subnet.
- NACLs are **stateless**. A rule allowing inbound traffic doesn't automatically allow the response, so you need matching outbound rules.
- Like security groups, NACLs don't filter DNS, DHCP, instance metadata and the other reserved traffic. They also can't block DNS requests to the Route 53 Resolver, so use Route 53 Resolver DNS Firewall for that.

A common approach is to leave the default NACL in place and manage access with security groups, then use custom NACLs for subnet-wide deny rules or an additional layer.

## Connecting VPCs and other networks

- **VPC peering** routes traffic between two VPCs.
- **Transit gateway** is a central hub that routes between VPCs, VPN connections and Direct Connect connections. For the Azure parallel, see /blog/azure-hub-spoke-network-firewall.
- **VPC endpoints** connect to AWS services privately, without an internet gateway or NAT device.
- **Site-to-Site VPN** connects a VPC to an on-premises network.

## Troubleshooting for Azure engineers

| Symptom | What to check |
|---|---|
| Instance in a new VPC can't reach the internet | Is there an internet gateway attached? Does its subnet route table have a route to it? Does the instance have a public IPv4 or Elastic IP address? |
| Private subnet instance can't download packages | Add a NAT gateway in a public subnet and a route to it from the private subnet's route table. |
| Public IP assigned but no inbound connection | The subnet is private if its route table has no internet gateway route. Also check the security group and NACL. |
| SSH or RDP times out | The security group needs an inbound rule for port 22 or 3389 from your address range. If no rule allows SSH, you can't connect. |
| Inbound works but replies are lost | Check the NACL. It is stateless and needs outbound rules for the response ports. |
| Can't block one address with a security group | Security groups have no deny rules. Use a network ACL deny rule. |
| Traffic to a peered VPC fails | Check that the route tables have a route for the other VPC's CIDR with the peering connection as target, then check security groups and NACLs. |
| A rule you expected to run first doesn't | Security groups have no priority numbers. NACLs evaluate by lowest rule number first, and the first match wins. |

## Checklist

- Plan one subnet per Availability Zone for each tier.
- Make public subnets only for resources that need direct internet exposure, such as load balancers and NAT gateways.
- Use a NAT gateway for private subnet outbound access.
- Create purpose-specific security groups, and reference groups instead of CIDR ranges between tiers.
- Restrict ports 22 and 3389 to specific ranges.
- Use network ACLs for deny rules, and remember they are stateless.
- Turn on VPC Flow Logs for troubleshooting.
- Review charges for NAT gateways and public IPv4 addresses.

## References

- What is Amazon VPC: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
- Route table concepts: https://docs.aws.amazon.com/vpc/latest/userguide/RouteTables.html
- How route priority works: https://docs.aws.amazon.com/vpc/latest/userguide/route-tables-priority.html
- Internet gateways: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
- NAT gateways: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
- Security groups: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
- Default security groups: https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html
- Network ACLs: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
- Azure virtual networks overview: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
- Azure network security groups: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
- Azure virtual network traffic routing: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

## Frequently asked questions

### What is the AWS equivalent of an Azure virtual network?

The AWS equivalent is the Amazon VPC, a logically isolated virtual network you define in your AWS account. Both contain subnets, route tables and traffic filtering. A key structural difference is that an AWS subnet must reside in a single Availability Zone, whereas Azure virtual networks and subnets span all availability zones in a region.

### Are AWS security groups the same as Azure NSGs?

They are similar but not identical. Both are stateful. AWS security groups contain only allow rules, attach to resources such as network interfaces, and let through only the traffic their rules allow. Azure NSGs have allow and deny rules with priorities from 100 to 4096 and can be associated with a subnet or a network interface.

### What makes a subnet public in AWS?

A subnet is public when its route table has a route to an internet gateway. Instances in it also need a public IPv4 address or an Elastic IP address to communicate over the internet. A subnet whose route table has no such route is private, even if its instances have public IPs.

### Do I need a NAT gateway in AWS like in Azure?

Usually yes, if private instances need outbound access. Azure virtual networks created with API versions released after March 31, 2026 use private subnets by default and need an explicit outbound method, and Microsoft recommends a NAT gateway for most cases. In AWS, instances in a private subnet have no route to the internet unless you add one, typically a public NAT gateway placed in a public subnet. The NAT gateway lets private instances connect out but not receive unsolicited inbound traffic.