This article is adapted from my new Pluralsight course: Automating AWS Operations with the AWS CLI. I’ll bet you’ve already got some stuff running on AWS and you made it happen using the browser console. But I’ll also bet that you already suspect that clicking your way through layers and layers of configuration pages isn’t always going to be the best approach. If fact, the AWS CLI is a better way that’ll get the exact same work done, but with a whole lot less effort. Let me quickly demonstrate. Suppose you want to launch an Amazon Linux instance from EC2. To get it up and running, you’ll need to… Load the EC2 Dashboard page Click Launch Instance Select an AMI from the AMI page Select an instance type from the Instance Type page Set network, IAM, life cycle behavior, and user data settings on the Configure Instance Details page Select one or more storage volumes on the Add Storage page Add tags on the Add Tags page Select or configure a security group on the — wait for it — Configure Security Group page And finally review and launch your instance on the page named (what else?) Review and Launch And don’t forget clicking through the pop up where you’ll confirm your key pair and then heading back to the EC2 Instances dashboard to get your instance data (like IP addresses). Sound like fun to you? Will it still sound like fun if you’re working with a slow internet connection? And how about if you need to perform variations of this process a half dozen times a week? Want to see how you’d fire up that configuration using the AWS CLI from a Bash shell (which you can run within Linux, macOS, and now even Windows 10)? Note how I used back slashes to tell Bash that the command isn’t complete yet. Hitting Enter gets the whole mess up and running. aws ec2 run-instances --image-id ami-04681a1dbd79675a5 \--count 1 \--instance-type r5d.large \--key-name MyKeyPair \--security-group-ids sg-007e43f80a1758f29 \--subnet-id subnet-970ec9f0 \--user-data file://my_script.sh \--tag-specifications \‘ResourceType=instance,Tags=[{Key=backend,Value=inventory1}]’ That precise command won’t work for you if you just paste it into your terminal and run it. The security group and subnet IDs are specific to my account, and you probably haven’t got a key pair called MyKeyPair or a script file called my_script.sh. But that does show you that, once you’ve done some basic up-front research to get all the right values and confirmed that it works, you’ll be able to save the command into a script file that you can modify and run whenever necessary. This can drop a five minute process down to a couple of seconds. The best place to go for up-to-date CLI installation instructions for your operating system is . Your best bet will normally be the Python package manager approach using PIP. this AWS documentation page The AWS CLI Installation Page Getting your CLI configured to securely access and administrate your AWS account resources is fairly straightforward. Although you will first need to generate (and copy/record) an access key for your AWS user from the My Security Credentials link in the account drop down menu back in the console. When that’s done, simply type “aws configure” at the command prompt and enter the Access Key ID and Secret Access Key you got from My Security Credentials. You can optionally choose default region and output format values. worker@workstation:~$ aws configureAWS Access Key ID [****************KB2Q]:AWS Secret Access Key [****************W/Cu]:Default region name [us-east-1]:Default output format [text]:worker@workstation:~$ AWS CLI Syntax Patterns You’re now all set to begin. Let’s start by breaking the command syntax down into its component parts and illustrate how it all works using practical examples. After the aws command prefix, a CLI command is made up of (which, as the name suggests, are optional), , , and . options commands subcommands parameters aws [options] <command> <subcommand> [parameters] This example will return all the EC2 AMI images officially maintained by Amazon that run the CentOS Linux operating system. aws --output table ec2 describe-images \--filters “Name=description,Values=*CentOS*” \“Name=owner-alias,Values=amazon” It uses the option, giving it the value of “ ” to display text output in tables. The top-level here is ec2. Most — if not all — top-level commands will invoke specific AWS services. s3, iam, and dynamodb are other examples. output table command The is , which will return data related to all the Amazon Machine Images currently available to use for your EC2 instances. That would return an awful lot of data, as there are many hundreds of AMIs and each one of them is represented by a lot of metadata. So you’ll want to narrow down the search just a bit. For that, I provided two values to the — filters parameter: the image description should contain the word — capitalizing the c, o, and s since this will be case sensitive, and the owner-alias value must equal . subcommand describe-images CentOS amazon You’ll often run _describe-_based subcommands to get important resource IDs that you can then plug into your actual action commands. That CentOS image ID would typically be used as part of an ec2 command to actually launch an instance. run-instances Besides describe and run, other common subcommands will begin with verbs like create, delete, enable, disable, modify, request, stop, and terminate. include , , and — which you’ve already seen — plus , which will do nothing, but instead display the output your command would generate it were actually run. This can be very useful when you’re not sure you’ve got the syntax quite right. Let’s try running that ec2 run-instances command from above, but this time adding . Options region output profile dry-run if dry-run S3 Example It’s time for a little S3 magic. I’ve got a business that needs a simple website without any database access or javascript bells and whistles. Just some regular, run of the mill, HTML5 goodness. So I’m going to create, carefully configure, and populate my bucket so that it’ll work as a static website — or, in other words, so that incoming traffic will automatically be directed to the index.html file I’ve created. Although it won’t play any role in this demo, I’m eventually going to want to set up a .com domain name in Amazon’s Route 53 that points to the site, so I’ll need to create an S3 bucket with exactly that name — .com and all. I make a bucket using and a globally unique bucket name. mb $ aws s3 mb s3://mysite548.com The bucket will have to be publicly readable, so I’ll use , along with the and parameters. The latter of those will take the value . s3api put-bucket-acl bucket acl public-read $ aws s3api put-bucket-acl --bucket mysite548.com --acl public-read Next I’ll use s3 sync to move all the contents of my current local directory up to my bucket. I’ve created three files: is the default web page and will be the page that’s loaded when a non-existent resource is requested. There’s also a small image to help prettify the demonstration. The parameter will give the files themselves the same permissions as the bucket. index.html error.html acl public-read $ aws s3 sync . s3://mysite548.com --acl public-read Finally, I’ll define the purpose of those html files for S3 using “s3 website”. The and parameters simply point to the relevant files. You don’t need to use those specific filenames, by the way, that’s just me. I’ll confirm that operation using s3api get-bucket-website. index-document error-document $ aws s3 website s3://mysite548.com/ --index-document index.html --error-document error.html$ aws s3api get-bucket-website --bucket mysite548.com What’s Next? The command syntax of the AWS CLI is fairly intuitive. Nevertheless, you will often need help getting it exactly right. As I show in , you can get excellent guidance from the system at the command line, or from the . My also contains useful guidance and examples. the Pluralsight course help AWS online documentation Learn Amazon Web Services in a Month of Lunches book This article is an excerpt adapted from my new Pluralsight course, Automating AWS Operations with the AWS CLI.

Administrating AWS resources productively using the AWS CLI

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A brief overview and history of systemd — the Linux process manager

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

Top 10 AI Development Companies in USA

12 Strategies to Reduce Amazon S3 Costs

A brief overview and history of systemd — the Linux process manager

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

Top 10 AI Development Companies in USA

12 Strategies to Reduce Amazon S3 Costs

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps