The last stage of the overall process consists of conducting regular performance reviews of your workload’s behavior. For that, you simply need to apply the best practices that were covered in this and previous chapters.
First, you want to automate the creation of your AWS resources to speed up your release process. So, define your Infrastructure as Code (IaC), using CloudFormation, CDK, Terraform, or any other templating engine – whichever makes more sense in your case. Once most, if not all, of your AWS resources have been coded taking an IaC approach, testing variations of your solution design becomes almost effortless to the point that it becomes an incentive to try out new things to improve your workload performance.
Make sure that you collect all relevant metrics to establish good judgment of whether your current design is optimal or not. This inevitably requires factoring cost metrics in. Anyone can increase the performance of a workload without any consideration of costs, but as the frugality Leadership Principle (LP) of Amazon says, “there are no extra points for growing budget size.” So, your objective is actually to do more with less, to perform better, and possibly optimize your costs at the same time. Therefore, make sure to factor cost metrics into your performance review and take these into account in your solution design and re-design exercises.
One additional element that needs to be taken into account is the launch of new services and features by AWS. Technology evolves fast and cloud technology evolves even faster. So, chances are that between the moment you produce your first solution design and the moment it gets released in production, AWS will have launched dozens of features, including some that may more efficiently address your workload requirements. How should you deal with AWS technology evolution? This is something important to include in your regular solution performance reviews. As an AWS solution architect, an essential part of your role is to keep up to date with AWS’ new services and features. These updates should then feed your performance reviews with fresh ideas to proactively improve the status quo. If you don’t do it, you will eventually build up technical debt in your workload. So, it is paramount to keep it in mind.
This review phase will greatly help you, especially if your workload performs poorly and misses its target.
This chapter started with the introduction of the AWS Well-Architected Framework’s performance design principles. You looked at what it actually means to architect for performance and what considerations you should make. Some of the essential services and design patterns that should be part of your toolkit as a solution architect were discussed. The chapter then concluded by focusing on the importance of monitoring, reviewing, and actually adapting your solution.
The next chapter will dive deeper into workload deployment.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
