ECS Fargate with ALB challenges - amazon-web-services

I am currently exploring AWS ECS with Fargate. At first, I thought that it is a good feature that can do autoscaling and save cost, as well as without server maintenance overhead.
But when I look further onto it, the more I see the pain into it.
Fargate does not provide static IP, and the recommendation is to use ALB. ALB alone is costing plenty of money.
ALB doing health check interval and thus Fargate rarely sleeps due to ALB (and thus incurring more charges then it should)
My question is:
Anyone have an alternative of dealing with issue (1) and (2)? a way that can overcome it for cost saving purposes and at the same time retaining an elastic IP
If ALB is forwarded to Fargate with IP address, what happen if IP ECS (Fargate) IP got restarted? Will ALB auto detect it or what are the way to detect Fargate IP changes and update back to ALB automatically, and if not, how to handle such situation where the IP is recycled?

Anyone have an alternative of dealing with issue (1) and (2)? a way that can overcome it for cost saving purposes and at the same time
retaining an elastic IP
A load balancer (ALB or NLB) is really your only option. Your statement about health checks preventing Fargate from "sleep" is incorrect though. There is no "sleep" option in Fargate.
If you want something very similar, but with a sleep option, I suggest looking into AWS App Runner.
If ALB is forwarded to Fargate with IP address, what happen if IP ECS (Fargate) IP got restarted? Will ALB auto detect it or what are
the way to detect Fargate IP changes and update back to ALB
automatically, and if not, how to handle such situation where the IP
is recycled?
ECS integrates directly with the load balancer target group. You configure the ECS service what load balancer and target group you are using, and ECS will keep the load balancer's target group up-to-date with your Fargate IP address(es) automatically.

Related

Is there a way to configure health checks to an ECS service without a load balancer?

I have an ECS Cluster with 2 ECS Services (1 app-controller, 1 app-event-processor). Is there a way to get health checks on both while API traffic only goes to app-controller? I realize health checks normally come from the load balancer but if I configure the load balancer to hit app-event-processor then API traffic also starts flowing to app-event-processor which is undesirable since I want that to handle only messages from SQS for example.
As #jordanm mentioned in their comment ECS does provide a built in health-check mechamism that is orthogonal (and in addition) to the "outside" LB health-check.

AWS : Is there a way to pause/unpause traffic to Elastic LoadBalancers?

Here's the scenario -
We're spinning up a few Instances via Cloudformation Autoscaling group which attaches instances to an Elastic Load Balancer using CloudFormation. The intent is, before the ELB starts serving traffic to these instances, we want to perform a few curl tests and once those look good - enable traffic flow to the instances via ELB.
Question : Is there a way to prevent the Elastic LoadBalancer to NOT send traffic to the instances until we allow it?
If not - is there a way to remove the "Attached Instances" to ELB as part of CloudFormation script itself? (so that we can manually re-attach them once we complete our tests).
Does Application Load Balancer work perhaps instead of Elastic Load Balancer in case ELBs are not sufficient?

AWS ELB zero downtime deploy

With an ELB setup, there as healthcheck timeout, e.g. take a server out of the LB if it fails X fail checks.
For a real zero down time deployment, I actually want to be able to avoid these extra 4-5 seconds of down time.
Is there a simple way to do that on the ops side, or does this needs to be in the level of the web server itself?
If you're doing continuous deployment you should deregister the instance you're deploying to from ELB (say, aws elb deregister-instances-from-load-balancer), wait for the current connections to drain, deploy you app and then register an instance with ELB.
http://docs.aws.amazon.com/cli/latest/reference/elb/deregister-instances-from-load-balancer.html
http://docs.aws.amazon.com/cli/latest/reference/elb/register-instances-with-load-balancer.html
It is also a common strategy to deploy to another AutoScaling Group, then just switch ASG on the load balancer.

How do I set up an ELB cluster?

