Skip to main content

Guidance for Managing EC2 Instance Expiration on AWS

Overview

This Guidance shows how to terminate Amazon Elastic Compute Cloud (Amazon EC2) instances based on expiration values defined in their tags. For example, you can stop an instance a specified number of hours after its launch time or at an exact date and time. These settings let you prevent ephemeral instances (such as build agent machines) from existing beyond their expected use. You can also preset development instances to automatically terminate at a future time or terminate an instance that has failed to continuously reset its own watchdog tag. This helps you to avoid running unnecessary compute.

How it works

These technical details feature an architecture diagram to illustrate how to effectively use this solution. The architecture diagram shows the key components and their interactions, providing an overview of the architecture's structure and functionality step-by-step.

Deploy with confidence

Ready to deploy? Review the sample code on GitHub for detailed deployment instructions to deploy as-is or customize to fit your needs. 

Go to sample code

Well-Architected Pillars

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

The Guidance sends events to an EventBridge event bus and provides a rule that matches those events. You can also add an Amazon SNS topic as a target to the rule. These aspects provide visibility into actions and let you integrate the actions with downstream systems to produce notifications or enable additional automation. Additionally, this Guidance supports decoupled integration with other systems. Finally, CloudWatch monitors the infrastructure and provides logs and metrics that aid troubleshooting of potential issues.

Read the Operational Excellence whitepaper

AWS Identity and Access Management (IAM) lets you set up granular permission policies and short-lived access through roles (rather than hard-coded credentials). By using IAM policies to implement the principle of least privilege for the Lambda function used in this Guidance, you can limit unauthorized access.

Read the Security whitepaper

This Guidance uses an Amazon SQS queue between event sources and the Lambda function that consumes those events. This enables Lambda to perform retries without event loss in the case of failure. Additionally, EventBridge is a fully managed and internally resilient service that helps you avoid any single point of failure.

Read the Reliability whitepaper

This Guidance uses event-driven services like EventBridge, Amazon SQS, and Lambda. This supports asynchronous, responsive behavior so that the solution can react and implement actions promptly. For example, Amazon EC2 instances stop (or terminate) within low-single-digit seconds of their scheduled expiration. This is more effective than a polling-based design, which would check instances for expiration at set intervals, resulting in imprecise implementation.

Read the Performance Efficiency whitepaper

EventBridge, Amazon SQS, and Lambda provide a pay-as-you-go pricing model, meaning you pay only for resources used. Because this solution remains idle for extended periods, these cost-elastic services offer significant savings by eliminating compute costs during times of inactivity.

Read the Cost Optimization whitepaper

This Guidance uses services that support event-driven, asynchronous, and intermittent behaviors. For example, Lambda only uses compute resources when necessary. And as a shared service, Amazon SQS does not dedicate compute to this Guidance specifically. These aspects make this solution resource efficient, supporting sustainability.

Read the Sustainability whitepaper

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.