In this first part of a two-part series, we explore how to enable high availability (HA) of Amazon EC2 instances on AWS Outposts servers. We’ll discuss detailed instructions, code samples, and considerations for automating Amazon EC2 instance relaunch on Outposts servers, with a focus on stateless applications. The second part of this series will delve into the specifics of stateful applications where EC2 instance store states need to be maintained during relaunch.
In this guide, we’ll show you how AWS deployment works, particularly when using Gigabits Cloud services to streamline the process.
Introduction of Amazon EC2 on AWS Outposts
AWS Outposts servers offer an ideal solution for low-latency, on-premises compute and networking services. These services are especially beneficial for environments like retail stores, branch offices, healthcare locations, or any other space-constrained environments. Outposts servers provide non-durable EC2 instance store storage, which is typically sufficient for stateless workloads. However, many application owners still require high uptime for these types of workloads.
In this post, you will learn how to set up and implement custom logic that ensures high availability for Amazon EC2 Instances on AWS Outposts Servers running stateless applications. By using two or more Outposts servers, you can achieve N+1 fault tolerance. The solution uses AWS CloudFormation, AWS Lambda, and Amazon CloudWatch for automation.
Solution Overview
The core of this solution is a Python script, init.py, that customizes an AWS CloudFormation template to enable EC2 instance relaunch in the event of a failure. This process tailors specifically for stateless applications, though you can modify the logic to suit other use cases. The following parameters are required to run the init.py script:
Launch template ID(s): Used to relaunch EC2 instances on the destination Outposts server if the source server fails.
Source Outpost ID: The Outpost ID of the server currently running the EC2 workload.
Template File: The base CloudFormation template file. The script customizes it based on the inputs provided.
Stack Name: The name you want to give your CloudFormation stack.
Region: The AWS region to which your Outposts servers are anchored.
Notification Email: The email that Amazon SNS uses to send alerts in case of a failure.
Launch Template Description: A description for the launch template used to relaunch the EC2 instances.
Once these parameters are provided, the script generates and deploys the CloudFormation stack in your AWS account. You will also receive a confirmation email once your SNS subscription is active.
Gigabits Cloud helps organizations leverage AWS by offering pre-configured AMIs (Amazon Machine Images) for seamless deployment of open-source software such as LAMP, WordPress, and more. These images are specifically designed to minimize setup time and maximize scalability.
Architecture Diagram
The architecture works by mapping a source Outposts server to a destination Outposts server, ensuring high availability. In the event of a failure, the system automatically relaunches the EC2 instances running on the source server to the destination server. If both servers become unavailable at the same time, you need to intervene.
How the Solution Works
Once you deploy the CloudFormation stack, the solution integrates several AWS services for high availability and automation:
- CloudWatch Alarm: Monitors the ConnectedStatus metric of the source Outposts server.
- Amazon SNS (Simple Notification Service): Sends alerts when the ConnectedStatus metric indicates a failure on the source Outposts server.
- AWS Lambda Function: Triggers the EC2 relaunch process on the destination Outposts server based on the parameters provided in the launch template.
If the ConnectedStatus of the source Outposts server shows as “down,” the Lambda function will relaunch the EC2 instances on the destination server, ensuring minimal downtime for the application.
Prerequisites
Before beginning, ensure the following prerequisites are met:
Python: You’ll need Python to run the init.py script, which dynamically creates the CloudFormation stack. Make sure your Python environment is set up and ready.
Outposts Servers: You need at least two Outposts servers, configured either in an active/active or active/passive setup, depending on your workload size.
Launch Templates: Create Launch Templates for your applications, ensuring that the instance types are compatible and available on the destination Outposts server.
AWS Credentials: You’ll need appropriate permissions to deploy the CloudFormation stack in your AWS account and interact with the necessary resources.
CloudWatch Cross-Account Observability: If you’re using an Outposts consumer account, set up cross-account observability to track Outposts metrics.
ec2-outposts-autorestart Repository: Download the repository containing the scripts and resources for automating your Outposts environment.
It’s important to keep your Python environment and repository up-to-date, and to test the setup in a staging environment before deploying to production. Additionally, consider setting up monitoring tools to gain insights into your infrastructure’s performance and health, helping prevent potential issues.
Step-by-Step Deployment of the Auto-Relaunch CloudFormation Stack
For this post, I created a virtual private cloud (VPC) named “Production-Application-A” and subnets on the two Outposts servers, “source-outpost-a” and “destination-outpost-b.” I supplied the destination-outpost-b subnet in the launch template used for this walkthrough.
Make sure that you are in the directory that contains the init.py and AutoRestartTemplate.yaml files. Next, run the following command to execute the init.py file. Note that you may need to change the file permissions to do this. If so, then run “chmod a+x init.py” to give all users execute permissions for this file:
./init.py --launch-template-id <value> --source-outpost-id <value> --template-file AutoRestartTemplate.yaml --stack-name <value> --region <value> --notification-email <value>After executing the preceding command, the init.py script asks you for a launch template description. Provide a brief description for the launch template that describes to which application it correlates. After that, theinit.py script customizes the AutoRestartTemplate.yaml file using the parameter values you entered, and the content of the file is displayed in the terminal for you to verify before confirming everything looks correct.
After verifying the AutoRestartTemplate.yaml file looks correct, enter ‘y’ to confirm. Then, the script deploys a CloudFormation stack in your AWS account using the AutoRestartTemplate.yaml file as its template. It takes a few moments for the stack to deploy, after which it is visible in your AWS account under your CloudFormation console.
Verifying the CloudFormation Stack and Email Notifications
Verify the CloudFormation stack is visible in your AWS account.
You receive an email asking you to confirm your subscription to the SNS topic created for your CloudWatch alarm. This alarm monitors your Outposts server’s ConnectedStatus metric. This is a crucial step—if you don’t confirm your SNS topic subscription for this alarm, you won’t receive a notification if your source Outposts server experiences a hardware or service link failure, and you won’t use this relaunch logic.
Once you have confirmed your email address, the implementation of this Amazon EC2 Auto-Relaunch logic is now complete, and in the event of a service link or source Outposts server failure, your EC2 instances now automatically relaunch on the destination Outposts server subnet you supplied as a parameter in your launch template. You also receive an email notifying you that your source Outpost went down and a relaunch event occurred.
I simulate a service link failure on the source-outpost-a server for the purpose of this post. Within a minute or so of the CloudWatch alarm triggering, you receive an email alert from the SNS topic you subscribed to earlier in the post. The email alert looks like the following image:
After receiving this alert, you can navigate to your EC2 Dashboard and view your running instances. There you should see a new instance being launched. It takes a minute or two to finish initializing before showing that both status checks passed:
Now that your EC2 instance(s) have relaunched on your healthy destination Outposts server, you can start triaging the cause of the failure on your source Outposts server. You no longer need to worry about getting your application(s) back up and running.
Clean-Up Process for Amazon EC2 Instances on AWS Outposts Servers
To remove the solution, simply delete the CloudFormation stack from your AWS account. This will delete all resources created through the stack, including the CloudWatch alarm, Lambda function, and SNS topic.
Conclusion Amazon EC2 Instances on AWS Outposts Servers
By implementing this custom logic using AWS CloudFormation, AWS CloudWatch, and AWS Lambda, you can ensure high availability for Amazon EC2 Instances on AWS Outposts Servers running stateless applications. This solution automates the process of relaunching EC2 instances on a secondary Outposts server in case of a hardware or service link failure, significantly reducing application downtime.
Although this tutorial addresses stateless workloads, you can modify the solution for stateful applications as well. In Part 2 of this series, we will focus on enabling high availability for stateful workloads, ensuring that the EC2 instance store state is maintained during the relaunch.
To ensure your solution is reliable, we recommend running regular failure drills to test the relaunch process and ensure it works as expected.
If you’re ready to start your AWS deployment, visit Gigabits Cloud and explore the wide range of services they offer. Their easy-to-use tools and optimized AMIs make getting started with cloud computing simpler than ever.
FAQs
1. How does the EC2 relaunch process work in the event of a failure?
When the ConnectedStatus metric of the source Outposts server goes down, the Lambda function triggers the relaunch of the EC2 instances on the destination Outposts server using the specified launch template.
How can I get support for my AWS deployment?
Gigabits Cloud offers 24/7 support to assist with any issues or questions during the deployment process.
3. How do I monitor the health of my Outposts server?
You can monitor the health of your Outposts server using Amazon CloudWatch, which tracks metrics such as ConnectedStatus to detect hardware or service link failures.
4. What happens if both Outposts servers fail simultaneously?
If both the source and destination Outposts servers fail at the same time, you will need to manually intervene. An SNS notification will alert you of the failure, and you can take necessary action to resolve the issue.
5. How can I clean up the resources after the setup?
To clean up, simply delete the CloudFormation stack from your AWS account. This will automatically remove all the resources created during the deployment process.
