Provisioning Your Instance

You configure your instance's operating system and software stack, hardware specs (the CPU power, memory, primary storage, and network performance), and environment before launching it. The OS is defined by the Amazon Machine Image (AMI) you choose, and the hardware follows the instance type.

Configuring an Environment for Your Instance

Deciding where your EC2 instance will live is as important as choosing a performance configuration. Here, there are three primary details to get right: geographic region, virtual private cloud (VPC), and tenancy model.

AWS Regions

As you learned earlier, AWS servers are housed in data centers around the world and organized by geographical region. You'll generally want to launch an EC2 instance in the region that's physically closest to the majority of your customers or, if you're working with data that's subject to legal restrictions, within a jurisdiction that meets your compliance needs.

EC2 resources can be managed only when you're “located within” their region. You set the active region in the console through the drop‐down menu at the top of the page and through default configuration values in the AWS CLI or your SDK. You can update your CLI configuration by running aws configure.

Bear in mind that the costs and even functionality of services and features might vary between regions. It's always a good idea to consult the most up‐to‐date official documentation.

VPCs

Virtual private clouds (VPCs) are easy‐to‐use AWS network organizers and great tools for organizing your infrastructure. Because it's so easy to isolate the instances in one VPC from whatever else you have running, you might want to create a new VPC for each one of your projects or project stages. For example, you might have one VPC for early application development, another for beta testing, and a third for production (see Figure 2.1).

Adding a simple VPC that doesn't incorporate a network address translation (NAT) gateway (docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html) or VPN access (docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) won't cost you anything. You'll learn much more about all this in Chapter 4, “Amazon Virtual Private Cloud.”

Tenancy

When launching an EC2 instance, you'll have the opportunity to choose a tenancy model. The default setting is shared tenancy, where your instance will run as a virtual machine on a physical server that's concurrently hosting other instances. Those other instances might well be owned and operated by other AWS customers, although the possibility of any kind of insecure interaction between instances is remote.

To meet special regulatory requirements, your organization's instances might need an extra level of isolation. The Dedicated Instance option ensures that your instance will run on a dedicated physical server. This means that it won't be sharing the server with resources owned by a different customer account. The Dedicated Host option allows you to actually identify and control the physical server you've been assigned to meet more restrictive licensing or regulatory requirements.

Naturally, dedicated instances and dedicated hosts will cost you more than instances using shared tenancy.

Exercise 2.1 will guide you through the launch of a simple EC2 Linux instance.

In Exercise 2.2, you'll see how changing an instance's type works.

Configuring Instance Behavior

You can optionally tell EC2 to execute commands on your instance as it boots by pointing to user data in your instance configuration (this is sometimes known as bootstrapping). Whether you specify the data during the console configuration process or by using the ‐‐user‐data value with the AWS CLI, you can have script files bring your instance to any desired state.

User data can consist of a few simple commands to install a web server and populate its web root, or it can be a sophisticated script setting up the instance as a working node within a Puppet Enterprise–driven platform.

Placement Groups

By default AWS will attempt to spread your instances across their infrastructure to create a profile that will be optimal for most use cases. But the specific demands of your operation might require a different setup. EC2 placement groups give you the power to define nonstandard profiles to better meet your needs. There are, at this time, three kinds of placement groups:

• Cluster groups launch each associated instance into a single availability zone within close physical proximity to each other. This provides low‐latency network interconnectivity and can be useful for high‐performance computing (HPC) applications, for instance.
• Spread groups separate instances physically across distinct hardware racks and even availability zones to reduce the risk of failure‐related data or service loss. Such a setup can be valuable when you're running hosts that can't tolerate multiple concurrent failures. If you're familiar with VMware's Distributed Resource Scheduler (DRS), this is similar to that.
• Partition groups let you associate some instances with each other, placing them in a single “partition.” But the instances within that single partition can be kept physically separated from instances within other partitions. This differs from spread groups where no two instances will ever share physical hardware.

Instance Pricing

You can purchase the use of EC2 instances through one of three models.

For always‐on deployments that you expect to run for less than 12 months, you'll normally pay for each hour your instance is running through the on‐demand model. On‐demand is the most flexible way to consume EC2 resources since you're able to closely control how much you pay by stopping and starting your instances according to your need. But, per hour, it's also the most expensive.

