Carving out address spaces for Subnets and VPNs – AWS vs Azure

A  Sample break up of addresses

Traffic flows from the internet to an ALB to a  Firewall (F5, Palo Alto ….) appliance. And into your application subnets (WEB subnet, APP Subnet and DATA subnet) to be specific.

In addition, access to all instances is via a jumpbox (in a jumpbox subnet).

A proposed CIDR breakout might look like this (on AWS using two AZs)

Parent Block – 172.30.0.0/22   – 1022 Hosts  OR 172.30.0.0/16 (65534 Hosts)

Public Subnets – AZ 1

1. 172.30.0.0/28 – Public ALB Subnet    – 14  addresses
2. 172.30.1.0/28 – Public F5 / PaloAlto Subnet  – 14 IPs
3. 172.30.2.0/28 – Public Jump Box Subnet   – 14 IP Addresses

Private Subnets – AZ 1

1. 172.30.3.0/24 – Private DATA Subnet   – 254 addresses
2. 172.30.4.0/24 – Private APP Subnet    – 254 addresses
3. 172.30.5.0/24 –Private WEB Subnet    – 254
4. 172.30.6.0/24 – Shared Services Subnet   – 254

Private Subnets – AZ 2

172.30.6.0/24 – Private DATA Subnet for data mirror/replication in AZ2 (on AWS)

Site to Site VPN address spaces – AWS vs Azure

In AWS, when we create a VPN tunnel between your data center and AWS (aka a Site to Site VPN), there isn’t any requirement on private address spaces (except that they don’t overlap with the on premises address spaces).

In other words, you DO NOT need to carve out a block from your on prem block of IPs (as seen in the diagram below).  

Your on premises private address space is 172.x.x.x and the VPC address space is a 10.x.x.x

Azure Site to Site VPN address spaces

Azure should not REQUIRE you to carve out a block from your existing block of on-premises addresses ( This restriction essentially reduces the number of private IPs you can use on prem and on Azure). However, the documentation is misleading and it would APPEAR that you are required to carve out the available addresses from your current block of on premises addresses.