Contents

Amazon Web Services (AWS) is built on the IPv4 protocol

Linux Apache MariaDB in the cloud

This guide is designed for those launching Linux instances within a VPC of an AWS region. I started research on it in the summer of 2023 when I saw the announcement that AWS would start charging a predatory price for every hour of use of a public IPv4 address starting February 2024. I started using AWS in 2017 and at that time new users were getting a default VPC for every region. Some accounts created earlier may not be in the VPC environment that is currently the AWS default.

The Amazon Web Services (AWS) is built on the IPv4 protocol and although you can add IPv6 capability including the automatic assignment of a public IPv6 address with the launch of an instance within the VPC you cannot eliminate IPv4. You will be running a dual stack and the foundation of AWS is based on each VPC having a private IPv4 address space with a portion of that space being assigned to a subnet for every availability zone within the region. You can request a public IPv4 address which will be associated with the private IPv4 address via NAT at the gateway.

These changes to the default for an AWS VPC will result in you running dual stack instances with a private IPv4 address and a public IPv6 address.

What does IPv6 get me

A public IP Address without paying $0.005 / Hour = $0.12 / Day ~= $3.60 / Month ~= $43.80 / year.

IPv6 addresses by default are public and uniquily addressable. IPv6 eliminates NAT (Network Address Translation) and instead provides end-to-end connectivity at the IP layer. This is doable because of the huge increase in IP addresses. Every address being unique prevents private address collisions.

Most consider a full migration to IPv6 as inevitable and important for the long-term sustainability of the internet but after 25 years we are at less than 50% adoption by most measures and a huge amount of computers capable of IPv6 are operating a Dual Stack.

Associate an IPv6 CIDR block with each VPC and subnet

I use an Amazon provided IPv6 CIDR block. Amazon provides a /56 block for each VPC. A /56 block is enough for 256 subnets that are each a /64 block. Each subnet has the number of addresses in the whole IPv4 space raised to the power of the number of addresses in the whole IPv4 space which is a mind boggling number. The IPv4 /20 CIDR block has 4096 addresses of which AWS reserves some for it's use so each availability zone provides over 4,000 IPv4 addresses for resources such as instances in the standard configuration.

  • 2600:1f14:3d86:2c00::/56 us-west-2 Oregon LAM AWS VPC IPv6 CIDR my main region
    • 2600:1f14:3d86:2c0a::/64 | 172.31.16.0/20 | us-west-2a availability zone
    • 2600:1f14:3d86:2c01::/64 | 172.31.32.0/20 | us-west-2b availability zone
    • 2600:1f14:3d86:2c0c::/64 | 172.31.0.0/20 | us-west-2c availability zone
    • 2600:1f14:3d86:2c00::/64 | 172.31.48.0/20 | us-west-2d availability zone
  • 2600:1f18:3370:6900::/56 us-east-1 N. Virginia LAM AWS VPC IPv6 CIDR
    • 2600:1f18:3370:690a::/64 | 172.31.16.0/20 | us-east-1a availability zone
    • 2600:1f18:3370:690b::/64 | 172.31.32.0/20 | us-east-1b availability zone
    • 2600:1f18:3370:690c::/64 | 172.31.0.0/20 | us-east-1c availability zone
    • 2600:1f18:3370:690d::/64 | 172.31.80.0/20 | us-east-1d availability zone
    • 2600:1f18:3370:690e::/64 | 172.31.48.0/20 | us-east-1e availability zone
    • 2600:1f18:3370:690f::/64 | 172.31.64.0/20 | us-east-1f availability zone
  • 2600:1f11:e3:1500::/56 ca-central-1 Canada
  • 2600:1f16:1e4e:7000::/56 us-east-2 Ohio
  • 2600:1f1c:920:e400::/56 us-west-1 N. California
  • 2a05:d014:3c:9000::/56 eu-central-1 Frankfurt
  • 2a05:d018:e47:4700::/56 eu-west-1 Ireland
  • 2a05:d01c:dc5:e00::/56 eu-west-2 London
  • 2a05:d012:faa:da00::/56 eu-west-3 Paris
  • 2a05:d016:6d7:ca00::/56 eu-north-1 Stockholm
  • 2600:1f1e:c9c:8300::/56 sa-east-1 Sao Paulo (South America)
  • 2406:da14:f5c:c900::/56 ap-northeast-1 Tokyo
  • 2406:da18:5b1:8700::/56 ap-southeast-1 Singapore
  • 2406:da1c:255:a800::/56 ap-southeast-2 Sydney
  • 2406:da12:e63:8e00::/56 ap-northeast-2 Seoul
  • 2406:da16:57c:ed00::/56 ap-northeast-3 Osaka
  • 2406:da1a:d73:6f00::/56 ap-south-1 Mumbai
  • 2600:1f1a:49a2:3500::/56 ca-west-1 Calgary
  • 2406:da11:79f:c900::/56 af-south-1 Cape Town
  • 2406:da1f:cf5:6d00::/56 ap-southeast-4 Melbourne
  • 2a05:d01e:ccf:6400::/56 me-south-1 Bahrain
  • 2406:da17:250:5f00::/56 me-central-1 United Arab Emirates (UAE)
  • 2a05:d025:b2e:d900::/56 il-central-1 Tel Aviv (Israel)
  • 2406:da1b:ad5:d700::/56 ap-south-2 Hyderabad (India)
  • 2406:da19:cf5:dc00::/56 ap-southeast-3 Jakarta {Indonesia)
  • 2a05:d01a:454:b900::/56 eu-south-1 Milan (Italy)
  • 2a05:d011:9ab:4400::/56 eu-south-2 Spain
  • 2a05:d019:113:7b00::/56 eu-central-2 Zurich
  • 2406:da1e:ee0:4b00::/56 ap-east-1 Hong Kong
  • 2406:da10:8bc3:8000::/56 ap-southeast-5 Asia Pacific (Malaysia)
  • 2406:da14:862d:8d00::/56 ap-aoutheast-7 Asia Pacific (Thailand)

