How is AWS ECS Priced?
Amazon Elastic Container Service (ECS) lets developers run containers at scale on Amazon Elastic Compute Cloud (EC2), Amazon Fargate, or on-premises via the AWS Outposts or ECS Anywhere service. 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 on AWS, beyond the regular cost of the EC2 instances used, EBS storage volumes, or Fargate virtual CPUs (vCPUs) and storage used.
The ECS Anywhere service allows Amazon customers to run ECS instances in the on-premise datacenter. These are customer-managed instances registered with an Amazon ECS cluster and running the Amazon ECS container agent. Amazon charges $0.01025 per hour for each ECS Anywhere on-premises instance. Another option for running ECS on-premises is via AWS Outposts, a service that extends AWS cloud infrastructure services, APIs and tools to the on-premise data center.
We’ll explain how pricing works on EC2, Fargate, ECS Anywhere, and also when running ECS on-premises using Amazon Outposts, and provide a few tips for optimizing your ECS costs.
This is part of an extensive series of guides about microservices.
In this article, you will learn:
- Amazon ECS Pricing for 4 Deployment Options
- 7 ECS Cost Optimization Tips
- Optimizing AWS ECS Pricing with Ocean from Spot by NetApp
Amazon ECS Pricing for 4 Deployment Options
There are four models for running and paying for Amazon ECS: via Amazon EC2, Amazon Fargate, Amazon ECS Anywhere, and AWS Outposts.
AWS ECS EC2 Launch Type Model
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.
Related content: read our guide to AWS EC2 pricing
AWS ECS Fargate Launch Type Model
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:
- Number of ECS tasks you ran during the period
- Duration each task ran
- Number of virtual CPUs (vCPUs) used for the task (charged per vCPU hour)
- Memory used for the task in GB (charge per GB-hour)
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:
- 10 tasks
- Each running for 20 minutes per day = 140 minutes total = 2.3 hours
- Each task using 1 vCPU
- Each task using 2 GB RAM
The cost of ECS on Fargate for the week is calculated as follows:
Number of Tasks | Number of hours | Cost of vCPUs + Cost of RAM | ||
10 | * | 2.3 | * | ( (1 * $0.01302749) + (2 * $0.00143051) ) |
Related content: read our guide to Fargate pricing
AWS ECS Anywhere
The ECS Anywhere service allows Amazon customers to run ECS instances in the on-premise datacenter. These are customer-managed instances that have been registered with an Amazon ECS cluster and run the Amazon ECS container agent.
Common use cases of ECS anywhere include deploying data processing workloads at the edge, ensuring consistency with on-premises tools when migrating to AWS, and running Windows container workloads using existing licenses.
Amazon charges $0.01025 per hour for each ECS Anywhere on-premises instance. There are no minimum charges or upfront costs, but you also pay for AWS resources (e.g. EC2 instances and EBS volumes) you create to store and run your application.
AWS ECS on AWS Outposts
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.
7 ECS Cost Optimization Tips
Here are a few tips you can use to optimize your use of ECS and save costs.
Fargate Spot Instances
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.
Fine Tuning Load-Based Auto Scaling
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.
Scheduled Auto Scaling
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.
Mixing Pricing Models
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.
Application Load Balancer
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 Containers
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:
- Setting limits value is too low, which will cause throttling of resources and reduce performance
- Setting limits too high, which leads to wasted resources
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.
Tagging
You can apply tags to resources in Amazon ECS and Fargate, including services, tasks, clusters, and containers. This allows you to:
- Allocate costs to specific projects or components
- Improve visibility into ECS workloads
- Identify orphaned or underutilized resources
- Search for containerized applications
- Programmatically manage your workloads
Optimizing AWS ECS Pricing with Ocean from Spot by NetApp
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:
- Automatically provision and reliably run an optimal blend of spot, on-demand and reserved instances to save up to 90% on cloud infrastructure
- Leverage predictive AI to identify spare capacity interruption and proactively replace at-risk spot instances or fall back to on-demand
- Auto scaling mechanisms respond to the resource requirements of incoming workloads, and uses bin packing algorithms to scale up instances
- Monitor and analyze container utilization and modify at runtime resource limitations for performance at lowest cost
- Manage different workloads on the same cluster and across AZs; use mixed instance types and sizes in the same node group.
Learn more about Ocean from Spot by NetApp
See Additional Guides on Key Microservices Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of microservices.
Application Mapping
Authored by CodeSee
- Bring visibility to your codebase
- What Is Software Mapping, 4 Types of Dependencies and How to Manage Them
- Why Code Dependencies Matter—and How to Identify and Resolve Them
Kubernetes Architecture
Authored by Spot
- Kubernetes Architecture: Control Plane, Data Plane, and 11 Core Components
Explained - Kubernetes Pod: Why, Where and How
- Kubernetes Helm: K8s Application Deployment Made Simple
Istio
Authored by Tigera