AWS – Conducting a technology baseline review self-assessment

Later in this chapter, we will walk through a full Well-Architected review, which is an extremely beneficial exercise, but the process can seem daunting if you are new to AWS. In this recipe, you will conduct what is known as a Technology Baseline Review (TBR) – a self-assessment of your technology that is quick and easy to accomplish. You will ask yourself, and your team, a series of basic questions about your architecture that capture the essence of the Well-Architected Framework. These are the most critical elements to have in place, and you should only give yourself a passing score if you end up with 100% affirmative answers.

Be completely honest when you conduct a self-assessment! You can’t improve if you gloss over areas where you are weak and pretend you are in better shape than you actually are.

How to do it…

Ask yourself the following questions, answer honestly, and make it a priority to resolve any questions where the answer is no:

  1. Do you have Business Support or greater enabled on all production accounts?
  2. Do you use IAM users or federated users instead of the root user login for routine access to your account?
  3. Do you have IAM users or some sort of user federation in place?
  4. Have you enabled Multi-Factor Authentication (MFA) on the root account?
  5. Have you enabled AWS CloudTrail on all accounts and in all regions?
  6. Are you storing all CloudTrail logs in a separate administrative domain (a separate AWS account or equivalent)?
  7. Is the CloudTrail log storage tamper-resistant?
  8. Have you enabled MFA on all interactive IAM accounts?
  1. Are you rotating all IAM user credentials regularly?
  2. Have you configured a strong password policy for your users?
  3. Does each user have their own dedicated IAM or federated user account?
  4. Are IAM policies for users and applications scoped down to the least privilege?
  5. Do you have any hardcoded credentials?
  6. Are all stored credentials encrypted at rest?
  7. Are you regularly backing up your data?
  8. Are you testing data recovery on a regular schedule, and after any significant application changes?
  9. Do you have a Recovery Point Objective (RPO) and Recovery Time Objective (RTO) defined for your services?
  10. Is your RTO less than 1 day for all critical services?
  11. Is your Disaster Recovery (DR) plan tested regularly, and after all significant application changes?
  12. If any of your S3 buckets have public access, has this access been reviewed to make sure it is necessary, and are controls in place to limit access to data that should not be public?
  13. Are your buckets that should not be public configured correctly to prevent public access?
  14. Do you have monitoring in place to alert you if a bucket is made public?
  15. If you require access to customer accounts, do you use cross-account roles instead of IAM users?

Did you answer no to any of those questions? If so, you could be placing your business and your customers at risk.

How it works…

These questions were pulled from the AWS Well-Architected Framework and are considered the absolute minimum threshold for what is considered secure, reliable, performant, cost-efficient, and operationally excellent.

This list is based on years of experience working with customers and partners, and each of the questions represents the possibility of serious consequences if you don’t pay attention to it. The history of the internet is rife with examples of companies that have gone out of business overnight due to a hacker gaining access to cloud resources, or a failed database resulting in a complete loss of customer data.

Here’s one scenario to consider regarding the disaster recovery questions: what would happen to your company if a hacker gained access to your root access credentials, logged in to your production account, and proceeded to delete everything? What if your backups and audit logs were deleted from that account? Even a robust multi-AZ database setup with cross-region replication of backup files is not going to help you if every resource in the account is deleted. If you wake up one morning and find that your account is simply destroyed, can you recover? Will you still be in business the next day?

The answer to that question should be a confident yes!

The response to that absolute worst-case scenario should not only be rehearsed, but it should also be fully automated. By the way, I didn’t just make up that scenario to scare you. It has happened many times, both on-premises and on cloud systems. More often than not, it’s a disgruntled employee with administrator privileges who has gone rogue, but whether it’s an employee or a hacker, the results are the same.

By following the recommendations of the technology baseline review, you can make that scenario much less likely, and even if it does happen, you can be confident in your ability to recover from it.

Once you have made the necessary changes to pass this review with a 100% score, you are ready to dive deeper into the Well-Architected Framework to make even more improvements to your cloud-based applications.

There’s more…

The baseline technology review process is an integral part of the AWS Partner Network (APN). If your company aspires to become a member of the APN as a technology partner, you will need to pass a baseline review as part of advancement through the APN tiers and as part of achieving designations such as technical competencies.

If you want to learn more about the APN, check it out at the following URL: https://aws.amazon.com/partners/. For more information about the baseline process, see https://aws.amazon.com/partners/technical-baseline-review/. Also, you can see the author in a video series about baseline reviews here: https://www.youtube.com/watch?v=oCkcOxx96-Y.

If your company provides a SaaS solution on top of AWS, creates Amazon Machine Images (AMIs) for commercial purposes, or provides consulting services to companies building on AWS, then you should definitely look into joining the APN!

Comments are closed.