PO Box 573
Glendora, CA 91740
Amazon ECS is one of many container hosting platforms specifically aimed at AWS developers. At first glance, it’s a bit confusing, even daunting, since the costs are hard to predict, there is a vast range of options and the terminology varies greatly. In this article, we aim to simplify matters by having a look at the basics, such as terminology and pricing structures.
ECS is short for Elastic Container Service that allows you to schedule and deploy Docker containers without having to worry about the orchestration and underlying server management. You have two options for container deployment: EC2 servers or Fargate, which is a serverless mode.
You can use ECS for both long-running and short burst tasks, since it’s easy to scale the container fleet to your specific needs. Scheduling is also pretty simple. If you want specific instances to be assigned to specific containers, you can use task placement definitions. Alternatively, AWS can take care of this for you – just spread across all Availability Zones.
Amazon ECS has many benefits. First off, integration with other Amazon services, like Load Balancers, IAM and VPCs, is easy. Scalability is also easy, since you don’t have to manage cluster masters. You can even pick the management method that suits you best, since AWS console, AWS API and CloudFormation templates can all be used for this. Managing and sorting your container images is simplified with the help of the Elastic Container Registry.
Terminology can be confusing and daunting. Let’s simplify some of the basics:
Container: As is suggested in the name, the container “contains” a bit of your code or service. In this isolated little box, you have the bare-bones bits and pieces needed to run a specific portion of your application or microservice. Containers are designed to run on Docker-compatible OS.
Task Definition: Think of this as a map of the pieces needed to run your application. This can include any number of containers, networking and system requirements, depending on the complexity of your application.
Task: This is when your task definition is being carried out. The same task definition can be used for multiple tasks.
Service: This can be likened to a map of task definitions, including boundaries and scaling options. Here, similar tasks are grouped together – this process is comparable to the relationship between AutoScaling Groups and EC2 Virtual Machines.
Cluster: This is where you will run your service – a collection of EC2 instances.
As you can guess, the cost of the ECS service depends on what you need and what you use. The method of deployment you choose is the first hurdle to overcome: Fargate abstracts away the underlying infrastructure, since this is a “serverless” mode. This is cool in that you only pay for what you use – you literally only pay for the seconds of vCPU and Memory used by your tasks. The minimum limit here is 1 minute per task. The downside is that it’s really hard to predict your costs, since not all tasks were created equal.
If you use standard ECS, you pay based on the infrastructure deployed for your cluster, not per task. When you set this up, you can specify the instance size and number of instances for the initial deployment. After this, AutoScaling Groups of EC2 instances are used. This is cool, since the system can easily accommodate a spike in task usage by scaling up or down. The downside is that you could end up with a large portion of underutilized or idle instances, adding to your bill unnecessarily.
Using Amazon ECS is great in that you don’t have to worry about the backend work as much. The downside is controlling costs, a potentially complicated and hair-raising experience. CloudSnooze sorts this out quickly and easily, ensuring that you’re not paying for any wasted or unused cloud resources. Contact us today for a free trial.
Share This News