Cloud Architecture Self-Assessment

So every question here is about behaviour, not inventory. Not whether you have backups, but when you last restored one. Not whether you have monitoring, but who finds out first when the site stops. A team with no tools and a rehearsed recovery plan scores better than a team with a dashboard nobody watches. That is deliberate, because that is how it plays out in practice.

The structure comes from the AWS Well-Architected pillars. That is borrowed vocabulary and nothing more. This is not a Well-Architected Review, which runs to hundreds of questions, needs access to your account, and takes days rather than minutes.

Every point comes from something you typed

Nothing is scanned. Nothing is measured. Nothing is looked up. The tool never opens a connection to your infrastructure, and it could not verify a single answer if it wanted to.

That is worth saying plainly, because it sets the limits. An optimistic answer produces an optimistic score. So the useful way to fill this in is to answer as your worst week would answer, not your best. If you want something that tests your setup from the outside instead, use the Website Health Check.

The scoring is arithmetic, and all of it is printed

Each answer is worth 2, 1 or 0. Every question weighs the same inside its pillar. Every pillar weighs the same overall.

Then the overall score is the mean of the 4 pillar scores, not total points over total points. Those two produce different numbers, and the difference matters: Operational Excellence has five questions rather than four, and averaging the pillars stops that extra question quietly buying it more influence than the rest.

There is no multiplier anywhere. No industry benchmark, no weighting table, no adjustment. The breakdown shows every answer next to what it scored, so you can rebuild the number by hand if you want to.

Reliability — what happens when something breaks

R1, how many machines. One machine is one failure domain. Two machines in the same rack are nearly one. Spreading across data centres or availability zones is what turns a total outage into a degraded one.

R2, the last restore test. This is the most important question on the page. Backups fail quietly: the job reports success, the file gets written, and the missing table only surfaces on the day you need it. A backup nobody has restored is a hypothesis, not a plan.

R3, the single point of failure. Most small setups have one. Knowing which component it is, and having written down what to do about it, is most of the value. Not knowing is the problem.

R4, recovery targets. How long can you be down, and how much data can you lose? Without numbers, every recovery decision gets argued during the incident, which is the worst possible time.

Operational Excellence — how fast you can respond

O1, how changes reach production. Manual deployment is not just slow. It is unrepeatable, which means the thing you tested and the thing you shipped are not provably the same.

O2, rollback. An untested rollback is the same as no rollback, because you will be finding out whether it works while the site is down. Rehearsing it once turns a bad afternoon into twenty minutes.

O3, how you learn about outages. If customers tell you first, the entire detection window is outside your control, and it costs goodwill on top of revenue. This is usually the cheapest gap on the whole page to close.

O4, logs and metrics. Logs on the box are fine until the box is the problem. Centralised and searchable is the difference between diagnosing an incident and guessing at it.

O5, infrastructure as code. A server built by hand can be rebuilt by hand, eventually, by whoever built it. Defined in code, it can be rebuilt by anyone, in minutes, exactly as it was.

Security — blast radius when something gets in

S1, how people sign in. Shared logins remove two things at once: knowing who did what, and revoking one person without disrupting everybody. It is also usually the account that can delete the backups.

S2, patching. Most compromises use a known vulnerability with a patch already available. A schedule beats good intentions here, and automation beats a schedule.

S3, where secrets live. A credential committed to a repository stays in the history after the file is deleted. So the fix has two halves, and rotating the values matters more than moving them.

S4, backup isolation. Backups in the same account as production share its fate. Whoever gets in, and whoever accidentally runs the wrong command, reaches both.

Performance Efficiency — what happens under load

P1, doubling traffic. Fixed capacity is a perfectly reasonable choice, right up until the day it is not. The question is whether you know which day that is.

P2, CDN and caching. A cache in front is usually the cheapest performance work available, and it doubles as protection when traffic spikes.

P3, a measured baseline. Without one you cannot tell a slow day from a developing problem, so the first real signal is a complaint.

P4, slow queries. Database queries degrade gradually as data grows. Tracking them catches the problem months before it becomes an outage.

Reliability is the weak pillar

Usually this is one untested restore and one component with nothing behind it. Start with the restore. Pull last night's backup into a scratch environment and bring the application up against it. You learn two things: whether it works, and how long it takes. Most people are wrong about the second one.

Then draw the dependency chain on paper and find the box that has no second. You do not have to fix it immediately. Writing down what to do when it fails already moves you from zero to one.

Operational Excellence is the weak pillar

This is the pillar that makes every other problem slower to fix, so it is often the best place to spend first. It is also the cheapest.

Take them in this order: alerting, then rollback, then deployment, then logs. Alerting first because it shortens every future incident. Rollback second because it makes shipping safe. Automating the deployment is more work than either and pays off once the first two exist.

Security is the weak pillar

Individual accounts with multi-factor is usually an afternoon, and it is the highest-return change available on most small setups. Do that before anything else on this list.

Then move secrets out of the repository and rotate every one of them. Rotation is the half that gets skipped, and skipping it means the old values are still valid in the git history. After that, get patching onto a schedule and move one copy of the backups somewhere production cannot reach.

Performance Efficiency is the weak pillar

Measure before you buy anything. A baseline costs nothing and it tells you whether the problem is the database, the application or the network. Without it, scaling up is guesswork that happens to be expensive.

After that, a CDN in front of static assets is normally the largest improvement for the smallest change. Autoscaling comes last, because it multiplies whatever you already have, including the problems.

Everything scored badly

That is more common than you would think, and it almost always means the setup grew rather than got designed. Nobody chose this. It accumulated.

So do not try to fix it all at once. Take the four highest-return items in order: restore a backup, turn on alerting, put multi-factor on the accounts, and write down what happens when the main server dies. That is a week of work spread over a month, and it moves the score more than any rebuild would.