Amazon Elastic Container Service (ECS) lets developers run containers at scale on Amazon Elastic Compute Cloud (EC2) or Amazon Fargate. ECS is a container orchestration service that manages clusters of containers, including aspects like container lifecycle, high availability, storage and networking.
There is no additional cost for using ECS, beyond the regular cost of the EC2 instances used, EBS storage volumes, or Fargate virtual CPUs (vCPUs) and storage used. We’ll explain how pricing works on EC2, Fargate, and also when running ECS on-premises using Amazon Outposts, and provide a few tips for optimizing your ECS costs.
This is part of our series of articles on AWS pricing.
There are three models for running and paying for Amazon ECS: via Amazon EC2, AWS Outposts, or Amazon Fargate.
When you run Amazon ECS in EC2 launch type, there is no additional charge for the ECS service. You pay for AWS resources used, such as EC2 instances and EBS volumes. There are no minimum rates or upfront commitments.
There are five ways to pay for Amazon EC2 Instances: On Demand, Reserved Instances, Spot Instances, and Savings Plans. The fifth option is a Dedicated Host that provides EC2 instance capacity on a dedicated physical server.
AWS Outposts is a fully-managed service that extends AWS cloud infrastructure services, APIs and tools to on-premise. Users can launch EC2 instances and run apps on AWS Outposts using the AWS console, CLI or SDK as they would in the cloud. You can control the pricing of Amazon ECS on AWS Outposts via the Amazon ECS control plane, which is located in the cloud. The service charges for EC2 capacity, which you can use to run container instances without incurring an additional cost.
The service offers a variety of AWS Outposts configuration options, which pool resources together, including EC2 instances, as well as EBS volumes and S3. Pricing for these configuration features include installation, delivery, upgrades, software patches, and infrastructure service maintenance.
AWS Fargate is a serverless container service that launches containers only for as long as they are needed, and then shuts them down. An Amazon ECS task can run on Fargate, and you pay Fargate charges for the amount of time the task actually ran, rounded to the nearest second.
Billing is calculated according to:
For example, currently the cost of Fargate spot instances for Amazon ECS in the US East region is $0.01302749 per vCPU-hour and $0.00143051 per GB-hour (see the official pricing page for up-to-date pricing).
Let’s say in a certain week you ran the following ECS workload:
|Number of Tasks||Number of hours||Cost of vCPUs + Cost of RAM|
|10||*||2.3||*||( (1 * $0.01302749) + (2 * $0.00143051) )|
Here are a few tips you can use to optimize your use of ECS and save costs.
ECS runs on Fargate Spot instances, letting you save up to 70% of regular on-demand price. In your Service Auto Scaling policy, you can specify that a certain number of tasks should run at all times (in on-demand mode), and the rest can run on spot instances, when available.
You should note that spot instances are the least reliable, which is why Amazon recommends them for stateless or fault tolerant applications. When using Fargate Spot instances, Amazon does not provide any SLA and can interrupt instances at any time, limiting the value of these instances for mission-critical workloads.
However, Spot by NetApp provides a solution to reliably run containerized applications using spot instances. Ocean, Spot’s serverless container engine, provides an enterprise-level SLA, allowing even mission-critical, production workloads to run on spot instances without risk of interruption.
Ocean uses advanced AI to predict spare capacity interruptions as early as one hour before termination (vs. the standard two-minute warning on AWS), and will proactively replace endangered instances. In the event that there is no spot instance available that meets workload requirements, Ocean automatically provisions an on-demand instance, ensuring workload continuity.
Auto scaling policies for ECS and Fargate can be used for cost optimization. You should fine-tune auto scaling configuration, by learning about the baseline performance of your application, and ensuring the cluster scales up only when really necessary.
For example, one application can be scaled effectively based on CPU utilization, while another based on disk utilization. Different applications will have different thresholds.
Scheduling ECS instances is an easy way to save costs. For example, if a system is used by employees, it makes sense to shut it down during the weekend or their off hours. Another option is to automate batch scheduling, running instances according to the number of jobs that need to run on them. You can schedule ECS workloads using the scheduled scaling configuration, available both in ECS and Fargate.
Spot instances are a great way to save on ECS, but they are also less reliable. An interesting way to overcome this problem is to rely on multiple pricing models. For example, running on demand instances for a critical management component, and spot instances for other application components which are more tolerant to failure.
You can use Amazon Spot Fleet to create auto scaling groups that include both spot instances and on-demand instances. When spot instances are not available given the instance type and bidding price, the auto scaling group uses on-demand instances as well.
However, automatically provisioning instances with the right configuration often requires custom templates and scripts. These can take a significant amount of time to create, and require specialized expertise.
With Ocean, from Spot by NetApp, users don’t have to worry about provisioning the right infrastructure when they need to deploy a workload or scale an application. Ocean automatically provisions the optimal blend of spot, on demand and reserved instances, based on application requirements, with spot instances as the preference to save costs. However, if there are unused reserved instances available, Ocean will utilize these prepaid instances first.
You can use the Multiple Load Balancer Target Group feature to attach one ECS service to multiple target groups. This simplifies code and can reduce costs by consolidating services.
For example, using multiple target groups, you can run one ECS service that receives traffic from internal and external load balancers. Otherwise you would have to maintain one copy of the service for internal requests and another for external.
Right sizing is a key technique for conserving cloud resources. In Kubernetes, you perform right sizing by specifying limits for resources available for containers in each pod. Use a tool like kube-resource-report to visualize actual utilization and strike a balance between:
Ocean, from Spot by NetApp, provides automated right-sizing recommendations, by comparing CPU and memory demands with actual utilization over time. This comparison helps to improve resource configuration and avoid over and under-provisioning of nodes.
You can apply tags to resources in Amazon ECS and Fargate, including services, tasks, clusters, and containers. This allows you to:
While the strategies above present significant opportunities for optimizing ECS, using them is not straightforward. In order to efficiently configure auto scaling and right sizing, you will need detailed monitoring and rigorous testing. In addition, using spot instances presents major operational challenges.
Spot by NetApp automates these capabilities as part of Ocean, which is designed to take advantage of pricing, lifecycles, performance, and availability of cloud compute infrastructure:
for up to 20 instances