AWS EKS with and without Fargate: Understanding the Differences

When you try to wrap your mind around container deployment services in the Amazon Web Services (AWS) cloud, you can easily feel like you’re drowning in alphabet soup.

There’s EKS, Amazon’s managed Kubernetes service. There’s ECS, another container orchestrator that kind of does the same thing as EKS, but not really. And then there’s Fargate – which, admittedly, is not an acronym, but its name is also not exactly easy to interpret.

All of these services and tools play a role in orchestrating and scheduling containers in the AWS cloud. But they work in different ways, and understanding the small details surrounding them is critical for planning the right AWS container strategy.

If you’re struggling to figure out what all of the above means – if, in other words, you’re confused by all the talk about schedulers and orchestrators and “Fargate mode” and so on – this article is for you. Below, we unpack the complex relationship between AWS Fargate and EKS. We’ll also clarify where ECS fits within all of this, even though ECS is not the focus of this article.

And we’ll answer the biggest question that many AWS users face today, which is when it does and doesn’t make sense to deploy containerized apps using Fargate, as opposed to using standard EKS.

AWS Container Services: EKS and ECS

Let’s start by defining the two main services that Amazon offers for deploying containerized applications:

• Elastic Kubernetes Service (EKS): EKS is a container deployment service based on open source Kubernetes. You could also call it a Kubernetes distribution or Kubernetes-as-a-Service.
• Elastic Container Engine (ECS): ECS is a container deployment service powered by a proprietary container orchestration engine that Amazon developed itself. AWS built ECS back in the days of the “orchestrator wars,” before it was clear that Kubernetes would become, by far and away, the leading container orchestration platform.

Both of these services let you do basically the same thing, albeit in slightly different ways: deploy containerized applications using an orchestration layer that is hosted in the AWS cloud. In most cases, ECS and EKS also rely on infrastructure that is hosted by AWS.

(The exception is if you use EKS Anywhere or if you run ECS or EKS via AWS Outposts, AWS’s hybrid cloud framework. In these situations, you can use private infrastructure to host your applications, even though the orchestration control plane would remain hosted in the AWS public cloud.)

What about Fargate?

On the surface, EKS and ECS seem simple enough.

Where things start to get complicated is when Fargate enters the picture. Fargate isn’t a container deployment service per se, because it doesn’t orchestrate containers on its own. It relies on other orchestrators – namely, EKS or ECS – to do the actual orchestration. So, Fargate isn’t an alternative to or competitor with EKS or ECS.

Instead, think of Fargate as an optional “deployment mode” that can – but does not necessarily have to – be used in conjunction with one of AWS’s container services to manage the way infrastructure is set up and containers are deployed onto it.

In other words, Fargate is one way to deploy containers on both EKS and ECS. But it’s not the only way. You can use ECS or EKS in what you might call standard mode, meaning without Fargate. In the latter case, ECS or EKS handle container deployment and scheduling on their own.

How Does Fargate Work?

Fargate works by letting you deploy containers without having to set up or manage the infrastructure that hosts them. You simply tell Fargate which container images you want to run and provide some details about how many compute and memory resources to allocate to them. Then, Fargate automatically provisions the host servers for you. You pay only for the resources consumed when your containers are actually running.

Again, Fargate still relies on either ECS or EKS to handle container orchestration tasks. But Fargate automates infrastructure setup and container deployment, making the overall process simpler.

AWS describes Fargate as a serverless compute engine because it eliminates the need for end-users to manage the servers that host containers. (To be clear, the servers still exist; AWS just manages them for you.) Note, however, that Fargate is different from AWS Lambda, another type of serverless computing service that was not designed to run containers specifically (although Lamba does now support the deployment of container images).

Fargate vs. Autoscaling and Managed Nodes

At this point, you may be thinking: if I don’t want to have to manage the infrastructure that hosts containers running on EKS (or ECS), can’t I just configure autoscaling or use EKS managed node groups?

The answer is “basically, yes.” EKS and ECS can both optionally be configured with autoscaling, which allows you to tell AWS to scale your container host infrastructure up or down automatically. In addition, on EKS, you can take advantage of managed node groups, a feature that automates node provisioning and lifecycle management.

These two features – autoscaling and managed node groups – are similar to Fargate. But there are important differences:

