Infrastructure as code is mentioned as a solution to many repetitive tasks. But faced with an existing compute solution running on AWS, I quickly realized how infrastructure would not help at all — The network traffic and processing power needs were not expected to increase. So followed a dialogue where infrastructure as code (enter product name <here>) was requested. However, the automation that was required was on a software layer, so Ansible and using the AWS CLI won the day.
- Check the historical needs of the running architecture. Are you well beyond the capacity of the AWS EC2 capabilities with the current instance type, then do not waste your time (or the project manager’s for that matter). If you do not have a business reason to present a spreadsheet full of instance-type metrics and differences, then refrain from spending time creating that document. For instance, when your general-purpose type with baseline CPU performance level works just fine.
- Show the data to the decision-makers. Any decision for an architectural change should be backed up by monitoring data, and so in this case, CloudWatch EC2 metrics were used as the single point of truth. CloudWatch can save you time and is one of your most important tools as an AWS architect and engineer. This also means involving the business stakeholders and the quality assurance members. Let the latter be part of the data gathering and shorten the communication paths between business and IT to make decisions faster.
- For an existing AWS solution, start the discussion with monitoring data to underpin your argument for a solution, and furthermore, for any discussions on how to go forward. Do not bring in historical performance data as an afterthought, and keep business needs and technical realities aligned.