Sameep Sigdel
Back to Blog

How Far Can You Actually Go IPv6-Only on AWS?

Sameep Sigdel

IPv6 has been "just around the corner" for as long as I can remember. But lately it feels more real: my home network runs IPv6, my phone uses it, and modern ISPs support it by default. So I got curious: how far could I actually take an IPv6-only setup on AWS today?

I wanted to run EC2 instances with no public IPv4 addresses and use AWS Systems Manager Session Manager for access. A genuinely IPv6-first setup, not just dual-stack with IPv6 as an afterthought.

It went further than I expected, right up until it didn't. Here's what I found.

What I Was Trying to Build

The setup was intentionally minimal:

  • EC2 instance in a public subnet, with IPv6 enabled but no public IPv4 assigned
  • AWS Systems Manager Session Manager for secure remote access

Each piece exists and is well-supported. The question was whether they'd all work together in a genuinely IPv4-free setup.

Setting Up IPv6 Networking

The first thing I ran into was a missing route. After enabling IPv6 on the VPC and subnet, the instance had an IPv6 address but couldn't reach the internet.

The fix:

Destination: ::/0
Target: Internet Gateway

After adding the IPv6 default route, instance-level connectivity worked exactly as expected:

Instance networking was solid. On to SSM.

Debugging SSM With SSH as a Break-Glass Tool

Session Manager connections started timing out. I temporarily enabled SSH as a fallback, not as a permanent method, just to get inside the instance and see what was happening. Since the instance was in a public subnet with a working IPv6 address, SSH worked fine over IPv6 directly:

ssh user@2600:1f18:xxxx:xxxx::1

From inside the instance, I ran:

# Confirm how SSM agent was installed
snap list | grep ssm

# Works on Amazon Linux, Debian, RHEL, SLES, Oracle Linux:
sudo systemctl status amazon-ssm-agent

# Ubuntu installs the agent via snap by default — use this instead:
sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

# Check outbound connectivity to SSM endpoint
curl -v https://ssm.us-east-1.amazonaws.com

# Review SSM agent logs
sudo journalctl -u snap.amazon-ssm-agent.amazon-ssm-agent.service -n 50

# Check DNS resolution for SSM endpoint
dig ssm.us-east-1.amazonaws.com

The agent was healthy. The logs pointed somewhere else.

Where It Broke

The SSM agent was running, the instance networking was working, but Session Manager kept timing out:

dial tcp 52.46.x.x:443: i/o timeout

The DNS lookup for ssm.us-east-1.amazonaws.com resolved to an IPv4 address. With no public IPv4, there was no path to reach it.

SSM public endpoints are currently IPv4-only. The instance was perfectly capable of IPv6, but the service layer is still catching up.

This is documented:

It's a useful reminder that VPC-level IPv6 and managed service endpoint IPv6 are two separate things. Your instances can be fully IPv6-capable while the services they connect to still resolve over IPv4.

Conclusion

Going IPv6-only on AWS is closer to reality than I expected. The instance and VPC layer is solid. The wall is SSM requiring IPv4 connectivity, either through a public IPv4 path or PrivateLink VPC endpoints, which keep traffic inside AWS's network but come at an added cost.

This post is based on hands-on exploration of AWS IPv6 networking and Systems Manager connectivity. All architecture diagrams represent tested configurations.

Back to Blog