If you're planning to keep the lights burning 24/7 for more than a year, then you'll enjoy a significant discount by purchasing a reserve instance—generally over a term commitment of between one and three years. You can pay up front for the entire term of a reserve instance or, for incrementally higher rates, either partially up front and the rest in monthly charges or entirely through monthly charges. Table 2.2 gives you a sense of how costs can change between models. These estimates assume a Linux platform, all up‐front payments, and default tenancy. Actual costs may vary over time and between regions.

For workloads that can withstand unexpected disruption (like computation‐intensive genome research applications), purchasing instances on Amazon's spot market can save you a lot of money. The idea is that you enter a maximum dollar‐value bid for an instance type running in a particular region. The next time an instance in that region becomes available at a per‐hour rate that's equal to or below your bid, it'll be launched using the AMI and launch template you specified. Once up, the instance will keep running either until you stop it—when your workload completes, for example—or until the instance's per‐hour rate rises above your maximum bid. You'll learn more about the spot market and reserve instances in Chapter 13, “The Cost Optimization Pillar.”

It will often make sense to combine multiple models within a single application infrastructure. An online store might, for instance, purchase one or two reserve instances to cover its normal customer demand but also allow autoscaling to automatically launch on‐demand instances during periods of unusually high demand.

Use Exercise 2.3 to dive deeper into EC2 pricing.

Instance Lifecycle

The state of a running EC2 instance can be managed in a number of ways. Terminating the instance will shut it down and cause its resources to be reallocated to the general AWS pool.

If your instance won't be needed for some time but you don't want to terminate it, you can save money by simply stopping it and then restarting it when it's needed again. The data on an EBS volume will in this case not be lost, although that would not be true for an instance volume.

Later in this chapter, you'll learn about both EBS and instance store volumes and the ways they work with EC2 instances.

You should be aware that a stopped instance that had been using a nonpersistent public IP address will most likely be assigned a different address when it's restarted. If you need a predictable IP address that can survive restarts, allocate an elastic IP address and associate it with your instance.

You can edit or change an instance's security group (which we'll discuss a bit later in this chapter) to update access policies at any time—even while an instance is running. You can also change its instance type to increase or decrease its compute, memory, and storage capacity (just try doing that on a physical server). You will need to stop the instance, change the type, and then restart it.

Resource Tags

The more resources you deploy on your AWS account, the harder it can be to properly keep track of things. Having constantly changing numbers of EC2 instances—along with accompanying storage volumes, security groups, and elastic IP addresses—all spread across two or three VPCs can get complicated.

The best way to keep a lid on the chaos is to find a way to quickly identify each resource you've got running by its purpose and its relationships to other resources. The best way to do that is by establishing a consistent naming convention and applying it to tags.

AWS resource tags can be used to label everything you'll ever touch across your AWS account—they're certainly not restricted to just EC2. Tags have a key and, optionally, an associated value. So, for example, you could assign a tag with the key production‐server to each element of a production deployment. Server instances could, in addition, have a value of server1, server2, and so on. A related security group could have the same production‐server key but security‐group1 for its value. Table 2.3 illustrates how that convention might play out over a larger deployment group.

Applied properly, tags can improve the visibility of your resources, making it much easier to manage them effectively, audit and control costs and billing trends, and avoid costly errors.

Service Limits

By default, each AWS account has limits to the number of instances of a particular service you're able to launch. Sometimes those limits apply to a single region within an account, and others are global. As examples, you're allowed only five VPCs per region and 5,000 Secure Shell (SSH) key pairs across your account. If necessary, you can ask AWS to raise your ceiling for a particular service.

You can find up‐to‐date details regarding the limits of all AWS services at docs.aws.amazon.com/general/latest/gr/aws_service:limits.html.

Elastic Block Store Volumes

You can attach as many Elastic Block Store (EBS) volumes to your instance as you like (although one volume can be attached to no more than a single instance at a time) and use them just as you would hard drives, flash drives, or USB drives with your physical server. And as with physical drives, the type of EBS volume you choose will have an impact on both performance and cost.

The AWS SLA guarantees the reliability of the data you store on its EBS volumes (promising at least 99.99 percent availability), so you don't have to worry about failure. When an EBS drive does fail, its data has already been duplicated and will probably be brought back online before anyone notices a problem. So, practically, the only thing that should concern you is how quickly and efficiently you can access your data.

There are currently four EBS volume types, two using SSD technologies and two using the older spinning hard drives. The performance of each volume type is measured in maximum IOPS/volume (where IOPS means input/output operations per second).

