Most of the risk in a South African AWS workload sits in a handful of gaps that can be fixed in weeks, not years. A Well-Architected Review shows you which ones to close first, and the right handover leaves your own team able to keep them closed.
That second part is where many reviews fall short. A report that only an outside consultant understands is a report that ages badly. This article covers what we look at, what we usually find, and how we make sure the fixes outlast our time on the account.
What is an AWS Well-Architected Review?
The AWS Well-Architected Framework is AWS’s own set of questions and best practices for running workloads in the cloud. It is organised into six pillars:
- Operational excellence
- Security
- Reliability
- Performance efficiency
- Cost optimisation
- Sustainability
A review takes one workload, such as your customer portal, policy system or data platform, and checks it against each pillar with the people who build and run it. The result is a list of high and medium risks, each tied to a specific question in the framework, and a plan to address them.
At MaH Quests, reviews are led by AWS Certified Solutions Architects at Professional level. We are an AWS Select Tier Services Partner and an AWS Well-Architected Partner, and the team holds more than 50 AWS certifications and accreditations, including four FinOps practitioners.
What we usually find
Every workload is different, but the same patterns come up again and again in local workloads, whether they run in the AWS Cape Town Region (af-south-1) or further afield. These are the findings we see most often.
Reliability: one Availability Zone, and a backup nobody has restored
Many workloads start life on a single server in a single Availability Zone, with a database next to it. That is fine for a proof of concept and risky in production. The second gap is quieter: backups run every night, but nobody has timed a full restore. Until you have, your recovery time is a guess.
What closes it: a second Availability Zone for the application and the database before go-live, and a scheduled, timed restore test with the result written down.
Security: who can do what, and who would notice
Long-lived IAM users with access keys, broad administrator rights, and logs kept for too short a time are still common. So is a gap between the security controls that are switched on and the ones anyone is alerted about.
What closes it: single sign-on through AWS IAM Identity Center instead of IAM users, guardrails across accounts, and security findings routed to a person who is on call for them. For workloads that hold personal information, data discovery and a written retention schedule help you meet POPIA obligations.
Operational excellence: you cannot fix what you cannot see
Teams often have basic server metrics but no end-to-end view of a request as it moves through the application. When something slows down, people search logs by hand. Alarms exist, but no one has agreed who responds to each one.
What closes it: tracing and dependency telemetry, one operations dashboard, and an incident response plan that names an owner for each alarm.
Cost optimisation: money spent on things nobody uses
This is usually the fastest win. Common examples are storage volumes left behind after a server was replaced, public IP addresses that are allocated but idle (AWS now charges for these), monitoring checks running more often than needed, and no budget alerts at all.
What closes it: a monthly cost review, budget and anomaly alerts, cost-allocation tags, and a clear picture of what production will cost before you scale up, not after the first invoice.
Performance efficiency and sustainability: sized for a guess
Instances are often sized for a launch-day estimate and never revisited. Right-sizing and auto scaling usually improve both cost and resilience, and they reduce waste, which is what the sustainability pillar asks for.
How a review runs
Our reviews are typically completed within five days. The shape is simple:
- Scope. We agree on one workload and the people who know it best: an architect or lead developer, someone from operations, and someone who owns the budget or the risk.
- Review. We work through the six pillars together, in the AWS Well-Architected Tool, and check the answers against the account itself, not only against what people remember.
- Risk register. Every high and medium risk is recorded, with the evidence behind it.
- Prioritised plan. We rank the fixes by risk and effort, so the first items on the list are the ones that matter most and cost least.
- Walkthrough. We take your team through the findings and the plan, item by item.
Why the handover matters as much as the findings
A common failure is a box ticked during a review that does not match reality, such as “multi-AZ” marked as done on a workload that runs in one Availability Zone. That happens when the people answering the questions are not the people looking at the account. We check the evidence, and we re-measure risk counts at each milestone so progress is real rather than reported.
The other failure is a team that inherits fixes it does not understand. That is why the walkthrough is part of every review, and why remediation work comes with written runbooks: an incident response plan, a backup and recovery plan, a cost review routine. The aim is that six months from now your engineers can explain each control and keep it running without us.
This is also why we train. Our Enterprise Java on AWS programme combines 720 hours of structured learning with 1,000 hours of logged work-integrated learning in real AWS environments, and we have run Java, Quarkus and cloud training for teams such as BMW IT Hub South Africa and the Derivco Graduate Programme. The people who run what we build should be able to improve it.
A real example
For Covision’s MyLife Plus platform, an insurance workload, we ran a Well-Architected Review and followed it with a remediation plan across security, reliability, operations and cost. The workload is now being prepared for the AWS Foundational Technical Review. You can read more on our cloud page.
Frequently asked questions
How long does an AWS Well-Architected Review take?
Our reviews are typically completed within five days for one workload, including the walkthrough with your team. Remediation is planned separately, based on the prioritised list.
Do we need to be fully on AWS to have a review?
No. A review looks at one workload that runs on AWS, or is about to. Many teams book one before go-live, when fixes are cheapest.
What do we get at the end?
A risk register with the evidence for each finding, a prioritised improvement plan, and a walkthrough of both with your team. The risks are also recorded in the AWS Well-Architected Tool, so you can track progress against them.
Book a review
If you run an important workload on AWS and are not sure where its biggest risks are, a five-day review is the quickest way to find out. Book a Well-Architected Review and talk to one of our architects.