AWS Fargate Deep Dive: Key Takeaways from Melbourne User Group

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

Image description

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



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *