“It’s a small AWS account, nothing complicated, we just need someone to tidy it up.” That sentence has preceded more scope disasters than any other I know of in freelance cloud work, and it’s almost never a lie. The person saying it believes it, because the parts of an AWS account that make work expensive are the parts nobody looks at.<\/p>\n\n\n\n
The expensive stuff is not the running instances. It’s the access keys nobody can attribute, the CloudTrail trail that quietly stopped delivering months ago, the Terraform state that no longer matches reality, and the region somebody spun a proof of concept up in two years ago. None of that comes up on a kickoff call. All of it comes up in week three, after you’ve quoted.<\/p>\n\n\n\n
So I run an AWS account health check before I give anyone a number. It’s read-only, it takes a couple of hours, and it’s the cheapest insurance in consulting. This post is the actual check: the six passes, the commands, what each finding does to the estimate, and what to do when the client won’t give you the access to run it.<\/p>\n\n\n\n
A quote is a bet on how much unknown there is. You’re pricing the work in the brief plus everything you’ll find while doing it, and the second half is invisible until you look. Two accounts can look identical and differ by a factor of three in effort. The difference is nearly always archaeology: how much has to be reverse engineered before you can safely change anything.<\/p>\n\n\n\n
There’s a second reason that matters more than pricing. If you touch an account that already had a compromised key sitting in it, the incident becomes yours by proximity. Establishing what the account looked like before you arrived isn’t paranoia. It’s the only version of events you’ll be able to evidence later.<\/p>\n\n\n\n
I ask for a cross-account IAM role that the client creates and my account assumes. Not an IAM user. Not keys in an email. A role, with an external ID the client generates.<\/p>\n\n\n\n
The external ID solves one specific problem. Without it, a trust policy that names my account can be used by anyone who talks me into assuming a role on their behalf, and I end up acting inside a third party’s account without knowing it. AWS calls this the confused deputy problem. It’s the piece of cross-account setup people skip most often.<\/p>\n\n\n\n
On that role I ask for two AWS managed policies: The reply to that request tells you as much as the check does.<\/p>\n\n\n\n Each pass answers one question. Everything here is read-only, and the order matters, because each pass changes how you read the next.<\/p>\n\n\n\n Confirm where you actually are first. That sounds trivial until you’re in an organization with a dozen similarly named accounts.<\/p>\n\n\n\n If the third command fails because the account isn’t in an organization, that’s a finding by itself. Standalone means no service control policies, no organization trail, and no central place to revoke anything.<\/p>\n\n\n\n Then the credential surface. The summary gives counts; the credential report gives per-principal detail, including when each password and key was last used.<\/p>\n\n\n\n The report generates asynchronously, so the second call may need a retry the first time. What I read from it: how many IAM users exist at all, how many have keys that have never been used, and how many have keys last used a long time ago that are still active.<\/p>\n\n\n\n An unused key is worse than a busy one. A key in daily use is attributable to something. A key last used eighteen months ago and still enabled belongs to a person or script nobody remembers, which means nobody will notice when someone else starts using it.<\/p>\n\n\n\n Then check whether anyone has ever asked this question before you:<\/p>\n\n\n\n IAM Access Analyzer offers external access analyzers, which flag resources shared outside a zone of trust you define, and unused access analyzers, which surface unused roles, keys and passwords. Unused access analysis is billed per IAM role and user analyzed per month, so it isn’t free, but it answers the least privilege question far faster than reading policy documents by hand. An empty list means nobody has ever asked this account who can reach what.<\/p>\n\n\n\n Root closes the pass. In an AWS Organizations setup, centralized root access management lets the management account or a delegated IAM administrator remove root credentials from member accounts entirely, so there’s no root password, key or MFA device to manage per account. Live root credentials on every member account is a real finding, and one of the few security fixes that’s genuinely quick.<\/p>\n\n\n\n Pass test: you can name every principal that can reach production, and say when each last did.<\/em><\/p>\n\n\n\n This is the pass that most often changes my number, because it’s the failure that stays invisible until it isn’t. Logging that exists but has silently stopped working is more dangerous than no logging, since everybody believes they’re covered.<\/p>\n\n\n\n The first command tells you a trail is configured. The second tells you whether it’s delivering, which is the part that matters. A trail whose last delivery failed because someone edited the destination bucket policy still shows up in the console as a configured trail. The status call is where the truth is.<\/p>\n\n\n\n Multi-region matters for the same reason region sprawl does: a single-region trail records nothing about the region where somebody is quietly running compute. Check GuardDuty too, and how long logs are actually retained. Ninety days of retention against a one-year obligation is a project, not a task, and it belongs in the quote rather than in week four.<\/p>\n\n\n\n One naming trap worth knowing: AWS renamed the original Security Hub to Security Hub CSPM and launched a separate, newer service under the Security Hub name. When a client says “we have Security Hub,” ask which one, because the findings format and the configuration are not the same thing.<\/p>\n\n\n\n Pass test: a trail is delivering right now, covers every region, and its logs are kept for at least as long as the business needs them.<\/em><\/p>\n\n\n\n People forget regions. Not occasionally, constantly. A demo in Singapore, a test bucket in Ireland, a Lambda deployed from a tutorial that defaulted to us-east-1.<\/p>\n\n\n\n Left without Run the same loop shape for anything carrying state or cost: RDS instances, load balancers, EBS volumes, NAT gateways. NAT gateways are the classic. They bill hourly whether or not anything routes through them, and a forgotten one in a region nobody visits is pure waste. Then the two exposure checks I never skip:<\/p>\n\n\n\n For each bucket that matters, check its public access block configuration and its policy. An open security group on 443 in front of a load balancer is fine. An open security group on a database port is a different conversation, and you want that conversation before you own the account.<\/p>\n\n\n\n Pass test: you have a list of every region with resources in it, and nothing on that list surprises the client.<\/em><\/p>\n\n\n\n The question isn’t “do they use Terraform.” It’s whether the code still describes the account. Those diverge quietly. Somebody makes an urgent console change during an incident, never brings it back into code, and from then on the repo is fiction that plans cleanly right up until the day it destroys something.<\/p>\n\n\n\n The refresh-only plan shows where real infrastructure has drifted from state without proposing to change anything. The detailed exit code version is the one for scripts: it exits 0 for no changes, 1 for an error and 2 when there’s a diff, so you can gate on drift instead of reading output by eye.<\/p>\n\n\n\n Three things I want to know here:<\/p>\n\n\n\n Tagging belongs here too. With nothing tagged you can’t attribute cost, can’t scope a change safely, and can’t tell a production resource from an abandoned experiment. Untagged environments add hours to everything that follows.<\/p>\n\n\n\n Pass test: a refresh-only plan comes back clean, or the drift is a short list you can read out loud.<\/em><\/p>\n\n\n\n I don’t care much about the total. I care about the shape: which services dominate, whether the curve is flat or climbing, and whether anything jumped without an explanation.<\/p>\n\n\n\n The If the client wants ongoing cost visibility past what Cost Explorer offers, platforms like Vantage or CloudZero sit on the Cost and Usage Report and give per-team allocation and unit economics that native tooling makes awkward. Raise it as a separate line, not part of the engineering work.<\/p>\n\n\n\n Pass test: you can explain the top three cost lines in a sentence each, and account for every month-on-month jump.<\/em><\/p>\n\n\n\n Short pass, about escalation. What support plan is the account on, and would anything wake a human up?<\/p>\n\n\n\n Support plan matters more than people expect. On Basic you get the service limits checks and a small subset of Trusted Advisor security and fault tolerance checks, manual refresh only, and no technical support cases at all. The full check library and the Trusted Advisor API need a paid plan. If your engagement depends on opening a case during a cutover, that’s a prerequisite, not a nice to have.<\/p>\n\n\n\n There’s one date worth carrying in your head, because it’s a real deprecation rather than a version number. AWS has announced that Developer Support, Business Support and Enterprise On-Ramp are discontinued on 1 January 2027, with Business Support+ as the replacement tier. If you’re scoping anything that runs past that boundary, check which plan the client is on and whether their support cost is about to move.<\/p>\n\n\n\n Then monitoring. CloudWatch alarms wired to an SNS topic with no confirmed subscribers are the same failure as the dead trail: configured, visible, useless. If they run anything beyond alarms, whether that’s Grafana Cloud, Datadog or a self-hosted Prometheus stack, find out who holds the credentials and whether the routing has been tested this year.<\/p>\n\n\n\n Pass test: you can name the human who gets woken up, and the path that reaches them.<\/em><\/p>\n\n\n\n I don’t present these as criticism. I present them as line items with an hour estimate against each, and let the client decide what’s in scope. That conversation is much easier before a contract exists than after.<\/p>\n\n\n\n Sometimes you get twenty minutes and a screen share.<\/p>\n\n\n\n Those cover identity, evidence, blast radius, delivery speed and money. The rest of the check refines a picture these five already gave you.<\/p>\n\n\n\n Two to three hours for a single account once you have access, including the write-up. Multi-account organizations take longer but not linearly, because the interesting variation concentrates in one or two accounts and the rest are copies of a landing zone pattern.<\/p>\n\n\n\n For a short engagement, folding it into the proposal is fine. For anything substantial, or where the client is shopping several consultants, quote it as a small standalone piece with a written deliverable. It qualifies the client, protects your time, and the findings have value to them even if they hire someone else.<\/p>\n\n\n\n Quote time and materials, or quote fixed price with an explicit assumptions list naming every unknown. Do not quote a fixed price on an account you haven’t seen. The pattern that works is a small paid discovery phase, then a fixed price set once you know what you’re dealing with.<\/p>\n\n\n\n It’s broader than you probably want. The enumeration, yes, and it’s worth scripting since you’ll run it repeatedly. The interpretation, no. Whether five unused IAM users are a problem depends entirely on what the client is trying to do, and that judgement is most of what you’re selling.<\/p>\n\n\n\n Stop and tell them immediately, in writing, with timestamps. Don’t remediate unilaterally: you’re read-only, and containment steps can destroy evidence. Your job is a clear description of what you saw and when, so they can involve whoever they need to.<\/p>\n\n\n\n Especially to small accounts. Larger organizations usually have some governance, even imperfect. A three year old account at a small business that four different contractors have touched is where the surprises live, and it’s exactly the account that gets described as simple.<\/p>\n\n\n\n An AWS account health check isn’t a security exercise dressed up as sales. It’s the only reliable way to price uncertainty, and uncertainty is what you’re actually quoting on.<\/p>\n\n\n\n If you take one habit from this, take the second pass. Everything else on the list is something you’d eventually trip over while doing the work. A logging gap is different, because it stays invisible while it costs you, and by the time it matters you’re the person who was in the account when it happened. Check the trail is delivering. Then check the rest.<\/p>\n\n\n\n I do this for consultancies scoping engagements and for businesses who inherited an account they don’t fully understand. Usually that looks like:<\/p>\n\n\n\n If you’ve got a credential report, a SecurityAudit<\/code> and ViewOnlyAccess<\/code>. The pairing is the point. ViewOnlyAccess<\/code> lets you enumerate resources across services, so you can see what exists. SecurityAudit<\/code> lets you read configuration and policy documents, so you can see how it’s wired together. Neither alone gives you the picture, and neither lets you change anything. Billing is separate again: Cost Explorer read access has to be added explicitly and the feature has to be enabled in the account.<\/p>\n\n\n\n\n
\n\n\n\nThe six passes<\/h2>\n\n\n\n
Pass 1: Who can do what<\/h3>\n\n\n\n
aws sts get-caller-identity\naws iam list-account-aliases\naws organizations describe-organization<\/code><\/pre>\n\n\n\naws iam get-account-summary\n\naws iam generate-credential-report\naws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv<\/code><\/pre>\n\n\n\naws accessanalyzer list-analyzers<\/code><\/pre>\n\n\n\nPass 2: Would anyone notice<\/h3>\n\n\n\n
aws cloudtrail describe-trails \n --query 'trailList[].{Name:Name,MultiRegion:IsMultiRegionTrail,Org:IsOrganizationTrail}'\n\naws cloudtrail get-trail-status --name TRAIL_NAME_HERE\n\naws configservice describe-configuration-recorder-status<\/code><\/pre>\n\n\n\nPass 3: How wide the blast radius is<\/h3>\n\n\n\n
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do\n count=$(aws ec2 describe-instances --region \"$r\" \n --query 'length(Reservations[].Instances[])' --output text)\n echo \"$r $count\"\ndone<\/code><\/pre>\n\n\n\n--all-regions<\/code>, describe-regions<\/code> returns the regions enabled for the account, which is exactly what you want. Adding the flag pulls in disabled regions too, and the per-region calls against those just error out.<\/p>\n\n\n\naws ec2 describe-security-groups \n --filters Name=ip-permission.cidr,Values=0.0.0.0\/0 \n --query 'SecurityGroups[].{Id:GroupId,Name:GroupName,VpcId:VpcId}'\n\naws s3api list-buckets --query 'Buckets[].Name' --output text<\/code><\/pre>\n\n\n\nPass 4: Whether any of this is described in code<\/h3>\n\n\n\n
terraform plan -refresh-only\n\nterraform plan -detailed-exitcode<\/code><\/pre>\n\n\n\n\n
Pass 5: What shape the spend is in<\/h3>\n\n\n\n
aws ce get-cost-and-usage \n --time-period Start=$(date -d '6 months ago' +%Y-%m-01),End=$(date +%Y-%m-01) \n --granularity MONTHLY \n --metrics UnblendedCost \n --group-by Type=DIMENSION,Key=SERVICE<\/code><\/pre>\n\n\n\ndate -d<\/code> syntax is GNU coreutils; on macOS use the BSD equivalent or a fixed start date. Worth knowing before you loop this: the Cost Explorer API bills per paginated request, unlike the console view, so a wide query across several dimensions is a small but real charge on the client’s bill. Keep it narrow and mention it in your notes.<\/p>\n\n\n\n\n
Pass 6: What happens at two in the morning<\/h3>\n\n\n\n
\n\n\n\nThe findings that actually move the number<\/h2>\n\n\n\n
\n
If you only run five checks<\/h2>\n\n\n\n
\n
Where this check goes wrong<\/h2>\n\n\n\n
\n
Frequently asked questions<\/h2>\n\n\n\n
How long should an AWS account health check take?<\/h3>\n\n\n\n
Should I charge for the assessment?<\/h3>\n\n\n\n
What if the client won’t give me read-only access before signing?<\/h3>\n\n\n\n
Is ReadOnlyAccess enough on its own?<\/h3>\n\n\n\n
ReadOnlyAccess<\/code> extends to reading data in some services, not just configuration, which is more than you need for scoping and more than many clients will be comfortable granting. The SecurityAudit<\/code> and ViewOnlyAccess<\/code> pairing is narrower and easier to justify in writing.<\/p>\n\n\n\nCan I automate the whole thing?<\/h3>\n\n\n\n
What if I find something actively compromised?<\/h3>\n\n\n\n
Does this apply to small accounts too?<\/h3>\n\n\n\n
The one thing worth remembering<\/h2>\n\n\n\n
\n\n\n\nNeed a second pair of eyes on an AWS account?<\/h2>\n\n\n\n
\n
terraform plan<\/code> output or a Cost Explorer screenshot you can’t make sense of, send it over and I’ll tell you what I’d look at next.<\/p>\n\n\n\n