Instance Store Volumes

Unlike EBS volumes, instance store volumes are ephemeral. This means that when the instances they're attached to are shut down, their data is permanently lost. So, why would you want to keep your data on an instance store volume more than on EBS?

• Instance store volumes are SSDs that are physically attached to the server hosting your instance and are connected via a fast NVMe (Non‐Volatile Memory Express) interface.
• The use of instance store volumes is included in the price of the instance itself.
• Instance store volumes work especially well for deployment models where instances are launched to fill short‐term roles (as part of autoscaling groups, for instance), import data from external sources, and are, effectively, disposable.

Whether one or more instance store volumes are available for your instance will depend on the instance type you choose. This is an important consideration to take into account when planning your deployment.

Even with all the benefits of EBS and instance storage, it's worth noting that there will be cases where you're much better off keeping large data sets outside of EC2 altogether. For many use cases, Amazon's S3 service can be a dramatically less expensive way to store files or even databases that are nevertheless instantly available for compute operations.

You'll learn more about this in Chapter 3, “AWS Storage.”

The bottom line is that EBS volumes are likely to be the right choice for instances whose data needs to persist beyond a reboot and for working with custom or off‐the‐shelf AMIs. Instance store volumes are, where available, useful for operations requiring low‐latency access to large amounts of data that needn't survive a system failure or reboot. And non‐EC2 storage can work well when you don't need fantastic read/write speeds, but you wish to enjoy the flexibility and cost savings of S3.

Security Groups

An EC2 security group plays the role of a firewall. By default, a security group will deny all incoming traffic while permitting all outgoing traffic. You define group behavior by setting policy rules that will either block or allow specified traffic types. From that point on, any data packet coming into or leaving the perimeter will be measured against those rules and processed accordingly.

Traffic is assessed by examining its source and destination, the network port it's targeting, and the protocol it's set to use. A TCP packet sent to the SSH port 22 could, for example, only be allowed access to a particular instance if its source IP address matches the local public IP used by computers in your office. This lets you open up SSH access on your instance without having to worry about anyone from outside your company getting in.

Using security groups, you can easily create sophisticated rule sets to finely manage access to your services. You could, say, open up a website to the whole world while blocking access to your backend servers for everyone besides members of your team.

If necessary, you can update your security group rules and/or apply them to multiple instances.

IAM Roles

You can also control access to AWS resources—including EC2 instances—through the use of IAM roles. You define an IAM role by giving it permissions to perform actions on specified services or resources within your AWS account. When a particular role is assigned to a user or resource, they'll gain access to whichever resources were included in the role policies.

Using roles, you can give a limited number of entities (other resources or users) exclusive access to resources like your EC2 instances. But you can also assign an IAM role to an EC2 instance so that processes running within it can access the external tools—like an RDS database instance—it needs to do its work.

You'll learn more about IAM in Chapter 6, “Authentication and Authorization—AWS Identity and Access Management.”

NAT Devices

Sometimes you'll need to configure an EC2 instance without a public IP address to limit its exposure to the network. Naturally, that means it won't have any Internet connectivity. But that can present a problem because you'll probably still need to give it Internet access so that it can receive security patches and software updates.

One solution is to use network address translation (NAT) to give your private instance access to the Internet without allowing access to it from the Internet. AWS gives you two ways to do that: a NAT instance and a NAT gateway (see Figure 2.2). They'll both do the job, but since a NAT gateway is a managed service, it doesn't require that you manually launch and maintain an instance. Both approaches will incur monthly charges.

NAT will be discussed at greater length in Chapter 4.

Key Pairs

As any professional administrator will know, remote login sessions on your running instances should never be initiated over unencrypted plain‐text connections. To ensure properly secured sessions, you'll need to generate a key pair, save the public key to your EC2 server, and save its private half to your local machine. If you're working with a Windows AMI, you'll use the private key file to retrieve the password you'll need to authenticate into your instance. For a Linux AMI, the private key will allow you to open an SSH session.

Each key pair that AWS generates for you will remain installed within its original region and available for use with newly launched instances until you delete it. You should delete the AWS copy in the event your public key is lost or exposed. Just be careful before you mess with your keys—your access to an instance might depend on it.

Launch Configurations

When you create an instance manually, you have to specify many configuration parameters, including an AMI, instance type, SSH key pair, security group, instance profile, block device mapping, whether it's EBS optimized, placement tenancy, and user data, such as custom scripts to install and configure your application. A launch configuration is essentially a named document that contains the same information you'd provide when manually provisioning an instance.

