AWS Subnets and Availability Zones — Why You Cannot Move One

An AWS subnet is a range of IP addresses carved out of a VPC’s CIDR block. Every subnet lives in exactly one Availability Zone, and that binding is set at creation and cannot be changed.

This is the answer to the most common question about them: you cannot move a subnet to a different Availability Zone. There is no API call, no console option and no workaround. The subnet’s AZ is part of its identity.

Why It Is Immutable

An Availability Zone is one or more physically separate data centres with independent power, cooling and networking. The subnet’s address range is announced within that zone’s physical network fabric. Moving it would mean re-announcing that range in a different facility while resources still hold addresses from it, which is not a configuration change but a physical routing change.

The design intent is also worth noting: because subnets are AZ-bound, you cannot accidentally build something that appears redundant but sits entirely in one facility. Spreading across zones requires spreading across subnets, deliberately.

What to Do Instead

If resources are in the wrong AZ, you create a new subnet in the target zone and migrate to it:

1. Create a subnet in the target AZ with a CIDR block that does not overlap any existing subnet in the VPC.
2. Associate a route table, a new subnet inherits the VPC’s main route table, which may not be what you want.
3. Associate the correct Network ACL, if you use non-default ones.
4. Recreate resources in the new subnet. EC2 instances cannot change subnet either, create an AMI, launch from it in the new subnet, then terminate the original.
5. Update anything referencing the old subnet, Auto Scaling groups, load balancer subnet mappings, RDS subnet groups, Lambda VPC configuration.
6. Delete the old subnet once nothing remains in it. Note that S3 buckets and other regional services are not subnet-bound and are unaffected.

Public vs Private Subnets

AWS does not have a “public subnet” setting. The distinction is entirely determined by the route table:

A subnet whose route table sends 0.0.0.0/0 to an Internet Gateway is public. Change that route and the same subnet becomes private. Nothing else about the subnet changes.

Note that the NAT Gateway must sit in a public subnet while serving private ones. Placing it in the private subnet it is meant to serve is a common mistake and produces no internet access at all.

Sizing Subnets

AWS reserves five addresses in every subnet, not the two you would expect from standard networking:

So a /28 gives 11 usable addresses, not 14. On a /24 the loss is negligible; on small subnets it matters.

Allowed sizes are /28 (smallest) to /16 (largest). Subnets cannot be resized after creation either, plan with room to grow, and remember that EKS and ECS consume addresses far faster than instance counts suggest, because every pod or task takes an ENI address.

Designing a VPC Properly

A layout that avoids most of the problems above:

VPC: 10.0.0.0/16

AZ-a:  10.0.0.0/24    public    (ALB, NAT GW)
       10.0.10.0/24   private   (application)
       10.0.20.0/24   private   (database)

AZ-b:  10.0.1.0/24    public
       10.0.11.0/24   private
       10.0.21.0/24   private

AZ-c:  10.0.2.0/24    public
       10.0.12.0/24   private
       10.0.22.0/24   private

Three points about this:

• Use at least two AZs, ideally three. Load balancers and RDS Multi-AZ both require subnets in multiple zones.
• Leave gaps between ranges. The layout above uses only a fraction of the /16, so new tiers can be added without renumbering.
• One NAT Gateway per AZ. A single shared NAT Gateway is both a single point of failure and a source of cross-AZ data transfer charges, which are billed in both directions.

Security Groups vs Network ACLs

The stateless behaviour of NACLs is the thing that bites people. If you tighten a NACL and forget to permit the ephemeral port range (1024–65535) inbound, outbound connections open and their replies are dropped, connections hang rather than fail cleanly. Security Groups have no such problem, which is why most designs leave NACLs at their default and do the work in Security Groups. See stateful vs stateless firewalls for why this matters.

Frequently Asked Questions

Can I change a subnet’s Availability Zone?

No. The AZ is fixed at creation. Create a new subnet in the target zone and migrate resources to it.

Can I resize a subnet?

No. The CIDR block is immutable. You can add another CIDR block to the VPC and create new subnets from it, but an existing subnet cannot grow.

Why do I only get 251 usable addresses in a /24?

AWS reserves five per subnet, network, VPC router, DNS, one for future use, and the broadcast address.

How do I make a subnet public?

Point its route table’s 0.0.0.0/0 route at an Internet Gateway. That is the only thing that distinguishes public from private.

Can a subnet span multiple Availability Zones?

No, one subnet, one AZ. High availability comes from creating subnets in several zones and spreading resources across them.

Do I need a NAT Gateway in every AZ?

Not strictly, but you should. A single NAT Gateway is a single point of failure for every private subnet routing through it, and it generates cross-AZ data transfer charges for traffic from other zones.