AWS Keeps Deleting My DevOps Server

March 2026

I like keeping my laptop clean. Over the years I’ve realized that installing dozens of development tools locally eventually turns a machine into a mess. Dependencies break, versions conflict, and upgrading one tool sometimes breaks another. Instead of dealing with that, I prefer doing most of my development work in the cloud by launching a virtual machine and using it as my workspace.

That machine typically runs everything I need: Git, Jenkins, AWS CLI, Terraform, Docker, Python, and Kubernetes CLI tools. Once I'm done experimenting, I save important files, terminate the instance and move on.

The environment is disposable, reproducible, and isolated from my laptop. If something breaks, I can simply launch a new machine. And perhaps the best part — it’s cheap.

My Cloud Development Environment

Instead of installing tools locally, I spin up an instance using Amazon EC2. Even better, I usually launch it as an Amazon EC2 Spot Instance.

Spot Instances use spare compute capacity inside AWS data centers. Because this capacity would otherwise sit unused, AWS offers it at a massive discount. In many cases, Spot Instances can cost up to 90% less than On-Demand instances.

For development work, that’s perfect. My environments are temporary anyway, so there’s no reason to pay full price for compute.

To make launching these environments fast, I rely on launch templates that already define everything I need — the instance type, security groups, IAM role, storage configuration, and my preferred AMI.

With this setup, spinning up a ready-to-use development server takes only a few seconds.

The Catch with Spot Instances

Spot Instances are cheap for a reason. AWS can reclaim them whenever the underlying capacity is needed elsewhere. When that happens, the instance receives an interruption notice and eventually terminates.

The first time this happened to me, I was in the middle of working on infrastructure. I was writing Terraform code, testing Docker containers, and configuring a Kubernetes cluster.

Then suddenly the instance disappeared. Everything I had installed or configured, and all the files I had created on that machine were gone.

That experience made me realize something important. If I want to use Spot Instances as my development environment, I need a way to recover my work when AWS decides to reclaim the capacity.

How I Prevent Losing My Work

Over time I started using several different approaches to deal with Spot interruptions. Depending on what I’m doing, I either preserve the disk directly, automatically back up the instance, or configure the instance so it can simply be restarted later.

Option 1 — Disable “Delete on Termination”

The simplest solution is disabling Delete on Termination on the root EBS volume.

Normally when an EC2 instance is terminated, its root volume is deleted automatically. But when this option is disabled, the disk survives even if the instance does not. So, when a Spot Instance gets terminated, the instance disappears but the root volume remains. Later I can attach that volume to a new instance and recover the environment.

This approach is simple and effective when I just want to preserve the contents of the disk.

Option 2 — Event-Driven Backup with Event Bridge and Lambda

Sometimes I want something more portable than just a leftover disk. For that situation I built a small automation workflow.

Using Amazon Event Bridge, I monitor EC2 state-change events. When the instance starts terminating, Event Bridge triggers an AWS Lambda function which creates either a snapshot of the root volume or a new AMI of the instance.

Instead of losing my development environment, I end up with a recovery image. Later I can launch a new instance — either another Spot Instance or an On-Demand instance — and continue working from where I left off.

What I like about this method is that it turns an unexpected termination into an automated backup process.

Option 3 — Persistent Spot Requests with Shutdown Behavior

Another solution I use in some situations is launching the instance through a persistent Spot request. With a persistent request, AWS continues trying to maintain the Spot capacity over time instead of treating it as a one-time request.

I also change the interruption behavior from terminate to shut down. When AWS reclaims the capacity, the instance shuts down instead of being destroyed. Because the instance still exists and the volumes remain attached, I can simply start it again later.

An additional benefit of this approach is that I can stop the instance when I’m not working and start it again later. This is useful when I want to pause my development environment without losing the machine state. This flexibility is not available with one-time Spot requests, which can only be terminated and can’t be stopped.

When I Use Each Approach

Over time I realized there isn’t a single perfect solution. Each method solves a slightly different problem.

• Disabling Delete on Termination is the fastest way to preserve the disk.
• Event Bridge and Lambda automation create snapshots or AMIs that can be reused later.
• Persistent Spot requests with shutdown behavior allow the instance itself to be restarted.

Using these approaches together lets me keep the cost advantages of Spot Instances while dramatically reducing the risk of losing my development environment.

Why I Like This Setup

This workflow gives me the best of both worlds. I get the massive cost savings of Spot Instances, but interruptions are no longer a major problem. My development machines are cheap, disposable, recoverable, and reproducible.

Most importantly, my laptop stays clean. I don’t need to install Terraform locally. I don’t need to manage Docker dependencies. I don’t worry about conflicting tool versions. I simply spin up a cloud machine, do the work, and shut it down when I’m finished.

The Real Lesson

Working this way changed how I think about infrastructure. Instead of trying to prevent failures, I design systems that expect them.

Spot Instances will disappear. Servers will crash. Instances will terminate. That’s normal in the cloud.

The real goal isn’t to stop failure — it’s to make sure your systems can recover automatically when it happens.

Final Thoughts

Using Spot Instances as a personal DevOps lab has been one of the most useful workflows I’ve built for myself in AWS. It keeps my costs low, encourages experimentation, and forces me to think about automation and resilience at the same time. And occasionally, when AWS decides to terminate my server in the middle of my work… at least now I know I can bring it back.

Roblex Tamo