Architecture review (Well-Architected style)
The review is structured around the six pillars of the AWS Well-Architected Framework: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. It is an independent review in that style, not an official AWS or AWS Partner review.
I review the infrastructure itself, not just a questionnaire: your cloud accounts, infrastructure code, CI/CD pipelines, monitoring and billing data, with read-only access. Then I talk to the engineers who run it, because the riskiest parts are often the ones nobody wrote down. Each finding is scored by risk and effort, so quick wins are easy to separate from roadmap items.
- Security: access and permissions, secrets, encryption, network exposure and logging
- Reliability: single points of failure, backups and recovery, scaling limits and what happens when a service fails
- Operations: deployments, monitoring, alerting and how quickly you can find and fix a fault
- Performance: compute, database and storage choices measured against real load
- Cost: spend by service and environment, waste, and cost per customer
- Sustainability: idle and oversized resources that use money and energy for no benefit
Cloud cost optimisation
Cloud bills grow quietly. Environments are created for a test and never removed, servers are sized for a launch spike that never came, and logs and backups pile up for years. My cost work is right-sized cloud architecture and automation that cut infrastructure bills, without trading away reliability or security.
I start with where the money actually goes, broken down by service, environment and, where tagging allows, product or customer. Every recommendation in the report comes with an estimated saving and the effort to make it, so you can decide what is worth doing. I won’t promise a figure before I’ve seen your billing data.
- Right-sizing compute and databases to the load they actually carry
- Removing idle resources and scheduling non-production environments to switch off out of hours
- Moving suitable workloads to serverless, with Lambda and API Gateway, or to containers
- Storage lifecycle rules for S3, logs and backups
- Commitment discounts, once the architecture has been right-sized
- Data transfer and caching, including Cloudflare in front of your application
- Tagging and cost reporting, so each team can see what it spends
Kubernetes, Terraform and CI/CD
Infrastructure that only exists in someone’s console is a risk: hard to review, hard to rebuild and hard to show an auditor. I move it into Terraform, so every change is reviewed, versioned and repeatable, and a new environment can be created from code.
Kubernetes is powerful, and often more than a startup needs. For a small team, serverless or simpler container hosting with Docker can cost less to run and less to maintain, and I’ll tell you honestly which fits. Where Kubernetes is the right call, I set it up with sensible defaults for scaling, secrets, health checks and resource limits.
For delivery, I build CI/CD pipelines in GitHub Actions with tests, security scanning, protected branches and staged releases, plus the observability to see what each release changed. It is the same platform reliability, observability and release engineering work I lead as Head of Engineering (AI & Cloud) at Magnus Infotech.
Multi-cloud: Azure and GCP
I work hands-on with AWS, including EC2, Lambda, S3, API Gateway, Cognito and Textract, and with Azure and GCP. Plenty of companies run on more than one, and the review covers all three with the same pillars and the same report format.
Multi-cloud should be a decision, not an accident. Using GCP for Vertex AI while the rest of the product runs on AWS can make sense. Running the same workload in two clouds for resilience often adds more cost and complexity than it removes, unless a customer or regulator requires it. I look at where data moves between clouds, what that costs, and whether identity, logging and security controls are consistent across them.
For companies working towards SOC 2 or ISO 27001, the review highlights the cloud controls an auditor will expect and feeds straight into a readiness engagement. Investors commissioning technical due diligence get the same cloud and cost analysis inside their report.
What you get
- A written review across the six Well-Architected pillars, with risk-scored findings
- A cost breakdown by service and environment, with an estimated saving and effort for each recommendation
- A prioritised plan: quick wins, roadmap items and what to leave alone
- Architecture diagrams of what runs today and the recommended target
- Security and compliance findings mapped to what a SOC 2 or ISO 27001 auditor will expect
- A walkthrough with your engineers and a plain-English summary for leadership
How it works
Step 01 · Before the review
Scope and access
NDA first, then a call on your product, cloud setup and concerns. You get a written scope and a fixed or capped price, and I ask for read-only access to accounts, infrastructure code and billing data.
Step 02 · Weeks 1–2
Review
Hands-on review of the accounts, infrastructure code, pipelines, monitoring and costs, plus working sessions with the engineers who run them. Anything urgent, such as exposed data, is reported to you the same day.
Step 03 · End of week 2
Report and walkthrough
Risk-scored findings, cost recommendations and a prioritised plan, then a walkthrough with your team to agree priorities and owners.
Step 04 · Optional, quoted separately
Implementation
If you want help making the changes, I quote a fixed or capped price and work alongside your team in Terraform and CI/CD, so every change is reviewable and repeatable.
Proof
“He has been instrumental in leading key security initiatives that have significantly strengthened our company’s overall security posture.”
Sam Tszho Ho
Head of AI and Platform
“What truly sets Arslan apart is the ability to communicate complex technical concepts in a clear and accessible manner.”
Ivan Zoria
Software Engineer
“He was able to deliver many parts of our system, communicate efficiently, and was fun to work with throughout the engagement.”
Chen Atlas
CTO & Founder, Optery
Price
From £3,500. For a fixed-scope architecture and cost review. Implementation is quoted separately, once we know what needs to change. Every engagement starts with a free 1-hour intro call, and you get a written scope with a fixed or capped price before any work starts.
FAQ
How much does an AWS architecture review cost in the UK?
My architecture and cost reviews start from £3,500 for a fixed scope. The price depends on the number of accounts, environments and products in scope, and whether Azure or GCP are included. Implementation is quoted separately, once the review shows what needs to change.
How much could we save on our AWS bill?
I can’t give an honest figure before I’ve seen your billing data and architecture, and I’d be wary of anyone who does. The review gives you an estimated saving and the effort involved for every recommendation, so you can decide what is worth doing.
Is this an official AWS Well-Architected Review?
No. I’m an AWS Certified Solutions Architect – Professional, but I’m not an AWS Partner, and this is not an AWS or AWS Partner programme. The review follows the six pillars of the AWS Well-Architected Framework, carried out independently, with findings specific to your system.
What access do you need to our AWS account?
Read-only access through a role you create and can revoke as soon as the review ends, plus read access to your infrastructure code and billing data. I don’t need write access for the review, and I sign an NDA before discovery.
Does a startup need Kubernetes?
Often not. Kubernetes suits teams running many services with the people to operate it, while smaller teams are usually better served by serverless or simpler container hosting. I recommend the simplest setup that meets your scale, security and compliance needs.
Can you make the changes as well as recommend them?
Yes. Implementation is scoped and priced in writing after the review. I work in Terraform and your CI/CD pipelines alongside your engineers, so the changes are reviewed, repeatable and owned by your team afterwards.