Cloud architecture and cost
In the cloud, every design choice turns up on a monthly bill, and a weak foundation turns up in security incidents. This lesson gives you three tools that architects use to keep both under control: the well-architected review, the landing zone and the FinOps loop.
By the end you can
- Run a well-architected review of one workload and turn the findings into a ranked risk list
- Lay out a landing zone: accounts, guardrails, identity, network and central logs
- Build a monthly cost model from business drivers, including festival peaks
- Apply the FinOps phases Inform, Optimize and Operate, in the right order
- Make cost a quality attribute with a unit cost that you track every month
The everyday picture
Picture a building with ten rented kitchens. The landlord provides power, water, gas and a fire alarm. Every kitchen pays for what it uses, by the meter, every month.
Three things decide whether this works. First, the building has rules that every tenant follows without being asked: fire doors stay closed, gas is checked once a year, nobody cooks on the roof. Second, every kitchen has its own meter, so when the gas bill doubles, you know whose oven runs all night. Third, an inspector visits with the same checklist every time, so problems are found while they are still small.
Cloud architecture has the same three parts. The building rules are the landing zone. The meters and the monthly look at them are FinOps. The inspector's checklist is the well-architected review. This lesson shows how to set up each one, with Mangrove's numbers.
Well-architected reviews: a checklist for risk
The three big cloud providers each publish a framework of questions for checking a design. The AWS Well-Architected Framework has six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. The Azure Well-Architected Framework has five (reliability, security, cost optimization, operational excellence, performance efficiency). The Google Cloud Well-Architected Framework has six, with security named "security, privacy and compliance" and performance named "performance optimization". The names differ a little; the questions are close, and you can use any of them on any cloud.
A review looks at one workload at a time, never the whole company. Here is the method:
- Scope. Name the workload, its owner and its quality-attribute scenarios from Quality attributes and constraints. A review without scenarios turns into opinions.
- Walk the pillars. For each pillar, answer the framework's questions with evidence: a dashboard, a runbook, a test result. "We think so" counts as "no".
- Record risks. Each gap becomes a finding with a level. The AWS Well-Architected Tool, a free console tool, marks answers as high risk or medium risk; use the same two levels on any cloud. A high risk is one that can break a scenario's measure or leak data.
- Plan improvements. Every high risk gets an owner, a fix, a cost and a date. Medium risks go on the backlog.
- Review again after big changes, or every six to twelve months.
The pillars pull against each other, and the review is where you make that visible. A standby database in a second zone improves reliability and roughly doubles the database line on the bill. Keeping 90 days of debug logs helps operations and costs money every day. The architect's job is to tie each choice to a scenario. If the order database must recover within five minutes (SLOs and nines), the standby is justified. The read replica for reports can be rebuilt from a backup in an hour, so it does not need one.
Quick check
A first review of Mangrove's order workload finds 14 gaps across the pillars. What should you do first?
The review exists to find the risks that matter to the business, so you rank by impact on scenarios and data. Cheap fixes feel good but may leave the dangerous gap open. Pillar order has no meaning for risk, and 14 gaps on a first review is normal.