CloudArchitecture

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.

The great AWS Tag standoff

You tried to launch an EC2 instance. Simple task. Routine, even.

Instead, AWS handed you an AccessDenied error like a parking ticket you didn’t know you’d earned.

Nobody touched the IAM policy. At least, not that you can prove.

Yet here you are, staring at a red banner while your coffee goes cold and your standup meeting starts without you.

Turns out, AWS doesn’t just care what you do; it cares what you call it.

Welcome to the quiet civil war between two IAM condition keys that look alike, sound alike, and yet refuse to share the same room: ResourceTag and RequestTag.

The day my EC2 instance got grounded

It happened on a Tuesday. Not because Tuesdays are cursed, but because Tuesdays are when everyone tries to get ahead before the week collapses into chaos.

A developer on your team ran `aws ec2 run-instances` with all the right parameters and a hopeful heart. The response? A polite but firm refusal.

The policy hadn’t changed. The role hadn’t changed. The only thing that had changed was the expectation that tagging was optional.

In AWS, tags aren’t just metadata. They’re gatekeepers. And if your request doesn’t speak their language, the door stays shut.

Meet the two Tag twins nobody told you about

Think of aws:ResourceTag as the librarian who won’t let you check out a book unless it’s already labeled “Fiction” in neat, archival ink. It evaluates tags on existing resources. You’re not creating anything, you’re interacting with something that’s already there. Want to stop an EC2 instance? Fine, but only if it carries the tag `Environment = Production`. No tag? No dice.

Now meet aws:RequestTag, the nightclub bouncer who won’t let you in unless you show up wearing a wristband that says “VIP,” and you brought the wristband yourself. This condition checks the tags you’re trying to apply when you create a new resource. It’s not about what exists. It’s about what you promise to bring into the world.

One looks backward. The other looks forward. Confuse them, and your policy becomes a riddle with no answer.

Why your policy is lying to you

Here’s the uncomfortable truth: not all AWS services play nice with these conditions.

Lambda? Mostly shrugs. S3? Cooperates, but only if you ask nicely (and include `s3:PutBucketTagging`). EC2? Oh, EC2 loves a good trap.

When you run `ec2:RunInstances`, you’re not just creating an instance. You’re also (silently) creating volumes, network interfaces, and possibly a public IP. Each of those needs tagging permissions. And if your policy only allows `ec2:RunInstances` but forgets `ec2:CreateTags`? AccessDenied. Again.

And don’t assume the AWS Console saves you. Clicking “Add tags” in the UI doesn’t magically bypass IAM. If your role lacks the right conditions, those tags vanish into the void before the resource is born.

CloudTrail won’t judge you, but it will show you exactly which tags your request claimed to send. Sometimes, the truth hurts less than the guesswork.

Building a Tag policy that doesn’t backfire

Let’s build something that works in 2025, not 2018.
Start with a simple rule: all new S3 buckets must carry `CostCenter` and `Owner`. Your policy might look like this:

{
  "Effect": "Allow",
  "Action": ["s3:CreateBucket", "s3:PutBucketTagging"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:RequestTag/CostCenter": ["Marketing", "Engineering", "Finance"],
      "aws:RequestTag/Owner": ["*"]
    },
    "Null": {
      "aws:RequestTag/CostCenter": "false",
      "aws:RequestTag/Owner": "false"
    }
  }
}

Notice the `Null` condition. It’s the unsung hero that blocks requests missing the required tags entirely.

For extra credit, layer this with AWS Organizations Service Control Policies (SCPs) to enforce tagging at the account level, and pair it with AWS Tag Policies (via Resource Groups) to standardize tag keys and values across your estate. Defense in depth isn’t paranoia, it’s peace of mind.

Testing your policy without breaking production

The IAM Policy Simulator is helpful, sure. But it won’t catch the subtle dance between `RunInstances` and `CreateTags`.

Better approach: spin up a sandbox account. Write a Terraform module or a Python script that tries to create resources with and without tags. Watch what succeeds, what fails, and, most importantly, why.

Automate these tests. Run them in CI. Treat IAM policies like code, because they are.

Remember: in IAM, hope is not a strategy, but a good test plan is.

The human side of tagging

Tags aren’t for machines. Machines don’t care.

Tags are for the human who inherits your account at 2 a.m. during an outage. For the finance team trying to allocate cloud spend. For the auditor who needs to prove compliance without summoning a séance.

A well-designed tagging policy isn’t about control. It’s about kindness, to your future self, your teammates, and the poor soul who has to clean up after you.

So next time you write a condition with `ResourceTag` or `RequestTag`, ask yourself: am I building a fence or a welcome mat?

Because in the cloud, even silence speaks, if you’re listening to the tags.

October 22, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

Why your AWS bill secretly hates Graviton

The party always ends when the bill arrives.

Your team ships a brilliant release. The dashboards glow a satisfying, healthy green. The celebratory GIFs echo through the Slack channels. For a few glorious days, you are a master of the universe, a conductor of digital symphonies.

And then it shows up. The AWS invoice doesn’t knock. It just appears in your inbox with the silent, judgmental stare of a Victorian governess who caught you eating dessert before dinner. You shipped performance, yes. You also shipped a small fleet of x86 instances that are now burning actual, tangible money while you sleep.

Engineers live in a constant tug-of-war between making things faster and making them cheaper. We’re told the solution is another coupon code or just turning off a few replicas over the weekend. But real, lasting savings don’t come from tinkering at the edges. They show up when you change the underlying math. In the world of AWS, that often means changing the very silicon running the show.

Enter a family of servers that look unassuming on the console but quietly punch far above their weight. Migrate the right workloads, and they do the same work for less money. Welcome to AWS Graviton.

What is this Graviton thing anyway?

Let’s be honest. The first time someone says “ARM-based processor,” your brain conjures images of your phone, or maybe a high-end Raspberry Pi. The immediate, skeptical thought is, “Are we really going to run our production fleet on that?”

Well, yes. And it turns out that when you own the entire datacenter, you can design a chip that’s ridiculously good at cloud workloads, without the decades of baggage x86 has been carrying around. Switching to Graviton is like swapping that gas-guzzling ’70s muscle car for a sleek, silent electric skateboard that somehow still manages to tow your boat. It feels wrong… until you see your fuel bill. You’re swapping raw, hot, expensive grunt for cool, cheap efficiency.

Amazon designed these chips to optimize the whole stack, from the physical hardware to the hypervisor to the services you click on. This control means better performance-per-watt and, more importantly, a better price for every bit of work you do.

The lineup is simple:

Graviton2: The reliable workhorse. Great for general-purpose and memory-hungry tasks.
Graviton3: The souped-up model. Faster cores, better at cryptography, and sips memory bandwidth through a wider straw.
Graviton3E: The specialist. Tuned for high-performance computing (HPC) and anything that loves vector math.

This isn’t some lab experiment. Graviton is already powering massive production fleets. If your stack includes common tools like NGINX, Redis, Java, Go, Node.js, Python, or containers on ECS or EKS, you’re already walking on paved roads.

The real numbers behind the hype

The headline from AWS is tantalizing. “Up to 40 percent better price-performance.” “Up to,” of course, are marketing’s two favorite words. It’s the engineering equivalent of a dating profile saying they enjoy “adventures.” It could mean anything.

