FARGATE

The slow unceremonious death of EC2 Autoscaling

Let’s pour one out for an old friend.

AWS recently announced a small, seemingly boring new feature for EC2 Auto Scaling: the ability to cancel a pending instance refresh. If you squinted, you might have missed it. It sounds like a minor quality-of-life update, something to make a sysadmin’s Tuesday slightly less terrible.

But this isn’t a feature. It’s a gold watch. It’s the pat on the back and the “thanks for your service” speech at the awkward retirement party.

The EC2 Auto Scaling Group (ASG), the bedrock of cloud elasticity, the one tool we all reflexively reached for, is being quietly put out to pasture.

No, AWS hasn’t officially killed it. You can still spin one up, just like you can still technically send a fax. AWS will happily support it. But its days as the default, go-to solution for modern workloads are decisively over. The battle for the future of scaling has ended, and the ASG wasn’t the winner. The new default is serverless containers, hyper-optimized Spot fleets, and platforms so abstract they’re practically invisible.

If you’re still building your infrastructure around the ASG, you’re building a brand-new house with plumbing from 1985. It’s time to talk about why our old friend is retiring and meet the eager new hires who are already measuring the drapes in its office.

So why is the ASG getting the boot?

We loved the ASG. It was a revolutionary idea. But like that one brilliant relative everyone dreads sitting next to at dinner, it was also exhausting. Its retirement was long overdue, and the reasons are the same frustrations we’ve all been quietly grumbling about into our coffee for years.

It promised automation but gave us chores

The ASG’s sales pitch was simple: “I’ll handle the scaling!” But that promise came with a three-page, fine-print addendum of chores.

It was the operational overhead that killed us. We were promised a self-driving car and ended up with a stick-shift that required constant, neurotic supervision. We became part-time Launch Template librarians, meticulously versioning every tiny change. We became health-check philosophers, endlessly debating the finer points of ELB vs. EC2 health checks.

And then… the Lifecycle Hooks.

A “Lifecycle Hook” is a polite, clinical term for a Rube Goldberg machine of desperation. It’s a panic button that triggers a Lambda, which calls a Systems Manager script, which sends a carrier pigeon to… maybe… drain a connection pool before the instance is ruthlessly terminated. Trying to debug one at 3 AM was a rite of passage, a surefire way to lose precious engineering time and a little bit of your soul.

It moves at a glacial pace

The second nail in the coffin was its speed. Or rather, the complete lack of it.

The ASG scales at the speed of a full VM boot. In our world of spiky, unpredictable traffic, that’s an eternity. It’s like pre-heating a giant, industrial pizza oven for 45 minutes just to toast a single slice of bread. By the time your new instance is booted, configured, service-discovered, and finally “InService,” the spike in traffic has already come and gone, leaving you with a bigger bill and a cohort of very annoyed users.

It’s an expensive insurance policy

The ASG model is fundamentally wasteful. You run a “warm” fleet, paying for idle capacity just in case you need it. It’s like paying rent on a 5-bedroom house for your family of three, just in case 30 cousins decide to visit unannounced.

This “scale-up” model was slow, and the “scale-down” was even worse, riddled with fears of terminating the wrong instance and triggering a cascading failure. We ended up over-provisioning to avoid the pain of scaling, which completely defeats the purpose of “auto-scaling.”

The eager interns taking over the desk

So, the ASG has cleared out its desk. Who’s moving in? It turns out there’s a whole line of replacements, each one leaner, faster, and blissfully unconcerned with managing a “fleet.”

1. The appliance Fargate and Cloud Run

First up is the “serverless container”. This is the hyper-efficient new hire who just says, “Give me the Dockerfile. I’ll handle the rest.”

With AWS Fargate or Google’s Cloud Run, you don’t have a fleet. You don’t manage VMs. You don’t patch operating systems. You don’t even think about an instance. You just define a task, give it some CPU and memory, and tell it how many copies you want. It scales from zero to a thousand in seconds.

This is the appliance model. When you buy a toaster, you don’t worry about wiring the heating elements or managing its power supply. You just put in bread and get toast. Fargate is the toaster. The ASG was the “build-your-own-toaster” kit that came with a 200-page manual on electrical engineering.

Just look at the cognitive load. This is what it takes to get a basic ASG running via the CLI:

# The "Old Way": Just one of the many steps...
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name my-legacy-asg \
    --launch-template "LaunchTemplateName=my-launch-template,Version='1'" \
    --min-size 1 \
    --max-size 5 \
    --desired-capacity 2 \
    --vpc-zone-identifier "subnet-0571c54b67EXAMPLE,subnet-0c1f4e4776EXAMPLE" \
    --health-check-type ELB \
    --health-check-grace-period 300 \
    --tag "Key=Name,Value=My-ASG-Instance,PropagateAtLaunch=true"

You still need to define the launch template, the subnets, the load balancer, the health checks…

Now, here’s the core of a Fargate task definition. It’s just a simple JSON file:

