AWS Fargate is a managed service that enables you to run containers in Amazon Elastic Kubernetes Service (EKS) or Elastic Container Service (ECS). Since Fargate is serverless, you don’t need to provision or manage servers or clusters. However, you do need to set up package containers, define resource requirements, and configure permissions and networking policies.
Fargate pricing is determined according to virtual CPUs (vCPUs) requirements, as well as usage of GBs of RAM for running services. You can choose between on-demand instances pricing and spot instances pricing. There are also options for cost reduction when using AWS Saving Plans.
In this article, you will learn:
- AWS Fargate vs Lambda vs EC2: pricing comparison
- Limitations of AWS Fargate
- How to reduce AWS Fargate costs and improve utilization
AWS Fargate is a managed, serverless compute engine that you can use to run containers in Amazon Elastic Kubernetes Service (EKS) or Elastic Container Service (ECS). It eliminates the need to provision or manage servers or clusters of instances and doesn’t require you to select specific server types, optimize cluster packing, or manually size and scale kubernetes clusters.
When running containers, you can use a Fargate launch type or capacity provider. With this option, you are responsible for packaging containers, defining resource requirements, setting permissions and networking policies, and launching your application. This service eliminates the need to define or deploy EC2 instances, provision or manage resources, or isolate applications.
Benefits of Fargate include:
- No need to deploy, manage, or maintain infrastructure
- Increased isolation for greater security
- Built-in integrations for observability
Fargate also has several limitations you should be aware of:
- Up to three times more expensive than on-demand EC2 instances
- Only available in limited regions
- No SLA for spot instances
- No support for GPUs
See more details in our section about Fargate limitations below.
Pricing in Fargate is determined by how many virtual CPUs (vCPUs) your services require. It is also affected by how many GBs of RAM you use while running services, priced per hour. Below you can find example pricing for the US East region. This gives you a general idea of cost but for more detailed options and up-to-date information, you can see the official AWS Fargate pricing page.
|On-demand instances (price per hour USD)||Spot instances (price per hour USD)|
|GB of RAM||0.004||$0.0014|
There is also a Compute Savings Plan available that you can use to save on costs. You can learn more about this plan in the utilization best practices section below.
When moving workloads to AWS, it helps to understand your options before making a decision. The most common services you should consider are Fargate, Lambda, EC2, and our very own Ocean. All four can be used to run workloads and host services although the methods these services support differ.
AWS Lambda is a serverless functions service that you can use as an application or service backend or to run individual workload processes. EC2 is a virtual machine service that enables you to create instances as standalone machines or as hosts for containers. It is also used in the background by AWS to provide Lambda and Fargate services.
Below, you can see a breakdown of how these services (such as EC2 vs Fargate) differ in terms of pricing:
|AWS Fargate Pricing||
Fargate instances are billed on CPU and memory use per hour. The amount of resources available depends on the amount you have configured and any unused resources you have reserved are wasted. Billing is not dependent on the number of requests or run length. This makes it easier to predict boundaries for use and price range.
You can use AWS’s Container Insights feature to help estimate your resource needs. You may also consider mixing services, using EC2 for more predictable or higher scale workloads. If you move these processes to EC2 you can save costs through spot or reserved instances.
|AWS Lambda Pricing||
Lambda is billed based on the number of requests, execution time, and resources reserved. Like with Fargate, any resources you reserve but don’t use are still billed for the duration of your function execution. When configuring functions in Lambda you can choose from a variety of memory tiers to right-size your resources.
To ensure that resources are properly distributed you can use CloudWatch Billing Alarms and Lambda Function logs. Both can provide you with metrics about your functions and how efficiently functions are operating. You can also configure events and reserved instances to reduce the number of function invocations, reducing billed time.
In EC2, billing is based on the instances types you choose, the resources consumed, and how long instances are retained. You have the choice of using either on-demand or reserved instances. The former is more flexible but more expensive while the latter is more reliable and may be cheaper.
When using EC2, it is your responsibility to efficiently host your containers. Alternatively, you can use a combination of Fargate and EC2 with the Fargate Launch Type. This type enables you to access billing per second and only charges you for the instance resources you use.
|Ocean by Spot Pricing||
Ocean by Spot is a cloud managed service for running and managing container infrastructure in the cloud. With a pay-as-you-save pricing model, Ocean utilizes EC2 spot instances to maximize customer savings. Users are still billed by their cloud provider for the instances they use, and when spare capacity is not available to run applications, Ocean will automatically fallback workloads to on-demand.
To minimize idle resources and over provisioned nodes, Ocean chooses instance type and size based on real time container and application resource utilization (CPU, memory, disk, network) and auto scales infrastructure to meet those requirements.
Despite its benefits over self managed container deployments, Fargate has limitations you should be aware of.
- Fargate is up to three times more expensive than on-demand EC2 instances, and Fargate with spot instances can be significantly more expensive than using EC2 spot instances
- You can only use Fargate in limited regions, depending on whether you are using it with ECS or EKS.
- There is no service level agreement (SLA) for availability when using spot instances with Fargate.
- Your resource requirements are rounded up, meaning you may still pay for unused resources.
- There is currently no support for stateful services in EKS. With ECS, you are limited to using AWS EFS volumes for persistent storage.
- You cannot currently use GPUs with Fargate.
- Fargate operates as a “black-box” making it difficult to diagnose performance issues or debug. This includes lack of visibility into cluster utilization or infrastructure.
Many additional limitations exist when using Fargate with EKS. These include:
- You can only use AWS’s Application Load Balancer to distribute your workloads.
- Your pods must be scheduled with a Fargate profile to ensure smooth operation. However, this limits each pod to 4 vCPU and 30Gb memory per pod.
- You are unable to run privileged containers, daemonsets, or pods with specified HostNetwork or HostPort.
- Only private subnets are supported.
When considering EC2 vs Fargate, try and get around the above limitations and ensure that you are getting the greatest ROI on your Fargate implementation, by employing the following best practices. These practices can help you reduce your overall costs by maximizing pricing plans, eliminating wasted resources, and easing workload management.
AWS Savings Plans
AWS Savings Plan is a pricing option that you can use to save up to 72% of the cost of EC2 instances. It applies to any instance type, including those used for standalone EC2, Lambda, and Fargate.
The savings plan works by recommending an amount of resources based on your previous use and defining a recommended amount you can commit to using in a given period. These resources are then billed like Reserved Instances in one or three year terms. Any resources you use within the savings plan limit is automatically deducted. If you go over your reservations, any additional resources are billed at the regular, On-Demand rate.
Terminate idle pods
If you have unpredictable workloads with traffic that fluctuates, you may have idle pods that cost money without contributing to performance. Right-sizing the number of active pods you have at any given time can help you avoid these costs and simplify your deployment.
To manage pods, the easiest way is to use the Kubernetes horizontal pod autoscaler feature. This feature enables you to control how pods scale and to control scaling in response to utilization metrics.
Tagging resources can grant more granular control over your resources and increase visibility. It is an especially helpful practice when managing multiple environments, including test, staging, and production. Tagging can help you quickly identify which pods are in use and help you ensure that pods are not orphaned or consuming more resources than expected.
AWS has a built-in tagging mechanism you can use or you can use Kubernetes features. However, if you use the AWS option, you can also monitor tagged resources through the AWS Billing and Cost Management console. This can help you better manage costs and evaluate the breakdown of your resources.
Fargate vs. Spot by NetApp Ocean
AWS Fargate eliminates the need to deploy and manage infrastructure. This managed service can increase isolation, promoting greater security. You can also use Fargate built-in integrations for observability. Fargate instances are billed on CPU and memory use per hour. If you continuously terminate idle pods and utilize resource tagging for monitoring, you can significantly reduce costs. You can also leverage AWS Saving Plans for further cost reduction.
Where you would find the most savings, however, Fargate falls short. Spot instances come at an enormous discount, but with Fargate, there is no SLA for availability, making it unreliable for production workloads. In contrast, Ocean by Spot offers an enterprise grade SLA for workloads running on EC2 spot instances, saving you up to 90% of what you would have spent on on-demand, and far less than you would spend using Fargate on-demand rates.
Ocean provides a serverless container experience by automatically optimizing cluster resources via auto scaling and right sizing, both driven by container resource requirements, resulting in highly utilized infrastructure with minimal waste. With detailed visibility into resource allocation and utilization, Ocean opens up the black box of infrastructure and provides cost breakdowns per node, deployment, and pod, right down to the container level. You can maintain granular control and full infrastructure access with features such as custom tagging per launch specification and detailed dashboards. In the next section we will look at some cost calculations comparing Fargate to Ocean.
Fargate Pricing Calculation
To help understand how Fargate on-demand pricing compares to Spot by NetApp Ocean, here is a breakdown of cost (in us-east Ohio) for 2 popular EC2 spot instances used for containerized applications vs. the equivalent usage (of vCPU and memory) in Fargate. It’s important to understand why we compare Fargate on-demand and not Fargate spot to Ocean. This is simply because Ocean offers a high availability SLA for production and mission-critical workloads on EC2 spot instances, while Fargate spot gives no such guarantee.
|EC2 instance||vCPU||Memory||Fargate (on-demand)||Ocean (spot instances with SLA for availability)||Potential savings using Ocean|