The aws-cli documentation and command line help text have not been updated yet to include the syntax for subscribing an AWS Lambda function to an SNS topic, but it does work!
Here’s the format:
aws sns subscribe \
--topic-arn arn:aws:sns:REGION:ACCOUNT:SNSTOPIC \
--protocol lambda \
--notification-endpoint arn:aws:lambda:REGION:ACCOUNT:function:LAMBDAFUNCTION
where REGION, ACCOUNT, SNSTOPIC, and LAMBDAFUNCTION are substituted with appropriate values for your account.
For example:
understand the commitment you are making to pay for the entire 1-3 years
Amazon just announced a change in the way that Reserved Instances are sold. Instead of selling the old Reserved Instance types:
EC2 is now selling these new Reserved Instance types:
Despite the fact that they are still called “Reserved Instances” and that there are three plans which sound like increasing commitment, the are not equivalent and do not map 1-1 old to new. In fact the new Reserved Instances are not even increasing commitment.
You should forget what you knew about Reserved Instances and read all the fine print before making any further Reserved Instance purchases.
One of the big differences between the old and the new is that you are always committing to spend the entire 1-3 years of cost even if you are not running a matching instance during part of that time. This text is buried in the fine print in a “**” footnote towards the bottom of the pricing page:
A fantastic new and oft-requested AWS feature was released during AWS re:Invent, but has gotten lost in all the hype about AWS Lambda functions being triggered when objects are added to S3 buckets. AWS Lambda is currently in limited Preview mode and you have to request access, but this related feature is already available and ready to use.
I’m talking about automatic S3 bucket notifications to SNS topics and SQS queues when new S3 objects are added.
Unlike AWS Lambda, with S3 bucket notifications you do need to maintain the infrastructure to run your code, but you’re already running EC2 instances for application servers and job processing, so this will fit right in.
To detect and respond to S3 object creation in the past, you needed to either have every process that uploaded to S3 subsequently trigger your back end code in some way, or you needed to poll the S3 bucket to see if new objects had been added. The former adds code complexity and tight coupling dependencies. The latter can be costly in performance and latency, especially as the number of objects in the bucket grows.
With the new S3 bucket notification configuration options, the addition of an object to a bucket can send a message to an SNS topic or to an SQS queue, triggering your code quickly and effortlessly.
Here’s a working example of how to set up and use S3 bucket notification configurations to send messages to SNS on object creation and update.
The AWS Lambda Walkthrough 2 uses AWS Lambda to automatically resize images added to one bucket, placing the resulting thumbnails in another bucket. The walkthrough documentation has a mix of aws-cli commands, instructions for hand editing files, and steps requiring the AWS console.
For my personal testing, I converted all of these to command line instructions that can simply be copied and pasted, making them more suitable for adapting into scripts and for eventual automation. I share the results here in case others might find this a faster way to get started with Lambda.
These instructions assume that you have already set up and are using an IAM user / aws-cli profile with admin credentials.
The following is intended as a companion to the Amazon walkthrough documentation, simplifying the execution steps for command line lovers. Read the AWS documentation itself for more details explaining the walkthrough.
Set up environment variables describing the associated resources:
If you uploaded SSL certificates to Amazon Web Services for ELB (Elastic Load Balancing) or CloudFront (CDN), then you will want to keep an eye on the expiration dates and renew the certificates well before to ensure uninterrupted service.
If you uploaded the SSL certificates yourself, then of course at that time you set an official reminder to make sure that you remembered to renew the certificate. Right?
However, if you inherited an AWS account and want to review your company or client’s configuration, then here’s an easy command to get a list of all SSL certificates in IAM, sorted by expiration date.
aws iam list-server-certificates \
--output text \
--query 'ServerCertificateMetadataList[*].[Expiration,ServerCertificateName]' \
| sort
To get more information on an individual certificate, you might use something like:
reduce the risk of losing control of your AWS account by not knowing the root account password
As Amazon states, one of the best practices for using AWS is:
We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, use your root user credentials only to create your IAM admin user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
The root account credentials are the email address and password that you used when you first registered for AWS. These credentials have the ultimate authority to create and delete IAM users, change billing, close the account, and perform all other actions on your AWS account.
You can create a separate IAM user with near-full permissions for use when you need to perform admin tasks, instead of using the AWS root account. If the credentials for the admin IAM user are compromised, you can use the AWS root account to disable those credentials to prevent further harm, and create new credentials for ongoing use.
However, if the credentials for your AWS root account are compromised, the person who stole them can take over complete control of your account, change the associated email address, and lock you out.
I have consulted for companies who lost control over the root AWS account which contained their assets. You want to avoid this.
Given:
The AWS root account is not required for regular use as long as you have created an IAM user with admin privileges
Amazon recommends not using your AWS root account
You can’t accidentally expose your AWS root account password if you don’t know it and haven’t saved it anywhere
You can always reset your AWS root account password as long as you have access to the email address associated with the account
Consider this approach to improving security:
With Amazon’s announcement that SSD is now available for EBS volumes, they have also declared this the recommended EBS volume type.
The good folks at Canonical are now building Ubuntu AMIs with EBS-SSD boot volumes. In my preliminary tests, running EBS-SSD boot AMIs instead of EBS magnetic boot AMIs speeds up the instance boot time by approximately… a lot.
Canonical now publishes a wide variety of Ubuntu AMIs including:
Matrix that out for reasonable combinations and you get 492 AMIs actively supported today.
The EC2 create-image API/command/console action is a convenient trigger to create an AMI from a running (or stopped) EBS boot instance. It takes a snapshot of the instance’s EBS volume(s) and registers the snapshot as an AMI. New instances can be run of this AMI with their starting state almost identical to the original running instance.
For years, I’ve been propagating the belief that a create-image call against a running instance is equivalent to these steps:
stopregister-imagestartHowever, through experimentation I’ve found that though create-image is similar to the above, it doesn’t have all of the effects that a stop/start has on an instance.
Specifically, when you trigger create-image,
the Elastic IP address is not disassociated, even if the instance is not in a VPC,
the Internal IP address is preserved, and
the ephemeral storage (often on /mnt) is not lost.
I have not tested it, but I suspect that a new billing hour is not started with create-image (as it would be with a stop/start).
So, I am now going to start saying that create-image is equivalent to:
use concurrent AWS command line requests to search the world for your instance, image, volume, snapshot, …
Amazon EC2 and many other AWS services are divided up into various regions across the world. Each region is a separate geographic area and is completely independent of other regions.
Though this is a great architecture for preventing global meltdown, it can occasionally make life more difficult for customers, as we must interact with each region separately.
One example of this is when we have the id for an AMI, instance, or other EC2 resource and want to do something with it but don’t know which region it is in.
This happens on ServerFault when a poster presents a problem with an instance, provides the initial AMI id, but forgets to specify the EC2 region. In order to find and examine the AMI, you need to look in each region to discover where it is.
configure your own ssh username in user-data
The official Ubuntu AMIs create a default user with the username ubuntu which is used for the initial ssh access, i.e.:
ssh ubuntu@<HOST>
You can create other users with your preferred usernames using standard Linux commands, but it is difficult to change the ubuntu username while you are logged in to that account since that is one of the checks made by usermod:
$ usermod -l myname ubuntu
usermod: user ubuntu is currently logged in
There are a couple ways to change the username of the default user on a new Ubuntu instance; both passing in special content for the user-data.
Each AMI publisher on EC2 decides what user (or users) should have ssh access enabled by default and what ssh credentials should allow you to gain access as that user.
For the second part, most AMIs allow you to ssh in to the system with the ssh keypair you specified at launch time. This is so common, users often assume that it is built in to EC2 even though it must be enabled by each AMI provider.
Unfortunately, there is no standard ssh username that is used to access EC2 instances across operating systems, distros, and AMI providers.
Here are some of the ssh usernames that I am aware of at this time:
Worth switching.
Amazon shared that the new c3.* instance types have been in high demand on EC2 since they were released.
I finally had a minute to take a look at the specs for the c3.* instances which were just announced at AWS re:Invent, and it is obvious why they are popular and why they should probably be even more popular than they are.
Let’s just take a look at the cheapest of these, the c3.large, and compare it to the older generation c1.medium, which is similar in price:
Here’s a useful tip mentioned in one of the sessions at AWS re:Invent this year.
There is a little known API call that lets you query some of the EC2 limits/attributes in your account. The API call is DescribeAccountAttributes and you can use the aws-cli to query it from the command line.
For full JSON output:
aws ec2 describe-account-attributes
To query select limits/attributes and output them in a handy table format:
My favorite session at AWS re:Invent was James Saryerwinnie’s clear, concise, and informative tour of the aws-cli (command line interface), which according to GitHub logs he is enhancing like crazy.
I just learned about a recent addition to aws-cli: The --query option lets you specify what parts of the response data structure you want output.
Instead of wading through pages of JSON output, you can select a few specific values and output them as JSON, table, or simple text. The new --query option is far easier to use than jq, grep+cut, or Perl, my other fallback tools for parsing the output.
aws --query ExamplesThe following sample aws-cli commands use the --query and --output options to extract the desired output fields so that we can assign them to shell variables:
use aws-cli to extend expiration and restart the delete or archive countdown on objects in an S3 bucket
S3 buckets allow you to specify lifecycle rules that tell AWS to automatically delete or archive any objects in that bucket after a specific number of days. You can also specify a prefix with each rule so that different objects in the same bucket stay for different amounts of time.
Example 1: I created a bucket named
logs.example.com(not the real name) that automatically archives an object to AWS Glacier after it has been sitting in S3 for 90 days.
Example 2: I created a bucket named
tmp.example.com(not the real name) that automatically delete a file after it has been sitting there for 30 days.
This works great until you realize that there are specific files that you want to keep around for just a bit longer than its original expiration.
You could download and then upload the object to reset its creation date, thus starting the countdown from zero; but through a little experimentation, I found that one easy way to reset the creation/modification timestamp on an S3 object is to ask S3 to change the object storage method to the same storage method it currently has.
The following example uses the new aws-cli command line tool to reset the timestamp of an S3 object, thus restarting the lifecycle counter. This has an effect similar to the Linux/Unix touch command.