Jul 4, 2024
AWS SNOW “PRIVATE” SUBNET – 34.223.14.128/25 – Addressing Disconnected Scenarios with AWS Snow Family
Something you will notice right away in Figure 4.15 is that the EC2 instances are configured for an internal network of 34.223.14.128/25, which is a routable prefix on the internet. At the same time, the “public” IPs mapped to them on their VNIs live on 192.168.100.0/24 – a non-routable RFC 1918 address space. This is counter-intuitive and the opposite of how public subnets work inside an AWS region.
Rest assured this is done for a reason. AWS owns the 34.223.13.128/25 space with IANA, and it is not actually used on the internet. AWS chose to do this to make deployment of Snow Family devices simpler by ensuring the default private subnet is never the same as whatever RFC 1918 address space a customer is using.
Note that while you can make the “public” subnet of the VNIs live on whatever you wish, it is not possible to change the “private” subnet on any AWS Snow Family device – it is always 34.223.14.128/25.
Two VNIs sharing one physical Ethernet port
In certain situations, physical constraints may prevent the ideal configuration of separating VNIs onto different Ethernet ports on an AWS Snowball Edge device:
Figure 4.16 – AWS Snowball Edge device with two VNIs on a single PNI
Figure 4.17 illustrates the two network paths possible from EC2 instance al2-1. This instance can connect to devices outside the AWS Snowball Edge environment via VNI 1, which is configured as a 1-1 NAT entry for 192.168.100.210 mapped to the IP the EC2 instance has configured internally of 34.223.13.193:
Figure 4.17 – AWS Snowball Edge network flows with VNIs
At the same time, al2-1 can communicate directly to centos-1 across the AWS Snowball Edge device’s internal subnet of 34.223.14.128/25.
VLANs on AWS Snow Family
It is possible for a Snow Family device to have VNIs that share the same physical Ethernet port configured for two different RFC 1918 subnets through the use of VLAN tagging. This helps to mitigate some security concerns expressed by customers, but be aware: instances will always be able to talk directly on the internal 34.223.14.128/25 subnet. It is therefore important that security groups are used to limit this.
More Details