1

I'm trying to avoid this new cost (public IPv4) in aws for small projects because it will represent a big percentage of the cost.

In my ECS cluster, I use EC2 instances as capacity providers, therefore, I followed this doc to make every new EC2 instance use IPV6 instead of IPV4 -- which worked.

However these instances are not joining the cluster to be a capacity provider, so the services will not run properly. This cluster was working fine with IPV4. I've tried different configurations in the subnets like:

  • Enable resource name DNS A record on launch
  • Enable resource name DNS AAAA record on launch
  • Hostname type: Resource name
  • Hostname type: IP name
  • Enable DNS64

Also, my security groups already support inbounds and outbounds for both types (IPV4 / IPV6)

Am I missing something or ECS doesn't support this configuration (at least with EC2)? If that is the case, do you have a suggestion on how I can reduce this IPV4 cost? For instance, could I avoid this cost using ECS with Fargate?

I know that Fargate cost is bigger than EC2, but maybe EC2 + IPV4 could be more expensive than Fargate using IPV6

EDIT 1: This is my current route table enter image description here

EDIT 2: I was able to ping6 www.google.com which means the instance has an internet connection. However, checking the agent log (/var/log/ecs/ecs-agent.log) I got the error:

health check [HEAD http://localhost:51678/v1/metadata] failed with error: Head \"http://localhost:51678/v1/metadata\": dial tcp 127.0.0.1:51678: connect: connection refused" module=healthcheck.go
4
  • Can you SSH into one of the EC2 instances and verify it has access to the Internet (using something like a curl command)? It sounds like it can't access the ECS API to register itself with the cluster. If you don't have a VPC endpoint in the VPC for the ECS service, then the instances would need Internet access to connect to the ECS API.
    – mbaird
    Commented Mar 29 at 15:43
  • @MarkB This could be the case to test cURL command, I'm trying to connect to my instance through vpc endpoint, since I cant use ssh without a public dns hostname
    – Matheus
    Commented Mar 29 at 17:08
  • You should be able to use the public IPv6 address to SSH into it.
    – mbaird
    Commented Mar 29 at 17:38
  • @MarkB I was able to ping6 google.com, so I don't think the problem is internet access
    – Matheus
    Commented Mar 30 at 18:59

1 Answer 1

0

I've come across the same issue, for the same reason (thanks Amazon).

Can't add a comment, but wondering if it could be related to DNS64, as DNS64 requires a NAT Gateway. This would mean AWS' ECS API endpoint is IPv4 only.

Have you tested with a NAT Gateway? Although, the cost of a NAT gateway negates the whole point of this exercise.

EDIT: Looks like this is the case, the ECS API endpoint hasn't got an AAAA record (as per https://repost.aws/questions/QU36yKU_NRQR6aH_IFLcbV5Q/ecs-support-for-ipv6-only).

3
  • So, if I could understand your answer, this migration is impossible without the NAT gateway, right? For small project (with a few instances)The nat gateway price is more expensive than the public IPv4. Since you had the same issue as I have, what did do? –
    – Matheus
    Commented Apr 9 at 14:06
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Apr 9 at 21:49
  • Yes, that is correct, you need a NAT gateway for DNS64 as the ECS endpoint hasn’t got an AAAA record. I haven’t done anything yet, apart from reduce the ALB AZs from 3 to 2, which dropped 1 public IP. What you can do is use IPAM insights (for free) to view your public IP utilisation, docs.aws.amazon.com/vpc/latest/ipam/….
    – warnox
    Commented Apr 10 at 16:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .