AWS administrators have several ways to launch an EC2 instance. For reliable, automated and consistent launches, many use the AWS Command Line Interface.
Users might choose the AWS CLI over the AWS Console because it is a scalable way to launch cloud resources. The AWS CLI also involves far less manual work than the Console to create and initiate an EC2 instance. Users, however, might experience a learning curve going from the GUI-based AWS Console to commands.
In this step-by-step tutorial, learn how to use the AWS CLI to launch EC2 instances. It covers the initial setup for the AWS CLI environment, the minimum parameters required to launch an instance and additional important parameters commonly used in AWS deployments.
Step 1. Set up the scripting environment
To start, install the CLI components. Refer to AWS' documentation for the latest commands, locations of packages and dependencies you need to install the AWS CLI in Linux, Apple MacOS and Windows operating systems.
Next, ensure that the right permissions are configured in the environment where you will execute CLI commands. For the AWS CLI, AWS credentials are stored in the $HOME/.aws/credentials file. You can include AWS credentials in environment variables or in the command itself, but that creates security vulnerabilities. Instead, configure those credentials in a local file. If running commands from an EC2 instance, configure an AWS Identity and Access Management (IAM) instance profile so you do not need to configure credentials internally.
To follow this tutorial, the IAM user configured in the credentials file needs sufficient permissions to start EC2 instances and write permissions related to EC2. For example, the user must be able to create AWS security groups and Elastic Block Storage (EBS) volumes. Attach the AmazonEC2FullAccess IAM policy to the user to ensure they can complete the steps required.
The AWS Region is an essential parameter to configure in the CLI. Use the file $HOME/.aws/config. You can also specify a region by setting the AWS_REGION environment variable or passing the parameter –region in the AWS CLI.
Step 2. Establish minimum parameters for the EC2 instance
You need the following parameters to launch an EC2 instance:
- The AMI ID to launch the instance.
- The EC2 instance type, which must be compatible with the AMI ID.
- The VPC ID and Subnet ID where the instance will launch.
- A security group ID to assign to the instance. If you are creating a new security group, do so before you launch the EC2 instance.
- The EC2 key pair name. Without it, users cannot secure shell into the EC2 instance or access it through Windows Remote Desktop.
Use the AMI Catalog screen in the EC2 Console to select an Amazon Machine Image. It shows the available AMIs for a particular region. Filter available AMIs by parameters such as OS, Architecture, AWS Marketplace Publisher, Pricing Model and Private AMIs. Note the relevant AMI IDs now -- the AMI IDs for scenarios where you plan to use the AWS CLI -- to avoid visiting this page each time you launch a new EC2 instance.
This tutorial assumes certain aspects of the EC2 configuration already exist. It does not cover how to create a new VPC or Subnet, security group or EC2 key pair.
To create the EC2 instance in the AWS CLI with the minimum recommended set of parameters, use the following commands:
aws ec2 run-instances \ --image-id <ami-id> \ --instance-type <instance-type> \ --subnet-id <subnet-id> \ --security-group-ids <security-group-id> <security-group-id> … \ --key-name <ec2-key-pair-name>
Step 3. Configure the instance with additional important parameters
The CLI command that launches an EC2 instance has 40 different parameters. In addition to the bare minimum parameters, consider specifying these others to enhance security, tailor the EC2 instance to the application, increase reliability and achieve other goals.
- BlockDeviceMappings. The default root volume value for an AWS Linux AMI is 8 GB. For a Windows AMI it is 30 GB. These capacities might not be enough for the intended application. Custom AMIs have a default EBS volume allocation as well. Use the BlockDeviceMappings parameter to allocate more EBS space than provided in the AMI by default.
- Monitoring. For enhanced monitoring, use the Monitoring parameter. It provides metric data in one-minute intervals, instead of the default five minutes. Shorter intervals enable faster response to health events and more efficient troubleshooting when analyzing metrics.
- UserData. If the EC2 instance should start some processes at launch, use the UserData parameter to set them up. For example, an instance can start application-specific processes for Apache or Nginx, or update application configuration files. This parameter enables flexibility and automation in the EC2 instance launch process.
- DisableApiTermination. If the EC2 instance will store critical data or perform a critical task, set this parameter to true to prevent accidental termination through the AWS Console or the CLI.
- IamInstanceProfile. Assigning an IAM instance profile is a security best practice when you create a new EC2 instance. It eliminates the need to configure AWS credentials in files or environment variables inside the instance. Configure this parameter at instance launch.
- TagSpecifications. Applying tags to AWS resources is a best practice to manage infrastructure in the long term. This parameter tags the EC2 instance appropriately. At minimum, set the Name tag to make it easy to find the EC2 instance in the Console.
- LaunchTemplate. Launch templates standardize the launch of EC2 instances by preconfiguring the AMI, instance type, volume configuration, security groups and other parameters. If launch templates are already configured for the AWS deployment, set this parameter to simplify configuration tasks for instance launch through the CLI.
- Count. The Count parameter specifies how many EC2 instances will launch.
- associatePublicIpAddress | noAssociatePublicIpAddress. AWS users can select this flag depending on whether the new instance or instances will use a public IP address. Subnets have a default configuration to disable or enable association with a public IP. For security reasons, some EC2 instances should not have a public IP address. In other use cases, it is required.