You can create a launch configuration from an existing EC2 instance. Auto Scaling will copy the settings from the instance for you, but you can customize them as needed. You can also create a launch configuration from scratch.

Launch configurations are for use only with EC2 Auto Scaling, meaning you can't manually launch an instance using a launch configuration. Also, once you create a launch configuration, you can't modify it. If you want to change any of the settings, you have to create an entirely new launch configuration.

Launch Templates

Launch templates are similar to launch configurations in that you can specify the same settings. But the uses for launch templates are more versatile. You can use a launch template with Auto Scaling, of course, but you can also use it for spinning up one‐off EC2 instances or even creating a spot fleet.

Launch templates are also versioned, allowing you to change them after creation. Any time you need to make changes to a launch template, you create a new version of it. AWS keeps all versions, and you can then flip back and forth between versions as needed. This makes it easier to track your launch template changes over time. Complete Exercise 2.5 to create your own launch template.

Auto Scaling Groups

An Auto Scaling group is a group of EC2 instances that Auto Scaling manages. When creating an Auto Scaling group, you must first specify either the launch configuration or launch template you created. When you create an Auto Scaling group, you must specify how many running instances you want Auto Scaling to provision and maintain using the launch configuration or template you created. You must specify the minimum and maximum size of the Auto Scaling group. You may also optionally set the desired number of instances you want Auto Scaling to provision and maintain.

• Minimum   Auto Scaling will ensure the number of healthy instances never goes below the minimum. If you set this to 0, Auto Scaling will not spawn any instances and will terminate any running instances in the group.
• Maximum   Auto Scaling will make sure the number of healthy instances never exceeds this amount. This might seem strange but remember that you might have budget limitations and need to be protected from unexpected (and unaffordable) usage demands.
• Desired Capacity   The desired capacity is an optional setting that must lie within the minimum and maximum values. If you don't specify a desired capacity, Auto Scaling will launch the number of instances as the minimum value. If you specify a desired capacity, Auto Scaling will add or terminate instances to stay at the desired capacity. For example, if you set the minimum to 1, the maximum to 10, and the desired capacity to 4, then Auto Scaling will create four instances. If one of those instances gets terminated—for example, because of human action or a host crash—Auto Scaling will replace it to maintain the desired capacity setting of 4. In the web console, desired capacity is also called the group size.

Auto Scaling Options

Once you create an Auto Scaling group, you can leave it be and it will continue to maintain the minimum or desired number of instances indefinitely. However, maintaining the current number of instances is just one option. Auto Scaling provides several other options to scale out the number of instances to meet demand.

Scheduled Actions

Scheduled actions are useful if you have a predictable load pattern and want to adjust your capacity proactively, ensuring you have enough instances before demand hits.

When you create a scheduled action, you must specify the following:

• A minimum, maximum, or desired capacity value
• A start date and time

You may optionally set the policy to recur at regular intervals, which is useful if you have a repeating load pattern. You can also set an end time, after which the scheduled policy gets deleted.

To illustrate how you might use a scheduled action, suppose you normally run only two instances in your Auto Scaling group during the week. But on Friday, things get busy, and you know you'll need four instances to keep up. You'd start by creating a scheduled action that sets the desired capacity to 2 and recurs every Saturday, as shown in Figure 2.3.

The start date is January 5, 2019, which is a Saturday. To handle the expected Friday spike, you'd create another weekly recurring policy to set the desired capacity to 4, as shown in Figure 2.4.

This action will run every Friday, setting the desired capacity to 4, prior to the anticipated increased load.

Note that you can combine scheduled actions with dynamic scaling policies. For example, if you're running an e‐commerce site, you may use a scheduled action to increase the maximum group size during busy shopping seasons and then rely on dynamic scaling policies to increase the desired capacity as needed.

Actions

Actions let you automatically or manually perform actions against your AWS resources, either individually or in bulk. These actions must be defined in documents, which are divided into three types:

• Automation—actions you can run against your AWS resources
• Command—actions you run against your Linux or Windows instances
• Policy—defined processes for collecting inventory data from managed instances

Insights

