-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fargate] [EIP support]: add Elastic IP support for Fargate #311
Comments
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 Which service(s) is this request for? Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Are you currently working around this issue? |
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Are you currently working around this issue? |
+1 as above - scheduled task to upload/transfer data TO external service that is IP restricted. Same workaround with EC2 instance. |
+1 When using Fargate as a proxy fleet is important to have fixed IPs |
@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 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. |
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. |
+1 Which service(s) is this request for? Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Are you currently working around this issue? |
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 |
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 |
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. |
Tell us about your request Which service(s) is this request for? Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? 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 Are you currently working around this issue? |
Tell us about your request Which service(s) is this request for? Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Are you currently working around this issue? |
Any updates on this feature request? |
any update , with new changes in Fargate 1.4 ? |
|
Looking forward to this! |
+1000, |
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. |
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. |
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. |
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. |
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. |
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
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANSCC7TXEWAD4XD3FRS6X3TH5XIBANCNFSM4HRYGDVA>
.
--
Βασίλης Τζανουδάκης
|
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. |
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. |
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. |
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 - |
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 |
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. |
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! |
would love to see this happen! |
Still no indication of this features being on the roadmap. Thank You AWS, Very Cool! |
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. |
@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 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. |
(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? :) |
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): #737 (comment) |
The App Runner project seems to be dead so it would be great it we could finally get EIP support for single Fargate tasks. Or given the change in pricing for Ipv4, maybe it would be possible to get a static Ipv6 address? Either way, the now defunct App Runner service is not the solution as it lacks most of the features that are available to Fargate and the team managing that project seem to have all been fired or reassigned to GenAI hype projects. |
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
The text was updated successfully, but these errors were encountered: