Today I Learned Cloud

How does AWS Fargate work?

Working with containers can make building and packaging micro services much more simple and easier to maintain. However managing and orchestrating a cluster of these containers can be time consuming, error prone, and difficult to understand at first. This is where AWS Fargate comes in.

How does AWS Fargate work? AWS Fargate works by having the underlying servers fully configured, hosted, patched, monitored and maintained by AWS. This enables a completely serverless experience for the customer to run distributed fleets of containers. The customer only pays for time that the container instances are used.

But what does AWS Fargate use to make this possible? Are there benefits to using this service over simply rolling your own container orchestration system?

AWS Fargate - Under the Hood

Amazon first introduced a service known as Amazon Elastic Container Service, or ECS, to give their customers a way of running container images on top of EC2 instances that are owned and operated by the customer. The benefit of using something like this service is that it relieved the customer from setting up a cluster of ec2 instances themselves and installing, maintaining and patching software like Docker Swarm, Mesos, or Kubernetes to provision the containers across the machines. Effectively ECS runs services like these for you on the configured EC2 instances.

The main difficulty with Amazon ECS is knowing how big to size the EC2 cluster of machines that is going to be used with the service. You may not know how many machines, or what size machines, to provision for the given workload. Another issue is knowing when to scale up and down that cluster of machines for the work load that hits the services. This can end up costing the customer more to run than they need if over provisioned or give a bad customer experience if under provisioned.

Auto scaling the EC2 fleet of machines can help with the above issue, but what if there was a better way? This is where AWS Fargate comes into play. The AWS Fargate service can be viewed as if Amazon themselves is running their own ECS cluster, but allowing other customers to run containers on that cluster. By doing so, the customer running the container, or containers, only pays for the run time and resources used by that container. This way you only need to know the CPU and memory usage required by a given container and then let Amazon find the proper EC2 instance to run that container on for you.

Given the enormous scale of the Amazon regions across the world, this makes running your containers across the world in a resilient and cost effective way quite easy. There is no way to over provision your container fleet, unless the amount of CPU and RAM is set too high for the containers, and it gives you virtually unlimited scale.

AWS Elastic Kubernetes Service

One container orchestration system that seems to have gained the lions share of the container space is Kubernetes. This is an open source system originally built by Google. It is very similar to other container orchestration systems like Docker Swarm and Mesos, but seems to have been the one that is chosen by most companies.

Amazon Web Services took this a step further by offering a fully hosted version of EKS on top of their Amazon Fargate service. This gives the familiar interface to containers that a lot of developers are used to, but it lets the containers run on top of the fully managed, serverless service offered by Amazon. There is no need for the end customer to be worried about the underlying servers that run the containers in the Kubernetes deployment, as Amazon will patch, maintain and host them for the customer. Again giving unlimited scale to the customers container workload without any of the headache.

All of the same traditional workflows and tools that were used with a customer hosted Kubernetes cluster continue to work with this Amazon Web Services hosted version. However the need to worry about scaling the available compute nodes, or worrying about the master nodes, is completely gone. For small teams, and even large teams, this can be an enormous benefit.

AWS Fargate Pricing

The main benefit to AWS Fargate is that you don’t need to pay for the full price of the underlying EC2 instances that may not be fully used by the customers container workload. This is a very nice benefit, but at what price does that advantage come in at?

AWS Fargate pricing is based on the amount of vCPU requested by the running container and the amount of memory, or RAM, also requested by that same container. So the more CPU or RAM requested, the more it will cost to run. The billing for this is charged by the second of use, with a minimum of a one minute charge. The clock starts ticking as soon as Fargate starts to download the docker image for the container, and ends when the container has terminated operation. This is then rounded up to the nearest second.

When looking in the US East (North Virginia) Region of AWS, the pricing for the two components previously mentioned turns out to be $0.04048 per vCPU hour and $0.004445 per GB of memory per hour. However, there are only certain configurations available to choose the amount of CPU and RAM from.

The above table gives an indication of what RAM options are available to a container running in AWS Fargate given the amount of vCPU selected.

Amazon also offers a cost savings feature to customers that have a consistent usage pattern. This allows the customer to pre-pay for an amount of AWS Fargate usage and get up to a 50% discount for that usage. This is known as the compute savings plan for ECS and is applicable for Fargate. The terms of these pre-payment plans are based on one year, or three years, of usage.

AWS Fargate Spot

Amazon has also built in a feature to AWS Fargate which can reduce the pricing even further. This is available when running the containers on an Amazon fleet of spot instances. These spot machines are essentially the extra capacity of compute nodes in the Amazon data centers that are not being used by on demand customers, or customers that have pre-paid for compute. This spare capacity is charged at a spot rate so that amazon can make some money off them even when customers are not willing to pay full price for the machines at the current time.

The risk to running containers on spot based instances is that the underlying instance can be taken away at any moment. If the on demand usage ends up spiking for the underlying instance that is running the container in Fargate, it could be taken away meaning the container will fail since it’s hardware has virtually failed.

If the micro service you are running can withstand failures of containers, or the container runs in an idempotent fashion, spot may be a useful way of running those containers. The large benefit of running it this way is the largely reduced cost. The vCPU charge for spot based fargate in US East (N. Virginia) is $0.01780807 per hour and the RAM charge is $0.0019546 per GB per hour. This works out to a 56% savings on both the vCPU and RAM based pricing when using Fargate spot pricing for ECS.

This is definitely something to look into for a micro-service running on AWS Fargate. It may even be worth rearchitecting the micro-service to be more resilient so that it take advantage of these spot price based savings. However, if this type of re-design is not possible for the given service, it may be worth looking into pre-paying for the container usage time commitment to get similar pricing.