There’s a whole mountain of official documentation on AWS best practices. Here’s a list of just some of the best practice documents currently available:
- Architecting for the AWS Cloud: Best Practices
- Web Application Hosting: Best Practices
- AWS Security Best Practices Whitepaper
- Amazon Simple Email Service Best Practices Whitepaper
- IAM Best Practices
- Best Practices for DynamoDB
- Best Practices for Amazon EC2
- Trusted Advisor Best Practices
Most new users will probably have a great deal of trouble working through all that material (not that you shouldn’t try). So I’m going to try to provide you with a bit of a short cut and present what I think are the top five AWS Best Practices you absolutely must know right now.
1. AWS Best Practices: protect your AWS credentials
Your AWS account represents a business relationship between you and AWS. Since you use your root AWS account to manage your AWS resources and services, it will need full access, which requires root permissions. But with great power comes great risk.
Do not use root account credentials for day-to-day interactions with AWS!
One of the very best of AWS best practices is to avoid creating an access key for your root account. Unless, for some strange reason, you absolutely must have a root access key, it is best not to generate one. Instead, create one or more AWS Identity and Access Management (IAM) users, give them the necessary permissions, and use those users for everyday interaction with AWS.
2. AWS Best Practices: secure your Applications
Sometimes it is better to explain a concept with a picture or diagram rather than with words.
The diagram below could be a small scale deployment on AWS. You have a Web Server, an App Server, and a DB server. You should allow access from the outside world only where necessary. So a security group should be created for the web server that only allows traffic through ports 80 (HTTP) and 443 (HTTPS). Another security group could restrict traffic into the App Server to port 22 (SSH), and even then only to sessions originating from a defined range of IP addresses. All other Internet traffic should be denied.
Further security configuration could control access between the servers themselves.
3. AWS Best Practices: backup a lot and test your recovery resources before you need them
With all your AWS credentials protected and your applications secured you should be sleeping better at night. Now it’s time to start thinking about a backup and recovery plan. Here are some things that should be part of any robust backup plan.
- Regularly back up your instance using Amazon EBS snapshots or a backup tool.
- Deploy critical components of your application across multiple Availability Zones, and replicate your data appropriately.
- Design your applications to handle dynamic IP addressing when your instance restarts.
- Monitor and respond to events.
- Ensure that you are prepared to handle failover. For a basic solution, you can manually attach a network interface or Elastic IP address to a replacement instance.
- Regularly test the process of recovering your instances and Amazon EBS volumes if they fail.
4. AWS Best Practices: use the Trusted Advisor
…Your customized cloud expert! It helps you to observe best practices for the use of AWS by inspecting your AWS environment with an eye toward saving money, improving system performance and reliability, and closing security gaps.
The good news is that there are four Trusted Advisor services available at no charge:
- Service Limits Check
- Security Groups – Specific Ports Unrestricted Check
- IAM Use Check
- MFA on Root Account Check
This is a must-use tool. All you need to do is click on the Trusted Advisor icon in your AWS console under Administration & Security and the screen will appear and give you an instantaneous snapshot of the current status of the four items listed above. This is the easiest of all the AWS Best Practices listed here, so there is really no excuse for not using it.
5. AWS Best Practices: understand the AWS Shared Responsibility Model
You must know what you are responsible for and what lies under Amazon Web Services’ control. Once again rather than bore you with a long explanation, when a diagram will be more effective, see if this doesn’t make things clear.
AWS Best Practices exist because they work best. And their significance increases exponentially as the size of your deployment grows. However, figuring out what to focus on can be very confusing at first. Hopefully this article will give you some idea of where you should begin.