Creating an AWS Account

If you don’t already have an Amazon Web Services (AWS) account, go to http://aws.amazon.com and click Create a Free Account to get started. If you already have one, skip ahead to the next section.

To create an AWS account, you will have to sign in using an Amazon.com account (see Figure 2-1). This can be the same account you use to shop on Amazon.com. If you are creating an AWS account for work, you might want to create a separate Amazon account using your work e-mail rather than using your personal account. If you want to create a new account, or have been living under a rock and don’t have an Amazon account already, you can create one now.

After you create an AWS account, it’s time to create an IAM account, which is discussed next.

Creating an IAM User Account

Now that you have an AWS account, you will need to create a new IAM user. (IAM stands for Identity and Access Management.) AWS has two types of users: account credentials and IAM users. The e-mail address you used to create the AWS account is called an “AWS account credential.” You should not use your account credentials for day-to-day activities on AWS. Save your AWS account credentials to change account options and access your bills. Create an IAM user for day-to-day activities instead.

IAM allows you to create multiple user accounts and configure the permissions of each user. If you already have an IAM user with administrator privileges, you can skip to the next section.

Open http://console.aws.amazon.com . If you are not already signed in, use your AWS account credential (i.e., the e-mail address used to create the account) to sign in. You will be taken to the AWS Management Console. Click Services from the menu bar at the top of the screen and search for IAM (see Figure 2-1).

From the IAM dashboard, click the Users on the left navigation and then click the Add User button. This will start the add user wizard.

Enter admin as the User name and choose both Programmatic access and AWS Management Console access. You can enter a password here or let the wizard generate a random password for you. Click the Next button. (See Figure 2-2.)

On the next page, click the Create group button. Enter the name admins and select the AdministratorAccess policy. Click Create group and then click Next: Tags. (See Figure 2-3.)

Skip the Tags screen by clicking the Next : Review button. Then, click the Create User button. Finally, click the Download .csv file. Keep this file somewhere safe. You will need it later.

Logging in As an IAM User

The last thing we need to do is get the custom sign-in URL for your new account. In order to sign in using your IAM username and password, you must visit the account sign-in URL. Each account has a unique sign-in URL, but the default URL is very difficult to remember; let’s change it to something we can remember.

To change the sign-in URL, return to the IAM dashboard and find the IAM user sign-in link (see Figure 2-4). Click the Customize link to specify a friendly account alias.

At this point you should sign out using the menu at the top right of the screen (see Figure 2-5).

Finally, navigate to the custom sign-in link and sign on as admin. If you let the wizard generate a password, you can find it in the csv file you downloaded earlier.

Note that you are now logged in as an IAM user. Compare the IAM user listed in the top right corner (see Figure 2-6) to the account credential in Figure 2-3. Note the IAM user includes the “@ alias.”

At this point you have an AWS account and an IAM user with administrative privileges. Next, we are going to install the AWS Tools for PowerShell and configure a few default values.

Configuring PowerShell

You can download the AWS tools from http://aws.amazon.com/powershell/ . If you are running your script on an AWS Windows instance (e.g., a server running in the AWS Cloud), the tools are already installed. If you want to run the tools on your own machine, download the installer from the preceding site.

The AWS tools are also available from the PowerShell gallery. There are two versions: AWSPowerShell and AWSPowerShell.NetCore. If you are running PowerShell on Linux, you will want to install AWSPowerShell.NetCore. For the rest of this book, I will assume you are running on Windows. However, nearly everything will work on PowerShell Core.

I usually write scripts using the PowerShell Integrated Script Environment (ISE) because it supports IntelliSense and debugging. The PowerShell ISE is a Windows feature. If it is not already enabled, you may need to enable the feature from Windows Server Explorer. This feature is enabled by default on AWS instances.

If the command succeeds, your PowerShell environment is set up correctly. Notice that we did not use the credentials we downloaded earlier. The Get-AWSRegion method does not require authentication. Before you can do anything exciting, you are going to have to supply your credentials. Let’s see how to do this in the next section.

Specifying Credentials and Region

Before you can use AWS, you need to log in. Remember that PowerShell uses the REST API. Therefore, you will need an access key and secret key in order to use PowerShell.

At this point, you should receive a list of your instances deployed in the specified region. If you just created a new account, you probably don’t have any instances yet. As long as you don’t get an error, it’s working correctly. This is everything you need to execute the scripts in this book, but there are still a few things we can do make life easier. For example, it would be nice to save the default credentials and region so we don’t have to add them to every command.