I added and Amazon provided IPv6 CIDR block for each of the regions I already have a VPC in. The region selection dialog told me there were 12 Regions that were not enabled for my account. I selected all to be enabled which was indicated to be a no charge action. Six on the regions went to an enabling status and six others failed. With a repeat request they all became enabled. I then proceeded to add an Amazon provided IPv6 CIDR block for all of the 29 AWS regions I now had an AWS VPC in. By default AWS assigned over 4.2 Sextillion IPv6 addresses for each of the 29 regions where I asked for an IPv6 CIDR block from the AWS pool. AWS reserves five or six of the IPv6 addresses in each subnet for their use.

The default VPC uses the 172.31.0.0/16 IPv4 private address space and subnets use a portion stating with 172.31.0.0/20. The number of availability zones varies by region. The order of subnets does not seem to mach the alphanumeric order of either the availability zone name or ID. For the us-east-1 region the six availability zone names are us-east-1{a,b,c,d,e,f} and I replaced 0::/56 of the IPv6 CIDR for the VPC with {a,b,c,d,e,f}::/64 matching the letter at the end of the availability zone name. I detailed the IPv6 CIDR blocks assigned to my subnets in the us-west-2 Oregon and us-east-1 N. Virginia regions in the above but left it out of the rest for brevity.

Update each subnet to Auto-assign an IPv6 address

The "Auto-assign IPv6 address" attribute for each subnet can only be set to yes after an IPv6 CIDR block has been assigned to the subnet.

By updating all the subnets I will always get an IPv6 address even when not specifying which subnet (or availability zone) to use when launching an instance in that region.

Update route table to route IPv6 traffic

Add a route from ::/0 to the Internet Gateway like the default route from 0.0.0.0/0

Update security group rules

Update security group rules to include rules for IPv6 addresses.

In my case I create a new aws-web-anywhere security group.

I add incoming rules for both IPv4 and IPv6 anywhere for HTTP HTTPS and for Custom TCP on 55520 and 2222 for SSH on alternate port. I add incoming rules for both IPv4 and IPv6 for SSH on the standard port limiting to the private IPv4 address space and the IPv6 CIDR blocks reserved for my AWS VPCs.

In us-west-2 I have rules for IMAPS on an alternate port and a ICMP rule to allow ping. I am not testing IMAPS or ping yet so am leaving these out of the aws-web-anywhere security group for other regions. The aws-web-anywhere security group in the new regions actually more closely matches the aws-web-anywhere-alt-ssh-port security group I use by default in the us-west-2 region by default these days.

Import the public part of a key pair

For my first region I had Amazon create a key pair for me then added the public key for the key pair I use most often in the cloud-init file. For the ca-central-1 and later regions I import that key into a lam-arsc key pair I use to launch a Linux instance.

Add an incoming rule for SSH to us-west-2 Oregon security group

Add an incoming rule for SSH on the standard port from the IPv6 CIDR blocks reserved for the LAM AWS VPC in the new region to the aws-web-anywhere-alt-ssh-port security group rules in the us-west-2 Oregon region where the main aws instance runs. This allows an instance in the region to communicate with the main aws instance during initialization which is required for a successful completion of an instance without a public IPv4 address as part of the IPv6 only workarounds I have developed.

The new SSH rule should actually be added to every region to allow an instance in any region to become my main aws instance but currently my main aws instance is limited to running in the us-west-2d Availablity Zone of the us-west-2 Oregon region.

Create and populate EFS with user resource files

The Linux Apache MariaDB in the cloud LAM Alaska clone initialization counts on an (AWS) Elastic File System (EFS) populated with the ubuntu.tgz and ec2-user.tgz user resource files'

Once the EFS has been created in the region and the aws-efs-mount.bash script modified with the EFS for the new region a new LAM Alaksa Clone instance will be able to mount the EFS for the region during initialization. Some later steps requiring the user resource files will fail but the instance can be used to populate the EFS with the user resource files and a subsequent instance launched into the region should be able to complete all initialization steps.

Log

  • On Thursday, January 9, 2025 I saw a new region had been added and by Friday, January 10, 2025 I can launch a LAM Alaska clone there.
  • On Friday, September 20, 2024 I was able to successfully initialize a LAM Alaska clone in the new ap-southeast-5 Asia Pacific (Malaysia) region after the following:
    • Create EFS (Elastic File System) in the Malaysia region.
    • Modify aws-efs-mount.bash script with EFS for Malaysia region.
    • Populate EFS with the latest ubuntu.tgz and ec2-user.tgz user resource files.
    • Modify Inbound aws-web-anywhere-alt-ssh-port security group rules for Malaysia region IPv6 CIDR
    • While in Cabo I found that EFS had become available in the new Asia Pacific (Malaysia) region and made a reminder to create the EFS and then launch a clone when I got home.
    • It may have been less that two months after the new ap-southeast-5 Asia Pacific (Malaysia) region became available for EC2 that EFS became available.
    • I can now launch a LAM Alaska clone in 30 of the current 34 regions (as of 2024).
    • I don't have access to the US Government us-gov-west-1 and us-gov-east-1 regions or the China cn-northwest-1 and cn-north-1 regions.
  • On Saturday, August 24, 2024 I enabled the new Asia Pacific (Malaysia) region. This is the 30th. region.
    • EFS is not yet available in the brand new Asia Pacific (Malaysia) region.
    • I removed the old region testing tags but added a new EFS is not yet available tag.
  • On Saturday, February 17, 2024 continuing from Friday I completed modifying the last of my 28 AWS VPCs for IPv6.
  • On Thursday, February 15, 2024 I added first test results for the regions I have enabled and modifed for IPv6
    • passed test 01: Ubuntu arm64 packages work without public IPv4 address
    • failed test 01: still shows that instance can get IPv6 address and launch without public IPv4 address in that region
    • passed test 02: Ubuntu arm64 packages work without public IPv4 address with sources.list fix
  • On Tuesday, February 13, 2024 I added all the LAM AWS VPC IPv6 CIDR blocks to the us-west-2 Oregon aws-web-anywhere-alt-ssh-port security group.
    • I did the 'Modify AWS VPC for IPv6' steps on ca-central-1 Canada, us-east-2 Ohio, us-west-1 N. California, and eu-central-1 Frankfurt VPS to add to the us-west-2 Oregon and us-east-1 N. Virginia where I can launch and instance and automatically get a public IPv6 address.
    • All tests of the newest 20240207.1 Jammy Jellyfish 22.04 LTS Ubuntu ami experienced the repo package problem from no IPv4 public address until I got to the eu-central-1 Frankfurt ami which was able to do package commands.
    • I created a euc-fix version of the aws-nwo-lam1-Ubuntu-CloudInit-ARM-No-Public-IPv4 cloud-init file that fully became a LAM AWS clone on arm64 without a public IPv4 address.
  • On Monday, February 12, 2024 I created this page.
    • After creating a security group specifically allowing ssh in the region to be specified at the time of launch I was able to connect.
  • On Sunday, February 11, 2024 I started a couple of instances in the us-east-1 region but was unable to connect. I had first modified the default VPC for the region so that each instance would get an IPv6 public address as well as a private IPv4 address. The private IPv4 address can optionally be tied to a public IPv4 address via NAT at the gateway for the hourly cost started this month.

up Top of this document up Wednesday, January 15, 2025 @ 7:41:52 PM (Alaska Time)