--- title: Never Put a Pet on an AWS Spot Instance | daily.dev description: An intern learned why AWS Spot instances were wrong for a stateful server during an internship task. Spot instances can be up to 90% cheaper than on-demand,... canonical: https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Never Put a Pet on an AWS Spot Instance | daily.dev og:description: An intern learned why AWS Spot instances were wrong for a stateful server during an internship task. Spot instances can be up to 90% cheaper than on-demand,... og:url: https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x og:image: https://api.daily.dev/og/posts/QSaXz6E4X.png og:image:alt: Never Put a Pet on an AWS Spot Instance og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Never Put a Pet on an AWS Spot Instance **[DEV](https://daily.dev/sources/devto)** · 4 min read · 0 upvotes · 0 comments ## Summary An intern learned why AWS Spot instances were wrong for a stateful server during an internship task. Spot instances can be up to 90% cheaper than on-demand, but AWS can reclaim them with only a two-minute warning, and the attached disk is terminated by default. The server in question stored all its data locally with no separate database, making it a 'pet' rather than 'cattle' in DevOps terms. Instead of Spot, the team chose an on/off schedule with on-demand instances, paying only for storage while stopped, with Spot reconsidered once data moves off the server. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why shouldn't I use an AWS Spot instance for a server that stores data on its own disk Because Spot instances can be reclaimed by AWS with only a two-minute warning, and by default the attached disk is terminated along with the instance. If the server keeps all its data locally with no separate database or backup, an interruption means losing everything built up, not just a running process. Such a server is considered a 'pet' rather than 'cattle' and is a poor fit for Spot. _Weighing spot versus on-demand for a stateful workload is exactly the kind of tradeoff developers track on daily.dev._ ### how can I save money on an AWS on-demand instance without using spot Run the instance on an on/off schedule so it only runs when needed. With on-demand pricing, compute isn't billed while the instance is stopped, only a small charge applies for the attached disk, and stopping (rather than terminating) preserves the disk so no data is lost overnight. This approach keeps costs down for stateful servers that can't tolerate Spot's interruption risk. _daily.dev helps engineers compare cost-saving tactics like this before committing to an architecture._ ### what's the difference between pets and cattle in devops server management Cattle are interchangeable servers with no unique data, such as a web server behind a load balancer where real data lives in a separate database; if one dies, it's simply replaced. Pets are servers with their own identity and locally stored data, where losing one means losing something irreplaceable. Spot instances suit cattle workloads but are risky for pets. _Developers sorting infrastructure into pets versus cattle often refine that judgment by following real-world cases on daily.dev._ ## Similar posts on daily.dev - [Kubernetes Spot Instances: How to Cut Compute Costs Without Gambling on Reliability](https://daily.dev/posts/kubernetes-spot-instances-how-to-cut-compute-costs-without-gambling-on-reliability-izpc2uk55) · Cast AI · 0 upvotes · 0 comments - [Tier Your Apps, Cut Your Costs: A Practical Framework for Spot Instances in Production](https://daily.dev/posts/tier-your-apps-cut-your-costs-a-practical-framework-for-spot-instances-in-production-txov8fzqw) · Cast AI · 0 upvotes · 0 comments - [Why Your AWS EC2 Bill Keeps Growing — And How MicroVMs Can Help Reduce It](https://daily.dev/posts/why-your-aws-ec2-bill-keeps-growing-and-how-microvms-can-help-reduce-it-kfyj7xcaf) · Medium · 0 upvotes · 0 comments - [The History of Pets vs Cattle and How to Use the Analogy Properly](https://daily.dev/posts/the-history-of-pets-vs-cattle-and-how-to-use-the-analogy-properly-8ilo3fu91) · Programming Digest · 0 upvotes · 0 comments - [Should You Use Spot or On-Demand GPUs for Model Training?](https://daily.dev/posts/should-you-use-spot-or-on-demand-gpus-for-model-training--dedtodaf7) · DigitalOcean Community · 0 upvotes · 0 comments --- Tags: [#cloud](https://daily.dev/tags/cloud), [#aws](https://daily.dev/tags/aws), [#devops](https://daily.dev/tags/devops), [#finops](https://daily.dev/tags/finops) [View this post on daily.dev](https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Never Put a Pet on an AWS Spot Instance","url":"https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x"},"datePublished":"2026-10-27T22:38:55.291Z","dateModified":"2026-10-27T23:37:20.563Z","description":"An intern learned why AWS Spot instances were wrong for a stateful server during an internship task. Spot instances can be up to 90% cheaper than on-demand,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fe6f183ea69021c379a5711ced303a95?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fe6f183ea69021c379a5711ced303a95?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DEV","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DEV","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/devto","url":"https://daily.dev/sources/devto"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"cloud,aws,devops,finops","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DEV","item":"https://daily.dev/sources/devto"},{"@type":"ListItem","position":3,"name":"Never Put a Pet on an AWS Spot Instance"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/never-put-a-pet-on-an-aws-spot-instance-qsaxz6e4x#faq","mainEntity":[{"@type":"Question","name":"why shouldn't I use an AWS Spot instance for a server that stores data on its own disk","acceptedAnswer":{"@type":"Answer","text":"Because Spot instances can be reclaimed by AWS with only a two-minute warning, and by default the attached disk is terminated along with the instance. If the server keeps all its data locally with no separate database or backup, an interruption means losing everything built up, not just a running process. Such a server is considered a 'pet' rather than 'cattle' and is a poor fit for Spot. Weighing spot versus on-demand for a stateful workload is exactly the kind of tradeoff developers track on daily.dev."}},{"@type":"Question","name":"how can I save money on an AWS on-demand instance without using spot","acceptedAnswer":{"@type":"Answer","text":"Run the instance on an on/off schedule so it only runs when needed. With on-demand pricing, compute isn't billed while the instance is stopped, only a small charge applies for the attached disk, and stopping (rather than terminating) preserves the disk so no data is lost overnight. This approach keeps costs down for stateful servers that can't tolerate Spot's interruption risk. daily.dev helps engineers compare cost-saving tactics like this before committing to an architecture."}},{"@type":"Question","name":"what's the difference between pets and cattle in devops server management","acceptedAnswer":{"@type":"Answer","text":"Cattle are interchangeable servers with no unique data, such as a web server behind a load balancer where real data lives in a separate database; if one dies, it's simply replaced. Pets are servers with their own identity and locally stored data, where losing one means losing something irreplaceable. Spot instances suit cattle workloads but are risky for pets. Developers sorting infrastructure into pets versus cattle often refine that judgment by following real-world cases on daily.dev."}}]} ```