But even with a healthy dose of cynicism, the trend is hard to ignore. Your mileage will vary depending on your code and where your bottlenecks are, but the gains are real.

Here’s where teams often find the gold:

Web and API services: Handling the same requests per second at a lower instance cost.
CI/CD Pipelines: Faster compile times for languages like Go and Rust on cheaper build runners.
Data and Streaming: Popular engines like NGINX, Envoy, Redis, Memcached, and Kafka clients run beautifully on ARM.
Batch and HPC: Heavy computational jobs get a serious boost from the Graviton3E chips.

There’s also a footprint bonus. Better performance-per-watt means you can hit your ESG (Environmental, Social, and Governance) goals without ever having to create a single sustainability slide deck. A win for engineering, a win for the planet, and a win for dodging boring meetings.

But will my stuff actually run on it?

This is the moment every engineer flinches. The suggestion of “recompiling for ARM” triggers flashbacks to obscure linker errors and a trip down dependency hell.

The good news? The water’s fine. For most modern workloads, the transition is surprisingly anticlimactic. Here’s a quick compatibility scan:

You compile from source or use open-source software? Very likely portable.
Using closed-source agents or vendor libraries? Time to do some testing and maybe send a polite-but-firm support ticket.
Running containers? Fantastic. Multi-architecture images are your new best friend.
What about languages? Java, Go, Node.js, .NET 6+, Python, Ruby, and PHP are all happy on ARM on Linux.
C and C++? Just recompile and link against ARM64 libraries.

The easiest first wins are usually stateless services sitting behind a load balancer, sidecars like log forwarders, or any kind of queue worker where raw throughput is king.

A calm path to migration

Heroic, caffeine-fueled weekend migrations are for rookies. A calm, boring checklist is how professionals do it.

Phase 1: Test in a safe place

Launch a Graviton sibling of your current instance family (e.g., a c7g.large instead of a c6i.large). Replay production traffic to it or run your standard benchmarks. Compare CPU utilization, latency, and error rates. No surprises allowed.

Phase 2: Build for both worlds

It’s time to create multi-arch container images. docker buildx is the tool for the job. This command builds an image for both chip architectures and pushes them to your registry under a single tag.

