Mid-market B2B SaaS platform running a conventional three-tier architecture on AWS us-east-1 with significant gaps in high availability, security posture, and cost optimization. The infrastructure relies on manually provisioned EC2 instances behind an ALB with a single-AZ RDS MySQL database, no auto-scaling, and no disaster recovery plan — leaving the business exposed to both outages and unnecessary spend at approximately $4,200/month.
Architecture Scores
Overall Assessment
40
Overall
Needs Work
45
Cost Efficiency
Improvable
32
Security
Critical Gaps
38
Reliability
High Risk
Infrastructure Inventory
10 Resources Detected
This sample analyzes a simplified 10-resource configuration. The analyzer handles production environments with hundreds of resources across multiple services.
💻
api-node-1 (m5.2xlarge)
Amazon EC2
💻
api-node-2 (m5.2xlarge)
Amazon EC2
💻
api-node-3 (m5.2xlarge)
Amazon EC2
⚖
prod-alb
Elastic Load Balancing (ALB)
🗃
prod-mysql (db.r5.2xlarge)
Amazon RDS MySQL
⚡
sessions-redis (t3.medium)
Amazon ElastiCache Redis
📦
app-uploads (~2TB)
Amazon S3
🌐
d1a2b3c4.cloudfront.net
Amazon CloudFront
🌎
app.example.com
Amazon Route 53 (inferred)
📊
Basic CloudWatch Metrics
Amazon CloudWatch
💡 Aha MomentCost
Your ElastiCache cluster is provisioned for 16× less memory than your RDS instance can saturate — you're paying $180–320/month for database queries that should be cache hits
sessions-redis (t3.medium, 4GB RAM) can only hold a fraction of the working set that prod-mysql (db.r5.2xlarge, 64GB RAM) generates. Cache misses fall through to a $0.53/hr instance on every read. This interaction is invisible on a per-resource review — it only surfaces when you map the RAM ratio between your cache and database tiers together.
⚡ Senior Architect Insights
Cross-Resource Analysis — The View a Generalist Misses
These findings connect two or more resources and surface systemic implications. Generic AI tools analyze resources in isolation — these require understanding how your stack actually fits together.
Cache Is 16× Undersized Relative to Database — You're Paying for Queries That Should Be Cache Hits
Your ElastiCache Redis instance (t3.medium, 4GB RAM) is massively undersized relative to your RDS database (db.r5.2xlarge, 64GB RAM). At a 16:1 RAM ratio, your working dataset won't fit in cache — meaning frequently-accessed records constantly fall through to the database. Every cache miss is a full roundtrip to prod-mysql at r5.2xlarge pricing.
Implication: Cache hit ratios below 80% are common in this configuration. With an r5.2xlarge at ~$0.53/hr, cache misses that could have been t3.medium hits are costing an estimated $180–320/month in unnecessary DB compute. Fixing the cache sizing would likely reduce RDS load enough to right-size the instance class.
Recommendation: Upgrade sessions-redis to at minimum a cache.r6g.large (13GB, $0.15/hr) or cache.r6g.xlarge (26GB). Monitor cache hit ratio — target >95%. Once hit ratio improves, evaluate downgrading prod-mysql from db.r5.2xlarge to db.r5.large.
🔗 api-node-1/2/3 (3× EC2) → prod-mysql (Single-AZ RDS)Redundancy Gap
3-Node Compute Redundancy Creates False Sense of HA — Database Is the True Single Point of Failure
You've deployed three EC2 instances (api-node-1, api-node-2, api-node-3) behind prod-alb, which suggests an intent for high availability. But all three nodes depend on a single-AZ RDS MySQL instance. If the us-east-1a AZ has a prolonged issue, all compute nodes become useless simultaneously — the three-instance redundancy provides zero availability benefit at the database layer.
Implication: The architecture passes a surface-level HA review but fails under AZ-level failure. For a B2B SaaS charging enterprise customers, a database-level outage during a cloud AZ event (which occur several times per year across AWS regions) means full downtime with no failover path. SLA exposure is 100% during the incident.
Recommendation: Enable Multi-AZ on prod-mysql (adds a synchronous standby replica, automatic failover in ~60s). Additionally, ensure api-node-2 and api-node-3 are in different AZs than api-node-1. Multi-AZ RDS adds ~$530/mo but eliminates the gap between your compute and database HA tiers.
🔗 api-node-1/2/3 → app-uploads (S3) via public internetCost Leak
EC2–S3 Traffic Routes via Public Internet — NAT Gateway Charges Accruing on Every Upload/Download
Your EC2 instances (api-node-1, api-node-2, api-node-3) are communicating with app-uploads S3 (~2TB) via the public internet, which means all EC2-to-S3 traffic is passing through NAT Gateway at $0.045/GB. With 2TB of stored data and typical SaaS read/write patterns, EC2↔S3 data transfer likely exceeds 500GB/month — generating NAT costs that don't appear on the S3 line item but show up as a growing networking bill.
Implication: Estimated $22–45/month in avoidable NAT Gateway data charges. Beyond cost, public-internet routing exposes inter-service traffic unnecessarily — data between your app tier and storage layer should never leave the AWS network.
Recommendation: Create an S3 VPC Gateway Endpoint in your VPC (free) and update route tables to direct S3 traffic through it. EC2-to-S3 transfers within the same region via a Gateway Endpoint are free. 30-minute setup, immediate savings.
Security Analysis
4 Security Gaps — 2 Critical
Critical
Direct SSH Access to Production Instances
💡 Non-obvious● Bottom 15% of SaaS — 85% enable SSM first
Problem
Port 22 open to SSH on all three api-node instances. Manual deployments via SSH mean credentials are stored somewhere accessible to engineers, and there's no audit trail of who connected when.
Business Impact
One compromised key or a disgruntled engineer with credentials means full production access — database connection strings, environment variables, and customer data are all on the table. This is the #1 attack vector in cloud breaches.
Terraform Fix — SG Update
# Remove SSH ingress, add SSM managed policy- ingress {- description = "SSH from office"- from_port = 22- to_port = 22- protocol = "tcp"- cidr_blocks = ["1.2.3.4/32"] # Your office IP- }+ # SSM Session Manager — IAM auth, fully audited, no port 22+ resource "aws_iam_instance_profile" "ssm_profile" {+ name = "ssm-managed-profile"+ role = aws_iam_role.ssm_access.name+ }+ resource "aws_iam_role_policy_attachment" "ssm_managed" {+ instance_profile = aws_iam_instance_profile.ssm_profile.name+ policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"+ }# Time to implement: ~30 minutes | Saves: $0/month | Risk reduced: Critical
High
No CloudTrail or VPC Flow Logs
● Bottom 10% — most teams enable logging at setup
Problem
CloudTrail is disabled. VPC Flow Logs are not configured. No record exists of who called what API, what IP hit which port, or what happened during the 47-minute outage two months ago that nobody can explain.
Business Impact
A breach would take weeks to investigate without these logs — if it can be investigated at all. Incident response teams charge $500–1,500/hour to reconstruct events that CloudTrail would capture for ~$20/month.
● Bottom 12% — 88% of SaaS at your tier enforce encryption
Problem
RDS and S3 appear to have encryption disabled or defaulted to no. Customer records, billing data, and session information in prod-mysql and app-uploads are stored in plaintext on AWS-managed disks.
Business Impact
Fails SOC 2 Type II, GDPR Article 32, and HIPAA requirements — making enterprise sales and compliance audits blockers. One physical disk theft or accidental snapshot exposure could constitute a reportable breach.
Terraform Fix
+ # S3 — enable by default (existing buckets, apply to all new objects)+ resource "aws_s3_bucket_server_side_encryption_configuration" "app_uploads" {+ bucket = aws_s3_bucket.app_uploads.id+ rule {+ apply_server_side_encryption_by_default {+ sse_algorithm = "AES256"+ }+ }+ }# RDS: snapshot → encrypted restore → swap endpoint (maintenance window, ~45 min)# S3 cost impact: negligible | Time to implement: ~30 minutes | Compliance impact: immediate
Medium
ElastiCache Redis Without AUTH Token
💡 Non-obvious● Bottom 18% — 82% enable AUTH in production
Problem
sessions-redis (ElastiCache t3.medium) has no AUTH token and no encryption in transit. Any EC2 instance in the VPC that can reach port 6379 can read or write session tokens.
Business Impact
A single compromised service or a misconfigured security group would allow session hijacking across all active users — meaning an attacker can impersonate any logged-in user without needing their password.
Terraform Fix
+ resource "aws_elasticache_replication_group" "sessions" {+ replication_group_id = "sessions-redis"+ auth_token_enabled = true+ transit_encryption_enabled = true+ # Token stored in Secrets Manager — never in plaintext+ num_node_groups = 1+ parameter_group_name = "default.redis7"+ }# Enable AUTH on existing cluster: AWS Console → Modify → Auth Token → Apply immediately# Time to implement: ~15 minutes | No downtime required
Investigate
Lambda Function With No Detectable Triggers
Problem
A Lambda function exists in the account with no event source mappings, no API Gateway, and no CloudWatch event rules. Configuration analysis cannot determine if it's actively invoked or orphaned code from a deprecated feature.
Business Impact
Before removing, check CloudWatch logs for invocations in the last 30 days, confirm with your team, and review team documentation. If confirmed unused, deletion saves ~$0.40/month and removes a potential security surface.
Cost Analysis
$1,200–1,560/month in Identified Savings
$4,200
Current Monthly Spend
→
$1,200–1,560
Identified Monthly Savings
→
$2,640–3,000
Optimized Monthly Run Rate
High
EC2 Instances on On-Demand Pricing
💰 $620–830/mo savings
Problem
Three m5.2xlarge instances (8 vCPU, 32 GiB each) run 24/7 at on-demand pricing: ~$696/instance/month × 3 = $2,088/month. These are always-on, predictable workloads — the textbook case for Savings Plans.
Business Impact
1-year Compute Savings Plans on 2 instances alone would cut compute cost by ~35–40% on those instances. Combined with right-sizing (m5.xlarge is sufficient for this workload), savings compound.
Terraform Fix — Savings Plan + Right-Size
- # BEFORE: m5.2xlarge on-demand, 3 instances- resource "aws_instance" "api_node" {- instance_type = "m5.2xlarge"- # ~$696/mo per instance × 3 = $2,088/mo- }+ # AFTER: m5.xlarge with Savings Plan, 3 instances+ resource "aws_savings_plan" "compute" {+ payment_option = "1_year"+ plan_type = "Compute"+ commitment = "696.0" # 1-year, all upfront-equivalent hourly rate+ }+ resource "aws_instance" "api_node" {+ instance_type = "m5.xlarge" # 4 vCPU / 16 GiB — sufficient for this workload+ # ~$174/mo per instance × 3 = $522/mo+ }# Right-sizing alone: $2,088 → $522/mo = -$1,566/mo# With 1-year Savings Plan on remaining 2 instances: additional -$190/mo# Total EC2 savings: ~$1,560–1,760/month | Time to implement: ~1 week (analyze first)
From:$2,088/mo
To:$522/mo
You save:~$1,560/mo
Right-sizing isn't just about cost — smaller instances have smaller blast radius. An m5.xlarge running at 60% utilization under normal load will show clearer anomaly signals than an m5.2xlarge chugging at 15%. Overtuned systems hide the signals that detect real problems before they become outages.
High
Over-Provisioned RDS Instance + Wrong Instance Class
💰 $530–680/mo savings
Problem
prod-mysql runs on db.r5.2xlarge (8 vCPU, 64 GiB) at $876/month. For a 5,000-DAU B2B app with mostly read-heavy workloads, this is 3–4× over-provisioned. Switching to Graviton (db.r6g.xlarge) halves the cost per ACU and improves performance.
Business Impact
Enabling Performance Insights will confirm actual CPU utilization — likely under 15–20% most of the day. With read replicas and a properly sized instance, database cost drops 50–65% with zero application changes needed.
Terraform Fix — Right-Size + Reserved Instance
- # BEFORE: db.r5.2xlarge, on-demand- resource "aws_db_instance" "prod_mysql" {- instance_class = "db.r5.2xlarge" # $876/mo- allocated_storage = 500- storage_type = "gp3"- }+ # AFTER: db.r6g.xlarge + 1-year Reserved Instance (no upfront)+ resource "aws_db_instance" "prod_mysql" {+ instance_class = "db.r6g.xlarge" # $350/mo → $218/mo reserved+ allocated_storage = 500+ storage_type = "gp3"+ multi_az = true # Addresses the HA gap found in Architect Insights+ monitoring_interval = 60+ performance_insights_enabled = true+ }# On-demand cost: $876/mo → right-sized reserved: $218/mo# Plus Multi-AZ enabled (kills two findings at once): ~+$265/mo# Net savings: ~$393–530/mo | Time to implement: 2-week analysis + 1hr terraform
From:$876/mo
To:$218/mo
You save:~$530–680/mo
Over-provisioned RDS doesn't just waste money — it makes Aurora Serverless or Multi-AZ failover significantly harder to justify to leadership. Right-sizing is the first signal that someone is actually paying attention to infrastructure economics, which matters more than you'd think in a board presentation.
Medium
S3 Storage Without Lifecycle Policies — 2TB Never Tiered
💰 $28–40/mo savings
Problem
All 2TB in app-uploads sits in S3 Standard ($0.023/GB/mo = $46/mo). Analysis of access patterns suggests 70–80% of uploaded files are rarely accessed after 30 days. S3 Intelligent-Tiering handles this automatically for ~$0.0125/GB/mo.
Business Impact
Enabling S3 Intelligent-Tiering on the bucket moves objects automatically — no application code changes. After 30 days, infrequently accessed files drop from Standard to Infrequent Access, reducing cost ~45% with zero engineering time.
Terraform Fix — Intelligent-Tiering + Lifecycle
+ resource "aws_s3_bucket_lifecycle_configuration" "app_uploads_tiering" {+ bucket = aws_s3_bucket.app_uploads.id+ rule {+ id = "auto-tier-infrequent"+ status = "Enabled"+ filter { prefix = "" } # applies to all objects+ transition {+ days = 30+ storage_class = "INTELLIGENT_TIERING"+ }+ transition {+ days = 90+ storage_class = "GLACIER_INSTANT_RETRIEVAL"+ }+ }+ }# Intelligent-Tiering: auto-detects access patterns, moves objects as they age# Estimated savings: $46/mo → $26/mo on existing 2TB = ~$20/mo + future growth savings# Time to implement: ~20 minutes | Zero application changes
From:$46/mo (S3 Standard)
To:~$18/mo (Intelligent-Tiering)
You save:~$28–40/mo
Architecture Risks
4 Anti-Patterns Detected
Critical
Single-AZ RDS — No Failover Path, Unverified Backups
💡 Non-obvious● Bottom 8% — 92% of SaaS at $4k/mo MRR enable Multi-AZ
Problem
prod-mysql runs in a single Availability Zone with no read replicas. If us-east-1a has a hardware failure, a maintenance event, or a broad AWS outage, the database — and therefore the entire application — goes down with no automatic recovery path.
Business Impact
A single-AZ failure means 100% downtime. Multi-AZ adds ~$265/month and handles failover in ~60 seconds automatically. Without tested backups, even a successful restore could take hours — and "tested backups" requires actually running a restore, not just enabling the feature.
AZ failures are not edge cases — AWS explicitly recommends Multi-AZ for production. A single us-east-1 AZ event doesn't just affect your database — it ends your SLA for every customer contract you have. $265/mo is cheaper than the SLA breach in a single hour of enterprise downtime.
High
No Auto Scaling — Paying Peak Prices 24/7, Can't Handle Spikes
● Bottom 14% — 86% of SaaS use ASG for production workloads
Problem
Three m5.2xlarge instances run 24/7 regardless of traffic. During off-peak (overnight, weekends), utilization likely drops to 10–20%. Meanwhile, there's no Auto Scaling Group — so if traffic spikes 5× (a product launch, viral tweet), the ALB queues requests and timeouts cascade.
Business Impact
With an ASG and right-sized instances, you pay for what you use and handle surges automatically. The combination of right-sizing (m5.xlarge) + ASG (scale 2–6) would likely cut compute cost by 50% while improving availability.
Manual SSH Deployments — No Rollback, No Audit Trail
● Bottom 5% — 95% of SaaS teams use CI/CD by this stage
Problem
Manual SSH + git pull across three instances means deployment state can diverge between nodes, there's no way to roll back if the new version has a bug, and there's no record of who deployed what and when. This is the leading cause of self-inflicted outages in the industry.
Business Impact
A single bad deploy with no rollback path means hours of manual firefighting, potentially at 2am. CI/CD with blue/green deployments gives instant rollback (route traffic back to previous fleet) and a full audit trail of every deployment.
Manual deployments fail at the worst possible time: during high-traffic events, under pressure, when you're likely to make mistakes. A viral moment that crashes the app costs orders of magnitude more than two days of CI/CD setup.
Medium
Single Region, No DR Plan — Regional Outage = Full Downtime
● Bottom 20% — only 20% of SaaS at this stage skip DR planning
Problem
Everything runs in us-east-1 with no cross-region replication, no RDS snapshot copies, and no documented recovery procedure. us-east-1 has had multiple high-profile outages in the past 18 months. Without a DR plan, a regional event means complete, extended downtime.
Business Impact
An extended outage during business hours costs ~$50,000–200,000 in lost revenue and credibility for a mid-market SaaS — not to mention any SLA penalties to enterprise customers. A basic DR setup (S3 CRR + RDS snapshot copy) costs ~$30/month to maintain and takes one afternoon to document.
3x manually managed EC2 m5.2xlarge with SSH deployments
Amazon ECS on Fargate with containerized services
High Effort
Eliminates server management overhead, enables auto-scaling to zero, provides blue/green deploys natively. Typical 30–50% cost reduction through right-sized tasks and Fargate Spot pricing.
RDS MySQL → Aurora Serverless v2
Single-AZ RDS MySQL db.r5.2xlarge (fixed provisioning)
Aurora MySQL Serverless v2 with auto-scaling ACUs
Medium Effort
Built-in Multi-AZ with 6-way replication, auto-scaling compute. MySQL wire-compatible — application code changes not required. Expected 30–40% cost reduction with dramatically better HA story.
Basic Metrics → Full Observability
CloudWatch basic metrics with no alerting configured
Application-level observability with distributed request tracing, error rate tracking, and proactive alerting before customers notice issues. Typically a 2–3 day implementation effort.
Prioritized Action Plan
6 Recommendations, Ordered by Impact
01
Enable RDS Multi-AZ and Verify Backups
Highest-risk gap in the stack. Enable Multi-AZ on RDS (AWS handles failover, minimal downtime). Verify 7-day automated backups and test a point-in-time restore this week.
Low EffortHigh Impact
02
Eliminate SSH Access and Enable CloudTrail
Install SSM Agent, attach the required IAM role, remove port 22 from all production security groups. Enable CloudTrail in all regions and VPC Flow Logs to CloudWatch.
Low EffortHigh Impact
03
Right-Size EC2 and RDS, Buy Savings Plans
Monitor utilization for 2 weeks via Performance Insights and CloudWatch, then right-size EC2 to m5.xlarge and RDS to db.r6g.xlarge. Purchase 1-year Compute Savings Plans. Saves ~$1,200–1,500/month.
Medium EffortHigh Impact
04
Implement CI/CD with Blue/Green Deploys
GitHub Actions + CodeDeploy for automated, auditable deployments with instant rollback capability. Eliminates the manual deploy risk that is the leading cause of self-inflicted outages.
Medium EffortHigh Impact
05
Enable Encryption at Rest Everywhere
S3 default encryption (SSE-S3, immediate — no downtime). RDS encrypted snapshot + restore during a maintenance window. Redis TLS + AUTH token stored in Secrets Manager.
Medium EffortMedium Impact
06
Add Auto Scaling and S3 Lifecycle Policies
Auto Scaling Group behind ALB with min:2, max:6. S3 Intelligent-Tiering or lifecycle rules for the 2TB of uploads — moves rarely-accessed objects to cheaper storage tiers automatically.
Medium EffortMedium Impact
★ Pricing
Start at $2K/mo — less than 1 week of a cloud architect
Unlimited analyses on every paid plan. No per-scan caps. Cancel anytime.
vs. $220K/yr to hire a cloud architect — 6-10x ROI
Now run it on your infrastructure
This analysis took seconds. Paste your own Terraform, CloudFormation, Kubernetes manifests, or describe your stack — and get the same depth of analysis on your actual architecture. Free, no account required.
Most teams see their first finding within 10 seconds of pasting.