David Clinton - AWS Certified Solutions Architect Study Guide

Whether you've created an IAM user

Whether multifactor authentication is enabled for the root user

Public access to an EBS or RDS snapshot

The Inventory Manager collects data from your instances, including operating system and application versions. Inventory Manager can collect data for the following:

Operating system name and version

Applications and filenames, versions, and sizes

Network configuration, including IP and media access control (MAC) addresses

Windows updates, roles, services, and registry values

CPU model, cores, and speed

You choose which instances to collect data from by creating a regionwide inventory association by executing the AWS‐GatherSoftwareInventory policy document. You can choose all instances in your account or select instances manually or by tag. When you choose all instances in your account, it's called a global inventory association , and new instances you create in the region are automatically added to it. Inventory collection occurs at least every 30 minutes.

When you configure the Systems Manager agent on an on‐premises server, you specify a region for inventory purposes. To aggregate metadata for instances from different regions and accounts, you may configure Resource Data Sync in each region to store all inventory data in a single S3 bucket.

Compliance insights show how the patch and association status of your instances stacks up against the rules you've configured. Patch compliance shows the number of instances that have the patches in their configured baseline, as well as details of the specific patches installed. Association compliance shows the number of instances that have had an association successfully executed against them.

The following example code shows how you can use an AWS CLI command to deploy an EC2 instance that includes many of the features you learned about in this chapter. Naturally, the image‐id, security‐group‐ids, and subnet‐idvalues are not real. Those you would replace with actual IDs that fit your account and region.

aws ec2 run-instances --image-id ami-xxxxxxxx --count 1 \ --instance-type t2.micro --key-name MyKeyPair \ --security-group-ids sg-xxxxxxxx --subnet-id subnet-xxxxxxxx \ --user-data file://my_script.sh \ --tag-specifications \ 'ResourceType=instance,Tags=[{Key=webserver,Value=production}]' \ 'ResourceType=volume,Tags=[{Key=cost-center,Value=cc123}]'

This example launches a single (‐‐ count 1) instance that's based on the specified AMI. The desired instance type, key name, security group, and subnet are all identified. A script file (that must exist locally so it can be read) is added using the user‐dataargument, and two tags are associated with the instance ( webserver:productionand cost‐center:cc123).

If you need to install the AWS CLI, perform Exercise 2.6.

Need help? Learn how to install the AWS CLI for your OS here:

docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

Refer to the previous AWS CLI example for help launching your instance. (Hint: You will need to fill in some xxxxxplaceholders with actual resource IDs.)

Never leave any resources running after you've finished using them. Exercise 2.7can help.

Since you've probably been launching resources while experimenting with AWS, you'll want to make sure you haven't accidentally left anything running that could cost you money. So, take a good look through the console and kill off what shouldn't still be alive. Here are some things to consider:

Remember to check any other AWS regions where you might have done some work—only a single region's resources will show up in the console at a time.

Some resources can't be deleted because they're in use by other resources. A snapshot used by a private AMI is one example. You'll need to shut those down in the right order.

When you're logged into your AWS account, you can check out your Billing and Cost Management dashboard in the console ( console.aws.amazon.com/billing). This dashboard will show you whether, taking into account your current resource usage, you stand to run up a bill in the current month.

The base software stack that runs on an EC2 instance is defined by your choice of Amazon Machine Image and any scripts or user data you add at launch time, and the hardware profile is the product of an instance type. A tenancy setting determines whether your instance will share a physical host with other instances.

As with all your AWS resources, it's important to give your EC2 instances easily identifiable tags that conform to a systemwide naming convention. There are limits to the number of resources you'll be allowed to launch within a single region and account wide. Should you hit your limit, you can always request access to additional resources.

If you plan to run an instance for a year or longer, you can save a significant amount of money compared to paying for on‐demand by purchasing a reserve instance. If your workload can withstand unexpected shutdowns, then a spot instance could also make sense.

There are four kinds of Elastic Block Store volumes: two high IOPS and low‐latency SSD types and two traditional hard drives. Your workload and budget will inform your choice. In addition, some EC2 instance types come with ephemeral instance store volumes that offer fast data access but whose data is lost when the instance is shut down.

All EC2 instances are given at least one private IP address, and should they require Internet access, they can also be given a nonpermanent public IP. If you require a permanent public IP, you can assign an elastic IP to the instance.

You secure access to your EC2 instances using software firewalls known as security groups and can open up secure and limited access through IAM roles, NAT instances or NAT gateways, and key pairs.

EC2 Auto Scaling can help you avoid application failures caused by overloaded instances. By implementing dynamic scaling policies, you can ensure that you always have enough instances to handle increased demand. In the event of some failure, a well‐designed Auto Scaling group will ensure that you always have a minimum number of healthy instances. When an instance becomes unhealthy, Auto Scaling will terminate and replace it.

Understand how to provision and launch an EC2 instance. You'll need to select the right AMI and instance type, configure a security group, add any extra storage volumes that might be needed, point to any necessary user data and scripts, and, ideally, tag all the elements using descriptive key values.

Understand how to choose the right hardware/software profile for your workload. Consider the benefits of building your own image against the ease and simplicity of using a marketplace, community, or official AMI. Calculate the user demand you expect your application to generate so that you can select an appropriate instance type. Remember that you can always change your instance type later if necessary.

Understand EC2 pricing models and how to choose one to fit your needs. Know how to calculate whether you'll be best off on the spot market, with on‐demand, or with reserve—or some combination of the three.

Understand how to configure a security group to balance access with security to match your deployment profile. Security groups act as firewalls, applying policy rules to determine which network traffic is allowed through. You can control traffic based on a packet's protocol and network port and its source and intended destination.