[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.

[CarlosDomingues]

Really surprised this is not supported. For simple tests / development scenarios all you want is to get a public IP / dns name and call it a day.

For applications that doesn't need high SLA (infrequent data pipelines, batch job APIs, internal applications, etc...), using ALBs is either a waste (one LB per app) or a hassle (need to manage priorities, rules, target groups, health checks, etc... sounds simple but requires a fair amount of Terraform / AWS CDK ).

I'd say the best current solution is to use something like Traefik in an EC2 instance (it can auto detect ECS Services and create routes accordingly, so cheap + less hassle), but not having to use anything would be even better.

[farzadpanahi]

I am starting to wonder this is a business decision and not a technical problem. Anyone from AWS team care to respond? At least let us know if this feature is in the road map or not.

[vtzan]

We fully agree that this is a business decision by AWS to force the usage of Load balancers. The usage of a Load balancer was the answer everytime we asked for this feature. The problem is that there are situations (like a SIP Edge proxy app) that the LB is useless and they force us to use EC2 and ECS on top of EC2.

On Sat, 10 Apr 2021 at 00:34, Farzad Panahi @.***> wrote:

I am starting to wonder this is a business decision and not a technical problem. Anyone from AWS team care to respond? At least let us know if this feature is in the road map or not.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aws/containers-roadmap/issues/311#issuecomment-816984299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANSCC7TXEWAD4XD3FRS6X3TH5XIBANCNFSM4HRYGDVA .

-- Βασίλης Τζανουδάκης

[penguinrunner]

I would love to host my $5 container on fargate, but I don't want to put it behind a $35 NAT Gateway just so my traffic comes from the same IP. Please let us just specify an EIP for a task/definition.

[CarlosDomingues]

App Runner was recently launched and it seems designed to cover some of the use cases presented here. I can't use it yet (can't restrict access, no support for secrets, no spot instance option), but some of you might want to take a look. It's a neat product.

[stevenlafl]

Please implement this. I know you can do this by virtue of the "autoassignip" directive but it is pooled and ephemeral. It makes no sense to have a small task running on an extremely expensive (by comparison) ALB. I don't need to load balance among similar or same tasks, I need to spin a single task at a different static IP per service.

[KAVA-Leigh]

Over 2 years later & we are no further advanced here.. how is this possible?

