AWS Step-by-Step
General Best Practices for AWS Admins, Part 2
In the first part of this series, I discussed some basic best practices for AWS admins. Now, I want to continue the discussion by talking about some additional best practices.
Adopt Infrastructure as Code
For those who might not be familiar with the concept of infrastructure as code (IaC), the idea is that you can use a script file or a definition file (such as a JSON or YAML file) as a mechanism for provisioning infrastructure, rather than clicking your way through the provisioning process within the AWS console. There are various tools that you can use to deploy IaC, but the tool itself is far less important than the overall concept.
At it's most basic, IaC is used for deploying resources in a standardized way. It eliminates the hassle of tedious manual configurations while also reducing the chances of human error. Once the IaC framework has been put into place, new resources can be provisioned very quickly with guaranteed adherence to your configuration requirements.
This type of automation is essential for scalability. It can also greatly simplify both troubleshooting and compliance audits since all infrastructure within AWS is configured in a standardized and predictable manner IaC can also be useful in disaster recovery situations.
One more benefit to adopting IaC is that doing so can help with configuration drift. Existing infrastructure components can be compared to the code used to deploy them. If discrepancies are found, then the infrastructure can be automatically remediated to bring it back into compliance.
As useful as IaC may be, I tend to think of it as being one part of a larger automation first mindset. In other words, if there is something within your AWS tenant that will need to be done more than once, then you should look for a way to automate it. Taking the time to automate processes now will often save you time in the future since automation tends to prevent problems stemming from human error and inconsistent configurations.
Create Subnets Based on Levels of Trust
When it comes to subnetting within AWS, there are a number of different mistakes that I have seen made over and over again. Some of these mistakes include having one giant subnet for everything (a flat network), "temporary" wide open rules that nobody ever got around to removing, trusting all internal traffic by default, or designs that are way more complex than they need to be.
While there are plenty of subnetting mistakes that should be avoided, there isn't necessarily one universally correct approach to subnetting. Each organization seems to adopt its own strategy. One strategy that I have personally found to be effective is to build subnets that effectively act as trust boundaries.
You could summarize the philosophy of subnetting by trust as the idea that if two systems do not need to directly communicate with one another then they should not be able to. However, the concept of subnetting by trust goes a little bit further than that.
One analogy that is sometimes used to explain subnetting by trust is to compare the subnets on a network to an office building. In an office building, not everyone has access to the same areas. The building's lobby for example, is generally accessible to anyone who walks in off the street. However, you wouldn't want some random person who wanders into the building to be able to go any further than the lobby. With that in mind, think of the lobby as being like the Internet facing portion of your AWS deployment. There are probably some systems that need to be publicly accessible, but Internet traffic should not be able to reach deeper into your AWS infrastructure.
Continuing with this same analogy, an office building has employee workspaces, but it also has more sensitive and restrictive areas such as locked server rooms. When it comes to AWS subnets, the employee workspaces are like those workloads that your users need direct access to, while the locked server room is more like the backend systems (think RDS databases and that sort of thing) that nobody other than IT should be touching.
Cost Management
I want to wrap things up by talking about some best practices surrounding cost management. The biggest thing to keep in mind with regard to cost governance is that cost optimization needs to be an ongoing process, not a one time task. This means regularly reviewing your AWS infrastructure to look for idle resources that might not be needed anymore or EC2 instances that have been overprovisioned. It's also important to regularly review your budgets and alerts to make sure that they are being applied correctly and that they do not need to be adjusted to reflect your evolving requirements. Finally, take the time to periodically review your auto scaling rules. Remember, systems should be designed to scale down, not just up.
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.