Containers-roadmap: [Fargate] [EIP support]: add Elastic IP support for Fargate

[squalo-villa]

Tell us about your request
New feature to allow EIP to be added to containers created with Fargate

Which service(s) is this request for?
Fargate

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We're deploying a single container for a webapp into ECS with Fargate, and we don't need a ALB because the app is simple. We are trying to avoid a new IP for the container every time we deploy via Cloudformation, because it'd make the approach not sustainable.

Are you currently working around this issue?
ALB, but it's money we don't want to spend, so we have to take a decision here.

Additional context
no

Attachments
-

[davidwav]

I would also really like to see this feature implemented.

It is inconvenient to manually update the DNS settings each time we redeploy a server on ECS Fargate.

Tell us about your request
New feature to allow EIP to be added to containers created with Fargate ECS

Which service(s) is this request for?
Fargate (ECS)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We're deploying a single container for a webapp into ECS with Fargate, we are trying to avoid a new IP for the container every time we deploy.

Are you currently working around this issue?
Manually, time consuming

[soukicz]

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Sheduled task to download data from external service that is IP restricted.

Are you currently working around this issue?
Lambda that starts EC2 instance with user-data

[benjaminwai]

+1 as above - scheduled task to upload/transfer data TO external service that is IP restricted. Same workaround with EC2 instance.

[rjpereira]

+1 When using Fargate as a proxy fleet is important to have fixed IPs

[mbergkvist]

@soukicz @benjaminwai If your task is launched in a private subnet with a NAT GW with EIP, wouldn't that help in your case?

[soukicz]

@soukicz @benjaminwai If your task is launched in a private subnet with a NAT GW with EIP, wouldn't that help in your case?

It would but that NAT GW would run 99% of time without doing anything and I would pay $40/month for GW to support fargate task that costs $0.2$/month.

I am okay to pay reservation fee for public IP but paying for GW that does nothing most of the time doesn't really feel like best practice.

[AyliD]

I want to run fluentd server on fargate and fluent-bit to forward events to it, for that i need EIP, i have only 1 instance for fluentd and loadbalancer feel like overkill.

[fluxx-sleblanc]

+1
Tell us about your request
Need a mechanism for ECS container instances (EC2 or Fargate) to have elastic IP addresses.

Which service(s) is this request for?
ECS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We have some integrations that require our instance IP addresses to be whitelisted by our clients. If the ECS container restarts, this IP is changed.

Are you currently working around this issue?
We have a Lambda and DynamoDB table set up to sync Route53 hostnames with ECS container IPs, but this doesn't help us at all when our clients can't use DNS to whitelist.

[vtzan]

The solution with the NAT GW doesn't work for a SIP service which needs 1:1 NAT like ec2 instances to work without issues.

So yes elastic IP on a fargate is needed in our case.

Thanks

[PadillaBraulio]

We have an specific requirement where all tasks need to connect to a client using differents IPs, so each task should have their own Public IP in order to make it work.

Thanks

[carlosrodf]

For our use case the client needs to be able to reach our service from a whitelisted set of ips, and it is not a loadbalanced solution because each container is spun up by client request.
Not being able to assing EIPs to fargate containers really prevents us from using the service for this specific workload

[vtzan]

Tell us about your request
New feature to allow EIP to be added to containers created with Fargate

Which service(s) is this request for?
Fargate

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We're deploying a SIP Service into ECS with Fargate. There are 2 common problems here
1)SIP Phones or PBXs need to register to the IP address of the endpoint for incoming calls to work. Example is when call initiated from ECS Fargate ---> Customer SIP phone. Sip phone isn't registered to this Fargate public IP so its discarding this incoming call request. SIP Phones are registered to the ALB public IP so they only allow this IP for incoming call requests by default.

2)System administrators (customers) need to known SIP telephony IP ranges to allow them on their firewall for security purposes and ISO Certifications so only elastic IP would solve that issue.

Example scenario of the problem
SIP phone registers to ALB Elastic IP: 1.1.1.1 (which forwards to 2.2.2.2) will receive incoming call from Fargate container which runs on public IP 2.2.2.2. SIP Phone sees this incoming call request coming from 2.2.2.2 which phone is not registered(as it is registered on 1.1.1.1) and so it discards this incoming call....

Are you currently working around this issue?
We have to use EC2 instances to run our SIP Service.

[michaelcohenunsw]

Tell us about your request
Need a mechanism for ECS container instances (EC2 or Fargate) to have elastic IP addresses.

Which service(s) is this request for?
ECS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We have some integrations that require our instance IP addresses to be whitelisted by our clients. If the ECS container restarts, this IP is changed.

Are you currently working around this issue?
No. However, a Lambda to create an EC2 instance with userdata to run a script may work.

[ashishnayak7]

Any updates on this feature request?

[ali-parsfar]

any update , with new changes in Fargate 1.4 ?

[vtzan]

any update , with new changes in Fargate 1.4 ?
Looking here in the containers filtered by fargate roadmap sadly this feature is not even in the researching part yet :-(

[milesgranger]

Looking forward to this!
We have Fargate tasks, which require a whitelisted static IP address, are data-intensive (along with just pulling a sizable image), and found the only way is to have them in private subnets, assign an EIP to the NAT gateway and then proceed to get _destroyed_ on data processing costs on the NAT gateway.

[petewilcock]

+1000, awsvpc network mode would imply automatic support for the standard ability to assign EIP to ENI - but not for Fargate tasks? Fingers crossed this is something that gets tidied up in 2020 re:invent.

[jvantuyl]

I have a fleet of very small, hardly used services. They're important but they'll never need scale.

Right now, I host them with two Fargate spot instances each and a ALB. The spot instances cost $3 per month. The load balancer is over ten times the cost and is idle most of the time.

It's profoundly wasteful and makes me want to host my services anywhere else. Please just get me an Elastic IP. Or an easy way to stack a hundred services behind a single load balancer.

Fargate could usher in a new era of efficient cloud utilization, truly realizing the dream of commoditized computing resources. But, the load balancer requirement for an ECS service just kills it.

[sc-alscient]

An NLB with listeners on different ports would lower your costs substantially. You are then having to call the services on non 80/443 though. If you require HTTP/HTTPS an option would be to route calls through an API gateway first separating the services by path, and route each separate path to a private NLB port through a VPC endpoint service.

[jvantuyl]

Oh, it undoubtedly could. But it makes it very difficult to administer them separately. The amount of Terraform required for even a modest Fargate service is already impressive. But it is, at least, self-contained. An even more complicated load balancer setup would likely work, but I'd much rather have some sort of feature that makes sense and is priced reasonably.

Frankly, I could run haproxy in a container for peanuts. But I can't easily figure out the IPs to route to, nor can I put a front-end IP on that haproxy. The fact that the resources to do this are clearly cheap but there's just no option that's sanely priced is a product gap, full stop. Feature, please.