AWS Step-by-Step
General Best Practices for AWS Admins, Part 1
I recently realized that it has been 10 years since I started writing about AWS. During that time, I have spent a lot of time figuring out what works and what doesn't. As such, I wanted to share with you some of the general AWS best practices that I have adopted for AWS administration. There are also best practices associated with all of the individual AWS services, and I might write about some of those in future blog posts. For now, though, I want to talk about best practices pertaining to AWS as a whole.
1. Cleanliness Counts
Although it might sound a little bit weird at first, my number one best practice is to always remember that cleanliness matters. Let me explain.
First and foremost, the idea of maintaining a clean account means deleting AWS resources that you no longer need. After all, failing to deprovision resources that you no longer use results in unnecessary costs and those resources can also potentially increase your attack surface. However, there is another aspect to account cleanliness that is just as important, but often overlooked.
One of my governing philosophies when working with AWS is to keep my AWS infrastructure as simple as I can. Yes, this helps to control costs, but there is more to it than that. Streamlining generally means that fewer resources are created, and reducing the number of resources deployed in the cloud also means that you are reducing your chances of having a problem. Even if a problem does occur, the simpler and less cluttered your AWS footprint is, the easier it will be to troubleshoot the problem. Simply put, fewer resources equals fewer problems.
And while I am on the subject of account cleanliness, I also want to quickly mention that the idea of maintaining a clean account goes well beyond infrastructure components. It also means getting rid of access control mechanisms that you no longer need. As an example, you should make a habit of removing old keys that are no longer needed. Likewise, don't create any more security groups than you need to, and get rid of those that are no longer used.
2. The Root Account Should be for Emergency Use Only
While it may be tempting to use the AWS root account as the main administrative account for AWS, it's best to reserve the root account for emergency use. There are a couple of different reasons for this.
First, the root account is highly privileged and has access to almost everything. It's rare that a single administrator is going to need that kind of access. It's better from a security standpoint to create individual admin accounts that have been assigned exactly the permissions that the account owner needs, and nothing more. This approach not only helps with meeting compliance requirements, it also helps to minimize the blast radius in the event that the account were to become compromised.
The other reason why it is so important to only use the root account for emergencies is that the root account has control over all of your other admin accounts and has access to your method of payment. If you were to use the root account on a day-to-day basis and that account were to become compromised, the attacker could easily lock you out of your own account, use your AWS account to deploy a botnet, and run up a huge bill.
Some other security best practices include using MFA everywhere and practicing least privilege access. It's also important to have a system in place for regularly reviewing roles and permissions and for revoking any access that is no longer needed.
3. Tag Everything
I have written articles in the past discussing various approaches to managing tags in AWS, so I don't want to go too deeply into the subject of tagging. What I will say is that any resource that you create in the AWS cloud should be tagged, regardless of what that resource might be.
Every organization is probably going to adopt its own unique approach to tagging, but at a minimum, your tags should convey the resource's creator or owner and what the resource is used for. Without this information, it's nearly impossible to accurately determine whether or not a given resource is still in use.
These are just a few of the best practices that I have adopted. I will share some more in Part 2 of this series.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.