Amazon Elastic Compute Cloud (Amazon EC2) Spot Cases supply vital price financial savings of as much as 90% in comparison with On-Demand pricing, making them engaging for cost-conscious workloads. Nevertheless, when utilizing Spot Cases inside AWS Auto Scaling Teams (ASGs), their unpredictable interruptions create operational challenges. With out correct visibility into interruption patterns, groups battle to optimize capability planning, implement efficient fallback mechanisms, and make knowledgeable choices about workload placement throughout availability zones and occasion varieties.
This problem might be addressed by a customized event-driven monitoring and analytics dashboard that gives close to real-time visibility into Spot Occasion interruptions particularly for ASG-managed cases. For the rest of this doc, we’ll seek advice from this practice resolution as “Spot Interruption Insights” for Auto Scaling Teams.
On this submit, you’ll discover ways to construct this complete monitoring resolution step-by-step. You’ll acquire sensible expertise designing an event-driven pipeline, implementing knowledge processing workflows, and creating insightful dashboards that assist you observe interruption traits, optimize ASG configurations, and enhance the resilience of your Spot Occasion workloads.
Answer overview
The structure makes use of an event-driven strategy using AWS native providers for sturdy spot occasion interruption monitoring.
The answer makes use of Amazon EventBridge to seize interruption occasions, Amazon Easy Queue Service (Amazon SQS) for dependable message queuing, AWS Lambda for knowledge processing, and Amazon OpenSearch Service for storage and visualization of interruption patterns.

- EC2 Spot interruption notices are captured through an Amazon EventBridge rule.
- The notices are routed to an SQS queue for dependable message dealing with.
- A Lambda perform processes the occasions, fetching EC2 occasion metadata and AWS Auto Scaling Group (ASG) particulars by making optimized batch calls to the EC2 and Auto Scaling APIs. This design minimizes throttling dangers on the management airplane APIs, guaranteeing scalability. The Lambda perform is configured with batching and concurrency limits to stop overwhelming the API endpoints and the OpenSearch Service bulk indexing course of.
- After processing, occasions are bulk-indexed into Amazon OpenSearch Service, enabling close to real-time visibility and analytics.
A Lifeless Letter Queue (DLQ) ensures no knowledge is misplaced in case of failures, whereas AWS Id and Entry Administration (IAM) roles implement least-privilege entry between all parts.
The OpenSearch Service area is deployed inside the non-public subnets of an Amazon VPC, guaranteeing it’s not publicly accessible.
- Entry to OpenSearch Dashboards is routed by an Software Load Balancer (ALB) configured with an HTTPS listener,
- ALB forwards visitors to an NGINX proxy operating on EC2 cases in an Auto Scaling group. This setup supplies safe and scalable entry.
- Authentication and authorization are enforced utilizing OpenSearch Service’s inner consumer database, guaranteeing that solely licensed customers can entry the dashboards.
OpenSearch Dashboards visualize interruption metrics, delivering actionable insights to assist efficient capability planning and workload placement.
Extensibility and various analytics instruments
Whereas this resolution makes use of Amazon OpenSearch Service for storing and visualizing Spot Interruption knowledge, the structure is versatile and might be prolonged to assist different analytics and observability platforms. You possibly can modify the Lambda perform to ahead knowledge to instruments equivalent to Amazon Fast Sight, Amazon Timestream, Amazon Redshift, or exterior providers relying in your analytics and compliance wants. This allows groups to make use of their most popular tooling for constructing visualizations, setting alerts, or integrating with present dashboards.
What you’ll construct
By the top of this submit, you’ll have an entire Spot Interruption monitoring system as seen within the following screenshot that mechanically captures EC2 Spot Occasion interruption occasions out of your Auto Scaling Teams and presents them by interactive dashboards. Your resolution will embrace real-time visualizations exhibiting interruption patterns by availability zone, occasion varieties, and time intervals, together with ASG-specific metrics that assist you determine optimization alternatives.