// The "New Way": A snippet from a Fargate Task Definition
{
  "family": "my-modern-app",
  "containerDefinitions": [
    {
      "name": "my-container",
      "image": "nginx:latest",
      "cpu": 256,
      "memory": 512,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80
        }
      ]
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

You define what you need, and the platform handles everything else.

2. The extreme couponer Spot fleets

For workloads that are less “instant spike” and more “giant batch job,” we have the “optimized fleet”. This is the high-stakes, high-reward world of Spot Instances.

Spot used to be terrifying. AWS could pull the plug with two minutes’ notice, and your entire workload would evaporate. But now, with Spot Fleets and diversification, it’s the smartest tool in the box. You can tell AWS, “I need 1,000 vCPUs, and I don’t care what instance types you give me, just find the cheapest ones.”

The platform then builds a diversified fleet for you across multiple instance types and Availability Zones, making it incredibly resilient to any single Spot pool termination. It’s perfect for data processing, CI/CD runners, and any batch job that can be interrupted and resumed. The ASG was always too rigid for this kind of dynamic, cost-driven scaling.

3. The paranoid security guard MicroVMs

Then there’s the truly weird stuff: Firecracker. This is the technology that powers AWS Lambda and Fargate. It’s a “MicroVM” that gives you the iron-clad security isolation of a full virtual machine but with the lightning-fast startup speed of a container.

We’re talking boot times of under 125 milliseconds. This is for when you need to run thousands of tiny, separate, untrusted workloads simultaneously without them ever being able to see each other. It’s the ultimate “multi-tenant” dream, giving every user their own tiny, disposable, fire-walled VM in the blink of an eye.

4. The invisible platform Edge runtimes

Finally, we have the platforms that are so abstract they’re “scaled to invisibility”. This is the world of Edge. Think Lambda@Edge or CloudFront Functions.

With these, you’re not even scaling in a region anymore. Your logic, your code, is automatically replicated and executed at hundreds of Points of Presence around the globe, as close to the end-user as possible. The entire concept of a “fleet” or “instance” just… disappears. The logic scales with the request.

Life after the funeral. How to adapt

Okay, the eulogy is over. The ASG is in its rocking chair on the porch. What does this mean for us, the builders? It’s time to sort through the old belongings and modernize the house.

Go full Marie Kondo on your architecture

First, you need to re-evaluate. Open up your AWS console and take a hard look at every single ASG you’re running. Be honest. Ask the tough questions:

Does this workload really need to be stateful?
Do I really need VM-level control, or am I just clinging to it for comfort?
Is this a stateless web app that I’ve just been too lazy to containerize?

If it doesn’t spark joy (or isn’t a snowflake legacy app that’s impossible to change), thank it for its service and plan its migration.

Stop shopping for engines, start shopping for cars

The most important shift is this: Pick the runtime, not the infrastructure.

For too long, our first question was, “What EC2 instance type do I need?” That’s the wrong question. That’s like trying to build a new car by starting at the hardware store to buy pistons.

The right question is, “What’s the best runtime for my workload?”

Is it a simple, event-driven piece of logic? That’s a Function (Lambda).
Is it a stateless web app in a container? That’s a Serverless Container (Fargate).
Is it a massive, interruptible batch job? That’s an Optimized Fleet (Spot).
Is it a cranky, stateful monolith that needs a pet VM? Only then do you fall back to an Instance (EC2, maybe even with an ASG).

Automate logic, not instance counts

Your job is no longer to be a VM mechanic. Your team’s skills need to shift. Stop manually tuning desired_capacity and start designing event-driven systems.

Focus on scaling logic, not servers. Your scaling trigger shouldn’t be “CPU is at 80%.” It should be “The SQS queue depth is greater than 100” or “API latency just breached 200ms”. Let the platform, be it Lambda, Fargate, or a KEDA-powered Kubernetes cluster, figure out how to add more processing power.

Was it really better in the old days?

Of course, this move to abstraction isn’t without trade-offs. We’re gaining a lot, but we’re also losing something.

The gain is obvious: We get our nights and weekends back. We get drastically reduced operational overhead, faster scaling, and for most stateless workloads, a much lower bill.

The loss is control. You can’t SSH into a Fargate container. You can’t run a custom kernel module on Lambda. For those few, truly special, high-customization legacy workloads, this is a dealbreaker. They will be the ASG’s loyal companions in the retirement home.

But for everything else? The ASG is a relic. It was a brilliant, necessary solution for the problems of 2010. But the problems of 2025 and beyond are different. The cloud has evolved to scale logic, functions, and containers, not just nodes.

The king isn’t just dead. The very concept of a throne has been replaced by a highly efficient, distributed, and slightly impersonal serverless committee. And frankly, it’s about time.

Serverless without the wait

I once bought a five-minute rice cooker that spent four of those minutes warming up with a pathetic hum. It delivered the goods, eventually, but the promise felt… deceptive. For years, AWS Lambda felt like that gadget. It was the perfect kitchen tool for the odd jobs: a bit of glue code here, a light API there. It was the brilliant, quick-fire microwave of our architecture.

Then our little kitchen grew into a full-blown restaurant. Our “hot path”, the user checkout process, became the star dish on our menu. And our diners, quite rightly, expected it to be served hot and fast every time, not after a polite pause while the oven preheated. That polite pause was our cold start, and it was starting to leave a bad taste.

This isn’t a story about how we fell out of love with Lambda. We still adore it. This is the story of how we moved our main course to an industrial-grade, always-on stove. It’s about what we learned by obsessively timing every step of the process and why we still keep that trusty microwave around for the side dishes it cooks so perfectly. Because when your p95 latency needs to be boringly predictable, keeping the kitchen warm isn’t a preference; it’s a law of physics.

What forced us to remodel the kitchen

No single event pushed us over the edge. It was more of a slow-boiling frog situation, a gradual realization that our ambitions were outgrowing our tools. Three culprits conspired against our sub-300ms dream.

First, our traffic got moody. What used to be a predictable tide of requests evolved into sudden, sharp tsunamis during business hours. We needed a sea wall, not a bucket.

Second, our user expectations tightened. We set a rather tyrannical goal of a sub-300ms p95 for our checkout and search paths. Suddenly, the hundreds of milliseconds Lambda spent stretching and yawning before its first cup of coffee became a debt we couldn’t afford.

Finally, our engineers were getting tired. We found ourselves spending more time performing sacred rituals to appease the cold start gods, fiddling with layers, juggling provisioned concurrency, than we did shipping features our users actually cared about. When your mechanics spend more time warming up the engine than driving the car, you know something’s wrong.

The punchline isn’t that Lambda is “bad.” It’s that our requirements changed. When your performance target drops below the cost of a cold start plus dependency initialization, physics sends you a sternly worded letter.

Numbers don’t lie, but anecdotes do

We don’t ask you to trust our feelings. We ask you to trust the stopwatch. Replicate this experiment, adjust it for your own tech stack, and let the data do the talking. The setup below is what we used to get our own facts straight. All results are our measurements as of September 2025.

The test shape

Endpoint: Returns a simple 1 KB JSON payload.
Comparable Compute: Lambda set to 512 MB vs. an ECS Fargate container task with 0.5 vCPU and 1 GB of memory.
Load Profile: A steady, closed-loop 100 requests per second (RPS) for 10 minutes.
Metrics Reported: p50, p90, p95, p99 latency, and the dreaded error rate.

Our trusty tools

Load Generator: The ever-reliable k6.
Metrics: A cocktail of CloudWatch and Prometheus.
Dashboards: Grafana, to make the pretty charts that managers love.

Your numbers will be different. That’s the entire point. Run the tests, get your own data, and then make a decision based on evidence, not a blog post (not even this one).

Where our favorite gadget struggled

Under the harsh lights of our benchmark, Lambda’s quirks on our hot path became impossible to ignore.

Cold start spikes: Provisioned Concurrency can tame these, but it’s like hiring a full-time chauffeur to avoid a random 10-minute wait for a taxi. It costs you a constant fee, and during a real rush hour, you might still get stuck in traffic.
The startup toll: Initializing SDKs and warming up connections added tens to hundreds of milliseconds. This “entry fee” was simply too high to hide under our 300ms p95 goal.
The debugging labyrinth: Iterating was slow. Local emulators helped, but parity was a myth that occasionally bit us. Debugging felt like detective work with half the clues missing.

Lambda continues to be a genius for event glue, sporadic jobs, and edge logic. It just stopped being the right tool to serve our restaurant’s most popular dish at rush hour.

Calling in the heavy artillery

We moved our high-traffic endpoints to container-native services. For us, that meant ECS on Fargate fronted by an Application Load Balancer (ALB). The core idea is simple: keep a few processes warm and ready at all times.

Here’s why it immediately helped:

Warm processes: No more cold start roulette. Our application was always awake, connection pools were alive, and everything was ready to go instantly.
Standardized packaging: We traded ZIP files for standard Docker images. What we built and tested on our laptops was, byte for byte, what we shipped to production.
Civilized debugging: We could run the exact same image locally and attach a real debugger. It was like going from candlelight to a floodlight.
Smarter scaling: We could maintain a small cadre of warm tasks as a baseline and then scale out aggressively during peaks.

A quick tale of the tape

Here’s a simplified look at how the two approaches stacked up for our specific needs.

Our surprisingly fast migration plan

We did this in days, not weeks. The key was to be pragmatic, not perfect.

1. Pick your battles: We chose our top three most impactful endpoints with the worst p95 latency.

2. Put it in a box: We converted the function handler into a tiny web service. It’s less dramatic than it sounds.

# Dockerfile (Node.js example)
FROM node:22-slim
WORKDIR /usr/src/app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

ENV NODE_ENV=production PORT=3000
EXPOSE 3000
CMD [ "node", "server.js" ]

// server.js
const http = require('http');
const port = process.env.PORT || 3000;

const server = http.createServer((req, res) => {
  if (req.url === '/health') {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    return res.end('ok');
  }

  // Your actual business logic would live here
  const body = JSON.stringify({ success: true, timestamp: Date.now() });
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(body);
});

server.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

3. Set up the traffic cop: We created a new target group for our service and pointed a rule on our Application Load Balancer to it.

{
  "family": "payment-api",
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "requiresCompatibilities": ["FARGATE"],
  "executionRoleArn": "arn:aws:iam::987654321098:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::987654321098:role/paymentTaskRole",
  "containerDefinitions": [
    {
      "name": "app-container",
      "image": "[987654321098.dkr.ecr.us-east-1.amazonaws.com/payment-api:2.1.0](https://987654321098.dkr.ecr.us-east-1.amazonaws.com/payment-api:2.1.0)",
      "portMappings": [{ "containerPort": 3000, "protocol": "tcp" }],
      "environment": [{ "name": "NODE_ENV", "value": "production" }]
    }
  ]
}

4. The canary in the coal mine: We used weighted routing to dip our toes in the water. We started by sending just 5% of traffic to the new container service.

# Terraform Route 53 weighted canary
resource "aws_route53_record" "api_primary_lambda" {
  zone_id = var.zone_id
  name    = "api.yourapp.com"
  type    = "A"

  alias {
    name                   = aws_api_gateway_domain_name.main.cloudfront_domain_name
    zone_id                = aws_api_gateway_domain_name.main.cloudfront_zone_id
    evaluate_target_health = true
  }

  set_identifier = "primary-lambda-path"
  weight         = 95
}

resource "aws_route53_record" "api_canary_container" {
  zone_id = var.zone_id
  name    = "api.yourapp.com"
  type    = "A"

  alias {
    name                   = aws_lb.main_alb.dns_name
    zone_id                = aws_lb.main_alb.zone_id
    evaluate_target_health = true
  }

  set_identifier = "canary-container-path"
  weight         = 5
}

5. Stare at the graphs: For one hour, we watched four numbers like hawks: p95 latency, error rates, CPU/memory headroom on the new service, and our estimated cost per million requests.

6. Go all in (or run away): The graphs stayed beautifully, boringly flat. So we shifted to 50%, then 100%. The whole affair was done in an afternoon.

The benchmark kit you can steal

Don’t just read about it. Run a quick test yourself.

// k6 script (save as test.js)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,
  duration: '5m',
  thresholds: {
    'http_req_duration': ['p(95)<250'], // Aim for a 250ms p95
    'checks': ['rate>0.999'],
  },
};

