Right now you have a choice in how you configure your network:
1. IPv4 private with NAT gateway and ELB dual stack providing IPv4/IPv6 for clients
2. IPv4 private with 1:1 ephemeral IP (avoids the NAT gateway tax, but now every VM gets a public IPv4 address) and ELB dual stack providing IPv4/IPv6 for clients
3. IPv6 globally unique with no IPv4 and ELB dual stack providing IPv4/IPv6 for clients
With option 1 you end up paying money for the NAT gateway for any outbound traffic instantiated from the instance (not return traffic through the ELB), this costs you 2 IPv4 addresses (1 for NAT gateway, one for the ELB, ignore AZ's and HA for now)
With option 2 you end up not paying for the NAT gateway, but get a free IPv4 address per VM, so N VM's + 1 ELB IPv4 address is N + 1 IPv4 addresses. (NAT Gateways are expensive, even if you have one sitting mostly idle, and don't forget cross AZ traffic if you have only one NAT gateway but instances in multiple AZ's, or you need to spin up multiple NAT gateways).
With option 3 you end up not paying for the NAT gateway, nor do you use a public IPv4 address. This might not work if your instance needs to reach IPv4 parts of the internet, but if its just API servers that communicate internally, they likely don't need to and can use IPv6 for the remaining traffic. Now you have just 1 IPv4 address on the ELB.
If AWS were able to incentivize its customers to deploy their systems in an IPv6 only configuration this would put pressure on the publishers of software to make sure their systems are IPv6 enabled so that their customers could download it, and it would reduce the amount of public IPv4 addresses that are required across AWS as a whole.
Running an IPv6 only core is entirely possible, and makes sense. No more worrying about overlapping IP space (having worked at two companies where they ran out of RFC1918 space and you had to deal with multiple hops to get into various networks, which is no fun), thus simplifying network management.
> having worked at two companies where they ran out of RFC1918 space
I get running out of 192.168.0.0/16, that is easy enough if you have a lot of locations and one /24 per location. But how in earth does one run out of 10.0.0.0/8 IPs, outside of a company merger?!
Often things are allocated and remain unused, but cannot be reallocated. So companies end up with large parts of 10/8 reserved. I recently had to start using some weird 100 addresses (some reserved router protocol) for this reason. It doesn't help that a lot of AWS stuff wants to consume an IPv4 for no good reason (IE, the machine gets an IPv4 but isn't reachable from the internet).
100.64.0.0/10 is reserved for CGNAT providers to assign to CPE. If you don't connect to a CGNAT then there's nothing stopping you from using it, however. Tailscale hands out addresses in 100.100 for that reason (deconflict with customer private networks)
Okay, so I may have left out a key detail that these "companies" were large ISP's and had massive networks of their own with hundreds of thousands of devices, let alone customer devices on that same network that needed to be managed.
When every set top box, cable modem, customer wifi gateway, and all of your routers/management interfaces need RFC1918 space it goes real quick, real fast.
It gets even worse when you are have to have a lab where you can setup infrastructure that looks/feels exactly like production and thus needs similar setups, now do that for testing/staging... and there's doubling of your required IP space already.
10/8 isn't actually that much space. It's only 256 /16s. Either way, mergers are common and it only takes one VPN to another company also using 10/8 to have a problem.
>10/8 isn't actually that much space. It's only 256 /16s. Either way, mergers are common and it only takes one VPN to another company also using 10/8 to have a problem.
I've had to address that with partners/service providers. It just requires a double NAT to make it work. Which is a pain, but necessity is the mother of invention after all.
It's not just NAT, you may also need split DNS, and it's a constant drag on everything because you keep needing to map between two sets of addresses. And it gets way harder when you have multiple or large companies involved, because you do start running out of RFC1918 space.
It's particularly silly because none of that is necessary at all. v6 means that each side has unique prefixes and you don't need to do any of the above. Even if you need to connect to someone without v6, all you need to do is NAT each partner's RFC1918 space into 64:ff9b:1:N::/96, with a different N for each partner. Then they're all accessible in a single unified address space.
>It's not just NAT, you may also need split DNS, and it's a constant drag on everything because you keep needing to map between two sets of addresses. And it gets way harder when you have multiple or large companies involved, because you do start running out of RFC1918 space.
You won't get any argument from me about the utility of IPv6 over IPv4.
I just pointed out that the scenario presented is workable with IPv4 -- in fact, I've done it more than once.
Sometimes you don't get the choice as to what IP version or addressing scheme you use. Not every environment is a "green field."
Back in the early 'teens, when we contracted/partnered with others that had overlapping IPv4 ranges, if I'd told my boss that "it would be so much easier to do this if we were native IPv6. Given me three-six months to migrate the routers at our dozen locations to dual-stack, replacing any equipment (don't worry, that'll cost less than $250,000) that can't support IPv6, then renumber our dozen class B's, re-implement our 802.1x infrastructure, reorganize our firewall policies and the myriad other tasks we need to do to migrate away from IPv4. By the way, I'll pretty much be engaged in this full-time, so you may need to hire a couple guys to do the work I'd otherwise be doing. And don't forget to tell the C-suite that they can't have the application access they wanted until this is all done."
I suppose I could have said that to my boss. But rather than doing that, then updating my resume as I'd probably have had a lot of extra time on my hands, I said "I'll make it happen. Please give me the contact info for my counterpart at the other organization."
Even with the ability to renumber RFC1918 is just not that large, and when you need to summarize routes/BGP you can't easily re-use empty space from one location in another because it'll blow up your routing tables.
could not edit, but probably a lot of people did not understand my comment.
our company often deals with very strict rules so that most services in the internet are blocked.
we use gcp/gke with surge updates, thus we would loose our static access ip.
however now since they explictly need to enable our services we need a static ip and it is way easier to do that with nat gateway.
basically we have a service that connects to http to their external ip which is firewall'd and thus if our client ip's will change it's a headache
