1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. How to Use the AWS Command-Line Interface

Managing your EC2 instances

Contents

Introduction to the AWS Command Line Interface
Start course
Overview
DifficultyIntermediate
Duration50m
Students1558
Ratings
5/5

Description

Although most AWS services can be managed through the console in Amazon's browser interface or via the APIs commonly used for programmatic access, there is a third way that, in many cases, can be very useful: the Command Line Interface (CLI). AWS has made software packages available for Linux, MacOS, and Windows that allows you to manage the main AWS services from a local terminal session's command line.

In this course, the Cloud Expert and Linux System Administrator David Clinton will tell you everything you need to know to get started with the AWS Command Line Interface and to use it proficiently in your daily operations. He will also provide many examples to clearly explain how command line connectivity really works.

Who should take this course

This is an intermediate course, as such you should already know the basic AWS concepts, and in particular of the services that described in this tutorial. Also, some experience with the Linux Command Line Interface is not strictly speaking necessary, but still quite useful.

If you want to boost your knowledge of AWS, EC2S3, and RDS, we strongly suggest you take our other AWS courses. Also, self-test questions are available if you'd like to test and increase your knowledge.

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

Transcript

Hi, welcome to CloudAcademy.com's video series on AWS CLI, the Amazon web services command line interface. In this video, we're going to learn how to use the command line interface to access and control your EC2 instances. In truth, there's a vast range of commands available for controlling EC2 instance through the command line interface, in fact for controlling every aspect of your AWS experience. We're not going to be able to describe and demonstrate even a small fraction of them. However, I will draw your attention to the very extensive help documentation that's available with at the command line. Type AWS, then let's say, EC2, then the word help. You will get help and a description of the many commands available in the EC2 access interface.

However, let's say you find a particular command you're interested in. Let's say it's describe key pairs. Just type help after that and you'll find a syntax guide for using EC2 describe key pairs. We'll take a look, and we see there's an overview of syntax and usage and even some examples. In the meantime, let's just run AWS EC2 describe key pairs to see what key pairs are available in my account. There are two. One's called my key, and the other's called new pair.pem. Let's create a new key pair, not because we necessarily need one, but just to demonstrate how it's done. Remember, without a key pair, you won't be able to access your instance via SSH.

So let's type AWS EC2 create key pair. And then, key name, the key name should be newer pair.pem. The program has displayed for us what should be the contents of this key of our side of the key pair. We should highlight the contents from the first line, begin RSA, and to the end, last line, end RSA. You could right click and copy that text. Then, nano newer pair.pem. Be very careful to make sure that the name of the file you're now creating is identical to the one you told Amazon to create. And then paste the contents and nothing but the contents of this file into the document, control X to exit, Y to accept the changes. And we now have a key pair file on our system in this directory. One more thing though. We have to run schmode or change mode 600 newer pair.pem. That means we will change the permissions associated with this file to be read and write for the owner of the file, but no access at all for anybody else. Not a group not another user on the system. This exclusive permission is necessary for newer pair to work. So in order to figure out which instance type you want, let's click on EC2. Then launch instance. And scroll down for the instance type, the AMI that we're after. We like Ubuntu, of course, but this Ubuntu, Ubuntu Super 1404 is HVM. As it turns out, HVM instance types are incompatible with command line access. So let's go down a little bit further to get to another Ubuntu image, like this one. Ubuntu server 1404 PV. And this has an AMI identifier of AMI D8480. That's the one we're after.

We'll make a note of this ID and make use of it later. Now that we have the kind of instance that we're looking for, let's run AWS EC2, run instances, which will tell Amazon that we're trying to launch a new instance with the following qualities: image ID should be AMI, AMI-E84D8480. That is, the AMI we found that was a Ubuntu PV image. Count will be one. That is, we want to launch only one instance of this image.

You could have obviously launched many more if you needed them. Instance type will be T1 micro, which is the smallest and least expensive of the Amazon instance types, which again for this purpose, is what we're after. Key name will be newer pair.pem. And we have to make sure that the actual newer pair.pem file is either in this directory or you would identify the directory it's in using an absolute address. In this case, we know that newerpair.pem is in the current directory.

And now very important, we also have to identify a security group. In this case, we're going to use quickstart-1, which is a security group that I've already created, that allows SSH access through port 22. If you do not identify a specific security group, then AWS will assign the default security group, which is great except that the default security group does not allow SSH access. So your instance will likely be fairly useless.

Let's hit enter. A little debugging is necessary now. Let's hit the up key to once again, enter the previous command.

And let's fix what we've done wrong. Instance type is one of those arguments that requires two dashes. This type of debugging is usually necessary the first time or two that you run such a long and involved command, at least in my case. I often leave something else out or add something or spell something wrong. Now let's try it with instance type properly notated. Seems to have worked. Let's scroll up a little bit to see what AWS has sent us. We have an image ID of AMI84D, E84D, which is the image ID we're after.

This is our instance ID. Let's copy it and make note of it elsewhere, because we're going to have to make reference to it in later commands. At this point, we don't yet know what the IP address, the public IP address is through which we can access the instance, but at least we know it's up and running and has an instance ID that it has given us. Now, in order to get that last piece of information, the public IP address, also known as the public DNS address, let's run AWS EC2 describe instances. There is only one instance at this point being run on my account. As you can see, here's the instance ID that we saw before. Here's the image ID we saw before. And here, very critically, is the public DNS name.

We'll copy that, and we will paste it here, but we're not ready to do anything with that just yet. First, we have to, at the beginning of the line, type SSH to tell Linux that we are about to start an SSH session. -I. Then identify the key pair.

Newerpair.pem, which again, is in the current directory. Then, because this is the Ubuntu session, by default the user of a Ubuntu instance is Ubuntu. So we type Ubuntu at the address. And let's see if that lets us in. Do we want to continue connecting? Of course we do. And we're in.

It worked. We created, designated, identified, and then attached ourselves to a Ubuntu instance running on AWS, completely from the command line. Let's run IF config just to see the network and the internal IP address, that is the internal IP address, is 10.238.259.92.

Let's CD to the root and run LS, list what's there. It's a regular Ubuntu file system. And it looks like we're all set to go. Of course, with this particular instance, we've got nothing to do. This was intended only as a demonstration of getting it going. So let's exit the session, which brings us back to our own shell on our computer. And there's really only one thing still to do, and that is AWS EC2 stop instances. Kind of a shame.

We just got it going. But that's the way of virtual computing. Instance IDS. In order to stop an instance, obviously you have to identify to AWS which instance you're talking about. There is where it becomes handy that we previously made a note of our instance ID. We'll now paste that in, run the command, and everything is stopped. Just to be sure, let's once again run describe instances. See what's returned. This instance does exist because we haven't terminated it. It certainly still does now exist. But its state is stopping. It's in the process of stopping.

It might not have completely come to a halt yet, but is in the process of stopping. To completely remove our instance from Amazon, we'll also have to terminate it. That is AWS EC2 terminate instances, instance IDs, and then the instance ID.

About the Author

Students16276
Courses17
Learning paths2

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.

Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.

His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.