AWS architecture design and review, while changing it is still cheap.
Deciding what to build on AWS before anyone builds it, or reviewing the design you already have before customers depend on it. Which services, how the data is shaped, where the blast radius stops, and what this looks like at ten times the traffic. Fixed price, agreed after a scoping call.
Leads every engagement. More than five years building and operating production workloads for a B2B SaaS company, and a multi-tenant SaaS platform on AWS that we still design and run end to end.
Why architecture decisions are expensive to change later
Most of what makes an AWS environment expensive, fragile or slow is decided in the first few weeks. Which database. One account or several. How the network is split. Where state lives. Those choices are cheap on a whiteboard and expensive once customers depend on them, because changing them later is a migration rather than an edit.
Often nobody decided at all. The first engineer picked what they knew, it worked, and the system grew around it. A few years on, the team works around the architecture instead of with it, and every new feature costs more than it should. A design review is how you find that out while it is still a conversation.
What an architecture review looks at
The same questions apply whether the system is running today or still on paper.
Service choices
Whether each part of the system sits on the right AWS service for its job, or on the one someone knew at the time. Containers or functions, managed or self-hosted, and what each choice costs to run.
How the data is shaped
Where the data lives, how it is modelled, and which database fits the way it is read and written. The hardest thing to change later, so it gets the most attention.
Where the blast radius stops
Account and network boundaries, availability zones, and whether one bad deploy or one noisy customer can take everything else down with it.
Ten times the traffic
What breaks first if usage grows tenfold, and whether the fix is a setting or a redesign. Better to know now than during a launch.
Security boundaries
Who and what can reach each part of the system, where secrets are kept, and whether the IAM model still makes sense when the team doubles.
Running cost
What the design costs each month at today's load and at the next stage of growth, so the bill is a decision rather than a surprise.
How an architecture engagement runs
- Scoping call. A short call about what you are building or what already exists, and which decisions are still open. You then get a written proposal with the deliverables, a fixed price and a delivery date.
- Discovery. We read what exists: diagrams, infrastructure code, the AWS accounts themselves where there are any, and the constraints your team works under. For a running system, we start from read-only access.
- Design or review. We work through the options with your engineers, not in a separate room. Each decision is written down with the alternatives and why they lost.
- Findings. Every recommendation carries a risk rating, and anything that could touch a customer experience is marked as such.
- Handover. The design is documented so your team can build from it, with or without us.
What you get
- An architecture diagram of the system as designed, or as it stands today
- The service choices, with the reasoning behind each one
- The honest list of what the design will not handle
- Recommendations with a risk rating each, in the order to act on them
- A view of how the design behaves at ten times today's traffic
- Documentation your engineers can build from without us in the room
Reviews from people who have to live with the result
Drawing an architecture is easy. Running one for years, patching it, paying for it and restoring it at 3am is harder. We have done the second part ourselves, and alongside client work we still design and run a multi-tenant SaaS platform on AWS. When we recommend something, we have usually lived with the consequences of the same decision.
That makes us wary of complexity for its own sake. The right answer is often the plainer one: fewer services, a managed database, one clear path for a deploy. Where a design needs more than that, we say why.
If the design holds up, the next step is usually building it in Terraform. If the review shows the current system has outgrown its choices, that becomes a staged migration. And if cost is what prompted the question, the cost audit is the faster place to start.
Who this is for
Teams about to build something significant on AWS, such as a new platform or a rearchitecture, where getting the foundations wrong is expensive. Teams with a design on paper who want a second opinion before committing to it. And teams whose system has outgrown the choices it was built on. B2B SaaS is our home ground. We work with teams in Canada, the United States and Europe, remotely.
Frequently asked questions
What does an AWS architecture review include?
A written review of how your system is built on AWS: service choices, data layout, account and network boundaries, failure handling, security and running cost. Every finding carries a risk rating and a recommended fix, in the order we would make them.
Can you review a design before we build it?
Yes, and it is the cheapest time to do it. We can review a design your team has drawn up, or design the system with you from the start. Either way you get the diagram, the service choices and the reasoning behind each one.
Is the work led by an AWS Certified Solutions Architect?
Yes. Every engagement is led by an AWS Certified Solutions Architect with more than five years of hands-on experience building and operating production workloads for a B2B SaaS company.
Do you build what you design?
If you want us to. The build is usually a separate fixed-price project, with everything defined in Terraform. Your team can also build it from the design, which is written so they can.
What if the review says our architecture needs to change?
We say so, with the reasons and the order to change things in. Larger changes are planned as a staged migration, each step reversible, so the system keeps running while it moves.
How is an architecture engagement priced?
A fixed price, agreed after a short scoping call and set out in a written proposal with the deliverables and a delivery date. No hourly billing, no open-ended meters.
Related services
Get the design right before it is built
Fifteen minutes on a call is enough to tell whether a design or a review is worth it for you. If it is not, we will say so.