export default function () {
  const url = __ENV.TARGET_URL || '[https://api.yourapp.com/checkout/v2/quote](https://api.yourapp.com/checkout/v2/quote)';
  const res = http.get(url);
  check(res, { 'status is 200': r => r.status === 200 });
  sleep(0.2); // Small pause between requests
}

Run it from your terminal like this:

k6 run -e TARGET_URL=https://your-canary-endpoint.com test.js

Our results for context

These aren’t universal truths; they are snapshots of our world. Your mileage will vary.

The numbers in bold are what kept us up at night and what finally let us sleep. For our steady traffic, the always-on container was not only faster and more reliable, but it was also shaping up to be cheaper.

Lambda is still in our toolbox

We didn’t throw the microwave out. We just stopped using it to cook the Thanksgiving turkey. Here’s where we still reach for Lambda without a second thought:

Sporadic or bursty workloads: Those once-a-day reports or rare event handlers are perfect for scale-to-zero.
Event glue: It’s the undisputed champion of transforming S3 puts, reacting to DynamoDB streams, and wiring up EventBridge.
Edge logic: For tiny header manipulations or rewrites, Lambda@Edge and CloudFront Functions are magnificent.

Lambda didn’t fail us. We outgrew its default behavior for a very specific, high-stakes workload. We cheated physics by keeping our processes warm, and in return, our p95 stopped stretching like hot taffy.

