The first things we check when we open your AWS account

TL;DR

• A RavGB infrastructure review opens with the AWS bill, because waste is the fastest problem to find and cloud bills are commonly full of it.
• From there we check identity and access, backups you can actually restore from, single points of failure, monitoring, and whether the account can be rebuilt from code.
• Each area maps to a well-understood principle, and we link an authoritative source for most of them so you can read past our summary.
• You get a short written report: what works, what is fragile, and the three fixes that matter most, with the effort and cost for each.
• Nothing locks you in. The account stays yours, and there is nothing of ours left in it when we finish.

When we open an AWS account for a review, we are not hunting for things to criticise. Early-stage infrastructure almost always grows by accident. Someone spins up what they need to ship, it works, and there is never a quiet week to go back and look at it properly. That is normal, and it is not a failure. It is what busy teams produce. A review is the quiet week you never got. Here is the order we work through, and the reason each step sits where it does.

Start with the bill, because waste is the loudest signal

Money is the fastest way to find problems, so we pull the cost and usage breakdown first. We are looking for the things you pay for every month but do not use. Idle compute that someone left running after a test. Databases provisioned two sizes larger than the workload needs. Volumes that are unattached, sitting there billing you for storage with nothing plugged into them. Snapshots from a migration a year ago that nobody has deleted. Data parked in a hot, expensive storage tier when it is read once a quarter and belongs somewhere cold.

None of this is exotic. It is the ordinary sediment that settles in any account that has been shipping for a while. The useful thing about cost is that it is honest. A resource you are paying for and not using shows up as a line on the bill whether or not anyone remembers creating it. That makes the bill a map of forgotten decisions, and the waste is commonly large enough that clearing it is the first thing worth doing.

We do not guess at this. The approach follows the AWS Well-Architected cost optimization guidance, which lays out how to match spend to the work being done rather than to the shape of the account on the day it was built. A founder reading their own bill should ask a short version of the same questions. What is running right now that nothing depends on. What is sized for a load we do not have. What are we storing that we will never read again. Those three questions find most of the money.

Identity and access: who can do what, and who should not

Once the waste is mapped, we look at access, because this is where a quiet problem turns into a loud one. We check whether anyone still uses the root account for daily work, which it was never meant for. We look for access keys that were created long ago and never rotated, the kind that get pasted into a script and then live forever. We look at whether every person and every service has far more permission than the job actually requires, because over-broad roles are the default that nobody circles back to tighten.

The reason this matters is not abstract. Industry reporting puts misconfiguration and leaked or over-permissioned credentials near the top of the list of how accounts get breached, year after year. The OWASP Top Ten has listed broken access control and security misconfiguration among its leading categories for exactly this reason. The breaches that hurt early teams are rarely clever. They are an old key in a public repository, or a role that could do far more than it ever needed to.

The fix is cheap, which is the good news. Least privilege means giving each identity the narrow set of permissions its job needs and nothing spare. Rotating or removing long-lived keys closes the window an attacker would use. Moving daily work off the root account and putting multi-factor authentication on it removes a whole class of bad day. AWS publishes a clear, specific list of IAM best practices that we work from, and a founder can read the same list and sanity-check their own account against it in an afternoon. This is some of the highest-value tightening you can do, because it is low effort and it removes risk rather than adding features.

Can you actually recover, or do you just hope you can

Next we look at backups, and specifically at whether anyone has ever restored from one. A backup you have never tested is not a plan. It is a hope with a cron job attached. Plenty of teams discover during a real incident that the backup was silently failing, or that it captured the database but not the configuration needed to make the database useful, or that the restore takes eight hours when the business can tolerate two.

So we check three things. First, that the data that matters is actually backed up, not just the parts someone remembered. Second, that the backups do not live in the same place as the thing they protect, because a failure that takes out the primary should not take out its only copy with it. The old 3-2-1 habit still holds: keep more than one copy, on more than one kind of storage, with at least one copy kept separately from the rest. Third, and most important, that someone has done a restore drill recently enough to trust it. The AWS Backup documentation covers the mechanics of centralising and automating this across services, but the mechanics are the easy part. The discipline is running the restore before you need it, on a normal Tuesday, so that the one time you need it at 2am it is a procedure and not an experiment.

