From Weeks to Hours: Building an AI-Powered Cloud Assessment Engine

If you've ever commissioned an AWS Well-Architected Framework Review, you know how it goes. You engage a consulting firm, schedule weeks of interviews, wait for a 200-page PDF, and write a check for $10,000 or more. The report is thorough. By the time it arrives, your infrastructure has already moved, and half the recommendations describe a system that no longer exists.

We wanted the same depth of assessment in about ten minutes, rerunnable every week, at a fraction of the cost. This post is how we built CloudThinker's assessment engine to do that: the structure of the problem, the architecture that exploits it, and the output format that makes the findings usable.

Why the traditional review doesn't scale

01Cost

Cost Optimization

Right-sizing, reserved capacity and pricing models.

02Security

Security

IAM policies, encryption and network isolation.

03Operations

Operational Excellence

Monitoring, automation and incident response.

04Reliability

Reliability

High availability, fault tolerance and disaster recovery.

05Performance

Performance Efficiency

Compute choice, caching and scalability.

06Sustainability

Sustainability

Utilization, energy efficiency and footprint.

The six pillars of the AWS Well-Architected Framework. Each pillar-resource pair can be judged on its own.

The AWS Well-Architected Framework defines six pillars for evaluating a cloud architecture. The framework is sound. The way reviews are delivered is the bottleneck, for three structural reasons.

It's sequential. One expert reviews one workload, one pillar at a time. According to AWS, a typical Well-Architected Review takes 4 to 6 hours per workload. For 50 resources in 10 workloads across all six pillars, that's 40 to 60 hours of consultant time plus stakeholder interviews, usually two to three weeks from kickoff to report.

It's a snapshot. A review describes the estate on the day the interviews happened. Every deploy after that makes it a little less true, and because it's expensive, it happens once a year.

Its output is prose. "Consider downsizing underutilized instances" isn't a ticket. Someone still has to find the instances, check the metrics, estimate the saving and work out how risky the change is.

The insight that shaped the design: the work is embarrassingly parallel. Judging the encryption of one S3 bucket doesn't depend on the right-sizing of one EC2 instance. Every pillar-resource pair is independent, so they can all run at once.

The architecture: matrix execution

01Select

Pillars × resources

Pick 1 to 6 pillars and any set of resources to assess.

02Fan out

One cell, one run

Each pillar-resource pair becomes its own conversation, run in parallel batches.

03Analyze

Tools, not guesses

The agent reads config, metrics and policies for that one resource.

04Recommend

Structured output

Before and after state, effort, risk, savings and the steps to apply it.

Matrix execution: 3 pillars × 45 resources becomes 135 independent conversations.

At the core of the engine is the assessment matrix:

Selected pillars × Selected resources = Assessment conversations
3 pillars × 10 resources = 30 parallel AI conversations

Each cell spawns an independent conversation in which an agent analyzes one resource through the lens of one pillar. The conversations run concurrently, coordinated by a Celery task queue with batching (10 tasks at a time, 500 ms between batches) so the run doesn't exhaust API rate limits or workers.

A real run looks like this:

Pillars selected: Cost Optimization, Security, Reliability
Resources selected: 20 EC2 instances, 15 RDS databases, 10 S3 buckets
Conversations spawned: 3 × 45 = 135, in parallel
Completion time: about 10 minutes, against roughly 270 hours done by hand

Keeping each cell to one resource and one pillar is what makes this reliable. The context per conversation is small, the question is narrow, and a failure in one cell doesn't poison the others.

Pillar-specific specialists

A security audit needs different tools and reasoning from a cost analysis, so cells are routed by pillar. A cost and performance specialist handles metrics, savings and configuration. A security specialist reviews IAM policies, encryption and network rules.

Each specialist gets a pillar-specific prompt that names the evaluation areas. An excerpt of the cost prompt:

Analyze this resource's configuration to identify cost optimization opportunities.

Evaluation areas:
1. Right-sizing: analyze CPU, memory and storage utilization
2. Unused resources: check for idle or underutilized assets
3. Pricing models: evaluate reserved instances, Savings Plans, Spot opportunities
4. Resource lifecycle: identify orphaned snapshots and old backups
...

After analysis, use #recommend to create specific, actionable recommendations.

The agents don't stop at reading the prompt. They call tools to query resource metadata from cloud APIs, fetch CloudWatch metrics, inspect security configuration, calculate cost projections and write structured recommendations.

One cell, end to end

Here's what a single Cost Optimization cell does with a t3.xlarge that looks quiet.

1. Name the readings. Low average CPU could mean the instance is oversized. It could also mean the workload is bursty (quiet on average, pinned at peak), or memory-bound (CPU idle because the process is waiting on RAM). Each reading leads to a different answer: downsize, leave alone, or move to a memory-optimized family.