If your latency targets and traffic shape look anything like ours, please steal our tiny benchmark kit. Run a one-day canary. See what the numbers tell you. The goal isn’t to declare one tool a winner, but to spend less time arguing with physics and more time building things that people love.

September 2, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

Why simplicity wins when you pick AWS ECS Fargate instead of EKS

Selecting the right tools often feels like navigating a crossroads. Consider planning a significant project, like building a custom home workshop. You could opt for a complex setup with specialized, industrial-grade machinery (powerful, flexible, demanding maintenance and expertise). Or, you might choose high-quality, standard power tools that handle 90% of your needs reliably and with far less fuss. Development teams deploying containers on AWS face a similar decision. The powerful, industry-standard Kubernetes via Elastic Kubernetes Service (EKS) beckons, but is it always the necessary path? Often, the streamlined native solution, Elastic Container Service (ECS) paired with its serverless Fargate launch type, offers a smarter, more efficient route.

AWS presents these two primary highways for container orchestration. EKS delivers managed Kubernetes, bringing its vast ecosystem and flexibility. It frequently dominates discussions and is hailed in the DevOps world. But then there’s ECS, AWS’s own mature and deeply integrated orchestrator. This article explores the compelling scenarios where choosing the apparent simplicity of ECS, particularly with Fargate, isn’t just easier; it’s strategically better.

Getting to know your AWS container tools

Before charting a course, let’s clarify what each service offers.

ECS (Elastic Container Service): Think of ECS as the well-designed, built-in toolkit that comes standard with your AWS environment. It’s AWS’s native container orchestrator, designed for seamless integration. ECS offers two ways to run your containers:

EC2 launch type: You manage the underlying EC2 virtual machine instances yourself. This gives you granular control over the instance type (perhaps you need specific GPUs or network configurations) but brings back the responsibility of patching, scaling, and managing those servers.
Fargate launch type: This is the serverless approach. You define your container needs, and Fargate runs them without you ever touching, or even seeing, the underlying server infrastructure.

Fargate: This is where serverless container execution truly shines. It’s like setting your high-end camera to an intelligent ‘auto’ mode. You focus on the shot (your application), and the camera (Fargate) expertly handles the complex interplay of aperture, shutter speed, and ISO (server provisioning, scaling, patching). You simply run containers.

EKS (Elastic Kubernetes Service): EKS is AWS’s managed offering for the Kubernetes platform. It’s akin to installing a professional-grade, multi-component software suite onto your operating system. It provides immense power, conforms to the Kubernetes standard loved by many, and grants access to its sprawling ecosystem of tools and extensions. However, even with AWS managing the control plane’s availability, you still need to understand and configure Kubernetes concepts, manage worker nodes (unless using Fargate with EKS, which adds its own considerations), and handle integrations.

The power of keeping things simple with ECS Fargate

So, what makes this simpler path with ECS Fargate so appealing? Several key advantages stand out.

Reduced operational overhead: This is often the most significant win. Consider the sheer liberation Fargate offers: it completely removes the burden of managing the underlying servers. Forget patching operating systems at 2 AM or figuring out complex scaling policies for your EC2 fleet. It’s the difference between owning a car, with all its maintenance chores, oil changes, tire rotations, and unexpected repairs, and using a seamless rental or subscription service where the vehicle is just there when you need it, ready to drive. You focus purely on the journey (your application), not the engine maintenance (the infrastructure).

Faster learning curve and easier management: ECS generally presents a gentler learning curve than the multifaceted world of Kubernetes. For teams already comfortable within the AWS ecosystem, ECS concepts feel intuitive and familiar. Managing task definitions, services, and clusters in ECS is often more straightforward than navigating Kubernetes deployments, services, pods, and the YAML complexities involved. This translates to faster onboarding and less time spent wrestling with the orchestrator itself. Furthermore, EKS carries an hourly cost for its control plane (though free tiers exist), an expense absent in the standard ECS setup.

Seamless AWS integration: ECS was born within AWS, and it shows. Its integration with other AWS services is typically tighter and simpler to configure than with EKS. Assigning IAM roles directly to ECS tasks for granular permissions, for instance, is remarkably straightforward compared to setting up Kubernetes Service Accounts and configuring IAM Roles for Service Accounts (IRSA) with an OIDC provider in EKS. Connecting to Application Load Balancers, registering targets, and pushing logs and metrics to CloudWatch often requires less configuration boilerplate with ECS/Fargate. It’s like your home’s electrical system being designed for standard plugs, appliances just work without needing special adapters or wiring.

True serverless container experience (Fargate): With Fargate, you pay for the vCPU and memory resources your containerized application requests, consumed only while it’s running. You aren’t paying for idle virtual machines waiting for work. This model is incredibly cost-effective for applications with variable loads, APIs that scale on demand, or batch jobs that run periodically.

Finding your route when ECS Fargate is the best fit

Knowing these advantages, let’s pinpoint the specific road signs indicating ECS/Fargate is the right direction for your team and application.

