AWS Fargate – A Quick Introduction & Why Is It Awesome

AWS Fargate – A perfect middle ground between EC2 and Lambda based serverless architecture

When your product or offerings are in an early stage, there are a lot of unknowns related to timelines for adoption as well as the speed at which adoption will shoot up. You want the product to scale up or down as needed but at the same time, you want availability, security and flexibility. Of course, you don’t want to invest too much early on when you are not sure of the adoption and steady-state needs.

Earlier, companies found cloud to be good way to minimize investment. Fast forward a few years and the novelty has gone down, people have started finding inefficiencies and want something more. A lot of money has been invested in Ops. And now you need cloud/DevOps experts instead of networking experts. Here comes serverless! Using the Lambda function, now you can truly pay per use. Your Ops efforts becomes a fraction of EC2. Isn’t that cool?

But now, you need to think differently as Lambda is a function-as-a-service. And not every application/deployment can be architected to be the Lambda functions or FaaS. Is there no pure serverless solution for EC2 deployments? If only you could reap the benefits of serverless computing without Lambda?

Don’t worry! Here comes Fargate!

What is AWS Fargate?

AWS Fargate is a serverless compute engine for containers and works with both Amazon Elastic Container Service (ECS) & Amazon Elastic Kubernetes Service (EKS). Fargate makes it easy for you to focus on building your applications. It removes the need to provision and manage servers, lets you specify and pay for resources per application, and improves security through application isolation by design.

Fargate allocates the right amount of computing power, eliminating the need to choose instances and scale cluster capacity. You only pay for the resources required to run your containers, so there is no over-provisioning and paying for additional servers. Fargate runs each task or pod in its own kernel providing the tasks and pods their own isolated compute environment. This enables your application to have workload isolation and improved security by design.

Fargate for containers is what Lambda is to functions. Lambda is FaaS (function as a service), while Fargate is CaaS (container as a service).

It all began with EC2 being used for traditional deployment or containerized deployment. Then came Lambda/serverless which gained popularity quickly as users didn’t have to deal with underlying infrastructure. People loved its ‘pay as you go’ concept.

Fargate bridges the gap between these two models by facilitating serverless deployment of the containers itself. Some of its useful features are:

• Immutable deployments, no entry into the servers
• No need to handle cluster resource provisioning, patching, configuring or scaling of machines
• Low cost of ownership
• Pay as you go pricing model

When should you use Fargate?

Fargate can be used to deploy containers either through ECS or EKS. Here are some ideal scenarios to choose Fargate:

• The user wants to get rid of container/cluster management on EC2 instances
• When there isn’t enough clarity about workloads/compute resources needed in the long term, making it harder to decide the EC2 instance type to be used
• When the user doesn’t want to deal with underlying infrastructure, patching of the OS, maintenance etc.
• When the user wants optimized costs and auto scalable deployments while paying only for the actual usage.
• It can also be used for scheduled or infrequent activities like taking DB backups/archiving files where an EC2 needs to be spun up to run those activities stopped on completion.

Comparison between Fargate and EC2

As the users don’t have direct control of the underlying infrastructure, there are a few major concerns in serverless deployments:

• How does one ensure the security, monitoring, VPC based deployments?
• Will all the good aspects of traditional EC2 deployment be available?
• How does one ensure accessibility to resources within the VPC like databases, other applications and usage of VPC endpoints

Well, Fargate deployments can work in similar manner as traditional EC2 deployments.

• Fargate allows the container tasks to be assigned a specific VPC and subnet. Security groups, inbound traffice, outbound traffic, VPC endpoints, NACLs and other resources in the VPC can therefore be managed like usual.

In the background, a task is assigned a private/ public ENI (Elastic Network Interface) from the IP range of the subnet it belongs to. This ENI is used as the IP address for any network communication.

• ALB can be deployed in front of the containers and SSL connections can be brought up to the ALB sitting in the public subnet. Containers can remain in the private subnets making it highly secure from attacks.
• It is easily integrable with CloudWatch logs for monitoring purposes
• It is easily integrable in CICD pipeline

The is one key difference between ECS deployment using EC2 and Fargate. In Fargate, one cannot login to the containers or underlying EC2 instances (that were launched by AWS). But that’s the whole purpose of immutable deployments. It leaves no surface for security threats as no one can login to underlying infrastructure. A good architecture should have immutable deployments with no direct entry into the application servers. The logs/ monitoring data should be published externally to the server to make it robust.

The CloudWatch logs provide good insight into what’s happening in your application through app logs and metrics. Fargate should be enough to give you insight into your container/ cluster management.

Fargate is not a right choice  only in cases where there is a very specific requirement to have a direct control over the underlying infrastructure.

Find out how we helped save 85% of infrastructure cost for a cloud management product by deploying AWS Fargate based serverless architecture.

Read Now

Factors to watch out for

In terms of pricing, anything that is serverless or ‘pay as you go’ works wonderfully for unpredictable and less workloads as it relieves users from reserving infrastructure and paying unnecessary costs for underutilized resources.

But eventually as the workloads become consistent, high and predictable, it is advisable to switch to reserved EC2 instance or cost saving plans (EC2) as that will be much cheaper.

Fargate shall result into good savings till that time.

And if you are planning to run your workloads on Fargate for a year or more, then ‘compute savings plan for AWS Fargate’ are worth looking into as they offer 20% savings over ‘on demand’ cost.