VPC 다시 배우기 : 서브넷과 Dual-StackRelearning VPC: Subnets and Dual-Stack

I’ve been going over VPCs from scratch while rereading One to Many: Evolving VPC Design, published on the AWS Architecture Blog in 2019. It’s a fairly old post, but its basic concepts still hold today.

If anything, reading it alongside newer features like Dual-Stack VPCs and IPv6-only subnets made ‘why it was designed this way’ even clearer. In this post we’ll cover what a subnet really is, Dual-Stack, and the E-IGW.

While organizing my notes I had a diagram drawn with howtodraw.cloud, so I cut its story into segments and attached each one to the matching paragraph.

A Subnet Is Not an Isolation Boundary

A common misconception when you first learn VPCs is ‘splitting into subnets isolates the network’. I understood it that way for a while myself. More precisely:

• Subnet: a container for routing policy. It has a CIDR range (/16 ~ /28), belongs to one AZ, and is always associated with exactly one route table.
• Isolation: handled by Security Groups (stateful firewalls), per instance, or more precisely per ENI.

In other words, a subnet has no isolation built into it. I said the same thing in a previous post:

In fact, every subnet starts out isolated; they’re simply split into public and private subnets depending on ‘whether they can route to an internet gateway’.

The split between a Public subnet and a Private subnet ultimately comes down to where that subnet’s route table points. Nowhere in the AWS console is there a checkbox like ‘make this subnet private’. We just call it that because we configured the route table that way.

So who does the isolating?

To sum up, a subnet decides ‘where to send traffic’, while SGs and NACLs decide ‘what to let through’. They do different jobs.

Reserved addresses are per subnet too

Within a subnet’s CIDR, five IPv4 addresses (the first four and the last one) are reserved by AWS and can’t be used. So if you create a /28 subnet, only 11 of its 16 addresses are usable.

$$2^{32-28} - 5 = 16 - 5 = 11$$

IPv6 subnets have reserved addresses too. But since there’s no broadcast address, only the first four are reserved.

Dual-Stack VPC: IPv4 Is Required, IPv6 Is Optional

When you create a VPC, an IPv4 CIDR always comes with it. And this primary IPv4 CIDR can’t be removed. The only way is to delete the VPC.

IPv6 is something you add on if you want it. You can take a /56 block provided by Amazon, or bring your own block with BYOIP. A VPC with IPv6 added like this is called a Dual-Stack VPC.

Subnets come in three flavors you can mix

The interesting part is at the subnet level. Inside a Dual-Stack VPC, you can freely combine three kinds of subnets.

Instances in an IPv6-only subnet have no IPv4 address on their ENI at all. Even though the VPC has IPv4, a particular subnet inside it can leave IPv4 out entirely.

Constraints of IPv6 subnets

Unlike IPv4 subnets, an IPv6 subnet CIDR is fixed at /64. You can’t choose the prefix length. Splitting the VPC’s /56 block into /64 pieces gives you 256 possible subnets.

$$2^{64-56} = 2^{8} = 256$$

Other things worth knowing before you use IPv6-only subnets:

• Only Nitro-based instance types are supported.
• To talk to IPv4-only destinations (external APIs and so on), you need the DNS64 + NAT64 combination. Route 53 Resolver synthesizes an IPv6 address from the IPv4 address, and the NAT gateway does the actual translation.
• Some services still offer only IPv4 endpoints, so check whether the services you use support IPv6 before adopting it.

Why look at IPv6 now?

Since February 1, 2024, every public IPv4 address has been billed by the hour. No exceptions, whether the address is in use or an unused EIP. Once you’re running hundreds of instances, the amount is hard to ignore.

That’s why more teams are looking at IPv6-only subnets in practice. It used to be ‘something we’ll have to do someday’; now it shows up right on the bill.

E-IGW: Why IPv6 Doesn’t Need NAT

IPv6 has such a huge address space that, unlike IPv4, it doesn’t need ‘NAT to share scarce public IPs’. The IPv6 address assigned to an instance is already a Global Unicast address — in other words, a public address.

But that raises a problem.

Then what do I use when I want to block inbound and allow only outbound, like a private subnet?

That’s where the Egress-Only Internet Gateway (E-IGW) comes in.

It controls direction, not hides addresses

The key point is that an E-IGW doesn’t change or hide addresses the way NAT does. The instance’s IPv6 address goes out fully visible. All the E-IGW does is control the direction of connections.

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'lineColor': '#fff',
      'primaryTextColor': '#fff',
      'primaryBorderColor': '#fff',
      'tertiaryColor': '#fff'
    }
  }
}%%

flowchart LR
    EC2A["EC2
Public Subnet"]
    EC2B["EC2
Private Subnet"]
    IGW["Internet
Gateway"]
    EIGW["Egress-Only
Internet Gateway"]
    NET(["Internet"])

    EC2A <--> IGW
    IGW <--> NET
    EC2B -- "initiates outbound" --> EIGW
    EIGW -- "return traffic only" --> EC2B
    EIGW <--> NET

> Figure 1. An IGW is bidirectional; an E-IGW only allows outbound-initiated connections

• Regular IGW: allows two-way communication. (Public subnet)
• E-IGW: a stateful gateway that lets through only the return traffic of connections initiated outbound. Connections started from the internet side can’t get through. (Private subnet)

Also, in the route table associated with a subnet, the ::/0 route can point to only one target, IGW or E-IGW. Which one you use depends on whether you’re designing that subnet as public or private.

Can’t I just use an IGW and block with SGs?

Technically, yes. Attach an IGW and open no inbound rules in the SG, and the result looks similar. But the defense sits at a different layer.

‘IGW + SG’ relies entirely on instance-level settings for inbound blocking. The moment someone accidentally adds a ::/0 inbound rule to an SG, the instance is exposed to the internet.

The E-IGW, by contrast, removes the path at the routing level altogether. Given that IPv4 private subnets were originally designed so that ‘the NAT gateway blocks inbound at the routing level’, the E-IGW is essentially that same design philosophy carried over to IPv6.

SGs at the instance level, the E-IGW at the routing level: two different layers guaranteeing the same goal (blocking inbound) twice over, a Defense in Depth setup.

Summing It Up in Route Tables

Everything so far boils down to a single set of route tables. Here the VPC CIDR is 10.0.0.0/16 and the IPv6 CIDR is 2001:db8:1a00::/56.

Route table for the public subnet

Route table for the private subnet

A NAT gateway for IPv4, an E-IGW for IPv6. Same role, different protocol. Understand this table and you’ve essentially figured out what public and private subnets really are.

Wrapping Up

Here are the key takeaways from revisiting VPCs:

• A subnet is a routing container, not an isolation boundary; isolation is the job of SGs and NACLs.
• A VPC always requires IPv4, and IPv6 is added optionally. This is called a Dual-Stack VPC.
• Per subnet, you can freely combine IPv4-only / Dual-Stack / IPv6-only.
• IPv6 doesn’t need NAT because its addresses are already public.
• An E-IGW doesn’t hide addresses; it’s a direction-control device that blocks inbound connection initiation at the routing level.

In the next part, we’ll look more closely at public subnets and the IGW, and cover a highly available NAT gateway setup for private subnets.

Thank you! 😊

References

• AWS Architecture Blog - One to Many: Evolving VPC Design
• AWS docs - IP addressing for your VPCs and subnets
• AWS docs - Egress-only internet gateways
• AWS docs - Subnet CIDR blocks