Teams prioritizing simplicity and velocity: If your primary goal is to ship features quickly and minimize the time spent on infrastructure management, ECS/Fargate is a strong contender. It allows developers to focus more on code and less on orchestration intricacies. It’s like choosing a reliable microwave and stove for everyday cooking; they get the job done efficiently without the complexity of a commercial kitchen setup.

Standard microservices or web applications: Many common workloads, like stateless web applications, APIs, or backend microservices, don’t require the advanced orchestration features or the specific tooling found only in the Kubernetes ecosystem. For these, ECS/Fargate provides robust, scalable, and reliable hosting without unnecessary complexity.

Deep reliance on the AWS ecosystem: If your application heavily leverages other AWS services (like DynamoDB, SQS, Lambda, RDS) and multi-cloud portability isn’t an immediate strategic requirement, ECS/Fargate’s native integration offers tangible benefits in ease of use and configuration.

Serverless-First architectures: For teams embracing a serverless mindset for event-driven processing, data pipelines, or API backends, Fargate fits perfectly. Its pay-per-use model and elimination of server management align directly with serverless principles.

Operational cost sensitivity: When evaluating the total cost of ownership, factor in the human effort. The reduced operational burden of ECS/Fargate can lead to significant savings in staff time and effort, potentially outweighing any differences in direct compute costs or the EKS control plane fee.

Acknowledging the alternative when EKS remains the champion

Of course, EKS exists for good reasons, and it remains the superior choice in certain contexts. Let’s be clear about when you need that powerful, customizable machinery.

Need for Kubernetes Standard/API: If your team requires the full Kubernetes API, needs specific Custom Resource Definitions (CRDs), operators, or advanced scheduling capabilities inherent to Kubernetes, EKS is the way to go.

Leveraging the vast Kubernetes ecosystem: Planning to use popular Kubernetes-native tools like Helm for packaging, Argo CD for GitOps, Istio or Linkerd for a service mesh, or specific monitoring agents designed for Kubernetes? EKS provides the standard platform these tools expect.

Existing Kubernetes expertise or workloads: If your team is already proficient in Kubernetes or you’re migrating existing Kubernetes applications to AWS, sticking with EKS leverages that investment and knowledge, ensuring consistency.

Hybrid or Multi-Cloud strategy: When running workloads across different cloud providers or in hybrid on-premises/cloud environments, Kubernetes (and thus EKS on AWS) provides a consistent orchestration layer, crucial for portability and operational uniformity.

Highly complex orchestration needs: For applications demanding intricate network policies (e.g., using Calico), complex stateful set management, or very specific affinity/anti-affinity rules that might be more mature or flexible in Kubernetes, EKS offers greater depth.

Think of EKS as that specialized, heavy-duty truck. It’s indispensable when you need to haul unique, heavy loads (complex apps), attach specialized equipment (ecosystem tools), modify the engine extensively (custom controllers), or drive consistently across varied terrains (multi-cloud).

Choosing your lane ECS Fargate or EKS

The key insight here isn’t about crowning one service as universally “better.” It’s about recognizing that the AWS container landscape offers different tools meticulously designed for different journeys. ECS with Fargate stands as a powerful, mature, and often much simpler alternative, decisively challenging the notion that Kubernetes via EKS should be the default starting point for every containerized application on AWS.

Before committing, honestly assess your application’s real complexity, your team’s operational capacity, and existing expertise, your reliance on the broader AWS vs. Kubernetes ecosystems, and your strategic goals regarding portability. It’s like packing for a trip: you wouldn’t haul mountaineering equipment for a relaxing beach holiday. Choose the toolset that minimizes friction, maximizes your team’s velocity, and keeps your journey smooth. Choose wisely.

April 28, 2025 by Fernando SRE Cloud stuff DevOps stuff Kubernetes SRE stuff

The easy way to persistent storage in ECS Fargate

Running containers in ECS Fargate is great until you need persistent storage. At first, it seems straightforward: mount an EFS volume, and you’re done. But then you hit a roadblock. The container fails to start because the expected directory in EFS doesn’t exist.

What do you do? You could manually create the directory from an EC2 instance, but that’s not scalable. You could try scripting something, but now you’re adding complexity. That’s where I found myself, going down the wrong path before realizing that AWS already had a built-in solution that simplified everything. Let’s walk through what I learned.

The problem with persistent storage in ECS Fargate

When you define a task in ECS Fargate, you specify a TaskDefinition. This includes your container settings, environment variables, and any volumes you want to mount. The idea is simple: attach an EFS volume and mount it inside the container.

But there’s a catch. The task won’t start if the mount path inside EFS doesn’t already exist. So if your container expects to write to /data, and you set it up to map to /my-task/data on EFS, you’ll get an error if /my-task/data hasn’t been created yet.

At first, I thought, Fine, I’ll just SSH into an EC2 instance, mount the EFS drive, and create the folder manually. That worked. But then I realized something: what happens when I need to deploy multiple environments dynamically? Manually creating directories every time was not an option.

A Lambda function as a workaround

My next idea was to automate the directory creation using a Lambda function. Here’s how it worked:

The Lambda function mounts the root of the EFS volume.
It creates the required directory (/my-task/data).
The ECS task waits for the directory to exist before starting.

To integrate this, I created a custom resource in AWS CloudFormation that triggered the Lambda function whenever I deployed the stack. The function ran, created the directory, and ensured everything was in place before the container started.

It worked. The container launched successfully, and I automated the setup. But something still felt off. I had just introduced an entirely new AWS service, Lambda, to solve what seemed like a simple storage issue. More moving parts mean more maintenance, more security considerations, and more things that can break.

The simpler solution with EFS Access Points

While working on the Lambda function, I stumbled upon EFS Access Points. I needed one to allow Lambda to mount EFS, but then I realized something, ECS Fargate supports EFS Access Points too.

Here’s why that’s important. Access Points in EFS let you:
✔ Automatically create a directory when it’s first used.
✔ Restrict access to specific paths and users.
✔ Set permissions so the container only sees the directory it needs.

