cd /news/ai-agents/stop-letting-your-ai-design-expensiv… · home topics ai-agents article
[ARTICLE · art-125535] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

Stop letting your AI design expensive, insecure AWS architectures

A developer built the AWS Solutions Architect Prover, an MCP server that reviews AI-generated cloud architectures against five mandatory gates derived from the AWS Well-Architected Framework. The tool, which deliberately requests no AWS credentials, rejects designs that fail requirements quantification, blast radius mapping, or service minimization, aiming to curb cost and security problems from LLM-hallucinated architectures. The developer argues LLMs default to popular rather than cost-effective or secure designs, citing idle NAT Gateways and unnecessary multi-region replication.

by read5 min views4 publishedSep 10, 2026

I've seen it happen dozens of times. A developer sits down with Claude or Cursor, asks for a scalable architecture to handle some new workload, and within ten minutes, the LLM has hallucinated a sprawling mess of EKS clusters, Kinesis streams, and Aurora Global Databases.

On paper, it looks impressive. To a junior dev or even a mid-level engineer, it looks "cloud-native." But to anyone who has ever stared at a massive monthly AWS bill or sat through an incident response call caused by an IAM wildcard, it looks like a disaster waiting to happen.

This isn't just about bad code. It's about bad reasoning. LLMs are trained on vast amounts of documentation and blog posts—including many terrible ones that advocate for unnecessary complexity under the guise of "resilience."

When you ask an AI to build something on AWS, it defaults to what is popular in training data, not what is cost-effective or secure for your specific constraints. It ignores the $32/mo idle NAT Gateway sitting in your VPC because it doesn't realize it's there. It proposes multi-region replication for a tool used by twenty people because "multi-region" sounds more professional than "single-AZ with backups."

That is exactly why we built the AWS Solutions Architect Prover. The fundamental issue with using LLMs for system design is that they lack accountability. They operate on probability, not on mathematical rigor or economic reality. Most AI-generated cloud designs suffer from three main pathologies:

Requirement Hallucination: The AI uses words like "highly available," "performant," or "scalable" as if they were technical specifications. Without knowing your actual RPS (Requests Per Second), p99 latency requirements, or RTO/RPO goals, any architectural choice is just a guess based on vibes.

Cost Hallucination: This is where the real damage happens. An LLM might tell you Lambda is cheap, but forget to mention the crushing cost of API Gateway at 40 million requests or the silent accumulation of cross-AZ transfer fees ($0.01/GB) and NAT Gateway charges. A design that technically works but costs $5k more than it should is a failed design.

Service Sprawl: Because LLMs want to satisfy every possible constraint simultaneously, they tend to stack primitives. Instead of picking one right tool (like SQS), they suggest Kinesis and MSK and EventBridge just to cover all bases. This creates an operational nightmare that no small team can actually manage.

You probably noticed immediately that this MCP server does not request AWS credentials or access to your environment. This is intentional.

A lot of people think cloud automation requires giving an agent full AdministratorAccess. That approach leads straight to the very breaches we are trying to prevent. We don't want an agent touching your infrastructure; we want an agent that acts as a senior reviewer during the design phase.

The Prover operates entirely at the reasoning layer. It takes your proposed architecture and subjects it to five mandatory gates derived from the AWS Well-Architected Framework. If any gate fails, the Prover rejects the design and demands concrete fixes.

The order is strictly non-negotiable: Gate 1: Requirements Quantified. If you haven't defined peak RPS, p99 latency in milliseconds, availability SLO (e.g., 99.95%), and RTO/RPO in minutes, the Prover stops right there. It refuses to move forward until you replace marketing adjectives with hard numbers.

Gate 2: Blast Radius Mapped. Does the design acknowledge what happens when an entire AZ goes dark? Or when a single service like KMS becomes unavailable? If you say "AWS handles it," you fail this gate instantly.

Gate 3: Services Minimized. This is where we fight service sprawl. For every service suggested (like EKS), the Prover demands you justify why you didn't choose its simpler counterpart (like Fargate). If you can't defend why you aren't using SQS instead of Kinesis, the suggestion is rejected.

Gate 4: Real TCO Calculated. We calculate the actual invoice components: Compute + Storage + NAT Gateway + Cross-AZ Transfer + Egress + VPC Endpoints + CloudWatch + Support Tier. This turns theoretical uptime into practical economics.

Gate 5: Security Designed In. This checks for Day 0 readiness. Are you using IAM roles instead of access keys? Are there wildcards (Resource: "*") in your policies? Is S3 Block Public Access active? Is everything encrypted with KMS CMKs?<br/>\lately">\r much harder stuff than permissions included here too.)<br/>\lately">\r much harder stuff than permissions included here too.)<br/>\l lately">\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<br/>λ>\r much harder stuff than permissions included here too.)<//font> \u002d-\u002d-\u002d No bullshit version ends now.

MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.

── more in #ai-agents 4 stories · sorted by recency
── more on @aws 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/stop-letting-your-ai…] indexed:0 read:5min 2026-09-10 ·