2. Check with the metrics. The average alone can't separate those cases, so the cell pulls average and maximum together over two weeks:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def4567890 \
  --statistics Average Maximum \
  --start-time 2026-09-23T00:00:00Z --end-time 2026-10-07T00:00:00Z \
  --period 3600

A 28% average with hourly maximums that stay well below 100% rules out the bursty reading. Memory isn't in the default EC2 metrics (it needs the CloudWatch agent), so if it isn't available the cell says so and makes memory verification the first step of the recommendation instead of assuming.

3. Check what the smaller size implies. T3 instances are burstable. On a t3.large, the same load lands at roughly 56% per vCPU, which is above the instance's baseline, so it will spend CPU credits. That's why the recommendation below is rated Medium risk rather than Low: the cell flags CPUCreditBalance as something to watch after the change.

4. Write the recommendation. The result is a structured record rather than a sentence:

Type: Rightsizing (Cost Optimization pillar)
Title: Consider downsizing t3.xlarge to t3.large
Description: The instance is significantly underutilized and can be downsized to reduce cost without affecting application performance.
Before state: t3.xlarge, 4 vCPUs, 16 GB RAM, $121.76/month, 28% average CPU
After state: t3.large, 2 vCPUs, 8 GB RAM, $60.88/month, 56% estimated CPU
Effort: Low
Risk: Medium
Potential savings: $60.88/month
Guidelines:
1. Verify the application's RAM requirements don't exceed 8 GB
2. Review CloudWatch metrics for peak usage patterns
3. Schedule a maintenance window in a low-traffic period
4. Stop the EC2 instance
5. Change the instance type to t3.large
6. Start the instance and verify application functionality
7. Monitor performance metrics for 24 hours after the change

That structure turns a vague suggestion into a ticket an engineering team can prioritize and execute.

Why this beats the traditional review

01Consulting review

Once a year

Weeks of interviews, a long PDF, and findings that age while you read them.

02Automated assessment

Every week

Minutes per run, structured recommendations, and a diff against last week.

The value moves from one deep audit to a cheap check you can repeat.

For a mid-sized infrastructure of 50 resources:

	Traditional Well-Architected Review	Automated assessment
Cost	$200/hour consultant, 100+ hours: about $20,000	About $500/month, unlimited assessments
Time per run	3 to 4 weeks to insights	10 to 15 minutes
Frequency	Once a year (too expensive to repeat)	Weekly or on demand
Coverage	All 6 pillars, 50 resources, thorough but infrequent	Configurable: 1 to 6 pillars, any number of resources
Output	PDF report, parsed by hand	Structured recommendations with effort, risk and savings

Over a year, that's $20,000 for one assessment against $6,000 for 52 or more: a $14,000 (70%) reduction, with 52 times more frequent findings.

The deeper difference is frequency. A once-a-year review can only tell you what was wrong. A weekly one tells you what changed, which is when problems are cheapest to fix.

Continuous assessment compounds

Assessments get more valuable once they're a habit rather than an event.

Month 1 (baseline). The first run finds 67 optimization opportunities worth $8,400/month in potential savings. The team implements the top 15 high-impact, low-effort items and realizes $5,200/month.

Month 2 (iteration). The rerun detects the 15 implemented recommendations and finds 23 new issues, because the infrastructure changed and new practices apply. The team implements 8 more. Cumulative savings: $6,800/month.

Month 6 (maturity). The estate is well-optimized and new runs find fewer critical issues. Attention shifts to new resources and newly adopted services, and the team starts treating the assessment as a pre-deployment checklist.

That last shift matters most. The assessment stops being something done to the team and becomes how the team checks its own work.

Applying recommendations safely

The assessment itself is read-only. It inspects configuration and metrics and writes recommendations; it changes nothing. Applying a recommendation (stopping an instance, changing its type, deleting a snapshot) goes through Auto Mode, so you decide what runs on its own and what waits for approval.

Getting started

1. Run a first assessment on a small scope.

"Run a Cost Optimization and Security assessment on our EC2 instances and S3 buckets in us-east-1. Show each recommendation with effort, risk and monthly savings. Propose only, change nothing."

2. Make it a weekly check.

"Rerun this assessment every Monday and show me only what's new or changed since last week."

3. Work the list.

"Turn the low-effort, low-risk recommendations into Jira tickets for the platform team, grouped by service."

Try it at app.cloudthinker.io/resources/assessment. Questions? Reach the team at biz@cloudthinker.io.

Conclusion

Traditional cloud assessments treat optimization as a compliance checkbox: done once a year, filed and forgotten. Splitting the review into independent pillar-resource cells, running them in parallel and writing structured recommendations turns a multi-week engagement into a ten-minute workflow you can run every week, without giving up depth.