Was hoping to use Fargate for what is just a cron scheduled job, which requires no inbound route - so apart from the cost of the ALB, it is completely pointless (beside providing an outbound EIP). NAT GW seems to be the only solution :(

[stevenlafl]

Over 2 years later & we are no further advanced here.. how is this possible?

Was hoping to use Fargate for what is just a cron scheduled job, which requires no inbound route - so apart from the cost of the ALB, it is completely pointless (beside providing an outbound EIP). NAT GW seems to be the only solution :(

In your case, you can have CloudWatch set to run a Lambda function periodically, which can be configured to run as a container from an image in your ECR. Here's more about this https://docs.aws.amazon.com/lambda/latest/dg/images-create.html

For PHP or any other executable, you'll need to write a custom Dockerfile and set the executable as your entrypoint (though, this is also configurable, so you might be able to get away with throwing literally any image up there).

I suspect without proper integration, it'll run but generate an error because it expects the handler to give a specific output back to Lambda. This is OK as long as your function does what -you- want.

[KAVA-Leigh]

Over 2 years later & we are no further advanced here.. how is this possible? Was hoping to use Fargate for what is just a cron scheduled job, which requires no inbound route - so apart from the cost of the ALB, it is completely pointless (beside providing an outbound EIP). NAT GW seems to be the only solution :(

In your case, you can have CloudWatch set to run a Lambda function periodically, which can be configured to run as a container from an image in your ECR. Here's more about this https://docs.aws.amazon.com/lambda/latest/dg/images-create.html - For PHP or any other executable, you'll need to write a custom Dockerfile and set the executable as your entrypoint (though, this is also configurable, so you might be able to get away with throwing literally any image up there). I suspect without proper integration, it'll run but generate an error because it expects the handler to give a specific output back to Lambda. This is OK as long as your function does what -you- want.

Thanks for the reply @stevenlafl I will still be subject to the execution time limitations of Lambda, even though it is using the ECR image? Or are you saying the container will continue running & Lambda will timeout, if no response is provided from the container?

[stevenlafl]

Over 2 years later & we are no further advanced here.. how is this possible? Was hoping to use Fargate for what is just a cron scheduled job, which requires no inbound route - so apart from the cost of the ALB, it is completely pointless (beside providing an outbound EIP). NAT GW seems to be the only solution :(

In your case, you can have CloudWatch set to run a Lambda function periodically, which can be configured to run as a container from an image in your ECR. Here's more about this https://docs.aws.amazon.com/lambda/latest/dg/images-create.html - For PHP or any other executable, you'll need to write a custom Dockerfile and set the executable as your entrypoint (though, this is also configurable, so you might be able to get away with throwing literally any image up there). I suspect without proper integration, it'll run but generate an error because it expects the handler to give a specific output back to Lambda. This is OK as long as your function does what -you- want.

Thanks for the reply @stevenlafl I will still be subject to the execution time limitations of Lambda, even though it is using the ECR image? Or are you saying the container will continue running & Lambda will timeout, if no response is provided from the container?

You can set it to whatever you want, as far as I know. I've set it to 10 minutes before so at least that. It's configurable somewhere in the Lambda interface when you are looking at your function settings. I'm saying that when it exits, it'll probably error but it's fine as long as your code does what you want it to.

For context, my experience with it is running a modified version of Brev (it runs PHP code), except without all that Serverless.io baggage.

Again, this is all just for custom runtimes. If your code is already node.js, python or other supported types, you can probably just get started with that. There's whole lot to this workflow, check out AWS SAM for some more information.

[KAVA-Leigh]

Over 2 years later & we are no further advanced here.. how is this possible? Was hoping to use Fargate for what is just a cron scheduled job, which requires no inbound route - so apart from the cost of the ALB, it is completely pointless (beside providing an outbound EIP). NAT GW seems to be the only solution :(

In your case, you can have CloudWatch set to run a Lambda function periodically, which can be configured to run as a container from an image in your ECR. Here's more about this https://docs.aws.amazon.com/lambda/latest/dg/images-create.html - For PHP or any other executable, you'll need to write a custom Dockerfile and set the executable as your entrypoint (though, this is also configurable, so you might be able to get away with throwing literally any image up there). I suspect without proper integration, it'll run but generate an error because it expects the handler to give a specific output back to Lambda. This is OK as long as your function does what -you- want.

Thanks for the reply @stevenlafl I will still be subject to the execution time limitations of Lambda, even though it is using the ECR image? Or are you saying the container will continue running & Lambda will timeout, if no response is provided from the container?

You can set it to whatever you want, as far as I know. I've set it to 10 minutes before so at least that. It's configurable somewhere in the Lambda interface when you are looking at your function settings. I'm saying that when it exits, it'll probably error but it's fine as long as your code does what you want it to.

For context, my experience with it is running a modified version of Brev (it runs PHP code), except without all that Serverless.io baggage.

It seems the limit is 15 mins now (was originally 5 mins), which is fine right now, but in a month from now, the limit will definitely be a problem.. unfortunately. Gets me thinking about more options though, thank you!

[kreditkenny]

would love to see this happen!

[iibrahimli]

Still no indication of this features being on the roadmap. Thank You AWS, Very Cool!

[mreferre]

We understand the passion around this and rest assured we monitor these threads (even if it seems we are taking no action). This one in particular is a tough one because providing a stable IP address to a single container is often considered an anti-pattern in the container world and so the simplified supporting workflows to produce such a setup in the product(s) do not exist (other than using additional configurations that, as you noted, could raise the cost). The main problem is that Fargate tasks (just like all containers really) are ephemeral by nature. Unfortunately binding manually an EIP to a Fargate ENI is not supported because it is a “managed ENI” and the user cannot alter its configuration. If this was possible, customers could build automation on top of it (just like some are doing today to register into Route53). The other only option is to create a workflow that would allow to create an ECS service / task-set with an EIP defined and with a single ephemeral task that always gets assigned that EIP. This would not be impossible to accomplish but it would require a certain amount of work to figure out all the corner cases and a proper user experience.

[CarlosDomingues]

@mreferre maybe providing a fixed URL like App Runner does would solve the issue for many in this thread (which is not needing ALB).

[mreferre]

@mreferre maybe providing a fixed URL like App Runner does would solve the issue for many in this thread (which is not needing ALB).

Thanks @CarlosDomingues. I think there are a couple of things here. First, I thought, reading the thread, that the major issue was having a stable IP address and not a FQDN. This is technically not possible today and providing a stable URL would not solve these requirements.

Yes App Runner does this but the way it's implemented is with additional infrastructure services that have a cost associated and that are factored in into the cost of App Runner. BTW if App Runner would do and if this specific setup (stable URL) was to be used for low traffic test/dev environments the App Runner ability to scale to (almost) zero would be ideal. Depending on the workload pattern App Runner may be a lot cheaper than a single Fargate task. See the example cost breakdowns at the bottom of this page.

[jtlz2]

(Not that I would like to, because I'd love an answer to this - but: ) Can we close this issue now - or is there any update? :)

[mreferre]

This thread is similar to another one (#737) where I have posted some details of a (scrappy) prototype I built to automate the binding of a single task ECS service to a stable A record in Route53.

To be clear this solution DOES NOT solve at all for the need of static IPs for PBX / legacy firewalls (because it relies on the random public IPs vended to tasks). In that thread I hinted about the possibility to extend this prototype to manage multiple tasks per ECS service thus creating what I referred to as a "poor man load balancer" (which is something that was discussed in this thread but I am not sure a DNS is the right answer to that).

More details on the other thread (in this comment): https://github.com/aws/containers-roadmap/issues/737#issuecomment-1410169740