Insights aggregate health, compliance, and operational details about your AWS resources into a single area of AWS Systems Manager. Some insights are categorized according to AWS resource groups, which are collections of resources in an AWS region. You define a resource group based on one or more tag keys and optionally tag values. For example, you can apply the same tag key to all resources related to a particular application—EC2 instances, S3 buckets, EBS volumes, security groups, and so on. Insight categories are covered next.

1. You need to deploy multiple EC2 Linux instances that will provide your company with virtual private networks (VPNs) using software called OpenVPN. Which of the following will be the most efficient solutions? (Choose two.)
   1. Select a regular Linux AMI and bootstrap it using user data that will install and configure the OpenVPN package on the instance and use it for your VPN instances.
   2. Search the community AMIs for an official AMI provided and supported by the OpenVPN company.
   3. Search the AWS Marketplace to see whether there's an official AMI provided and supported by the OpenVPN company.
   4. Select a regular Linux AMI and SSH to manually install and configure the OpenVPN package.
   5. Create a Site‐to‐Site VPN Connection from the wizard in the AWS VPC dashboard.
2. As part of your company's long‐term cloud migration strategy, you have a VMware virtual machine in your local infrastructure that you'd like to copy to your AWS account and run as an EC2 instance. Which of the following will be necessary steps? (Choose two.)
   1. Import the virtual machine to your AWS region using a secure SSH tunnel.
   2. Import the virtual machine using VM Import/Export.
   3. Select the imported VM from among your private AMIs and launch an instance.
   4. Select the imported VM from the AWS Marketplace AMIs and launch an instance.
   5. Use the AWS CLI to securely copy your virtual machine image to an S3 bucket within the AWS region you'll be using.
3. Your AWS CLI command to launch an AMI as an EC2 instance has failed, giving you an error message that includes InvalidAMIID.NotFound. What of the following is the most likely cause?
   1. You haven't properly configured the ~/.aws/config file.
   2. The AMI is being updated and is temporarily unavailable.
   3. Your key pair file has been given the wrong (overly permissive) permissions.
   4. The AMI you specified exists in a different region than the one you've currently specified.
4. The sensitivity of the data your company works with means that the instances you run must be secured through complete physical isolation. What should you specify as you configure a new instance?
   1. Dedicated Host tenancy
   2. Shared tenancy
   3. Dedicated Instance tenancy
   4. Isolated tenancy
5. Normally, two instances running m5.large instance types can handle the traffic accessing your online e‐commerce site, but you know that you will face short, unpredictable periods of high demand. Which of the following choices should you implement? (Choose two.)
   1. Configure autoscaling.
   2. Configure load balancing.
   3. Purchase two m5.large instances on the spot market and as many on‐demand instances as necessary.
   4. Shut down your m5.large instances and purchase instances using a more robust instance type to replace them.
   5. Purchase two m5.large reserve instances and as many on‐demand instances as necessary.
6. Which of the following use cases would be most cost effective if run using spot market instances?
   1. Your e‐commerce website is built using a publicly available AMI.
   2. You provide high‐end video rendering services using a fault‐tolerant process that can easily manage a job that was unexpectedly interrupted.
   3. You're running a backend database that must be reliably updated to keep track of critical transactions.
   4. Your deployment runs as a static website on S3.
7. In the course of a routine infrastructure audit, your organization discovers that some of your running EC2 instances are not configured properly and must be updated. Which of the following configuration details cannot be changed on an existing EC2 instance?
   1. AMI
   2. Instance type
   3. Security group
   4. Public IP address
8. For an account with multiple resources running as part of multiple projects, which of the following key/value combination examples would make for the most effective identification convention for resource tags?
   1. servers:server1
   2. project1:server1
   3. EC2:project1:server1
   4. server1:project1
9. Which of the following EBS options will you need to keep your data‐hungry application that requires up to 20,000 IOPS happy?
   1. Cold HDD
   2. General‐purpose SSD
   3. Throughput‐optimized HDD
   4. Provisioned‐IOPS SSD
10. Your organization needs to introduce Auto Scaling to its infrastructure and needs to generate a “golden image” AMI from an existing EBS volume. This image will need to be shared among multiple AWS accounts belonging to your organization. Which of the following steps will get you there? (Choose three.)
    1. Create an image from a detached EBS volume, use it to create a snapshot, select your new AMI from your private collection, and use it for your launch configuration.
    2. Create a snapshot of the EBS root volume you need, use it to create an image, select your new AMI from your private collection, and use it for your launch configuration.
    3. Create an image from the EBS volume attached to the instance, select your new AMI from your private collection, and use it for your launch configuration.
    4. Search the AWS Marketplace for the appropriate image and use it for your launch configuration.
    5. Import the snapshot of an EBS root volume from a different AWS account, use it to create an image, select your new AMI from your private collection, and use it for your launch configuration.