I read this from https://docs.wso2.com/display/ELB211/FAQ#FAQ-HowdoImaketheELBhighlyavailable , the FAQ section of WSO2's ELB documentation :
How do I make the ELB highly available? Create an ELB cluster and
route the requests to them through a hardware load balancer.
How exactly do I set up an ELB cluster? I looked at the other clustering docs on wso2.com (https://docs.wso2.com/display/CLUSTER420) and didn't see how to cluster the ELB itself. My best guess is that I just get one ELB working and then set up another instance with the identical configuration but on a different host or port and then let the hardware load balancer do the rest. Is that all that's required?
Just found this, but haven't yet tried it:
http://wso2.com/library/tutorials/2013/09/make-wso2-elb-highly-available-through-aws-elb/
You must specify a different port value for each ELB in the cluster. Do this configuration for both the ELBs. This configuration is done primarily to make both ELBs aware of each other. If both your well-known members are ELBs, then each ELB has to know about the other ELB in order to create the ELB cluster. To do that, in each ELB's cluster configuration, you have to mention the other ELB. This is exceptionally helpful in scenarios when one ELB restarts and it would need to get the existing cluster information to serve requests again. To do that, it would need to communicate with the other ELB.

Does it make sense to have an Amazon Elastic Load Balancer with just one EC2 instance?

My question is simple. Does it make sense to have an Amazon Elastic Load Balancer (ELB) with just one EC2 instance?
If I understood right, ELB will switch traffic between EC2 instances. However, I have just one EC2 instance. So, does it make sense?
On the other hand, I´m using Route 53 to route my domain requests example.com, and www.example.com to my ELB, and I don´t see how to redirect directly to my EC2 instance. So, do I need an ELB for routing purposes?
Using an Elastic Load Balancer with a single instance can be useful. It can provide your instance with a front-end to cover for a disaster situation.
For example, if you use an auto-scaling group with min=max=1 instance, with an Elastic Load Balancer, then if your instance is terminated or otherwise fails:
auto-scaling will launch a new replacement instance
the new instance will appear behind the load balancer
your user's traffic will flow to the new instance
This will happen automatically: no need to change DNS, no need to manually re-assign an Elastic IP address.
Later on, if you need to add more horsepower to your application, you can simply increase your min/max values in your autoscaling group without needing to change your DNS structure.
It's much easier to configure your SSL on an ELB than an EC2, just a few clicks in the AWS console. You can even hand pick the SSL protocols and ciphers.
It's also useful that you can associate different security groups to the actual EC2 and the forefront ELB. You can leave the ELB in the DMZ and protect your EC2 from being accessible by public and potentially vulnerable to attacks.
There is no need to use a Load Balancer if you are only running an single Amazon EC2 instance.
To point your domain name to an EC2 instance:
In the EC2 Management Console, select Elastic IP
Allocate New Address
Associate the address with your EC2 instance
Copy the Elastic IP address and use it in your Route 53 sub-domain
The Elastic IP address can be re-associated with a different EC2 instance later if desired.
Later, if you wish to balance between multiple EC2 instances:
Create an Elastic Load Balancer
Add your instance(s) to the Load Balancer
Point your Route 53 sub-domain to the Load Balancer
With NO ELB :-
Less Secure (DOS Attacks possible as HTTP 80 will be open to all, instead of being open only to ELB)
You won't have the freedom of terminating an instance to save EC2 hrs without worrying about remapping your elastic IP(not a big deal tho)
If you don't use ELB and your ec2 instance becomes unhealthy/terminates/goesDown
Your site will remain down (It will remain up if you use ELB+Scaling Policies)
You will have to remap your elastic IP
You pay for the time your elastic IP is not pointing to an instance around $0.005/hr
You get 750 hours of Elastic Load Balancing plus 15 GB data processing with the free tier so why not use it along with a min=1,max=1 scaling policy
On top of the answer about making SSL support easier by putting a load balancer in front of your EC2 instance, another potential benefit is HTTP/2. An Application Load Balancer (ALB) will automatically handle HTTP/2 traffic and convert up to 128 parallel requests to individual HTTP/1.1 requests across all healthy targets.
For more information, see: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-configuration
It really depends on what are you running in the EC2 instance.
While with only one EC2 instance it's not necessary to use ELB (all your traffic will go to that instance anyways), if your EC2 service has to scale in the near future, is not a bad idea to invest some time now and get familiar with ELB.
This way, when you need to scale, it's just a matter of firing up additional instances, because you have the ELB part done.
If your EC2 service won't scale in the near future, don't worry too much!
About the second part, you definitely can route directly to your EC2 instance, you just need the EC2 instance IP. Take a look at the amazon route53 docs. Mind that if your IP is not static (you don't setup an Amazon Elastic IP), you'd need to change the IP mapping everytime the EC2 ip changes.
You can also use an ELB in front of EC2 if for example you want it to be publically reachable, without having to use up an Elastic IP address. As said previously they work well too with ASG's