EC2 Checklist: 7 things to do after launching an instance
Launching an EC2 instance takes minutes. Keeping your virtual machines secure and maintaining your VMs is more work. In this blog post, I share seven things to do after launching a Linux, Windows, or macOS instance:
- Configure remote access with SSM Session Manager.
- Back up your data with AWS Backup.
- Install patches on a schedule with SSM Patch Manager.
- Configure the CloudWatch agent to ship logs, disk, and memory metrics to CloudWatch.
- Add CloudWatch alarms for alerting and instance recovery.
- Disable IMDSv1 to prevent a Capital One-like data breach.
- Schedule regular software scans to detect vulnerabilities with Inspector.
Do you prefer listening to a podcast episode over reading a blog post? Here you go!
Read on and learn to implement each best practice in your AWS account.
Gone are the days where we connected to virtual machines using SSH or RDP directly. AWS Systems Manager Session Manager allows you to connect to any EC2 instance without inbound network connectivity. All you need is the SSM agent1 (preinstalled on Amazon Linux, Amazon Linux 2, Ubuntu, macOS, and Windows Server) and access to the AWS API2.
You can use Session Manager in two ways:
- Connect to your EC2 instance directly from the AWS Console and get bash or PowerShell access.
- Forward any port (e.g., 3389 for RDP) from the EC2 instance to your local machine and connect to the local port. To connect to your Windows instance, forward the remote port
3389to a local port such as
13389and point your local RDP client to
localhost:13389. No security group changes are required to make it work! The EC2 instance needs only outbound access to the AWS API.
There are many reasons why you want to back up the disk of your virtual machine. Typical reasons are human error (configuration mistakes, accidental deletion of files) or hardware failure. AWS Backup takes care of creating backups on a schedule, removing them after a configurable period, and restoring them.
Warning: AWS Backup supports EBS volumes, not instance store volumes attached to EC2 instances. AWS Backup creates “crash consistent” backups for Linux and macOS (don’t back up a database this way!) Windows backups are “application consistent” by using VSS.
AWS Systems Manager Patch Manager applies patches during a configurable maintenance window (e.g., Sunday morning) and tracks and displays the installed patches for you. Configure a maintenance window and create a patching configuration.
SSM Patch Manager works with the following operating systems: Amazon Linux, Amazon Linux 2, CentOS, Debian Server, macOS, Oracle Linux, RHEL, SLES, Ubuntu Server, and Windows Server.
By default, the CPU utilization of your EC2 instance is reported to CloudWatch. Unfortunately, memory and disk utilization metrics are missing. I recommend streaming logs to a central system to make them searchable and securely archive them. AWS provides the CloudWatch agent to solve both tasks: metric and log collection. The following figure shows how metrics are reported.
Looking for a new challenge?
CloudWatch agent supports Amazon Linux, Amazon Linux 2, Ubuntu Server, CentOS, RHEL, Debian, SLES, Oracle Linux, macOS, Windows Server 2019, 2016, and 2012.
After sending memory and disk usage metrics to CloudWatch, it’s time to monitor all the metrics to alert you when the virtual machine is running at capacity. Monitor the following constrained resources with CloudWatch alarms:
One open question is what happens if the utilization reaches the predefined threshold? Out of the box, you can send an email. With AWS Chatbot, you can send a message in Slack. Or you use our chatbot marbot to configure monitoring, receive alerts, and solve incidents.
On top of that, a CloudWatch alarm monitors the
StatusCheckFailed_System metric to trigger a recovery action. Instance recovery moves the virtual machine to another hypervisor in case of hardware issues without changing the metadata (id, IP address, tags, …) of the EC2 instance.
IMDSv2 can improve EC2 security by making it harder to accidentally making the instance metadata service (IMDS) accessible from the public. IMDS can be used to obtain IAM credentials for the attached IAM role. AWS Foundational Security Best Practices recommends that EC2 instances use IMDSv2 (see control EC2.8). If you are interested in the details, read my Transition to IMDSv2 on EC2 - Introduction, Preparation, Pitfalls post. Otherwise, follow these steps to disable IMDSv1 and transition to IMDSv2.
Amazon Inspector is the service of choice to automatically check your EC2 instances for:
- Unintended network accessibility
- Deviations from best practices (such as CIS Amazon Linux 2 Benchmark).
Inspector relies on an agent to collect the needed information on your EC2 instances. Findings are presented in a table and include remediation hints, as the following screenshot shows.
Implementing the best practices after launching an EC2 instance is time-consuming and error-prone. If you are interested in automating the work, check out our CloudFormation templates. They include all best practices except AWS Inspector. You can use a CloudFormation template to spin up hundreds of EC2 instances without any manual work. You can find the source code on GitHub.
Launching an EC2 instance takes minutes. With the correct settings, you can securely run your virtual machines without much ongoing effort. Keep in mind that some settings can not be changed after instance launch and are therefore not in the scope of this blog post. E.g., EBS volume encryption or the VPC subnet. I have also not included the obvious candidates, such as security group rules and the IAM policies of the attached IAM role.
- 1. Installation instructions can be found here https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html ↩
- 2. In private VPCs, you need to add VPC endpoints for
ssmmessages: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-systems-manager-vpc-endpoints/ ↩