# Build and push an image for both amd64 and arm64 from one command
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag $YOUR_ACCOUNT.dkr.ecr.$[REGION.amazonaws.com/my-web-app:v1.2.3](https://REGION.amazonaws.com/my-web-app:v1.2.3) \
  --push .

Phase 3: Canary and verify

Slowly introduce the new instances. Route just 5% of traffic to the Graviton pool using weighted target groups. Stare intently at your dashboards. Your “golden signals”, latency, traffic, errors, and saturation, should look identical across both pools.

Here’s a conceptual Terraform snippet of what that weighting looks like:

resource "aws_lb_target_group" "x86_pool" {
  name     = "my-app-x86-pool"
  # ... other config
}

resource "aws_lb_target_group" "arm_pool" {
  name     = "my-app-arm-pool"
  # ... other config
}

resource "aws_lb_listener_rule" "weighted_routing" {
  listener_arn = aws_lb_listener.frontend.arn
  priority     = 100

  action {
    type = "forward"

    forward {
      target_group {
        arn    = aws_lb_target_group.x86_pool.arn
        weight = 95
      }
      target_group {
        arn    = aws_lb_target_group.arm_pool.arn
        weight = 5
      }
    }
  }

  condition {
    path_pattern {
      values = ["/*"]
    }
  }
}

Phase 4: Full rollout with a parachute

If the canary looks healthy, gradually increase traffic: 25%, 50%, then 100%. Keep the old x86 pool warm for a day or two, just in case. It’s your escape hatch. Once it’s done, go show the finance team the new, smaller bill. They love that.

Common gotchas and easy fixes

Here are a few fun ways to ruin your Friday afternoon, and how to avoid them.

The sneaky base image: You built your beautiful ARM application… on an x86 foundation. Your FROM amazonlinux:2023 defaulted to the amd64 architecture. Your container dies instantly. The fix: Explicitly pin your base images to an ARM64 version, like FROM –platform=linux/arm64 public.ecr.aws/amazonlinux/amazonlinux:2023.
The native extension puzzle: Your Python, Ruby, or Node.js app fails because a native dependency couldn’t be built. The fix: Ensure you’re building on an ARM machine or using pre-compiled manylinux wheels that support aarch64.
The lagging agent: Your favorite observability tool’s agent doesn’t have an official ARM64 build yet. The fix: Check if they have a containerized version or gently nudge their support team. Most major vendors are on board now.

A shift in mindset

For decades, we’ve treated the processor as a given, an unchangeable law of physics in our digital world. The x86 architecture was simply the landscape on which we built everything. Graviton isn’t just a new hill on that landscape; it’s a sign the tectonic plates are shifting beneath our feet. This is more than a cost-saving trick; it’s an invitation to question the expensive assumptions we’ve been living with for years.

You don’t need a degree in electrical engineering to benefit from this, though it might help you win arguments on Hacker News. All you really need is a healthy dose of professional curiosity and a good benchmark script.

So here’s the experiment. Pick one of your workhorse stateless services, the ones that do the boring, repetitive work without complaining. The digital equivalent of a dishwasher. Build a multi-arch image for it. Cordon off a tiny, five-percent slice of your traffic and send it to a Graviton pool. Then, watch. Treat your service like a lab specimen. Don’t just glance at the CPU percentage; analyze the cost-per-million-requests. Scrutinize the p99 latency.

If the numbers tell a happy story, you haven’t just tweaked a deployment. You’ve fundamentally changed the economics of that service. You’ve found a powerful new lever to pull. If they don’t, you’ve lost a few hours and gained something more valuable: hard data. You’ve replaced a vague “what if” with a definitive “we tried that.”

Either way, you’ve sent a clear message to that smug monthly invoice. You’re paying attention. And you’re getting smarter. Doing the same work for less money isn’t a stunt. It’s just good engineering.

October 19, 2025 by Fernando SRE Cloud stuff Computer Science stuff DevOps stuff SRE stuff

Why your Kubernetes pods and EBS volumes refuse to reconnect

You’re about to head out for lunch. One last, satisfying glance at the monitoring dashboard, all systems green. Perfect. You return an hour later, coffee in hand, to a cascade of alerts. Your application is down. At the heart of the chaos is a single, cryptic message from Kubernetes, and it’s in a mood.

Warning: 1 node(s) had volume node affinity conflict.

You stare at the message. “Volume node affinity conflict” sounds less like a server error and more like something a therapist would say about a couple that can’t agree on which city to live in. You grab your laptop. One of your critical application pods has been evicted from its node and now sits stubbornly in a Pending state, refusing to start anywhere else.

Welcome to the quiet, simmering nightmare of running stateful applications on a multi-availability zone Kubernetes cluster. Your pods and your storage are having a domestic dispute, and you’re the unlucky counselor who has to fix it before the morning stand-up.

Meet the unhappy couple

To understand why your infrastructure is suddenly giving you the silent treatment, you need to understand the two personalities at the heart of this conflict.

First, we have the Pod. Think of your Pod as a freewheeling digital nomad. It’s lightweight, agile, and loves to travel. If its current home (a Node) gets too crowded or suddenly vanishes in a puff of cloud provider maintenance, the Kubernetes scheduler happily finds it a new place to live on another node. The Pod packs its bags in a microsecond and moves on, no questions asked. It believes in flexibility and a minimalist lifestyle.

Then, there’s the EBS volume. If the Pod is a nomad, the Amazon EBS Volume is a resolute homebody. It’s a hefty, 20GB chunk of your application’s precious data. It’s incredibly reliable and fast, but it has one non-negotiable trait: it is physically, metaphorically, and spiritually attached to one single place. That place is an AWS Availability Zone (AZ), which is just a fancy term for a specific data center. An EBS volume created in us-west-2a lives in us-west-2a, and it would rather be deleted than move to us-west-2b. It finds the very idea of travel vulgar.

You can already see the potential for drama. The free-spirited Pod gets evicted and is ready to move to a lovely new node in us-west-2b. But its data, its entire life story, is sitting back in us-west-2a, refusing to budge. The Pod can’t function without its data, so it just sits there, Pending, forever waiting for a reunion that will never happen.

The brute force solution that creates new problems

When faced with this standoff, our first instinct is often to play the role of a strict parent. “You two will stay together, and that’s final!” In Kubernetes, this is called the nodeSelector.

You can edit your Deployment and tell the Pod, in no uncertain terms, that it is only allowed to live in the same neighborhood as its precious volume.

# deployment-with-nodeslector.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateful-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-stateful-app
  template:
    metadata:
      labels:
        app: my-stateful-app
    spec:
      nodeSelector:
        # "You will ONLY live in this specific zone!"
        topology.kubernetes.io/zone: us-west-2b
      containers:
        - name: my-app-container
          image: nginx:1.25.3
          volumeMounts:
            - name: app-data
              mountPath: /var/www/html
      volumes:
        - name: app-data
          persistentVolumeClaim:
            claimName: my-app-pvc

This works. Kind of. The Pod is now shackled to the us-west-2b availability zone. If it gets rescheduled, the scheduler will only consider other nodes within that same AZ. The affinity conflict is solved.

But you’ve just traded one problem for a much scarier one. You’ve effectively disabled the “multi-AZ” resilience for this application. If us-west-2b experiences an outage or simply runs out of compute resources, your pod has nowhere to go. It will remain Pending, not because of a storage spat, but because you’ve locked it in a house that’s just run out of oxygen. This isn’t a solution; it’s just picking a different way to fail.

The elegant fix of intelligent patience

So, how do we get our couple to cooperate without resorting to digital handcuffs? The answer lies in changing not where they live, but how they decide to move in together.

The real hero of our story is a little-known StorageClass parameter: volumeBindingMode: WaitForFirstConsumer.

By default, when you ask for a PersistentVolumeClaim, Kubernetes provisions the EBS volume immediately. It’s like buying a heavy, immovable sofa before you’ve even chosen an apartment. The delivery truck drops it in us-west-2a, and now you’re forced to find an apartment in that specific neighborhood.

WaitForFirstConsumer flips the script entirely. It tells Kubernetes: “Hold on. Don’t buy the sofa yet. First, let the Pod (the ‘First Consumer’) find an apartment it likes.”

Here’s how this intelligent process unfolds:

You request a volume with a PersistentVolumeClaim.
The StorageClass, configured with WaitForFirstConsumer, does… nothing. It waits.
The Kubernetes scheduler, now free from any storage constraints, analyzes all your nodes across all your availability zones. It finds the best possible node for your Pod based on resources and other policies. Let’s say it picks a node in us-west-2c.
Only after the Pod has been assigned a home on that node does the StorageClass get the signal. It then dutifully provisions a brand-new EBS volume in that exact same zone, us-west-2c.

The Pod and its data are born together, in the same place, at the same time. No conflict. No drama. It’s a match made in cloud heaven.

Here is what this “patient” StorageClass looks like:

# storageclass-patient.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc-wait
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
# This is the magic line.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Your PersistentVolumeClaim simply needs to reference it:

# persistentvolumeclaim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  # Reference the patient StorageClass
  storageClassName: ebs-sc-wait
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

And now, your Deployment can be blissfully unaware of zones, free to roam as a true digital nomad should.

# deployment-liberated.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateful-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-stateful-app
  template:
    metadata:
      labels:
        app: my-stateful-app
    spec:
      # No nodeSelector! The pod is free!
      containers:
        - name: my-app-container
          image: nginx:1.25.3
          volumeMounts:
            - name: app-data
              mountPath: /var/www/html
      volumes:
        - name: app-data
          persistentVolumeClaim:
            claimName: my-app-pvc

Let your infrastructure work for you

The moral of the story is simple. Don’t fight the brilliant, distributed nature of Kubernetes with rigid, zonal constraints. You chose a multi-AZ setup for resilience, so don’t let your storage configuration sabotage it.

By using WaitForFirstConsumer, which, thankfully, is the default in modern versions of the AWS EBS CSI Driver, you allow the scheduler to do its job properly. Your pods and volumes can finally have a healthy, lasting relationship, happily migrating together wherever the cloud winds take them.

And you? You can go back to sleep.

October 18, 2025 by Fernando SRE Cloud stuff DevOps stuff Kubernetes

Your Terraform S3 backend is confused not broken

You’ve done everything right. You wrote your Terraform config with the care of someone assembling IKEA furniture while mildly sleep-deprived. You double-checked your indentation (because yes, it matters). You even remembered to enable encryption, something your future self will thank you for while sipping margaritas on a beach far from production outages.

And then, just as you run terraform init, Terraform stares back at you like a cat that’s just been asked to fetch the newspaper.

Error: Failed to load state: NoSuchBucket: The specified bucket does not exist

But… you know the bucket exists. You saw it in the AWS console five minutes ago. You named it something sensible like company-terraform-states-prod. Or maybe you didn’t. Maybe you named it tf-bucket-please-dont-delete in a moment of vulnerability. Either way, it’s there.

So why is Terraform acting like you asked it to store your state in Narnia?

The truth is, Terraform’s S3 backend isn’t broken. It’s just spectacularly bad at telling you what’s wrong. It doesn’t throw tantrums, it just fails silently, or with error messages so vague they could double as fortune cookie advice.

Let’s decode its passive-aggressive signals together.

The backend block that pretends to listen

At the heart of remote state management lies the backend “s3” block. It looks innocent enough:

terraform {
  backend "s3" {
    bucket         = "my-team-terraform-state"
    key            = "networking/main.tfstate"
    region         = "us-west-2"
    dynamodb_table = "tf-lock-table"
    encrypt        = true
  }
}

Simple, right? But this block is like a toddler with a walkie-talkie: it only hears what it wants to hear. If one tiny detail is off, region, permissions, bucket name, it won’t say “Hey, your bucket is in Ohio but you told me it’s in Oregon.” It’ll just shrug and fail.

And because Terraform backends are loaded before variable interpolation, you can’t use variables inside this block. Yes, really. You’re stuck with hardcoded strings. It’s like being forced to write your grocery list in permanent marker.

The four ways Terraform quietly sabotages you

Over the years, I’ve learned that S3 backend errors almost always fall into one of four buckets (pun very much intended).

1. The credentials that vanished into thin air

Terraform needs AWS credentials. Not “kind of.” Not “maybe.” It needs them like a coffee machine needs beans. But it won’t tell you they’re missing, it’ll just say the bucket doesn’t exist, even if you’re looking at it in the console.

Why? Because without valid credentials, AWS returns a 403 Forbidden, and Terraform interprets that as “bucket not found” to avoid leaking information. Helpful for security. Infuriating for debugging.

Fix it: Make sure your credentials are loaded via environment variables, AWS CLI profile, or IAM roles if you’re on an EC2 instance. And no, copying your colleague’s .aws/credentials file while they’re on vacation doesn’t count as “secure.”

2. The region that lied to everyone

You created your bucket in eu-central-1. Your backend says us-east-1. Terraform tries to talk to the bucket in Virginia. The bucket, being in Frankfurt, doesn’t answer.

Result? Another “bucket not found” error. Because of course.

S3 buckets are region-locked, but the error message won’t mention regions. It assumes you already know. (Spoiler: you don’t.)

Fix it: Run this to check your bucket’s real region:

aws s3api get-bucket-location --bucket my-team-terraform-state

Then update your backend block accordingly. And maybe add a sticky note to your monitor: “Regions matter. Always.”

3. The lock table that forgot to show up

State locking with DynamoDB is one of Terraform’s best features; it stops two engineers from simultaneously destroying the same VPC like overeager toddlers with a piñata.

But if you declare a dynamodb_table in your backend and that table doesn’t exist? Terraform won’t create it for you. It’ll just fail with a cryptic message about “unable to acquire state lock.”

Fix it: Create the table manually (or with separate Terraform code). It only needs one attribute: LockID (string). And make sure your IAM user has dynamodb:GetItem, PutItem, and DeleteItem permissions on it.

Think of DynamoDB as the bouncer at a club: if it’s not there, anyone can stumble in and start redecorating.

4. The missing safety nets

Versioning and encryption aren’t strictly required, but skipping them is like driving without seatbelts because “nothing bad has happened yet.”

Without versioning, a bad terraform apply can overwrite your state forever. No undo. No recovery. Just you, your terminal, and the slow realization that you’ve deleted production.

Enable versioning:

aws s3api put-bucket-versioning \
  --bucket my-team-terraform-state \
  --versioning-configuration Status=Enabled

And always set encrypt = true. Your state file contains secrets, IDs, and the blueprint of your infrastructure. Treat it like your diary, not your shopping list.

Debugging without losing your mind

When things go sideways, don’t guess. Ask Terraform nicely for more details:

TF_LOG=DEBUG terraform init

Yes, it spits out a firehose of logs. But buried in there is the actual AWS API call, and the real error code. Look for lines containing AWS request or ErrorResponse. That’s where the truth hides.

Also, never run terraform init once and assume it’s locked in. If you change your backend config, you must run:

terraform init -reconfigure

Otherwise, Terraform will keep using the old settings cached in .terraform/. It’s stubborn like that.

A few quiet rules for peaceful coexistence

After enough late-night debugging sessions, I’ve adopted a few personal commandments:

One project, one bucket. Don’t mix dev and prod states in the same bucket. It’s like keeping your tax documents and grocery receipts in the same shoebox, technically possible, spiritually exhausting.
Name your state files clearly. Use paths like prod/web.tfstate instead of final-final-v3.tfstate.
Never commit backend configs with real bucket names to public repos. (Yes, people still do this. No, it’s not cute.)
Test your backend setup in a sandbox first. A $0.02 bucket and a tiny DynamoDB table can save you a $10,000 mistake.

It’s not you, it’s the docs

Terraform’s S3 backend works beautifully, once everything aligns. The problem isn’t the tool. It’s that the error messages assume you’re psychic, and the documentation reads like it was written by someone who’s never made a mistake in their life.

But now you know its tells. The fake “bucket not found.” The silent region betrayal. The locking table that ghosts you.

Next time it acts up, don’t panic. Pour a coffee, check your region, verify your credentials, and whisper gently: “I know you’re trying your best.”

Because honestly? It is.

October 13, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

When invisible limits beat warm Lambdas

My team had a problem. Or rather, we had a cause. A noble crusade that consumed our sprints, dominated our Slack channels, and haunted our architectural diagrams. We were on a relentless witch hunt for the dreaded Lambda cold start.

We treated those extra milliseconds of spin-up time like a personal insult from Jeff Bezos himself. We became amateur meteorologists, tracking “cold start storms” across regions. We had dashboards so finely tuned they could detect the faint, quantum flutter of an EC2 instance thinking about starting up. We proudly spent over $3,000 a month on provisioned concurrency¹, a financial sacrifice to the gods of AWS to keep our functions perpetually toasty.

We had done it. Cold starts were a solved problem. We celebrated with pizza and self-congratulatory Slack messages. The system was invincible.

Or so we thought.

The 2:37 am wake-up call

It was a Tuesday, of course. The kind of quiet, unassuming Tuesday that precedes all major IT disasters. At 2:37 AM, my phone began its unholy PagerDuty screech. The alert was as simple as it was terrifying: “API timeouts.”

I stumbled to my laptop, heart pounding, expecting to see a battlefield. Instead, I saw a paradox.

The dashboards were an ocean of serene green.

Cold starts? 0%. Our $3,000 was working perfectly. Our Lambdas were warm, cozy, and ready for action.
Lambda health? 100%. Every function was executing flawlessly, not an error in sight.
Database queries? 100% failure rate.

It was like arriving at a restaurant to find the chefs in the kitchen, knives sharpened and stoves hot, but not a single plate of food making it to the dining room. Our Lambdas were warm, our dashboards were green, and our system was dying. It turns out that for $3,000 a month, you can keep your functions perfectly warm while they helplessly watch your database burn to the ground.

We had been playing Jenga with AWS’s invisible limits, and someone had just pulled the wrong block.

Villain one, The great network card famine

Every Lambda function that needs to talk to services within your VPC, like a database, requires a virtual network card, an Elastic Network Interface (ENI). It’s the function’s physical connection to the world. And here’s the fun part that AWS tucks away in its documentation: your account has a default, region-wide limit on these. Usually around 250.

We discovered this footnote from 2018 when the Marketing team, in a brilliant feat of uncoordinated enthusiasm, launched a flash promo.

Our traffic surged. Lambda, doing its job beautifully, began to scale. 100 concurrent executions. 200. Then 300.

The 251st request didn’t fail. Oh no, that would have been too easy. Instead, it just… waited. For fourteen seconds. It was waiting in a silent, invisible line for AWS to slowly hand-carve a new network card from the finest, artisanal silicon.

Our “optimized” system had become a lottery.

The winners: Got an existing ENI and a zippy 200ms response.
The losers: Waited 14,000ms for a network card to materialize out of thin air, causing their request to time out.

The worst part? This doesn’t show up as a Lambda error. It just looks like your code is suddenly, inexplicably slow. We were hunting for a bug in our application, but the culprit was a bureaucrat in the AWS networking department.

Do this right now. Seriously. Open a terminal and check your limit. Don’t worry, we’ll wait.

# This command reveals the 'Maximum network interfaces per Region' quota.
# You might be surprised at what you find.
aws service-quotas get-service-quota \
  --service-code vpc \
  --quota-code L-F678F1CE

Villain two, The RDS proxy’s velvet rope policy

Having identified the ENI famine, we thought we were geniuses. But fixing that only revealed the next layer of our self-inflicted disaster. Our Lambdas could now get network cards, but they were all arriving at the database party at once, only to be stopped at the door.

We were using RDS Proxy, the service AWS sells as the bouncer for your database, managing connections so your Aurora instance doesn’t get overwhelmed. What we failed to appreciate is that this bouncer has its own… peculiar rules. The proxy itself has CPU limits. When hundreds of Lambdas tried to get a connection simultaneously, the proxy’s CPU spiked to 100%.

It didn’t crash. It just became incredibly, maddeningly slow. It was like a nightclub bouncer enforcing a strict one-in, one-out policy, not because the club was full, but because he could only move his arms so fast. The queue of connections grew longer and longer, each one timing out, while the database inside sat mostly idle, wondering where everybody went.

The humbling road to recovery

The fixes weren’t complex, but they were humbling. They forced us to admit that our beautiful, perfectly-tuned relational database architecture was, for some tasks, the wrong tool for the job.

The great VPC escape
For any Lambda that only needed to talk to public AWS services like S3 or SQS, we ripped it out of the VPC. This is Lambda 101, but we had put everything in the VPC for “security.” Moving them out meant they no longer needed an ENI to function. We implemented VPC Endpoints², allowing these functions to access AWS services over a private link without the ENI overhead.
RDS proxy triage
For the databases we couldn’t escape, we treated the proxy like the delicate, overworked bouncer it was. We massively over-provisioned the proxy instances, giving them far more CPU than they should ever need. We also implemented client-side jitter, a small, random delay before retrying a connection, to stop our Lambdas from acting like a synchronized mob storming the gates.
The nuclear option DynamoDB
For one critical, high-throughput service, we did the unthinkable. We migrated it from Aurora to DynamoDB. The hardest part wasn’t the code; it was the ego. It was admitting that the problem didn’t require a Swiss Army knife when all we needed was a hammer. The team’s reaction after the migration was telling: “Wait… you mean we don’t need to worry about connection pooling at all?” Every developer, after their first taste of NoSQL freedom.

The real lesson we learned

Obsessing over cold starts is like meticulously polishing the chrome on your car’s engine while the highway you’re on is crumbling into a sinkhole. It’s a visible, satisfying metric to chase, but it often distracts from the invisible, systemic limits that will actually kill you.

Yes, optimize your cold starts. Shave off those milliseconds. But only after you’ve pressure-tested your system for the real bottlenecks. The unsexy ones. The ones buried in AWS service quota pages and 5-year-old forum posts.

Stop micro-optimizing the 50ms you can see and start planning for the 14-second delays you can’t. We learned that the hard way, at 2:37 AM on a Tuesday.

¹ The official term for ‘setting a pile of money on fire to keep your functions toasty’.

² A fancy AWS term for ‘a private, secret tunnel to an AWS service so your Lambda doesn’t have to go out into the scary public internet’. It’s like an employee-only hallway in a giant mall.

October 10, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

What replaces Transit Gateway on Google cloud

Spoiler: There is no single magic box. There is a tidy drawer of parts that click together so cleanly you stop missing the box.

The first time I asked a team to set up “Transit Gateway on Google Cloud,” I received the sort of polite silence you reserve for relatives who ask where you keep the fax machine. On AWS, you reach for Transit Gateway and call it a day. On Azure, you reach for Virtual WAN and its Virtual Hubs. On Google Cloud, you reach for… a shorter shopping list: one global VPC, Network Connectivity Center with VPC spokes when you need a hub, VPC Peering when you do not, Private Service Connect for producer‑consumer traffic, and Cloud Router to keep routes honest.

Once you stop searching for a product name and start wiring the right parts, transit on Google Cloud turns out to be pleasantly boring.

The short answer

Inter‑VPC at scale → Network Connectivity Center (NCC) with VPC spokes
One‑to‑one VPC connectivity → VPC Peering (non‑transitive)
Private access to managed or third‑party services → Private Service Connect (PSC)
Hybrid connectivity → Cloud Router + HA VPN or Interconnect with dynamic routing mode set to Global

That’s the toolkit most teams actually need. The rest of this piece is simply: where each part shines, where it bites, and how to string them together without leaving teeth marks.

How do the other clouds solve it?

AWS: VPCs are regional. Transit Gateway acts as the hub; if you span regions, you peer TGWs. It is a well‑lit path and a single product name.
Azure: VNets are regional. Virtual WAN gives you a global fabric with per‑region Virtual Hubs, optionally “secured” with an integrated firewall.
Google Cloud: a VPC is global (routing table and firewalls are global, subnets remain regional). You do not need a separate “global transit” box to make two instances in different regions talk. When you outgrow simple, add NCC with VPC spokes for hub‑and‑spoke, PSC for services, and Cloud Router for dynamic routing.

Different philosophies, same goal. Google Cloud leans into a global network and small, specialized parts.

What a global VPC really means

A Google Cloud VPC gives you a global control plane. You define routes and firewall rules once, and they apply across regions; you place subnets per region where compute lives. That split is why multi‑region feels natural on GCP without an extra transit layer. Not everything is magic, though:

Cloud Router, VPN, and Interconnect are regional attachments. You can and often should set dynamic routing mode to Global so learned routes propagate across the VPC, but the physical attachment still sits in a region.
Global does not mean chaotic. IAM, firewall rules, hierarchical policies, and VPC Service Controls provide the guardrails you actually want.

Choosing the right part

Network connectivity center with VPC spokes

Use it when you have many VPCs and want managed transit without building a mesh of N×N peerings. NCC gives you a hub‑and‑spoke model where spokes exchange routes through the hub, including hybrid spokes via Cloud Router. Think “default” once your VPC count creeps into the double digits.

Use when you need inter‑VPC transit at scale, clear centralization, and easy route propagation.

Avoid when you have only two or three VPCs that will never grow. Simpler is nicer.

VPC Peering

Use it for simple 1:1 connectivity. It is non‑transitive by design. If A peers with B and B peers with C, A does not automatically reach C. This is not a bug; it is a guardrail. If you catch yourself drawing triangles, take the hint and move to NCC.

Use when two VPCs need to talk, and that’s the end of the story.

Avoid when you need full‑mesh or centralized inspection.

Private Service Connect

Use it when a consumer VPC needs private access to a producer (managed Google service like Cloud SQL, or a third‑party/SaaS running behind a producer endpoint). PSC is not inter‑VPC transit; it is producer‑consumer plumbing with private IPs and tight control.

Use when you want “just the sauce” from a service without crossing the public internet.

Avoid when you are trying to stitch two application VPCs together. That is a job for NCC or peering.

Cloud Router with HA VPN or Interconnect

Use it for hybrid. Cloud Router speaks BGP and exchanges routes dynamically with your on‑prem or colo edge. Set dynamic routing to Global so routes learned in one region are known across the VPC. Remember that the attachments are regional; plan for redundancy per region.

Use when you want fewer static routes and less drift between environments.

Avoid when you expected a single global attachment. That is not how physics—or regions—work.

Three quick patterns

Multi‑region application in one VPC

One global VPC, regional subnets in us‑east1, europe‑west1, and asia‑east1. Instances talk across regions without extra kit. If the app grows into multiple VPCs per domain (core, data, edge), bring in NCC as the hub.

Mergers and acquisitions without a month of rewiring

Projects in Google Cloud are movable between folders and even organizations, subject to permissions and policy guardrails. That turns “lift and splice” into a routine operation rather than a quarter‑long saga. Be upfront about prerequisites: billing, liens, org policy, and compliance can slow a move; plan them, do not hand‑wave them.

Shared services with clean tenancy

Run shared services in a host project via Shared VPC. Attach service projects for each team. For an external partner, use VPC Peering or PSC, depending on whether they need network adjacency or just a service endpoint. If many internal VPCs need those shared bits, let NCC be the meeting place.

ASCII sketch of the hub

Pitfalls you can dodge

Expecting peering to be transitive. It is not. If your diagram starts to look like spaghetti, stop and bring in NCC.
Treating Cloud Router as global. It is regional. The routing mode can be Global; the attachment is not. Plan per‑region redundancy.
Using PSC as inter‑VPC glue. PSC is for producer‑consumer privacy, not general transit.
Forgetting DNS. Cross‑project and cross‑VPC name resolution needs deliberate configuration. Decide where you publish private zones and who can see them.
Over‑centralizing inspection. The global VPC makes central stacks attractive, but latency budgets are still a thing. Place controls where the traffic lives.

Security that scales with freedom

A global VPC does not mean a free‑for‑all. The security model leans on identity and context rather than IP folklore.

IAM everywhere for least privilege and clear ownership.
VPC firewall rules with hierarchical policy for the sharp edges.
VPC Service Controls for data perimeter around managed services.
Cloud Armor and load balancers at the edge, where they belong.

The result is a network that is permissive where it should be and stubborn where it must be.

A tiny buying guide for your brain

Two VPCs, done in a week → VPC Peering
Ten VPCs, many teams, add partners next quarter → NCC with VPC spokes
Just need private access to Cloud SQL or third‑party services → PSC
Datacenter plus cloud, please keep routing sane → Cloud Router with HA VPN or Interconnect, dynamic routing Global

If you pick the smallest thing that works today and the most boring thing that still works next year, you will almost always land on the right square.

Where the magic isn’t

Transit Gateway is a great product name. It just happens to be the wrong shopping query on Google Cloud. You are not assembling a monolith; you are pulling the right pieces from a drawer that has been neatly labeled for years. NCC connects the dots, Peering keeps simple things simple, PSC keeps services private, and Cloud Router shakes hands with the rest of your world. None of them is glamorous. All of them are boring in the way electricity is boring when it works.

If you insist on a single giant box, you will end up using it as a hammer. Google Cloud encourages a tidier vice: choose the smallest thing that does the job, then let the global VPC and dynamic routing do the quiet heavy lifting. Need many VPCs to talk without spaghetti? NCC with spokes. Need two VPCs and a quiet life? Peering. Need only the sauce from Cloud SQL or a partner? PSC. Need the campus to meet the cloud without sticky notes of static routes? Cloud Router with HA VPN or Interconnect. Label the bag, not every screw.

The punchline is disappointingly practical. When teams stop hunting for a product name, they start shipping features. Incidents fall in number and in temperature. The network diagram loses its baroque flourishes and starts looking like something you could explain before your coffee cools.

So yes, keep admiring Transit Gateway as a name. Then close the tab and open the drawer you already own. Put the parts back in the same place when you are done, teach the interns what each one is for, and get back to building the thing your users actually came for. The box you were searching for was never the point; the drawer is how you move faster without surprises.

October 7, 2025 by Fernando SRE Cloud stuff

The mutability mirage in Cloud

We’ve all been there. A DevOps engineer squints at a script, muttering, “But I changed it, it has to be mutable.” Meanwhile, the cloud infrastructure blinks back, unimpressed, as if to say, “Sure, you swapped the sign. That doesn’t make the building mutable.”

This isn’t just a coding quirk. It’s a full-blown identity crisis in the world of cloud architecture and DevOps, where confusing reassignment with mutability can lead to anything from baffling bugs to midnight firefighting sessions. Let’s dissect why your variables are lying to you, and why it matters more than you think.

The myth of the mutable variable

Picture this: You’re editing a configuration file for a cloud service. You tweak a value, redeploy, and poof, it works. Naturally, you assume the system is mutable. But what if it isn’t? What if the platform quietly discarded your old configuration and spun up a new one, like a magician swapping a rabbit for a hat?

This is the heart of the confusion. In programming, mutability isn’t about whether something changes; it’s about how it changes. A mutable object alters its state in place, like a chameleon shifting colors. An immutable one? It’s a one-hit wonder: once created, it’s set in stone. Any “change” is just a new object in disguise.

What mutability really means

Let’s cut through the jargon. A mutable object, say, a Python list, lets you tweak its contents without breaking a sweat. Add an item, remove another, and it’s still the same list. Check its memory address with id(), and it stays consistent.

Now take a string. Try to “modify” it:

greeting = "Hello"  
greeting += " world"

Looks like a mutation, right? Wrong. The original greeting is gone, replaced by a new string. The memory address? Different. The variable name greeting is just a placeholder, now pointing to a new object, like a GPS rerouting you to a different street.

This isn’t pedantry. It’s the difference between adjusting the engine of a moving car and replacing the entire car because you wanted a different color.

The great swap

Why does this illusion persist? Because programming languages love to hide the smoke and mirrors. In functional programming, for instance, operations like map() or filter() return new collections, never altering the original. Yet the syntax, data = transform(data), feels like mutation.

Even cloud infrastructure plays this game. Consider immutable server deployments: you don’t “update” an AWS EC2 instance. You bake a new AMI and replace the old one. The outcome is change, but the mechanism is substitution. Confusing the two leads to chaos, like assuming you can repaint a house without leaving the living room.

The illusion of change

Here’s where things get sneaky. When you write:

counter = 5  
counter += 1

You’re not mutating the number 5. You’re discarding it for a shiny new 6. The variable counter is merely a label, not the object itself. It’s like renaming a book after you’ve already read it, The Great Gatsby didn’t change; you just called it The Even Greater Gatsby and handed it to someone else.

This trickery is baked into language design. Python’s tuples are immutable, but you can reassign the variable holding them. Java’s String class is famously unyielding, yet developers swear they “changed” it daily. The culprit? Syntax that masks object creation as modification.

Why cloud and DevOps care

In cloud architecture, this distinction is a big deal. Mutable infrastructure, like manually updating a server, invites inconsistency and “works on my machine” disasters. Immutable infrastructure, by contrast, treats servers as disposable artifacts. Changes mean new deployments, not tweaks.

This isn’t just trendy. It’s survival. Imagine two teams modifying a shared configuration. If the object is mutable, chaos ensues, race conditions, broken dependencies, the works. If it’s immutable, each change spawns a new, predictable version. No guessing. No debugging at 3 a.m.

Performance matters too. Creating new objects has overhead, yes, but in distributed systems, the trade-off for reliability is often worth it. As the old adage goes: “You can optimize for speed or sanity. Pick one.”

How not to fall for the trick

So how do you avoid this trap?

Check the documentation. Is the type labeled mutable? If it’s a string, tuple, or frozenset, assume it’s playing hard to get.
Test identity. In Python, use id(). In Java, compare references. If the address changes, you’ve been duped.
Prefer immutability for shared data. Your future self will thank you when the system doesn’t collapse under concurrent edits.

And if all else fails, ask: “Did I alter the object, or did I just point to a new one?” If the answer isn’t obvious, grab a coffee. You’ll need it.

The cloud doesn’t change, it blinks

Let’s be brutally honest: in the cloud, assuming something is mutable because it changes is like assuming your toaster is self-repairing because the bread pops up different shades of brown. You tweak a Kubernetes config, redeploy, and poof, it’s “updated.” But did you mutate the cluster or merely summon a new one from the void? In the world of DevOps, this confusion isn’t just a coding quirk; it’s the difference between a smooth midnight rollout and a 3 a.m. incident war room where your coffee tastes like regret.

Cloud infrastructure doesn’t change; it reincarnates. When you “modify” an AWS Lambda function, you’re not editing a living organism. You’re cremating the old version and baptizing a new one in S3. The same goes for Terraform state files or Docker images: what looks like a tweak is a full-scale resurrection. Mutable configurations? They’re the digital equivalent of duct-taping a rocket mid-flight. Immutable ones? They’re the reason your team isn’t debugging why the production database now speaks in hieroglyphics.

And let’s talk about the real villain: configuration drift. It’s the gremlin that creeps into mutable systems when no one’s looking. One engineer tweaks a server, another “fixes” a firewall rule, and suddenly your cloud environment has the personality of a broken vending machine. Immutable infrastructure laughs at this. It’s the no-nonsense librarian who will replace the entire catalog if you so much as sneeze near the Dewey Decimal System.

So the next time a colleague insists, “But I changed it!” with the fervor of a street magician, lean in and whisper: “Ah, yes. Just like how I ‘changed’ my car by replacing it with a new one. Did you mutate the object, or did you just sacrifice it to the cloud gods?” Then watch their face, the same bewildered blink as your AWS console when you accidentally set min_instances = 0 on a critical service.

The cloud doesn’t get frustrated. It doesn’t sigh. It blinks. Once. Slowly. And in that silent judgment, you’ll finally grasp the truth: change is inevitable. Mutability is a choice. Choose wisely, or spend eternity debugging the ghost of a server that thought it was mutable.

(And for the love of all things scalable: stop naming your variables temp.)

October 5, 2025 by Fernando SRE Cloud stuff Computer Science stuff DevOps stuff

Parenting your Kubernetes using hierarchical namespaces

Let’s be honest. Your Kubernetes cluster, on its bad days, feels less like a sleek, futuristic platform and more like a chaotic shared apartment right after college. The frontend team is “borrowing” CPU from the backend team, the analytics project left its sensitive data lying around in a public bucket, and nobody knows who finished the last of the memory reserves.

You tried to bring order. You dutifully handed out digital rooms to each team using namespaces. For a while, there was peace. But then those teams had their own little sub-projects, staging, testing, that weird experimental feature no one talks about, and your once-flat world devolved into a sprawling city with no zoning laws. The shenanigans continued, just inside slightly smaller boxes.

What you need isn’t more rules scribbled on a whiteboard. You need a family tree. It’s time to introduce some much-needed parental supervision into your cluster. It’s time for Hierarchical Namespaces.

The origin of the namespace rebellion

In the beginning, Kubernetes gave us namespaces, and they were good. The goal was simple: create virtual walls to stop teams from stealing each other’s lunch (metaphorically speaking, of course). Each namespace was its own isolated island, a sovereign nation with its own rules. This “flat earth” model worked beautifully… until it didn’t.

As organizations scaled, their clusters turned into bustling archipelagos of hundreds of namespaces. Managing them felt like being an air traffic controller for a fleet of paper airplanes in a hurricane. Teams realized that a flat structure was basically a free-for-all party where every guest could raid the fridge, as long as they stayed in their designated room. There was no easy way to apply a single rule, like a network policy or a set of permissions, to a group of related namespaces. The result was a maddening copy-paste-a-thon of YAML files, a breeding ground for configuration drift and human error.

The community needed a way to group these islands, to draw continents. And so, the Hierarchical Namespace Controller (HNC) was born, bringing a simple, powerful concept to the table: namespaces can have parents.

What this parenting gig gets you

Adopting a hierarchical structure isn’t just about satisfying your inner control freak. It comes with some genuinely fantastic perks that make cluster management feel less like herding cats.

The “Because I said so” principle: This is the magic of policy inheritance. Any Role, RoleBinding, or NetworkPolicy you apply to a parent namespace automatically cascades down to all its children and their children, and so on. It’s the parenting dream: set a rule once, and watch it magically apply to everyone. No more duplicating RBAC roles for the dev, staging, and testing environments of the same application.
The family budget: You can set a resource quota on a parent namespace, and it becomes the total budget for that entire branch of the family tree. For instance, team-alpha gets 100 CPU cores in total. Their dev and qa children can squabble over that allowance, but together, they can’t exceed it. It’s like giving your kids a shared credit card instead of a blank check.
Delegated authority: You can make a developer an admin of a “team” namespace. Thanks to inheritance, they automatically become an admin of all the sub-namespaces under it. They get the freedom to manage their own little kingdoms (staging, testing, feature-x) without needing to ping a cluster-admin for every little thing. You’re teaching them responsibility (while keeping the master keys to the kingdom, of course).

Let’s wrangle some namespaces

Convinced? I thought so. The good news is that bringing this parental authority to your cluster isn’t just a fantasy. Let’s roll up our sleeves and see how it works.

Step 0: Install the enforcer

Before we can start laying down the law, we need to invite the enforcer. The Hierarchical Namespace Controller (HNC) doesn’t come built-in with Kubernetes. You have to install it first.

You can typically install the latest version with a single kubectl command:

kubectl apply -f [https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/latest/download/hnc-manager.yaml](https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/latest/download/hnc-manager.yaml)

Wait a minute for the controller to be up and running in its own hnc-system namespace. Once it’s ready, you’ll have a new superpower: the kubectl hns plugin.

Step 1: Create the parent namespace

First, let’s create a top-level namespace for a project. We’ll call it project-phoenix. This will be our proud parent.

kubectl create namespace project-phoenix

Step 2: Create some children

Now, let’s give project-phoenix a couple of children: staging and testing. Wait, what’s that hns command? That’s not your standard kubectl. That’s the magic wand the HNC just gave you. You’re telling it to create a staging namespace and neatly tuck it under its parent.

kubectl hns create staging -n project-phoenix
kubectl hns create testing -n project-phoenix

Step 3: Admire your family tree

To see your beautiful new hierarchy in all its glory, you can ask HNC to draw you a picture.

kubectl hns tree project-phoenix

You’ll get a satisfyingly clean ASCII art diagram of your new family structure:

You can even create grandchildren. Let’s give the staging namespace its own child for a specific feature branch.

kubectl hns create feature-login-v2 -n staging
kubectl hns tree project-phoenix

And now your tree looks even more impressive:

Step 4 Witness the magic of inheritance

Let’s prove that this isn’t all smoke and mirrors. We’ll create a Role in the parent namespace that allows viewing Pods.

# viewer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-viewer
  namespace: project-phoenix
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Apply it:

kubectl apply -f viewer-role.yaml

Now, let’s give a user, let’s call her jane.doe, that role in the parent namespace.

kubectl create rolebinding jane-viewer --role=pod-viewer --user=jane.doe -n project-phoenix

Here’s the kicker. Even though we only granted Jane permission in project-phoenix, she can now magically view pods in the staging and feature-login-v2 namespaces as well.

# This command would work for Jane!
kubectl auth can-i get pods -n staging --as=jane.doe
# YES

# And even in the grandchild namespace!
kubectl auth can-i get pods -n feature-login-v2 --as=jane.doe
# YES

No copy-pasting required. The HNC saw the binding in the parent and automatically propagated it down the entire tree. That’s the power of parenting.

A word of caution from a fellow parent

As with real parenting, this new power comes with its own set of challenges. It’s not a silver bullet, and you should be aware of a few things before you go building a ten-level deep namespace dynasty.

Complexity can creep in: A deep, sprawling tree of namespaces can become its own kind of nightmare to debug. Who has access to what? Which quota is affecting this pod? Keep your hierarchy logical and as flat as you can get away with. Just because you can create a great-great-great-grandchild namespace doesn’t mean you should.
Performance is not free: The HNC is incredibly efficient, but propagating policies across thousands of namespaces does have a cost. For most clusters, it’s negligible. For mega-clusters, it’s something to monitor.
Not everyone obeys the parents: Most core Kubernetes resources (RBAC, Network Policies, Resource Quotas) play nicely with HNC. But not all third-party tools or custom controllers are hierarchy-aware. They might only see the flat world, so always test your specific tools.

Go forth and organize

Hierarchical Namespaces are the organizational equivalent of finally buying drawer dividers for that one kitchen drawer, you know the one. The one where the whisk is tangled with the batteries and a single, mysterious key. They transform your cluster from a chaotic free-for-all into a structured, manageable hierarchy that actually reflects how your organization works. It’s about letting you set rules with confidence and delegate with ease.

So go ahead, embrace your inner cluster parent. Bring some order to the digital chaos. Your future self, the one who isn’t spending a Friday night debugging a rogue pod in the wrong environment, will thank you. Just don’t be surprised when your newly organized child namespaces start acting like teenagers, asking for the production Wi-Fi password or, heaven forbid, the keys to the cluster-admin car.After all, with great power comes great responsibility… and a much, much cleaner kubectl get ns output.

October 3, 2025 by Fernando SRE Cloud stuff DevOps stuff Kubernetes SRE stuff

Building living systems with WebSockets

For the longest time, communication on the web has been a painfully formal affair. It’s like sending a letter. Your browser meticulously writes a request, sends it off via the postal service (HTTP), and then waits. And waits. Eventually, the server might write back with an answer. If you want to know if anything has changed five seconds later, you have to send another letter. It’s slow, it’s inefficient, and frankly, the postman is starting to give you funny looks.

This constant pestering, “Anything new? How about now? Now?”, is the digital equivalent of a child on a road trip asking, “Are we there yet?” It’s called polling, and it’s the clumsy foundation upon which much of the old web was built. For applications that need to feel alive, this just won’t do.

What if, instead of sending a flurry of letters, we could just open a phone line directly to the server? A dedicated, always-on connection where both sides can just shout information at each other the moment it happens. That, in a nutshell, is the beautiful, chaotic, and nonstop chatter of WebSockets. It’s the technology that finally gave our distributed systems a voice.

The secret handshake that starts the party

So how do you get access to this exclusive, real-time conversation? You can’t just barge in. You have to know the secret handshake.

The process starts innocently enough, with a standard HTTP request. It looks like any other request, but it carries a special, almost magical, header: Upgrade: websocket. This is the client subtly asking the server, “Hey, this letter-writing thing is a drag. Can we switch to a private line?”

If the server is cool, and equipped for a real conversation, it responds with a special status code, 101 Switching Protocols. This isn’t just an acknowledgment; it’s an agreement. The server is saying, “Heck yes. The formal dinner party is over. Welcome to the after-party.” At that moment, the clumsy, transactional nature of HTTP is shed like a heavy coat, and the connection transforms into a sleek, persistent, two-way WebSocket tunnel. The phone line is now open.

So what can we do with all this chatter?

Once you have this open line, the possibilities become far more interesting than just fetching web pages. You can build systems that breathe.

The art of financial eavesdropping

Think of a stock trading platform. With HTTP, you’d be that sweaty-palmed investor hitting refresh every two seconds, hoping to catch a price change. With WebSockets, the server just whispers the new prices in your ear the microsecond they change. It’s the difference between reading yesterday’s newspaper and having a live feed from the trading floor piped directly into your brain.

Keeping everyone on the same page literally

Remember the horror of emailing different versions of a document back and forth? “Report_Final_v2_Johns_Edits_Final_FINAL.docx”. Collaborative tools like Google Docs killed that nightmare, and WebSockets were the murder weapon. When you type, your keystrokes are streamed to everyone else in the document instantly. It’s a seamless, shared consciousness, not a series of disjointed monologues.

Where in the world is my taxi

Ride-sharing apps like Uber would be a farce without a live map. You don’t want a “snapshot” of where your driver was 30 seconds ago; you want to see that little car icon gliding smoothly toward you. WebSockets provide that constant stream of location data, turning a map from a static picture into a living, moving window.

When the conversation gets too loud

Of course, hosting a party where a million people are all talking at once isn’t exactly a walk in the park. This is where our brilliant WebSocket-powered dream can turn into a bit of a logistical headache.

A server that could happily handle thousands of brief HTTP requests might suddenly break into a cold sweat when asked to keep tens of thousands of WebSocket phone lines open simultaneously. Each connection consumes memory and resources. It’s like being a party host who promised to have a deep, meaningful conversation with every single guest, all at the same time. Eventually, you’re just going to collapse from exhaustion.

And what happens if the line goes dead? A phone can be hung up, but a digital connection can just… fade into the void. Is the client still there, listening quietly? Or did their Wi-Fi die mid-sentence? To avoid talking to a ghost, servers have to periodically poke the client with a ping message. If they get a pong back, all is well. If not, the server sadly hangs up, freeing the line for someone who actually wants to talk.

How to be a good conversation host

Taming this beast requires a bit of cleverness. You can’t just throw one server at the problem and hope for the best.

Load balancers become crucial, but they need to be smarter. A simple load balancer that just throws requests at any available server is a disaster for WebSockets. It’s like trying to continue a phone conversation while the operator keeps switching you to a different person who has no idea what you were talking about. You need “sticky sessions,” which is a fancy way of saying the load balancer is smart enough to remember which server you were talking to and keeps you connected to it.

Security also gets a fun new twist. An always-on connection is a wonderfully persistent doorway into your system. If you’re not careful about who you’re talking to and what they’re saying (WSS, the secure version, is non-negotiable), you might find you’ve invited a Trojan horse to your party.

A world that talks back

So, no, WebSockets aren’t just another tool in the shed. They represent a philosophical shift. It’s the moment we stopped treating the web like a library of dusty, static books and started treating it like a bustling, chaotic city square. We traded the polite, predictable, and frankly boring exchange of letters for the glorious, unpredictable mess of a real-time human conversation.

It means our applications can now have a pulse. They can be surprised, they can interrupt, and they can react with the immediacy of a startled cat. Building these living systems is certainly noisier and requires a different kind of host, one who’s part traffic cop and part group therapist. But by embracing the chaos, we create experiences that don’t just respond; they engage, they live. And isn’t building a world that actually talks back infinitely more fun?

October 1, 2025 by Fernando SRE Cloud stuff Computer Science stuff