Instead of manually creating directories or relying on Lambda, I set up an Access Point for /my-task/data and configured my ECS TaskDefinition to use it. That’s it, no extra code, no custom logic, just a built-in feature that solved the problem cleanly.

The key takeaway

My first instinct was to write more code. A Lambda function, a CloudFormation resource, and extra logic, all to create a folder. But the right answer was much simpler: use the tools AWS already provides.

The lesson? When working with cloud infrastructure, resist the urge to overcomplicate things. The easiest solution is often the best one. If you ever find yourself scripting something that feels like it should be built-in, take a step back because it probably is.

February 19, 2025 by Fernando SRE Cloud stuff DevOps stuff

Container deployment in AWS with ECS, EKS, and Fargate

How do the apps you use daily get built, shipped, and scaled so smoothly? A lot of it has to do with the magic of containers. Think of containers like neat little LEGO blocks, self-contained, portable, and ready to snap together to build something awesome. In the tech world, these blocks hold all the essential bits and pieces of an application, making it super easy to move them around and run them anywhere.

Imagine you’ve got a bunch of these LEGO blocks, each representing a different part of your app. You’ll need a good way to organize them, right? That’s where container orchestration comes in. It’s like having a master builder who knows how to put those blocks together, make sure they’re all playing nicely, and even create more blocks when things get busy.

And guess what? AWS, the cloud superhero, has a whole toolkit to help you with this container adventure.

AWS container services toolkit

AWS offers a variety of services that work together like a well-oiled machine to help you build, deploy, and manage your containerized applications.

Amazon Elastic Container Registry (ECR) – Your container garage

Think of ECR as your very own garage for storing container images. It’s a fully managed service that allows you to store, share, and deploy your container images securely. ECR is like a safe and organized space where you keep all your valuable LEGO creations. You can easily control who has access to your images, making sure only the right people can use them. Plus, it integrates seamlessly with other AWS services, making it a breeze to include in your workflows.

Amazon Elastic Container Service (ECS) – Your container playground

Once you’ve got your container images stored safely in ECR, what’s next? Meet ECS, your container playground! ECS is a highly scalable and high-performance container orchestration service that allows you to run and manage your containers on a cluster of Amazon EC2 instances. It’s like having a dedicated play area where you can arrange your LEGO blocks, build amazing structures, and even add or remove blocks as needed. ECS takes care of all the heavy lifting, so you can focus on what matters most, building awesome applications.

Amazon Elastic Kubernetes Service (EKS) – Your Kubernetes command center

For those of you who prefer the Kubernetes way of doing things, AWS has you covered with EKS. It’s a managed Kubernetes service that makes it easy to run Kubernetes on AWS without having to worry about managing the underlying infrastructure. Kubernetes is like a super-sophisticated set of instructions for building complex LEGO structures. EKS takes care of all the complexities of managing Kubernetes so that you can focus on building and deploying your applications.

EC2 vs. Fargate – Choosing your foundation

Now, let’s talk about the foundation of your container playground. You have two main options: EC2 and Fargate.

EC2-based container deployment – The DIY approach

With EC2, you get full control over the underlying infrastructure. It’s like building your own LEGO table from scratch. You choose the size, shape, and color of the table, and you’re responsible for keeping it clean and tidy. This gives you a lot of flexibility, but it also means you have more responsibilities.

AWS Fargate – The hassle-free option

Fargate, on the other hand, is like having a magical LEGO table that appears whenever you need it. You don’t have to worry about building or maintaining the table; you just focus on playing with your LEGOs. Fargate is a serverless compute engine for containers, meaning you don’t have to manage any servers. It’s a great option if you want to simplify your operations and reduce your overhead.

Making the right choice

So, which option is right for you? Well, it depends on your specific needs and preferences. If you need full control over your infrastructure and want to optimize costs by managing your own servers, EC2 might be a good choice. But if you prefer a serverless approach and want to avoid the hassle of managing servers, Fargate is the way to go.

AWS Container Services Compared

To make things easier, here’s a quick comparison of ECS, EKS, and Fargate:

Service	Description	Use Case
ECS	Managed container orchestration for EC2 instances	Great for full control over infrastructure
EKS	Managed Kubernetes service	Ideal for teams with Kubernetes expertise
Fargate	Serverless compute engine for ECS or EKS	Simplifies operations, no infrastructure management

Best practices and security for building a secure and reliable playground

Just like any playground, your container environment needs to be safe and secure. AWS provides a range of tools and best practices to help you build a reliable and secure container playground.

Security best practices for keeping your LEGOs safe

AWS offers a variety of security features to help you protect your container environment. You can use IAM to control access to your resources, implement network security measures (like Security Groups and NACLs) to protect your containers from unauthorized access, and scan your container images for vulnerabilities with tools like Amazon Inspector.

High availability for ensuring your playground is always open

To ensure your applications are always available, you can use AWS’s high-availability features. This includes deploying your containers across multiple availability zones, configuring load balancing to distribute traffic across your containers, and implementing disaster recovery measures to protect your applications from unexpected events.

Monitoring and troubleshooting for keeping an eye on your playground

AWS provides comprehensive monitoring and troubleshooting tools to help you keep your container environment running smoothly. You can use CloudWatch to monitor your containers’ performance, set up detailed alarms to catch issues before they escalate, and use CloudWatch Logs to dive deep into the activity of your applications. Additionally, AWS X-Ray helps you trace requests as they travel through your application, giving you a granular view of where bottlenecks or failures may occur. These tools together allow for proactive monitoring, quick detection of anomalies, and effective root-cause analysis, ensuring that your container environment is always optimized and functioning properly.

DevOps integration for automating your LEGO creations

AWS container services integrate seamlessly with your DevOps workflows, allowing you to automate deployments, ensure consistent environments, and streamline the entire development lifecycle. By integrating services like CodeBuild, CodeDeploy, and CodePipeline, AWS enables you to create end-to-end CI/CD pipelines that automate testing, building, and releasing your containerized applications. This integration helps teams release features faster, reduce errors due to manual processes, and maintain a high level of consistency across different environments.

