AWS Best Practices: Five Key Approaches to Get You Started

There’s a whole mountain of official documentation on AWS 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.
Amazon EC2 Security Group Firewall

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

I’ve written about Trusted Advisor before.  As it turns out, so has the Amazon documentation team. They characterized their Trusted Advisor as

…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. To dive into the AWS Trusted Advisor service and how you can use it to benefit your AWS account, take a look at Cloud Academy’s Overview of AWS Trusted Advisor course.

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 Shared Responsibility Model


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.

Here’s a list of just some of the best practice documents currently available if you wish to continue reading on AWS best practices:

Cloud Academy