What an AWS Review Should Check: Cost, Security, Reliability

By Nam Bok Rodriguez · October 16, 2026 · 5 min read

A useful AWS review checks three things with evidence: who can do what in your accounts, whether you can actually recover from a failure, and where money is being spent for no benefit. The AWS Well-Architected Framework gives the structure. The value of a review is in turning its questions into concrete checks with a short, ranked list of fixes.

Here is what we look at, pillar by pillar, and why.

What framework should an AWS review follow?

The AWS Well-Architected Framework is built on six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. AWS compares neglecting them to building on a weak foundation, and the comparison holds. Most incidents and surprise bills trace back to a gap in one of these areas.

We use the pillars as a map, but a review should not be a questionnaire. Each item below is something you can verify in the console, the CLI or the bill.

What should the security part check?

Security findings come first in our reports, because they carry the largest downside.

Root user locked down. AWS's best practice SEC01-BP02 says MFA should always be used for the root user, root access keys should not exist, and root should be used only for the few tasks that require it. It rates the risk of skipping this as high.
Root activity is alarmed. The same guidance recommends alarms on root credential use, and notes that Amazon GuardDuty can alert through its RootCredentialUsage finding.
Recovery paths are owned by the company. AWS points out that the root email and phone number are part of the recovery flow, so they belong to a team distribution list and a company controlled number, not one person.
Least privilege in practice. IAM Access Analyzer flags resources shared outside your account, plus unused roles, unused access keys and unused permissions. We review both lists.
No long lived keys where roles will do. Old IAM user access keys in CI systems and laptops are a common finding.
Detective controls switched on. AWS publishes a Well-Architected Security Pillar conformance pack for AWS Config that turns many of these checks into continuous rules.
Public exposure. Open security groups, public S3 buckets, public snapshots and databases reachable from the internet.

What should the reliability part check?

The question is not "do you have backups" but "have you restored one recently, and how long did it take."

Recovery objectives exist. Each workload needs a written recovery time objective (how long you can be down) and recovery point objective (how much data you can lose).
Restores are tested. AWS best practice REL09-BP04 lists the anti patterns plainly: assuming a backup exists, assuming it is usable, and assuming the restore fits inside your recovery time. Its fix is periodic test restores that validate the data and measure the time.
Point in time recovery where it matters. The same page notes that Amazon RDS and DynamoDB support point in time recovery from continuous backups.
No single Availability Zone dependency for production databases, load balancers and compute that must stay up.
Alarms page a human. We check that alarms exist for the failures that matter, and that they reach someone who will act.

What should the cost part check?

Cost findings are usually the fastest wins, because many require no code changes.

Rightsizing and idle resources. AWS Compute Optimizer analyzes 14 days of CloudWatch metrics by default and recommends rightsizing and idle resource cleanup across EC2, Auto Scaling groups, EBS, Lambda, Fargate, RDS and Aurora, NAT gateways and more. You have to opt in first.
Commitments match steady usage. Savings Plans offer up to 66% off with Compute Savings Plans and up to 72% with EC2 Instance Savings Plans, on one or three year terms. We check coverage after rightsizing, never before.
Storage on current types. AWS says gp3 volumes cost up to 20% less per GB than gp2.
Log retention set. By default, CloudWatch Logs keeps data indefinitely. Log groups set to never expire are a quiet, growing cost.
NAT gateway traffic. NAT gateways charge per hour and per GB processed. AWS's VPC pricing page uses $0.045 for each in its US East (Ohio) example. Traffic to S3 through a NAT gateway is a frequent waste, since gateway VPC endpoints have no hourly or data processing charge.
Costs are attributable. Cost allocation tags must be activated in the Billing console before they appear in Cost Explorer. Without them, nobody can say what a product costs to run.
Budgets with alerts. AWS Budgets can alert on thresholds and run actions automatically or through an approval step.

What about operations, performance and sustainability?

These pillars get lighter coverage in a first review, but a few checks earn their place:

Infrastructure as code. Is production reproducible from a repository, or does it live only in the console?
Deploys and rollbacks. Can you ship and revert without a person clicking through screens?
Runbooks. Is there a written procedure for the top three failures?
Instance generations. Older instance families often cost more for less. AWS states Graviton instances use up to 60% less energy than comparable EC2 instances for the same performance, which touches both cost and sustainability.

What should you get at the end of a review?

A good review produces a short document, not a dump of tool output. Each finding should state the evidence, the risk or the monthly cost, the fix, and the effort. Then rank by impact. Security exposures and untested restores go at the top even when they save nothing, because they protect against the expensive day.

An AWS review checklist

Root user has MFA, no access keys, and alarmed usage.
Root email and phone are owned by the company, not one person.
IAM Access Analyzer is on, and external and unused access findings are reviewed.
No long lived access keys where a role would work.
No unintended public buckets, snapshots, databases or open security groups.
Recovery time and recovery point objectives are written for each workload.
A test restore has been done recently, with its duration recorded.
Production avoids single Availability Zone dependencies.
Compute Optimizer is enabled and its recommendations reviewed.
Savings Plans coverage matches steady usage after rightsizing.
EBS volumes are on gp3 where possible, and CloudWatch log retention is set.
S3 and DynamoDB traffic uses gateway endpoints instead of a NAT gateway.
Cost allocation tags are activated and budgets alert the right people.
Infrastructure is defined in code, with tested rollbacks.

If you want a second pair of eyes on your AWS accounts, with findings ranked by risk and cost, we can run that review for you. Start a project and tell us what you run on AWS today.