11. Which of the following are benefits of instance store volumes? (Choose two.)
    1. Instance volumes are physically attached to the server that's hosting your instance, allowing faster data access.
    2. Instance volumes can be used to store data even after the instance is shut down.
    3. The use of instance volumes does not incur costs (beyond those for the instance itself).
    4. You can set termination protection so that an instance volume can't be accidentally shut down.
    5. Instance volumes are commonly used as a base for the creation of AMIs.
12. According to default behavior (and AWS recommendations), which of the following IP addresses could be assigned as the private IP for an EC2 instance? (Choose two.)
    1. 54.61.211.98
    2. 23.176.92.3
    3. 172.17.23.43
    4. 10.0.32.176
    5. 192.140.2.118
13. You need to restrict access to your EC2 instance‐based application to only certain clients and only certain targets. Which three attributes of an incoming data packet are used by a security group to determine whether it should be allowed through? (Choose three.)
    1. Network port
    2. Source address
    3. Datagram header size
    4. Network protocol
    5. Destination address
14. How are IAM roles commonly used to ensure secure resource access in relation to EC2 instances? (Choose two.)
    1. A role can assign processes running on the EC2 instance itself permission to access other AWS resources.
    2. A user can be given permission to authenticate as a role and access all associated resources.
    3. A role can be associated with individual instance‐based processes (Linux instances only), giving them permission to access other AWS resources.
    4. A role can give users and resources permission to access the EC2 instance.
15. You have an instance running within a private subnet that needs external network access to receive software updates and patches. Which of the following can securely provide that access from a public subnet within the same VPC? (Choose two.)
    1. Internet gateway
    2. NAT instance
    3. Virtual private gateway
    4. NAT gateway
    5. VPN
16. What do you have to do to securely authenticate to the GUI console of a Windows EC2 session?
    1. Use the private key of your key pair to initiate an SSH tunnel session.
    2. Use the public key of your key pair to initiate an SSH tunnel session.
    3. Use the public key of your key pair to retrieve the password you'll use to log in.
    4. Use the private key of your key pair to retrieve the password you'll use to log in.
17. Your application deployment includes multiple EC2 instances that need low‐latency connections to each other. Which of the following AWS tools will allow you to locate EC2 instances closer to each other to reduce network latency?
    1. Load balancing
    2. Placement groups
    3. AWS Systems Manager
    4. AWS Fargate
18. To save configuration time and money, you want your application to run only when network events trigger it but shut down immediately after. Which of the following will do that for you?
    1. AWS Lambda
    2. AWS Elastic Beanstalk
    3. Amazon Elastic Container Service (ECS)
    4. Auto Scaling
19. Which of the following will allow you to quickly copy a virtual machine image from your local infrastructure to your AWS VPC?
    1. AWS Simple Storage Service (S3)
    2. AWS Snowball
    3. VM Import/Export
    4. AWS Direct Connect
20. You've configured an EC2 Auto Scaling group to use a launch configuration to provision and install an application on several instances. You now need to reconfigure Auto Scaling to install an additional application on new instances. Which of the following should you do?
    1. Modify the launch configuration.
    2. Create a launch template and configure the Auto Scaling group to use it.
    3. Modify the launch template.
    4. Modify the CloudFormation template.
21. You create an Auto Scaling group with a minimum group size of 3, a maximum group size of 10, and a desired capacity of 5. You then manually terminate two instances in the group. Which of the following will Auto Scaling do?
    1. Create two new instances
    2. Reduce the desired capacity to 3
    3. Nothing
    4. Increment the minimum group size to 5
22. You're running an application that receives a spike in traffic on the first day of every month. You want to configure Auto Scaling to add more instances before the spike begins and then add additional instances in proportion to the CPU utilization of each instance. Which of the following should you implement? (Choose all that apply.)
    1. Target tracking policies
    2. Scheduled actions
    3. Step scaling policies
    4. Simple scaling policies
    5. Load balancing
23. As part of your new data backup protocols, you need to manually take EBS snapshots of several hundred volumes. Which type of Systems Manager document enables you to do this?
    1. Command
    2. Automation
    3. Policy
    4. Manual