The sections of this submit stroll you thru the step-by-step implementation of this resolution, from deployment to organising the event-driven structure to configuring the analytics dashboards. Bear in mind that you may deploy and customise this resolution on your setting.
Stipulations
You will need to have entry to an AWS account with sufficient privileges to create and handle the AWS assets mentioned on this weblog submit.You will need to even have the next software program/parts put in in your machine:
Word: This software makes use of a number of AWS providers, and there are related prices past the Free Tier utilization. Confer with the AWS Pricing web page for particular particulars. You’re accountable for any incurred AWS prices. This instance resolution doesn’t suggest any guarantee.
Deployment directions
Create a brand new listing, navigate to that listing in a terminal and clone the GitHub repository:
Change listing to the answer listing:
Guidelines for deployment
This part lists the setup and configurations which can be required earlier than you deploy the answer stack by utilizing AWS SAM.
When you don’t have a VPC, Subnets, NAT Gateway already created and configured you possibly can observe the steps talked about in the Amazon VPC documentation to create the mandatory assets.
- VPC Created – Guarantee a VPC exists with DNS hostnames and DNS decision enabled. You will have the VPC ID throughout deployment
- Public Subnets (2 or extra) – Configure two or extra public subnet IDs from totally different Availability Zones.
- Personal Subnets (2 or extra) – Configure two or extra non-public subnet IDs from totally different Availability Zones.
- Outbound Web Entry for Personal Subnets – Guarantee NAT Gateway entry as nginx proxy can be put in on EC2 occasion in non-public subnet. Confer with Instance: VPC with servers in non-public subnets and NAT for extra info on organising NAT for cases in non-public subnets.
- ALB Entry – CIDR IP vary allowed to entry ALB (equivalent to,
`1.2.3.4/32`). That is for accessing the dashboard. - Certificates ARN for ALB HTTPS Listener – To configure HTTPS listener. Certificates (might be self-signed) for HTTPS port of the load balancer. Confer with Stipulations for importing ACM certificates for extra info on importing self-signed certificates into AWS Certificates Supervisor (ACM)
- OpenSearch Service-Linked Function – Earlier than deploying this template, make sure the AWS OpenSearch service-linked position exists in your account by operating:
Word:
- This command solely must be run as soon as per AWS account.
- If the position already exists, you’ll see an error message that may be safely ignored.
- This position permits Amazon OpenSearch Service to handle community interfaces in your VPC.
- With out this position, deployments that place OpenSearch Service domains in a VPC will fail with the error: “Earlier than you possibly can proceed, it’s essential to allow a service-linked position to offer Amazon OpenSearch Service permissions to entry your VPC.”
- The service-linked position is called
"AWSServiceRoleForAmazonOpenSearchService"and is managed by AWS.
- AMIId – Legitimate EC2 AMI ID for the area. Word:- This resolution is designed to work solely with AMIs that use the DNF bundle supervisor. Use the newest Amazon Linux 2023 AMI for optimum compatibility and safety.
The next AMIs are confirmed appropriate with this resolution:
- Amazon Linux 2023
- Fedora (35 and newer)
- RHEL 8 and newer
- CentOS Stream 8 and newer
- Oracle Linux 8 and newer
Construct and deploy the answer – From the command line, use AWS SAM to construct and deploy the AWS assets as specified within the template.yml file.
In the course of the prompts: Fill-out the next parameters:
- Stack Title: {Enter your most popular stack identify}
- AWS Area: {Enter your most popular area code}
- Parameter DomainName: {Enter the identify on your new OpenSearch Service area the place the index can be created and knowledge can be pushed for analytics. It will create a brand new OpenSearch area with the identify you specify – Ideally preserve quick area identify}
- MasterUsername: {Admin username to login to the OpenSearch dashboard}
- MasterUserPassword: { Should include lowercase, uppercase, numbers, and particular characters (!@#$%^&*). Minimal 12 characters really helpful. Keep away from widespread passwords (Password123!, Admin@2024 and extra) as these could trigger deployment failures because of safety validation checks.}
- IndexName: {OpenSearch Index identify the place Spot interrupted occasion associated knowledge can be pushed}
- EventRuleName: {Amazon EventBridge rule identify to seize EC2 Spot interruption notices}
- CustomEventRuleName: {Amazon EventBridge customized rule identify to seize EC2 Spot interruption notices. This can be used for verifying the answer}
- TargetQueueName: {EventBridge Rule goal SQS identify}
- SQSDLQQueueName: {Goal SQS Lifeless Letter Queue identify}
- LambdaDLQQueueName: {Lambda Lifeless Letter Queue identify}
- VPCId: {Enter the VPCId the place the assets can be deployed}
- PublicSubnetIds: {Enter 2 or extra Public SubnetIDs separated by comma}
- PrivateSubnetIds: {Enter 2 or extra Personal SubnetIDs separated by comma}
- RestrictedIPCidr: {IP deal with/CIDR for limiting ALB entry in CIDR format (equivalent to
10.2.3.4/32)} - CertificateArn: {Certificates ARN for configuring ALB HTTPS Listener}
- AMIId: {Legitimate EC2 AMI ID for the area}
- Verify adjustments earlier than deploy: Y
- Enable SAM CLI IAM position creation: Y
- Disable rollback: N
- Save arguments to configuration file: Y
- SAM configuration file: {Press enter to make use of default identify}
- SAM configuration setting: {Press enter to make use of default identify}
Word: The entire resolution could take roughly 15-20 minutes to deploy. After the deployment is full, there are just a few handbook steps that must be carried out to make sure the answer capabilities as anticipated.
Submit deployment directions
The next steps must be carried out in OpenSearch Dashboards after logging in. Get the DNS Title of the Software Load Balancer endpoint from the deployment output part of the CloudFormation stack or the ALB console. Entry the OpenSearch dashboards utilizing the ALB DNS identify as follows –
You’ll be redirected to the OpenSearch Dashboards login web page. Log in utilizing the MasterUsername and MasterUserPassword you specified throughout deployment.
If that is the primary time you might be logging in then you might even see a Welcome display.
- Select ‘Discover by myself’ on the Welcome display.
- Select ‘Dismiss’ on the subsequent display.
- If the ‘Choose your tenant’ dialog seems with ‘International’ preselected, Select ‘Verify’. In any other case, choose ‘International’ first after which and select ‘Verify’.
Create index and attribute mapping
This part lists the required steps to create the index and attribute mapping.
- On the Residence display choose the Hamburger Menu icon (
) on the highest left - Choose ‘Dev Instruments’ on the backside of the menu.
- On the dev instruments console, paste the next PUT command and execute the request by selecting ‘Click on to ship request’.
Word The index identify ought to match what you entered throughout the deployment. Change the index identify accordingly earlier than creating the index.
The next is a screenshot of this command in Dev Instruments.

- Verify that the index was created efficiently.

Create index sample
This part lists the required steps to create the index sample
- Entry the Hamburger Menu icon on the highest left.
- Choose ‘Dashboard Administration’ from the underside of the menu.
- Select ‘Index Patterns’
- Select “Create Index Sample”

- Enter the Index sample identify and select “Subsequent step”.
The index sample identify must be the index identify you entered throughout the deployment adopted by an asterisk. See the next screenshot for reference.
- Choose ‘timestamp’ in main Time discipline and select ‘Create index sample’

- Select the star icon to make the index sample default

Configure Lambda with required entry for brand spanking new index
On this part you’ll create a job in OpenSearch Service dashboards and can map Lambda execution position to the identical to carry out operations on the brand new index.
- Navigate to the Lambda console
- Seek for the perform starting along with your OpenSearch Service area identify.
- Within the perform particulars, go to Configuration > Permissions
- Select the Function Title within the Execution Function part.
- Copy the Lambda execution position ARN from this perform which handles Spot interruption occasions.
- Entry the Hamburger Menu icon on the highest left and choose ‘Safety’ from the underside of the menu.
- Now choose the ‘Roles’ menu possibility below ‘Safety’ menu after which choose ‘Create Function’
- Enter a job identify and set Cluster Permissions to “cluster_composite_ops_ro“.
- For Index Permissions, choose the index sample identify created throughout deployment.
See the next screenshot for reference.

- Set the Tenant Permissions to “global_tenant” as seen within the picture and Select “Create”.

- After the position is created, on the identical display, choose the ‘Mapped Customers’ tab and select ‘Handle Mapping’

- Select ‘Handle Mapping’
- Within the ‘Backend roles’ add the Lambda execution position ARN copied earlier and Select ‘Map’

You possibly can create extra customers within the inner database and grant acceptable entry to the visualisations and dashboards. The next steps present how one can create a learn solely position and to create an inner consumer and grant learn solely entry.
Handle customers and roles
On this part you’ll create a brand new consumer and a job with read-only entry, then assign the position to the consumer to grant them read-only entry to the Spot Interruption dashboard and visualizations.
- Entry the Hamburger Menu icon on the highest left
- Choose ‘Safety’ from the underside of the menu
- Choose ‘Inside Customers’ after which choose ‘Create Inside consumer’

- Enter username and set a Password, then select “Create”.

- Now choose the ‘Roles’ menu possibility below ‘Safety’ menu after which choose ‘Create Function’
- Enter the position identify and set Cluster Permissions to “cluster_composite_ops_ro“.
- For Index Permissions, choose the index sample identify created throughout deployment.
See the next screenshot for reference.

- Set the Tenant Permissions to “global_tenant” as seen within the picture and Select “Create”.

- After the position is created, on the identical display, choose the ‘Mapped Customers’ tab and select ‘Handle Mapping’

- Choose the consumer created above in ‘Customers’ and select ‘Map’

Configure and deploy pattern visualisations and dashboard
Pattern visualizations and a starter dashboard are offered below the information folder of the git repo you cloned earlier. Search for the file named spot-interruption-dashboard-visualisations.ndjson.To import the visualizations:
- Navigate to Saved Objects below Dashboard Administration in OpenSearch Dashboards.
- Import the
spot-interruption-dashboard-visualisations.ndjsonfile. - In the course of the import, you might encounter index sample conflicts. Choose the index sample you created from the dropdown and select “Verify all adjustments”.

As soon as imported, the pattern visualizations and dashboard linked to your index sample can be obtainable below Dashboards within the left-side hamburger menu. You possibly can view the Spot Interruption Dashboard, which incorporates visualizations primarily based on Availability Zones, Areas, Occasion Varieties, Auto Scaling Teams (ASGs), and Interruptions over time. You possibly can additional customise by creating your personal visualizations utilizing the attributes obtainable within the index or by modifying/creating new dashboards. The dashboard will show empty views till Spot interruption knowledge is offered to visualise.
Check the answer
A brief occasion rule was created throughout deployment to simulate matching Amazon EC2 Spot interruption notices. The rule identify is the identify you specified throughout deployment for the CustomEventRuleName parameter.
To confirm the answer, you possibly can ship pattern occasions from the EventBridge console as depicted beneath. Within the AWS console,
After the occasion is shipped efficiently, you possibly can log in to OpenSearch Dashboards and think about the Spot Interruption Dashboard, which has been prebuilt with the listed occasion knowledge. This dashboard supplies insights throughout key dimensions equivalent to Availability Zones, Areas, occasion varieties, Auto Scaling teams, and interruption traits over time. Use the dashboard as a place to begin to know the sorts of insights doable and customise or create new visualizations primarily based in your wants and the fields obtainable within the index.
Alternatively, you possibly can navigate to the Uncover part within the menu to view the uncooked occasion particulars. Make sure that you choose the index sample you created earlier on this demonstration, and regulate the time vary if mandatory (such because the final quarter-hour) to view the newest knowledge.
Safety and price optimizations
This resolution is designed to be safe and cost-efficient by default, however there are some extra optimizations you possibly can apply to additional scale back price and improve safety:
Safety greatest practices
- Amazon Cognito Authentication : Combine Amazon Cognito with OpenSearch Dashboards to handle consumer authentication, allow Multi Issue Authentication, and keep away from hardcoding admin credentials. Extra info Configuring Amazon Cognito authentication for OpenSearch Dashboards
- Lambda Layer Versioning: Guarantee pinned variations of Lambda Layers are used to keep away from sudden adjustments. Extra info Managing Lambda dependencies with layers
- Logging and Menace Detection: Allow AWS CloudTrail and Amazon GuardDuty to observe for unauthorized exercise or anomalies. Extra info Monitoring Amazon OpenSearch Service API calls with AWS CloudTrail
Value optimizations
- Bulk Indexing with Throttling Controls: Lambda processes batches and respects throttling limits to keep away from extreme OpenSearch utilization.
- Quick Retention for CloudWatch Logs: Tune log retention intervals to keep away from pointless storage prices.
- Optimize Visualizations: Design saved visualizations to keep away from costly queries (like huge time ranges and enormous aggregations). Extra info Optimizing question efficiency for Amazon OpenSearch Service knowledge sources
- Index State Administration (ISM) : Configure ISM insurance policies in OpenSearch to delete or archive older interruption knowledge. Extra info Index State Administration in Amazon OpenSearch Service
Cleanup
Run the next command to delete the assets deployed earlier.
After deleting the stack, ensure to additionally take away any post-deployment configurations you will have created inside the OpenSearch Service dashboards console. Whereas these configurations gained’t incur further prices, it’s thought-about a greatest follow to wash up your setting by deleting any assets which can be not wanted. Take a while to assessment the OpenSearch Service dashboards and determine any customized settings, dashboards, or visualizations you arrange throughout the deployment course of. Then, delete these particular person configurations to make sure your setting is absolutely cleaned up.
Conclusion
On this submit, you discovered how one can construct and deploy a complete Spot Occasion interruption monitoring resolution for Auto Scaling teams by utilizing EventBridge, Amazon SQS, Lambda, and OpenSearch Service. You carried out an event-driven pipeline to seize and course of Amazon EC2 Spot Occasion interruption occasions, created safe analytics dashboards, and established real-time visibility into interruption patterns throughout your Auto Scaling group–managed workloads.
This submit’s resolution empowers your groups with the visibility and agility wanted to function confidently with Amazon EC2 Spot Cases. By combining event-driven structure with safe, scalable analytics, now you can proactively monitor interruption occasions, determine interruption traits, and optimize workload methods for resilience and cost-efficiency.
With real-time knowledge at your fingertips, you’re geared up to make smarter infrastructure choices and maximize the advantages of Spot Occasion capability whereas minimizing disruption dangers.

















