AWS Best Practices Guide

In this blog, we will cover essential security practices for AWS, focusing on EC2 roles, IAM, and S3. We'll explore how to securely manage application access using EC2 roles instead of embedding credentials, streamline permissions with IAM groups, and set up automated security audits using CloudTrail. Additionally, we'll dive into best practices for S3, including bucket naming for SSL compatibility, optimizing performance with random key prefixes, and how integrating CloudFront with S3 can enhance content delivery speed and scalability.

Security

EC2 Roles : Use EC2 roles, do not give applications an IAM account.

If your application has AWS credentials baked into it, you’re “doing it wrong”. One of the reasons it’s important to use the AWS SDK for your language is that you can really easily use EC2 IAM roles. The idea of a role is that you specify the permissions a certain role should get, then assign that role to an EC2 instance. Whenever you use the AWS SDK on that instance, you don’t specify any credentials. Instead, the SDK will retrieve temporary credentials which have the permissions of the role you set up. This is all handled transparently as far as you’re concerned. It’s secure, and extremely useful.
Group Permissions : Assign permissions to groups, not users.

Managing users can be a pain, if you’re using Active Directory, or some other external authentication mechanism which you’ve integrated with IAM, then this probably won’t matter as much (or maybe it matters more). But I’ve found it much easier to manage permissions by assigning them only to groups, rather than to individual users. It’s much easier to rein in permissions and get an overall view of the system than going through each individual user to see what permissions have been assigned.
Security Audit : Set up automated security auditing.

It’s important to keep track of changes in your infrastructure’s security settings. One way to do this is to first set up a security auditer role (JSON template), which will give anyone assigned that role read-only access to any security related settings on your account. You can then use this rather fantastic Python script, which will go over all the items in your account and produce a canonical output showing your configuration. You set up a cronjob somewhere to run this script, and compare its output to the output from the previous run. Any differences will show you exactly what has been changed in your security configuration. It’s useful to set this up and just have it email you the diff of any changes.
CloudTrail : Use CloudTrail to keep an audit log.

CloudTrail will log any action performed via the APIs or web console into an S3 bucket. Set up the bucket with versioning to be sure no one can modify your logs, and you then have a complete audit trail of all changes in your account. You hope that you will never need to use this, but it’s well worth having for when you do.

IAM - Identity and access management

Use IAM Roles

Don’t create users for application, always use IAM roles if you can. They simplify everything, and keeps things secure. Having application users just creates a point of failure (what if someone accidentally deletes the API key?) and it becomes a pain to manage.
Multiple API Keys : Users can have multiple API keys.

This can be useful if someone is working on multiple projects, or if you want a one-time key just to test something out, without wanting to worry about accidentally revealing your normal key.
Multi-factor Auth : IAM users can have multi-factor authentication, use it!

Enable MFA for your IAM users to add an extra layer of security. Your master account should most definitely have this, but it’s also worth enabling it for normal IAM users too.

S3 Bucket

Bucket Names: Use ”-” instead of ”.” in bucket names for SSL.

If you ever want to use your bucket over SSL, using a ”.” will cause you to get certificate mismatch errors. You can’t change bucket names once you’ve created them, so you’d have to copy everything to a new bucket.
Avoid FS Mounts : Avoid filesystem mounts (FUSE, etc).

I’ve found them to be about as reliable as a large government department when used in critical applications. Use the SDK instead.
Cloudfront and S3 : You don’t have to use CloudFront in front of S3 (but it can help).

If all you care about is scalability, you can link people directly to the S3 URL instead of using CloudFront. S3 can scale to any capacity, so is great if that’s all your care about. Additionally, updates are available quickly in S3, yet you have to wait for the TTL when using a CDN to see the change (although I believe you can set a 0s TTL in CloudFront now, so this point is probably moot).

If you need speed, or are handling very high bandwidth (10TB+), then you might want to use a CDN like CloudFront in front of S3. CloudFront can dramatically speed up access for users around the globe, as it copies your content to edge locations. Depending on your use case, this can also work out slightly cheaper if you deal with very high bandwidth (10TB+) with lower request numbers, as it’s about $0.010/GB cheaper for CloudFront bandwidth than S3 bandwidth once you get above 10TB, but the cost per request is slightly higher than if you were to access the files from S3 directly. Depending on your usage pattern, the savings from bandwidth could outweigh the extra cost per request. Since content is only fetched from S3 infrequently (and at a much lower rate than normal), your S3 cost would be much smaller than if you were serving content directly from S3. The AWS documentation on CloudFront explains how you can use it with S3.
S3 Keys : Use random strings at the start of your keys.

This seems like a strange idea, but one of the implementation details of S3 is that Amazon use the object key to determine where a file is physically placed in S3. So files with the same prefix might end up on the same hard disk for example. By randomising your key prefixes, you end up with a better distribution of your object files. (Source: S3 Performance Tips & Tricks)