- Newest
- Most votes
- Most comments
To clarify upfront: the restriction you quoted is actually correct. (The auto-generated answer posted earlier on this thread seems not accurate.)
Looking at the AWS documentation's IPv4 CIDR block association restrictions table: if your VPC already uses a 10.0.0.0/8 block, then adding a secondary CIDR from the other RFC 1918 ranges (172.16.0.0/12 or 192.168.0.0/16) is Restricted. The same applies to the other RFC 1918 families. So you cannot freely mix RFC 1918 private ranges — you're effectively locked into the same family.
Why AWS imposes this: Some AWS services rely on cross-VPC and cross-account features that require non-conflicting CIDR blocks on the AWS service side. If customers could freely combine all three RFC 1918 ranges, those combinations could collide with ranges these services use internally, causing routing conflicts. To prevent that, mixing across RFC 1918 families is disallowed.
So what is permitted?
- Another CIDR from the same RFC 1918 family (e.g., if you're on 10.x, another block within 10.0.0.0/8, sized /16–/28, that doesn't overlap an existing CIDR or route)
- Any publicly routable (non-RFC 1918) CIDR, or a block from the 100.64.0.0/10 range
Note: if you want to use both private (RFC 1918) and publicly routable ranges in the same VPC, you must add the RFC 1918 CIDR first when creating the VPC, then add the non-RFC 1918 CIDR as a secondary block.
Source: VPC CIDR blocks - Amazon VPC (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)
I need to clarify that the restriction you've described isn't actually how AWS VPC CIDR blocks work. Based on AWS documentation, you can associate additional IPv4 CIDR blocks from different RFC 1918 ranges to your VPC - you're not locked into the same RFC 1918 family.
However, there are important restrictions when mixing RFC 1918 (private) and non-RFC 1918 (publicly routable) CIDR blocks. If your VPC has a publicly routable CIDR block or uses the 100.64.0.0/10 range, you cannot add CIDR blocks from the RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) or from the 198.19.0.0/16 range as secondary associations.
The reason for these restrictions is that some AWS services use cross-VPC and cross-account features that require non-conflicting CIDR blocks on the AWS service side. To maintain proper routing and avoid conflicts with these AWS service integrations, certain CIDR combinations are not permitted.
If you want to use both RFC 1918 and non-RFC 1918 ranges in the same VPC, you must add the RFC 1918 CIDR first when you create the VPC, and then add the non-RFC 1918 CIDR afterward as a secondary block.
Sources
VPC CIDR blocks - Amazon Virtual Private Cloud
Relevant content
asked 7 years ago
- AWS OFFICIALUpdated a year ago
I think I'm still missing part of the reasoning.
If the purpose of this restriction is to avoid conflicts with AWS-managed services or internally reserved address ranges, why does restricting customers to the same RFC 1918 family help?
The risk of a conflict seems to depend on the specific CIDR block, not on whether it belongs to the 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 range.
For example, if AWS internally uses a subnet within 10.0.0.0/8, allowing me to add another 10.x.x.x CIDR could still create a conflict. On the other hand, adding a non-overlapping 192.168.x.x CIDR might not create any conflict at all.
So I'm struggling to see how restricting secondary CIDRs to the same RFC 1918 family actually prevents the problem described. Is there a more specific technical limitation behind this rule?