Start/Stop Automation: Pay Only For What You Use
Start/stop automation is like putting your cloud resources on a timer to save money. It's essential for non-production environments like dev and staging used only during business hours.
WHY IT EXISTS: Cloud providers bill for running resources, even if they're idle. Many environments, especially for development and testing, are only used for 8-10 hours a day, 5 days a week. Leaving them on 24/7 means paying for over 100 hours of idle time per week, which can account for over 70% of the bill for those resources.
THE MENTAL MODEL: Think of it as an automatic light switch for your cloud infrastructure. You wouldn't leave every light in an office building on 24/7. You put them on timers or motion sensors. Start/stop automation does the same for your virtual machines and databases, turning them off when no one is "in the office" to save on your cloud bill.
HOW IT WORKS: You tag your cloud resources (e.g., VMs, databases) with a specific schedule name, like "uk-office-hours". A central scheduling service, like AWS Instance Scheduler or Azure Automation, runs on a timer. It scans for resources with schedule tags. If the current time falls within the "stop" period for a resource's schedule, the service issues a 'stop' API call. When the "start" period begins, it issues a 'start' call. Schedules are often defined using cron-like expressions and must handle timezones carefully.
WHEN TO USE IT: This is a must-have for non-production environments like development, testing, and staging. It's also useful for batch processing workloads that only need to run for a few hours a day, or for demo environments that are only spun up for specific presentations.
WHEN NOT TO USE IT: Do not apply this to production services that require 24/7 uptime. Also, avoid it for stateful applications that cannot tolerate being shut down or that take a very long time to restart. For example, a database with a massive in-memory cache might perform poorly for a long time after each startup, negating the cost savings with poor performance.
ONE CANONICAL EXAMPLE: A development team has 20 EC2 instances for their work. Using AWS Instance Scheduler, they tag these instances with Schedule=uk-office-hours. They define this schedule to run from 9:00 AM to 6:00 PM, Monday to Friday, in the Europe/London timezone. The scheduler automatically stops the instances at 6:01 PM and starts them at 8:59 AM, reducing their EC2 costs for these instances by roughly 70%.
Read the original → docs.aws.amazon.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.