I have an auto scaling ECS cluster backed by fargate. The lower bound is 1 instance. Would i need to worry about HA? Lets say an AZ crashes, wouldnt the cluster logic spawn it in another AZ, does this imply that among other benefits, Fargate cuts out the HA/redundancy cost as well, with some service degrade of course
Only if you run your ECS service in vpc with subnets in more then one AZ. If you just run a single ECS task (not ECS service), you will not have HA.
Related
I have one confusion, did we need to pay for ECS separately, if i had already EKS cluster with t3.medium EC2 instance as worker node. Because in documentation i found that there is no addition charge for ECS if we have EC2 instance.
EKS (Elastic Kubernetes Service) and ECS (Elastic Container Service) are two distinct services on AWS. Both are used for container orchestration. EKS, as the name suggests, is a managed Kubernetes cluster whereas ECS is an AWS-native solution.
Both EKS and ECS can be used on top of either EC2 instances or on Fargate. Fargate is a “serverless” solution in the sense that it manages the underlying servers and the autoscaling for you.
If you run ECS on EC2 instances instead of Fargate, you will only pay for the EC2 instances, just like normal. There is no additional cost for the fact that you run an ECS cluster on top of them. EKS however does charge you for the cluster itself, regardless of the underlying launch type.
We have a requirement of deploying Redis as an External Load Balancer Service on AWS-EKS (Elastic Kubernetes Service). As Redis will be a statefulset which of the following combination will be the best fit with EKS -
EKS with Self-managed nodes
EKS with Managed Node Groups
EKS with AWS Fargate
Although, I have studied that AWS Fargate should be used for deploying stateless applications.
Fargate, thus far, has been ideal for running stateless containerized workloads in a secure and cost-effective manner. Secure because Fargate runs each pod in a VM-isolated environment and patches nodes automatically. Cost-effective because, in Fargate, you only pay for the compute resources you have configured for your pod.
I didn't understand how stateless applications will be cost-effective. Kindly verify the below statement. It would be quite helpful.
In the stateless applications, the container will be in the running state, when there will be requests and otherwise no. of instances will be 0 just as in GCP Cloud Run.
Whereas in the stateful ones, the container will be running every time. And for this reason, we should use, EC2 instances for stateful applications
I have a cluster with a mixture of services running on EC2 and Fargate, all being used internally. I am looking to deploy a new Fargate Service which is going to be publicly available over the Internet and will get around 5000 requests per minutes.
What factors do I need to consider so that I can choose if a new cluster should be created or if I can reuse the existing one? Would sharing of clusters also lead to security issues?
If your deployment is purely using Fargate, not EC2, then there's really no technical reason to split it into a separate ECS cluster, but there's also no reason to keep it in the same cluster. There's no added cost to create a new Fargate cluster, and logically separating your services into separate ECS clusters can help you monitor them separately in CloudWatch.
From what I've read so far:
EC2 ASG is a simple solution to scale your server with more copies of it with a load balancer in front of the EC2 instance pool
ECS is more like Kubernetes, which is used when you need to deploy multiple services in docker containers that works with each other internally to form a service, and auto scaling is a feature of ECS itself.
Are there any differences I'm missing here? Because ECS is almost always a superior choice to go with if they work as I understand.
You are right, in a very simple sense, EC2 Autoscaling Groups is a way to add/remove (register/unregister) EC2 instances to a Classic Load Balancer or Target Groups (ALB/NLB).
ECS has two type of scaling as does any Container orchestration platform:
Cluster Autoscaling: Add remove EC2 instances in a Cluster when tasks are pending to run
Service Autoscaling: Add/remove tasks in a service based on demand, uses Application AutoScaling service behind the scenes
I think you have 2 scaling
1 for ec2 instance
1 for ecs task
So I think flow goes like
You get more requests
Your tasks need more resources (cpu/memory)
Your ecs task autoscaling kicks in and creates more task
your ec2 autoscaling also kicks in and creates more ec2
Questions
your ecs needs to know newly launched ec2 (from ec2 autoscaling group) is the host that it can run on (how?)
I want the number of ec2 instance starts from one.
I think one instance is already running in the ecs cluster
Do I make ec2 autoscaling group start from 0?
ec2 autoscaling group has pricing option to use spot instance, but I didn't see such option when I created ecs cluster instances. To be clear, can I make ecs cluster with 0 ecs-instance, and let ec2 autoscaling group starts with 1 instance?
Your ecs task autoscaling kicks in and creates more task
your ec2 autoscaling also kicks in and creates more ec2
Your ECS task scale if there is a memory so fine it will scale and launch new container, if not enough memory then it will not launch an instance, you need to configure cloud watch alarm to scale ECS cluster based on the task scaling.
Tutorial: Scaling Container Instances with CloudWatch Alarms
your ecs needs to know newly launched ec2 (from ec2 autoscaling group)
is the host that it can run on (how?)
ECS agent registers the new instance with the same cluster, and the new task can be placed in any instance that have available resources to handle and launch the container.
I want the number of ec2 instance starts from one. I think one
instance is already running in the ecs cluster Do I make ec2
autoscaling group start from 0?
You should start from 1 otherwise no container will launch and will throw error no instance found in the cluster. if you do not want run container for now then you can start from 0.
ec2 autoscaling group has pricing option to use spot instance, but I
didn't see such option when I created ecs cluster instances. To be
clear, can I make ecs cluster with 0 ecs-instance, and let ec2
autoscaling group starts with 1 instance?
You can read about spot ECS cluster instance here.
Amazon ECS is a highly scalable, high performance, container
management service that supports Docker containers and allows you to
run applications on a managed cluster of Amazon EC2 instances easily.
ECS already handles the placement and scheduling of containers on EC2
instances. When combined with Spot fleet, ECS can deliver significant
savings over EC2 on-demand pricing.