Every infrastructure review we run starts the same way: we put the architecture diagram next to the actual account, and they disagree. Not slightly. The diagram shows three environments; the account contains five, two of them half-decommissioned. The diagram shows one VPC; there are four, one of them peered to an account nobody in the room can name. This is not incompetence. Diagrams are drawn once, under calm conditions. Infrastructure is edited continuously, under deadline. The account is the truth; the diagram is a memory of it.
That gap is the reason we ask for read-only access before we ask for a single meeting. A viewer role tells us more in a day than a week of interviews, because interviews describe intent and the account records behavior. We cover exactly what access we request and how it is scoped in how we work; the short version is that we can see everything and change nothing.
What day one shows
With read access, the first day is inventory against reality. Resources tagged "temp" from two years ago. Security groups open to 0.0.0.0/0 on ports that were meant to be closed after a debugging session, the same unreconciled drift that makes teams afraid of terraform apply. A database in a region the company does not operate in. Load balancers pointing at zero healthy targets, still billing. None of these are findings yet. They are threads, and the review is the act of pulling them.
The categories we walk
Every account is different but the walk is the same. We work through five categories in order:
- Single points of failure: the one NAT gateway, the one Redis node, the database with no replica, the DNS zone living in a personal account
- Backup reality versus backup theory: not whether backups are configured, but whether a restore has ever been performed, and whether the keys needed to decrypt them still exist
- IAM sprawl: users who left the company eighteen months ago, access keys older than the interns, roles granted star-on-star because someone was debugging at midnight
- Cost anomalies: reserved capacity for instance families no longer in use, storage volumes orphaned from deleted machines, cross-AZ traffic nobody can explain
- Things held together by one person's memory: the deploy that only works from a specific laptop, the certificate renewal that lives as a reminder in someone's personal calendar
The last category is the one CTOs consistently underestimate. It never appears in a dashboard, because dashboards measure machines and this is a property of the org chart.
What a finding looks like
The deliverable is an itemized table, not a slide deck. Every finding carries the same four fields, and every row is actionable by your own team without hiring us again:
Severity: High
Resource: rds/prod-orders-db (ap-south-1)
Finding: Single-AZ, no replica; restore from snapshot
never tested; snapshot KMS key scheduled for
deletion in 22 days
Fix: Cancel the key deletion today; test a restore
into staging; enable Multi-AZ in the next
maintenance window
Effort: Half a day; Multi-AZ roughly doubles the
instance cost
A deck summarizes; a table assigns work. If a review ends with a presentation and no ticket-ready rows, you paid for a lecture.
The findings that surprise people
It is almost never the exotic attack surface. The findings that produce silence in the readout are mundane. The backup that has run nightly for three years and has never once been restored: here is a claim plenty of engineers will argue with, but a backup you have never restored is not a backup, it is a hope with a schedule. The former employee whose access key is still active and still used weekly by a forgotten cron job. The staging environment that costs more than production because nobody shut it down after the migration finished. And the honest one: the realization that if one specific engineer resigned, deploys would stop within a month, because the pipeline exists partly in scripts and partly in that person's head.
What we leave alone
A review is not a modernization pitch, and this is where we differ from firms that audit with one hand and sell migrations with the other. The EC2 instance running a cron job that has fired reliably for six years is not a finding. The PHP monolith serving production traffic at 20 percent CPU is not a finding. The bash deploy script is not a finding, provided it sits in version control and two people understand it. Unfashionable is not a severity level.
The popular move is the opposite: recommend Kubernetes, because a three-service stack on plain VMs looks embarrassing in a hiring post. For most small teams that migration swaps problems you understand for problems you do not, and adds a control plane as a brand new single point of failure. We would rather you spent the quarter testing restores.
This is the lens we bring to every cloud infrastructure engagement: read-only access, five categories, an itemized table your team can execute without us, and restraint about working systems that merely look dated.
One observation from years of doing this: when something breaks at 2 a.m., nobody opens the architecture diagram. They open the console. A review is that same act, performed deliberately, in daylight, before the pager forces it.