AWS Fargate Deep Dive: Key Takeaways from Melbourne User Group

Last night, I spoke at the AWS Melbourne User Group, providing a deep dive into AWS Fargate.
I began by recounting my first talk at the AWSUG in 2012
Talking at the AWSUG Aug 2012
Why Fargate?
I highlighted the key challenges Fargate aims to solve:
- With the rise of 12-factor apps, teams want to focus on deploying containers without managing underlying infrastructure
- Keeping operating systems up-to-date is often difficult and easily neglected
Fargate Architecture
AWS Fargate (Linux version) is powered by Firecracker VM technology, providing security isolation for Linux-based Fargate containers and Lambda functions. The compute resource appears in your AWS account and is shared via a network interface (ENI).
Pricing Considerations
Fargate pricing depends on several factors:
- Spot vs. on-demand instances
- ARM vs. X86 architecture (note: Windows Fargate doesn’t yet support ARM)
- Windows vs. Linux (Windows incurs additional licensing costs)
- CPU shares and memory allocation from a predefined menu (custom configurations not available)
Container Scheduler Platforms
AWS offers two main container scheduler platforms:
- Elastic Kubernetes Service (EKS)
- Elastic Container Service (ECS)
Both platforms support:
- Running containers on Fargate
- Running containers on self-managed EC2 instances (or managed nodegroups in EKS)
- Mixed deployment models
ECS vs. EKS: Key Differences
ECS:
- Highly opinionated and simple
- AWS-specific
- Supports decentralized “you build it, you run it” operating models
- Suited for multiple ECS clusters
EKS:
- Highly flexible with a rich plugin ecosystem
- Requires specialized skills to operate effectively
- Better suited for centralized operations
- Typically uses fewer, larger clusters
Choosing the Right Approach
Consider your organization’s operating model:
- For traditional SRE centralized operations, EKS might be preferable
- For decentralized operations that empower teams, ECS’s simplicity may be advantageous
Note: Regardless of platform choice, developer-focused golden path tooling remains critical!
Fargate Limitations at Scale
When operating at scale, Fargate on EKS has some limitations:
- Cannot run daemonsets (requires sidecar pattern instead)
- Risk of overprovisioning if pod requirements don’t align with Fargate launch options
For a middle-ground approach, consider Bottlerocket as an AMI in EKS to reduce OS-level security risks. Additionally, running kube-scheduler on Fargate (including Karpenter) while using Karpenter to manage EC2-based nodes offers an excellent compromise.
This is the video of my talk: here