CI/CD pipeline integration for building and deploying automatically

You can use AWS CodePipeline to create a continuous integration and continuous delivery (CI/CD) pipeline that automatically builds, tests, and deploys your containerized applications. This allows you to release new features and updates quickly and efficiently. Imagine using CodePipeline as an automated assembly line for your LEGO creations.

Cost optimization for saving money on your LEGOs

AWS offers a variety of cost optimization tools to help you save money on your container deployments. You can use ECR lifecycle policies to manage your container images efficiently, choose the right instance types for your workloads, and leverage AWS’s pricing models to optimize your costs. Additionally, AWS provides Savings Plans and Spot Instances, which allow you to significantly reduce costs when running containerized workloads with flexible scheduling. Utilizing the AWS Compute Optimizer can also help identify opportunities to downsize or modify your infrastructure to be more cost-effective, ensuring you’re always operating in a lean and optimized manner.

Real-world implementation for bringing your LEGO creations to life

Deploying containerized applications in a production environment requires careful planning and execution. This involves assessing your infrastructure, understanding resource requirements, and preparing for potential scaling needs. AWS provides a range of tools and best practices, such as infrastructure templates, automated deployment scripts, and monitoring solutions, to help ensure that your applications are deployed successfully. Additionally, AWS recommends using blue-green deployments to minimize downtime and risk, as well as leveraging autoscaling to maintain performance under varying loads.

Production deployment checklist for your Pre-flight check

Before deploying your applications, it’s important to consider a few key factors, such as your application’s requirements, your infrastructure needs, and your security and compliance requirements. AWS provides a comprehensive checklist to help you ensure your applications are ready for production.

Common challenges and solutions for troubleshooting your LEGO creations

Deploying and managing containerized applications can present some challenges, such as dealing with scaling complexities, managing network configurations, or troubleshooting performance bottlenecks. However, AWS provides a wealth of resources and support to help you overcome these challenges. You can find solutions to common problems, troubleshooting tips, and best practices in the AWS documentation, community forums, and even through AWS Support Plans, which offer access to technical experts. Additionally, tools like AWS Trusted Advisor can help identify potential issues before they impact your applications, while AWS Well-Architected Framework guides optimizing your container deployments for reliability, performance, and cost-efficiency.

Choosing the right tools for the job

AWS offers a comprehensive suite of container services to help you build, deploy, and manage your applications. By understanding the different services and their capabilities, you can choose the right tools for your specific needs and build a secure, reliable, and cost-effective container environment.

The key is to choose the right tools for the job and follow best practices to ensure your applications are secure, reliable, and scalable.

November 19, 2024 by Fernando SRE Cloud stuff Kubernetes

Scaling for Success. Cost-Effective Cloud Architectures on AWS

One of the most exciting aspects of cloud computing is the promise of scalability, the ability to expand or contract resources to meet demand. But how do you design an architecture that can handle unexpected traffic spikes without breaking the bank during quieter periods? This question often comes up in AWS Solution Architect interviews, and for good reason. It’s a core challenge that many businesses face when moving to the cloud. Let’s explore some AWS services and strategies that can help you achieve both scalability and cost efficiency.

Building a Dynamic and Cost-Aware AWS Architecture

Imagine your application is like a bustling restaurant. During peak hours, you need a full staff and all tables ready. But during off-peak times, you don’t want to be paying for idle resources. Here’s how we can translate this concept into a scalable AWS architecture:

Auto Scaling Groups (ASGs): Think of ASGs as your restaurant’s staffing manager. They automatically adjust the number of EC2 instances (your servers) based on predefined rules. If your website traffic suddenly spikes, ASGs will spin up additional instances to handle the load. When traffic dies down, they’ll scale back, saving you money. You can even combine ASGs with Spot Instances for even greater cost savings.
Amazon EC2 Spot Instances: These are like the temporary staff you might hire during a particularly busy event. Spot Instances let you take advantage of unused EC2 capacity at a much lower cost. If your demand is unpredictable, Spot Instances can be a great way to save money while ensuring you have enough resources to handle peak loads.
Amazon Lambda: Lambda is your kitchen staff that only gets paid when they’re cooking, and they’re really good at their job, they can whip up a dish in under 15 minutes! It’s a serverless compute service that runs your code in response to events (like a new file being uploaded or a database change). You only pay for the compute time you actually use, making it ideal for sporadic or unpredictable workloads.
AWS Fargate: Fargate is like having a catering service handle your entire kitchen operation. It’s a serverless compute engine for containers, meaning you don’t have to worry about managing the underlying servers. Fargate automatically scales your containerized applications based on demand, and you only pay for the resources your containers consume.

How the Pieces Fit Together

Now, let’s see how these services can work together in harmony:

Core Application on EC2 with Auto Scaling: Your main application might run on EC2 instances within an Auto Scaling Group. You can configure this group to monitor the CPU utilization of your servers and automatically launch new instances if the average CPU usage reaches a threshold, such as 75% (this is known as a Target Tracking Scaling Policy). This ensures you always have enough servers running to handle the current load, even during unexpected traffic spikes.
Spot Instances for Cost Optimization: To save costs, you could configure your Auto Scaling Group to use Spot Instances whenever possible. This allows you to take advantage of lower prices while still scaling up when needed. Importantly, you’ll also want to set up a recovery policy within your Auto Scaling Group. This policy ensures that if Spot Instances are not available (due to high demand or price fluctuations), your Auto Scaling Group will automatically launch On-Demand Instances instead. This way, you can reliably meet your application’s resource needs even when Spot Instances are unavailable.
Lambda for Event-Driven Tasks: Lambda functions excel at handling event-driven tasks that don’t require a constantly running server. For example, when a new image is uploaded to your S3 bucket, you can trigger a Lambda function to automatically resize it or convert it to a different format. Similarly, Lambda can be used to send notifications to users when certain events occur in your application, such as a new order being placed or a payment being processed. Since Lambda functions are only active when triggered, they can significantly reduce your costs compared to running dedicated EC2 instances for these tasks.
Fargate for Containerized Microservices: If your application is built using microservices, you can run them in containers on Fargate. This eliminates the need to manage servers and allows you to scale each microservice independently. By decoupling your microservices and using Amazon Simple Queue Service (SQS) queues for communication, you can ensure that even under heavy load, all requests will be handled and none will be lost. For applications where the order of operations is critical, such as financial transactions or order processing, you can use FIFO (First-In-First-Out) SQS queues to maintain the exact order of messages.