• Setup: With autoscaling, you still have to set up the initial infrastructure. Fargate totally eliminates the setup process.
• Control: Autoscaling gives you more control over exactly how scaling is managed. In Fargate mode, AWS handles scaling totally on its own.
• Cost: While there is no cost for using EKS autoscaling and managed nodes specifically, the EKS cost structure is different from that of Fargate.
• Region support: Support for Fargate and EKS managed node groups varies by AWS region. Make sure your region (or regions) supports the deployment mode you want to use before you try to configure them.

EKS with and without Fargate: Two Examples

To illustrate the differences between EKS with and without Fargate, let’s look at three basic cluster creation examples.

EKS in Standard Mode without Autoscaling

To set up an EKS cluster in standard mode – meaning without using Fargate, and without using managed node groups or autoscaling – you have to specify how many nodes to create when setting up the cluster using an eksctl command such as:

eksctl create cluster --name=cluster-1 --nodes=4Code language: JavaScript (javascript)

This process is easy enough, but note that we had to make decisions upfront about how large the cluster should be. You can always go in and add or remove nodes manually later, but that’s less ideal than specifying the perfect cluster size from the start.

EKS in Standard Mode with Autoscaling

If you want to configure autoscaling, you’d use the –nodes-min and –nodes-max flags to specify the range of the cluster size you want to configure. For example:

eksctl create cluster --name=cluster-5 --nodes-min=3 --nodes-max=5Code language: JavaScript (javascript)

With autoscaling configured, we can have more confidence that our cluster size will match workload needs even as workload needs change. Still, we had to make an explicit decision upfront about how large the cluster should be.

EKS with Managed Nodes

If you don’t specify node count, your EKS clusters will use managed node groups. For example:

eksctl create cluster --name my-cluster --region region-codeCode language: JavaScript (javascript)

That was pretty easy. We let EKS decide how large to make our cluster. The downside, of course, is that we place cluster management in the hands of AWS, so we have less control.

EKS with Fargate

To create a cluster for use with Fargate mode, we use the –fargate flag:

eksctl create cluster --name my-cluster --region region-code --fargateCode language: JavaScript (javascript)

That was also very easy. The caveat is that we have no explicit control over cluster scaling. In addition, billing for this cluster will be based on Fargate pricing.

When and When Not to Use Fargate

Now that you know the various approaches available for working with EKS, let’s evaluate the main factors that typically determine when and when not to use Fargate mode.

Control

Fargate gives you less control in various ways. Not only do you not control cluster sizing, but you also can’t specify configuration variables like HostPort and HostNetwork for containers running in Fargate mode. You also can’t run containers in privileged mode, and you can’t configure DaemonSets.

In general, then, Fargate makes most sense when you don’t need fine-tuned control over how your containers run. If you need as much control as possible, use EKS in standard mode.

Security

In certain respects, containers deployed via Fargate are a bit more secure because they run inside dedicated virtual machines. This level of isolation certainly won’t stop all threats, but it doesn’t hurt.

The fact that Fargate doesn’t support privileged mode is also sort of a security feature, because it saves you from taking the risk of running privileged containers.

On the other hand, the greater control that EKS in standard mode gives you may lead to better security outcomes.

Supported Regions and Configurations

As noted above, support for Fargate varies between AWS regions. It’s also not available if you use AWS Outposts or EKS Anywhere. So, in some cases, your broader AWS deployment strategy will determine whether you can use Fargate or not.

Pricing

As noted above, standard EKS and Fargate are subject to different pricing schedules. The exact prices vary by AWS region and workload type. Whether Fargate or standard EKS is more cost effective depends largely on how good you are at configuring the right cluster size if you use standard EKS.

In general, though, Fargate tends to be cheaper in the long run if you don’t do a good job of configuring EKS autoscaling, or if your workload scales up and down massively on a frequent basis. But standard EKS will likely cost less for workloads that don’t need to scale frequently, or in cases where you carefully rightsize your cluster based on cost and performance needs.

Convenience

If simplicity and ease of use are your top priority, Fargate is the clear choice. EKS in standard mode is not exactly hard to use, but it still requires more effort than Fargate mode.

Conclusion

When it comes to choosing between EKS in standard mode and EKS in Fargate mode, there is no choice that is universally right or wrong. You’ll need to think carefully about which types of workloads you are deploying, what their scaling requirements look like, and which level of management effort you can commit to in order to decide whether or not to use Fargate with EKS.