[ARTICLE]

AWS Fargate: Positives and Negatives

Fargate is a serverless compute engine for containers aka Container-as-a-Service or CaaS offering from AWS.  It works with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Fargate removes the need to manage infrastructure to run containerized applications. Also, its pay-by-the-second by application model can result in cost savings compared with running your own server instances. 

What is AWS Fargate?

If you have used either ECS or EKS to run your containerized applications, you are well aware that you are managing infrastructure, specifically clusters of EC2 instances, on which the ECS or Kubernetes service then manages running containers.  In the case of ECS, you are responsible for the EC2 instances you are running (you handle scaling, monitoring, patching, and security) in addition to the actual application concerns. Fargate looks a bit like a PaaS in that you no longer need to worry about that infrastructure stuff. While not providing as integrated a dev experience as a Heroku or OpenShift, the CaaS model lets you focus on developing the containerized app. It also lets Fargate handle running it.

How Does AWS Fargate Work? 

While AWS Fargate still runs on Elastic Container Service (ECS), you are not responsible for managing the ECS service. To run an application on Fargate you will need to: 

  • Have an AWS account
  • Containerize your application
  • Define your application’s CPU and memory requirements
  • Define any necessary IAM / networking policies 

Although we can assume Fargate is run using ECS on EC2 instances, but AWS does not provide much detail about the internal workings. This is perhaps the point. This is not your concern. You are able to manage your containers without creating a cluster of virtual machines. AWS manages the scaling of underlying resources and ensures 

AWS Fargate: Pluses and Minuses

Now you might think not needing to manage infrastructure and getting pay-by-the-second pricing makes going with Fargate a simple decision. However, there are also drawbacks. As I often caution eager adopters of new technology – know how your use case maps to the functionality of the tool you are considering.

Positives (+):

  • Less Complexity
  • Better Security
  • Lower Costs (Maybe)

Negatives (-):

  • Higher Costs (Maybe)
  • Less Customization
  • Limited Regions Available

Plus: Simplicity

Fargate is a Container as a Service (CaaS) technology.  It eliminates the need to manage servers. Thus the reason it is a “serverless” technology. While, yes, your containers are still running on servers, you don’t actually need to worry about configuring and maintaining the servers. AWS does that for you. You are still responsible for defining the infrastructure parameters your containers require (e.g. CPU, memory, storage, and networking). Then AWS will run your app for as long, or short, a time as you’d like.

Plus: Better Security

Complexity is problematic from a security perspective. Fargate removes the security burden of managing the complexity of ECS or EKS. Fargate runs each task for pod its own kernel providing your applications with their own isolated compute environment. Instead, you embed security within the container itself. There are also third party companies that offer additional security services for running applications in Fargate.

Plus… or Minus: Costs

On the surface, Fargate provides a tempting cost-saving opportunity when compared to ECS or EKS. It is important to remember you are still paying for a service. While not explicitly broken out in the cast of Fargate, that includes infrastructure management. It will come down to use case, size of infrastructure needs, and how good/efficient your ops team are. The important thing to remember is that the per-hour cost of Fargate is higher than ECS or EKS

Two areas you can expect to claim cost savings are:

  • Intermittent or highly variable workloads. Fargate only charges you, by the second, when your container workloads are running. The total time the VM is running does not matter.
  • Interruption tolerant processes can be run on Fargate Spot, which can provide even greater savings.
  • Fargate is good at time and event based (via CloudWatch) task scheduling so making sure that containers only run when needed is easy.

Long running events may be better served with EC2 instances. This is to take advantage of spot instances or reserved instances. You no longer pay per container, but along with this comes the responsibility of managing the infrastructure. You also need to make sure the containers you are running are efficiently packed onto those instances. 

Minus: Less Customizable

Do you have special requirements for compliance, governance, risk management, and the like? Fargate may not allow the finer-grained control that a more traditional model provides. 

Minus: Limited Regional Availability

If placing your application resources in a specific region or zone is important to realize the service is not available in all regions/zones. Also, far fewer EKS supporting regions support Fargate:

  • US East (N. Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • Europe (Ireland)
  • Europe (Frankfurt)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Asia Pacific (Tokyo)

For the most up to date availability listing, check the Amazon Regional Services page.