[mdaniel]

I'm not trying to shoot the messenger, but that is pretty up there in the list of dumbest things, and accompanying reason for dumb things, I've heard in quite a long time

Also, I especially enjoy that control-f "iam" or "sts" on https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su... is all hurp-durp as is $(dig sts.api.aws. AAAA) so I guess one should be sure to email themselves some credentials in any such IPv6-only EC2 setup. I wondered if it was just a documentation oversight but https://docs.aws.amazon.com/general/latest/gr/sts.html seems to agree

Now I'm just deathly curious and will try to remember to boot up one of these allegedly IPv6-only EC2 setups to see what running $(aws --debug sts get-caller-identity) does from one of those Instance Profiles

[colmmacc]

You're not shooting the messenger. I signed off on this strategy. In our case, quite a number of customers lock down their IAM policies with IP address based permissions. They have rules like "This account can be used only from our datacenter", or "These EIPs are the only legitimate source for changes" that help them defend against credential theft. There are other defenses, but for some ... this simple defense makes sense. My understanding is that GitHub have a similar challenge, and you can see in their note at: https://docs.github.com/en/enterprise-cloud@latest/organizat...

If we turned IPv6 on like a light switch and suddenly broke all of those customers whose traffic would flip to IPv6 ... that'd be pretty bad. That's not dumb. So instead we have dedicated endpoints for IPv6 and are working with customers to get their policies updated and tested.

For IAM creds on an EC2 instance it's more common to use EC2 Instance Roles. Those are retrieved locally from the IMDS, which is available over IPv6. We have a number of customers, including some large ones, running IPv6-only on their EC2 setups.