Single points of failure and the shape of resilience

Then we map where the account breaks. Every system has points where one thing failing takes everything with it. The single server that the whole product runs on. The one person who knows how a service is deployed and keeps that knowledge in their head. The step in the release that only works because someone remembers to do it by hand. These are the parts that turn a small incident into a long one, because the fix depends on a thing or a person that is not available right when you need it.

We are not prescribing a globally redundant, multi-region architecture for a team that does not need one yet. That would be its own kind of waste. The AWS Well-Architected Framework is useful here precisely because it frames reliability as a set of trade-offs you make on purpose rather than a box you tick. The right question for an early team is not “are we infinitely resilient” but “if this one thing fails tonight, what happens, and is that acceptable for where we are.” Writing that answer down, honestly, for each weak point, is most of the work. The fixes often turn out to be small once the risk is named.

Observability: find out before your users do

A system you cannot see is one you can only debug after it has already hurt someone. So we check what you would actually learn when something goes wrong, and when you would learn it. Are there alerts on the things that matter, like error rates, latency, disk filling up, and the bill spiking. Do those alerts reach a human through a channel that human actually reads. Is there enough logging and metrics to answer the question “what just happened” without adding instrumentation in the middle of the incident.

The goal is simple to state and easy to neglect: you should find out about a problem before your users tell you about it. Teams that get paged by a customer email instead of a monitor are always a step behind, reacting to damage rather than preventing it. Good observability does not mean an expensive, sprawling monitoring stack. For most early teams it means a small number of well-chosen alerts that fire on real problems and stay quiet otherwise, so that an alert means something and nobody learns to ignore them.

Infrastructure as code and whether you can rebuild

Finally we look at reproducibility. If your account was configured by hand in the console, click by click, then the account lives in one person’s memory and in whatever they happened to remember to document. That is fragile in a specific way: you cannot reliably rebuild it, you cannot review a change before it happens, and you cannot easily stand up a copy to test against.

Infrastructure as code fixes this by making the account a thing you can read, review, and recreate. The configuration lives in a repository, changes go through the same review as application code, and a new environment is something you build from the definition rather than from memory. We work with CloudFormation, Terraform, and Pulumi, and the aim is always the same: an account you can reason about and rebuild, not one that only exists because nobody has turned it off. This is the step that makes every earlier step durable, because a fix you apply by hand drifts back, while a fix encoded in the definition stays fixed.

What you actually get

The deliverable is deliberately small. You get a short written report with three parts: what is working and should be left alone, what is fragile and why, and the three fixes most worth doing first, each with a rough sense of the effort and the cost. We rank ruthlessly, because a list of forty things is a way of telling you nothing. Three fixes you will actually make beat forty you will not.

You can act on that report with us or without us. If you want the changes made, we will make them. If you want to hand the report to your own engineer, it is written to be read that way. Either path is fine, and we say which is which rather than steering you toward the one that bills more. Nothing we touch locks you in. When the engagement ends, the account is yours and there is nothing of ours left in it to remove. That is the same honesty we try to hold everywhere, and we have written separately about why we tell you what we cannot do yet, because scoping a review honestly is the same discipline as scoping anything else.

This is work drawn from years of production DevOps experience, not a checklist assembled last week. The DevOps page sets out the full shape of how you can hire us, from a one-off review like this one to ongoing help, and you can see the rest of what the studio does on the services page.

Start a DevOps review

If your infrastructure grew by accident and you want someone to look at it properly before it has a loud day, this review is where to start. It is a fixed-fee, time-boxed look at the account with a written report at the end, and no commitment beyond it. Tell us what you are running and we will take a look.

Start a DevOps engagement