Monitoring and Optimization: Imagine having a restaurant manager who constantly monitors how busy the restaurant is, how much food is being wasted, and how satisfied the customers are. This is what Amazon CloudWatch does for your AWS environment. It provides detailed metrics and alarms, allowing you to fine-tune your scaling policies and optimize your resource usage. With CloudWatch, you can visualize the health and performance of your entire AWS infrastructure at a glance through intuitive dashboards and graphs. These visualizations make it easy to identify trends, spot potential issues, and make informed decisions about resource allocation and optimization.

The Outcome, A Satisfied Customer and a Healthy Bottom Line

By combining these AWS services and strategies, you can build a cloud architecture that is both scalable and cost-effective. This means your application can gracefully handle unexpected traffic spikes, ensuring a smooth user experience even during peak demand. At the same time, you won’t be paying for idle resources during quieter periods, keeping your cloud costs under control.

Final Analysis

Designing for scalability and cost efficiency is a fundamental aspect of cloud architecture. By leveraging AWS services like Auto Scaling, EC2 Spot Instances, Lambda, and Fargate, you can create a dynamic and responsive environment that adapts to your application’s needs. Remember, the key is to understand your workload patterns and choose the right tools for the job. With careful planning and the right AWS services, you can build a cloud architecture that is both powerful and cost-effective, setting your business up for success in the cloud and in the restaurant. 😉

July 24, 2024 by Fernando SRE Cloud stuff

Exploring Containerization on AWS: Insights into ECS, EKS, Fargate, and ECR

Imagine exploring a vast universe, not of stars and galaxies, but of containers and cloud services. In AWS, this universe is populated by stellar services like ECS, EKS, Fargate, and ECR. Each, with its unique characteristics, serves different purposes, like stars in the constellation of cloud computing.

ECS: The Versatile Heart of AWS, ECS is like an experienced team of astronauts, managing entire fleets of containers efficiently. Picture a global logistics company using ECS to coordinate real-time shipping operations. Each container is a digital package, precisely transported to its destination. The scalability and security of ECS ensure that, even on the busiest days, like Black Friday, everything flows smoothly.

EKS: Kubernetes Orchestration in AWS, Think of EKS as a galactic explorer, harnessing the power of Kubernetes within the AWS cosmos. A university hospital uses EKS to manage electronic medical records. Like an advanced navigation system, EKS directs information through complex routes, maintaining the integrity and security of critical data, even as it expands into new territories of research and treatment.

Fargate: Containers without Server Chains, Fargate is like the anti-gravity of container services: it removes the weight of managing servers. Imagine a TV network using Fargate to broadcast live events. Like a spaceship that automatically adjusts to space conditions, Fargate scales resources to handle millions of viewers without the network having to worry about technical details.

ECR: The Image Warehouse in AWS Space, Finally, ECR can be seen as a digital archive in space, where container images are securely stored. A gaming startup stores versions of its software in ECR, ready to be deployed at any time. Like a well-organized archive, ECR allows this company to quickly retrieve what it needs, ensuring the latest games hit the market faster.

The Elegant Transition: From Complex Orchestration to Streamlined Efficiency

ECS: When Precision and Control Matter, Use ECS when you need fine-grained control over your container orchestration. It’s like choosing a manual transmission over automatic; you get to decide exactly how your containers run, network, and scale. It’s perfect for customized workflows and specific performance needs, much like a tailor-made suit.

EKS: For the Kubernetes Enthusiasts, Opt for EKS when you’re already invested in Kubernetes or when you need its specific features and community-driven plugins. It’s like using a Swiss Army knife; it offers flexibility and a range of tools, ideal for complex applications that require Kubernetes’ extensibility.

Fargate: Simplicity and Efficiency First, Choose Fargate when you want to focus on your application rather than infrastructure. It’s akin to flying autopilot; you define your destination (application), and Fargate handles the journey (server and cluster management). It’s best for straightforward applications where efficiency and ease of use are paramount.

ECR: Enhanced Container Registry for Docker and OCI Images

Leverage ECR for a secure, scalable environment to store and manage not just your Docker images but also OCI (Open Container Initiative) images. Envision ECR as a high-security vault that caters to the most utilized image format in the industry while also embracing the versatility of OCI standards. This dual compatibility ensures seamless integration with ECS and EKS and positions ECR as a comprehensive solution for modern container image management—crucial for organizations committed to security and forward compatibility.

Synthesizing Our Cosmic AWS Voyage

In this expedition through AWS’s container services, we’ve not only explored the distinct capabilities of ECS, EKS, Fargate, and ECR but also illuminated the scenarios where each shines brightest. Like celestial guides in the vast expanse of cloud computing, these services offer tailored paths to stellar solutions.

Choosing between them is less about picking the ‘best’ and more about aligning with your specific mission needs. Whether it’s the tailored precision of ECS, the expansive toolkit of EKS, the streamlined simplicity of Fargate, or the secure repository of ECR, each service is a specialized instrument in our technological odyssey.

Remember, understanding these services is not just about comprehending their technicalities but about appreciating their place in the grand scheme of cloud innovation. They are not just tools; they are the building blocks of modern digital architectures, each playing a pivotal role in scripting the future of technology.

December 9, 2023 by Fernando SRE Cloud stuff DevOps stuff Kubernetes