Setting Defaults

It can get cumbersome including the keys on every line of every script. Life would be easier if you had to specify the keys only once. Luckily, Amazon thought of this and included the Set-AWSCredentials and Set-DefaultAWSRegion commands .

Notice that once I set a default region and credentials, I can run the Get-EC2Instance command without any parameters. This is so much easier. I can simply include these two lines at the top of the script, and I don’t have to worry about it again.

Setting defaults is great, but we have to remember to set them each time we start PowerShell. We can take it one step further and persist the defaults between PowerShell sessions.

Persisting Defaults

We are almost done discussing defaults, but there is one more option I want to mention: stored credentials. Stored credentials allow you to store multiple credentials and switch between them quickly.

Using Stored Credentials

You may find that you have more than one set of credentials to manage. Maybe you have separate AWS accounts for development and production servers; in my opinion, this is a really good idea. (And I hope you’re not running these examples in the same account that you use to host production workloads.)

At this point your PowerShell environment is ready. In the next chapter, we are going to launch a few instances. Before you do that, however, you are going to need an EC2 key pair.

Using Key Pairs

Before we move on to creating instances, you will need a key pair. This key pair is used to encrypt the Windows Password for a new instance. AWS keeps the public key, and you keep the private key. When you create a Windows instance, AWS creates a local administrator account and generates a random password. It then encrypts the random password with the public key and stores the encrypted copy.

You can retrieve the password any time and decrypt it with your private key. Note that AWS does not keep the plain-text password. Therefore, only you can decrypt the password.

To create a key pair, log in using your IAM admin user and choose a region. I will be using Northern Virginia, but you can select the location nearest you. Then, navigate to the EC2 service and choose Key Pairs from the left navigation. Click Create Key Pair.

Name the key pair and click Create. Your browser will download the private key. Make sure you save it. Note that the examples in this book assume your key is stored in c:awsmykey.pem.

That’s everything you need to complete the exercises in this book. If you cannot wait any longer to launch an instance, feel free to move on to Chapter 3. But, if you have the patience, I would like to tell you about one more feature: IAM roles.

Using IAM Roles

We have covered a lot of material already in this chapter, but there is one more feature I want to discuss. It is a bad idea to have your production scripts running as an individual user. What happens if that user leaves the company? If you delete her account, all of your scripts will stop working.

You could create an additional IAM user just for running production scripts. But, how do you keep those keys secret? How do you keep a disgruntled administrator you fired from using the keys to terminate all your servers? Luckily, AWS provides a solution for this, too: IAM roles.

An IAM role allows you to grant permission to an EC2 instance. This way, you don’t need keys to run PowerShell scripts. In other words, if you assign an IAM role to an instance, the instance has permission to run scripts rather than a user. Any scripts that are run on that instance are implicitly granted the permissions defined to the IAM role. Therefore, you don’t have to bother with keys at all. Although you don’t have to set credentials, you still need to set the region.

Of course this only works for instances running in AWS. You cannot use IAM roles for machines running in your data center. In addition, you have to assign the role when you create the instance; you cannot assign it later.

To create an IAM role, open the AWS Management Console and navigate to the IAM Console. (I assume you know how to do this by now. If not, go back to the “Creating a User Account” section at the beginning of this chapter.) Choose Roles from the left navigation. Then, click the Create Role button and name your new role (see Figure 2-6). I will use the name AdminRole for the scripts in this book.

There are many types of roles available. On the first screen of the create role wizard, choose AWS Service and EC2, then click Next: Permissions. (See Figure 2-7.)

On the next screen, choose AdministratorAccess and click Next:Tags (see Figure 2-8). Note that in a real-life scenario you would want to restrict the role. With administrator permissions assigned to an EC2 instance, anyone who runs a script on that instance will have full control over your account. For the purposes of this book, this is fine, but please be more restrictive in real life.

You can skip the Tags screen by clicking Next: Review. On the last screen, name the role AdminRole and click the Create role button. (See Figure 2-9.)

We will use this role in the second exercise of Chapter 3.

Summary

In this chapter, we created an AWS account and IAM user. Then we installed the AWS Tools for PowerShell and configured our PowerShell scripting environment with a default region and credentials. Finally, we created an EC2 key pair and an IAM role. We now have everything in place to begin using the cloud. In the next chapter, we will launch a few basic instances.