EC2, Grossly Simplified

So yeah although I’d been using AWS for a good while, I hadn’t been the one to do the actual provisioning: I recently started learning how to configure AWS and these are my continuing notes.

This post is a whizzbang super-fast careening through EC2/EBS/EFS.

EC2 Proper

I find EC2 is very much “does what it says on the tin”, so not much to say here except reminders to myself that:

• You can actually create multiple instances in one go (it’s just that the default count is 1)
• If you don’t want the root device to be nuked on terminate, you have to expressly set it so during creation.
• you can attach extra volumes besides the root device
• you can attach multiple security groups to an EC2 (which is good because your SGs can encapsulate aspects of your security scheme that EC2s can then inherit/combine as needed)
• 🚀 This is v cool: You can supply a bash script on startup (during step 3 - configuration instance details). Like, a legit, whole entire literal bash script replete with the #! /bin/bash at the top!
• network - in the config step, don’t forget to choose the desired/intended subnet to provision into!
• placement: clustered (single AZ to minimize latency), spread or partitioned (diff pieces of hardware, maximize failover)

Getting creds for invoking the AWS CLI inside an EC2 instance

So turns out if you want to use the AWS cli (you know, provision stuff etc) from inside your EC2 instance, you can’t unless you also provide your AWS credentials. Copying and pasting those to and fro is bad enough but worse, they get saved (afaics in plain text) inside ~/.aws… which, I’m sure we are all agreed, is very bad. The better way to provide credentials to your instance is:

• IAM > roles > create role
• Choose EC2
• Select the policy which provides programmatic access to aws (e.g. administrative access, or full access to a particular service, etc.)
• finish creating the role then go to the EC2 instance:
• goto Actions > Instance Settings > Replace / Attach IAM Role

Creds for the new role instantly propagate to the EC2 instance and now you can run nifty aws cli commands

Self-Awareness

Sometimes, an instance needs to know a bit about itself. Amazon provides this data at a static IP. From inside the instance, do:

> sudo su
> curl http://169.254.169.254/latest/meta-data

This will provide access to a bunch of instance-specific data. If you replace meta-data above with user-data, it’ll dump the startup script used to bootstrap the environment (the one that you supplied, remember?) to the screen.

EBS as it relates to EC2

These live under EC2 > Elastic Block Store. Don’t foresee (directly) needing these a whole lot in my scenarios, but handy to know that:

• EBS-backed volumes have to be in the same AZ as your EC2 instance
• You can create a snapshot of a volume
• you can create an image from the snapshot
• you can launch a new instance from the image…
• …and in so doing, choose the destination subnet for the new instance… which turns out to be a nifty way to move data from one place to another

When bootstrapping another vm from an image like this, the virtualization type matters. You generally want HVM (Hardware-assisted Virtualization Machine), over PV (Para virtual) for reasons that I admit to snoring through. But generally the types of AMI (images) available to you during EC2 instance creation will be kinda limited with PV. And who wants to be limited? Right?!

If you think I slept through the PV vs HVM argument I promise you I was positively comatose wrt Instance-store-backed VMs.

EFS as it relates to EC2

Elastic File System is based on linux NFS and:

• allows multiple EC2s to share the same file system
• can scale!
• The inbound rules for the security group (for the EC2 instance pool using the EFS) needs to be updated to allow NFS on TCP, port 2049
• then you you need to mount EFS from your instances

End of my notes on this.