Skip to main content
Illustrative sample — not a real customer report.

Sample AWS Cost Optimization Audit Report

This sample deliverable illustrates the exact depth, telemetry evidence, risk ratings, and engineering remediation blueprints delivered to your engineering team within 24 hours.

1

Connect Read-Only AWS Access

5-min CloudFormation deployment. Strict least-privilege SecurityAudit role.

2

See Savings % in 5 Minutes

Automated waste telemetry sweep and instant ROI feasibility check.

3

Full Report in 24 Hours

Deterministic calculations reviewed by certified cloud architects.

Executive Summary Environment: Primary Production & Staging

Identified Savings & Telemetry Overview

Baseline AWS Spend
$18,420 /month $18,420/month
Trailing 30-day baseline
Identified Savings 22.7%
$4,180 /month $4,180/month
$50,160/year annualized
High-Confidence 5 Findings
$2,740 /month $2,740/month
Immediate, non-disruptive
Medium-Confidence 3 Findings
$1,440 /month $1,440/month
Requires brief review
Factual findings established via deterministic calculations, not AI guesswork.
Resource Allocation

Identified Savings by AWS Domain

Total: $4,180/month
Compute & Scheduling
$1,990/mo 47.6%
Storage & Lifecycle
$780/mo 18.7%
Database Optimization
$640/mo 15.3%
Network & Logs
$770/mo 18.4%
Quick Navigation

Findings at a Glance

Detailed Technical Findings

8 Identified Optimization Opportunities

Low Risk: 7 Medium Risk: 1
Finding #01 • Compute Rightsizing Amazon EC2 • us-east-1
Risk: Low Confidence: High Complexity: Low

Over-Provisioned EC2 Worker Fleet (c6i.4xlarge → c6i.2xlarge)

Potential Monthly Savings
$780/month
$9,360/year
Deterministic Calculation Breakdown
4 instances × ($0.680/hr − $0.340/hr) × 730 hrs/month = $992.80/month

Assumptions: Calculated using us-east-1 On-Demand list prices ($0.680/hr for c6i.4xlarge vs $0.340/hr for c6i.2xlarge). Applied a conservative 21.4% ($212.80/mo) buffer to account for potential scale-out bursts during month-end batch processing.

Current Configuration

4x c6i.4xlarge On-Demand instances (16 vCPU, 32 GiB RAM each) running background asynchronous processing workers 24/7. Current combined compute cost: $3,856/month.

Recommended Action

Update the Auto Scaling launch template to use c6i.2xlarge (8 vCPU, 16 GiB RAM). Execute a phased instance refresh with 50% minimum healthy percentage during normal operational hours.

Evidence & Telemetry Analysis
Continuous 30-day CloudWatch telemetry shows aggregate CPU utilization across all 4 nodes averaged 6.8%, with maximum peak utilization never exceeding 14.2%. Sustained memory utilization remained below 28% without swap activation.
Why It Was Flagged
Instances were originally provisioned for peak historical ingestion prior to offloading high-throughput queue fanout to AWS Lambda. The dedicated instance capacity is over-provisioned by approximately 4x relative to actual steady-state load.
Safe Engineering Validation Steps
  1. Deploy launch template update to staging worker cluster and simulate 2x peak queue ingestion.
  2. Verify worker processing latency and message queue depth metrics in Amazon SQS remain within SLA.
  3. Trigger Canary instance refresh in production (replacing 1 node initially) and monitor CloudWatch CPU/memory metrics for 24 hours.
  4. Complete rolling deployment across remaining worker nodes.
Finding #02 • Database Optimization Amazon Aurora • us-east-1
Risk: Medium Confidence: Medium Complexity: Medium

Over-Sized Multi-AZ Aurora MySQL Staging Cluster

Potential Monthly Savings
$640/month
$7,680/year
Deterministic Calculation Breakdown
2 instances × ($1.040/hr − $0.260/hr) × 730 hrs/month = $1,138.80/mo gross delta; downsized to db.r6g.large = $640/month net reduction

Assumptions: Multi-AZ staging cluster downsized to 2x db.r6g.large nodes with zero reader licensing overhead.

Current Configuration

Multi-AZ Amazon Aurora MySQL cluster (1 writer + 1 reader on db.r6g.2xlarge; 8 vCPU, 64 GiB RAM each) serving the staging integration environment. Current monthly database spend: $1,840/month.

Recommended Action

Modify the staging Aurora cluster instance classes from db.r6g.2xlarge down to db.r6g.large (2 vCPU, 16 GiB RAM), or transition staging to Aurora Serverless v2 with an allocated scale boundary of 0.5 to 4.0 ACUs.

Evidence & Telemetry Analysis
Telemetry over 30 days indicates average CPU utilization was 4.6% (peak 18.1% during nightly snapshot backup); database connection pool averaged 12 active connections against a configured limit of 2,000; buffer cache hit ratio consistently exceeded 99.8%.
Why It Was Flagged
The staging environment database was cloned from production during an exploratory performance benchmark but was never downsized to appropriate non-production capacity. Full Multi-AZ with high-memory nodes is generating unnecessary expenditure.
Safe Engineering Validation Steps
  1. Review slow query logs and Performance Insights for memory-intensive queries in staging.
  2. Perform test instance type change on reader instance first to measure zero application downtime.
  3. Initiate failover to make downsized reader the writer, then resize original writer during scheduled maintenance window.
  4. Execute end-to-end integration test suite against downsized database.
Finding #03 • Storage Cleanup Amazon EBS • us-east-1 & us-west-2
Risk: Low Confidence: High Complexity: Low

Unattached & Orphaned EBS Volumes (gp2/gp3)

Potential Monthly Savings
$420/month
$5,040/year
Deterministic Calculation Breakdown
4,200 GB unattached block storage × $0.10/GB-month (blended gp2/gp3) = $420.00/month

Assumptions: 100% idle volumes deleted after creating cold snapshot archives in S3.

Current Configuration

19 unattached EBS volumes (combination of legacy gp2 and gp3) totaling 4,200 GB across us-east-1 (14 volumes) and us-west-2 (5 volumes). Current monthly idle cost: $420/month.

Recommended Action

Create a pre-deletion AWS snapshot for each of the 19 unattached volumes tagged with "Archive-Before-Deletion", then delete the unattached EBS volumes using the AWS CLI or Terraform.

Evidence & Telemetry Analysis
AWS EC2 volume status has reported "available" (unattached to any running or stopped EC2 instance) with zero read/write IOPS recorded in CloudWatch for > 45 consecutive days. CloudTrail logs show parent instances were terminated without DeleteOnTermination enabled.
Why It Was Flagged
When EC2 instances were deleted through previous manual or automated deployments, the attached EBS volumes remained in the account and continue to incur standard AWS block storage and provisioned IOPS fees indefinitely.
Safe Engineering Validation Steps
  1. Cross-reference volume IDs against past CloudTrail instance termination events to confirm decommissioning status.
  2. Execute snapshot script with tag Key="KloudSenseDecom", Value="pre-deletion-backup".
  3. Delete the 19 unattached volumes and confirm 0 unattached volumes in EC2 Console dashboard.
  4. Verify next AWS Cost Explorer billing cycle reflects elimination of unattached volume charges.
Finding #04 • Storage Lifecycle Amazon S3 • us-east-1
Risk: Low Confidence: High Complexity: Low

Unmanaged S3 Storage Tiers & Missing Lifecycle Transition

Potential Monthly Savings
$360/month
$4,320/year
Deterministic Calculation Breakdown
48 TB transitioned from S3 Standard ($0.023/GB) to Glacier Instant Retrieval ($0.004/GB) + Intelligent-Tiering = $360.00/month

Assumptions: Net savings after accounting for one-time transition request API fees.

Current Configuration

58 TB of application build artifacts, raw data exports, and audit logs stored in S3 Standard storage ($0.023/GB) across 4 primary buckets with zero lifecycle rules configured. Current spend: $1,334/month.

Recommended Action

Apply an S3 Lifecycle rule across the 4 buckets to automatically transition objects to S3 Intelligent-Tiering after 30 days, transition archive prefixes to Glacier Instant Retrieval after 90 days, and expire temporary build artifacts after 180 days.

Evidence & Telemetry Analysis
S3 Storage Lens analysis and CloudWatch access metrics indicate that 82% of stored objects (48 TB) have not been accessed or downloaded for over 90 days. 12 TB of build logs have not had a GET request in over 180 days.
Why It Was Flagged
Stale historical archives and build artifacts remain in the highest-cost S3 Standard storage tier due to missing automated transition policies, rather than leveraging S3 Intelligent-Tiering or Glacier Instant Retrieval ($0.004/GB).
Safe Engineering Validation Steps
  1. Review data governance and compliance retention obligations for build logs and exports.
  2. Apply lifecycle rule via Terraform or AWS S3 Management console in non-production bucket first.
  3. Verify lifecycle transition status in AWS S3 Storage Lens dashboard after 24–48 hours.
  4. Confirm application read latency is unaffected (Glacier Instant Retrieval preserves millisecond access).
Finding #05 • Network Architecture Amazon VPC • us-east-1
Risk: Low Confidence: Medium Complexity: Low

Unrouted S3 Data Transfer Traversing NAT Gateways

Potential Monthly Savings
$480/month
$5,760/year
Deterministic Calculation Breakdown
11.2 TB intra-region S3 traffic × $0.045/GB NAT processing fee = $504.00/month

Assumptions: Free S3 Gateway Endpoint completely eliminates $0.045/GB processing charge with $480/month estimated realization.

Current Configuration

2x NAT Gateways in us-east-1 processing 16.4 TB/month of outbound traffic, incurring $738/month in NAT data processing charges ($0.045/GB) in addition to $65/month hourly gateway fees ($803/month total NAT spend).

Recommended Action

Provision a free AWS Gateway VPC Endpoint for Amazon S3 in the VPC and associate it with all private subnet route tables. S3 traffic will automatically route directly over AWS internal fiber at zero cost ($0.00/GB).

Evidence & Telemetry Analysis
VPC Flow Logs analysis reveals that 68% of total bytes passing through the NAT Gateways (11.2 TB/month) represents internal AWS network traffic destined for Amazon S3 REST API endpoints located within the same region.
Why It Was Flagged
Private subnets without public IP addresses route all outbound requests through NAT Gateways by default. Without a Gateway VPC Endpoint, internal intra-region traffic to S3 incurs avoidable $0.045/GB NAT data processing charges.
Safe Engineering Validation Steps
  1. Verify that existing S3 bucket policies do not restrict traffic by specific elastic IP addresses.
  2. Provision the S3 Gateway VPC Endpoint in staging VPC and verify route table prefix list entry (pl-xxxxxxxx).
  3. Perform test curl/upload from a private EC2 instance to S3 bucket to verify direct route.
  4. Deploy in production VPC route tables and monitor NAT Gateway BytesOutToDestination in CloudWatch.
Finding #06 • Logging Optimization Amazon CloudWatch • us-east-1
Risk: Low Confidence: High Complexity: Low

Indefinite CloudWatch Logs Retention & Verbose Debug Ingestion

Potential Monthly Savings
$290/month
$3,480/year
Deterministic Calculation Breakdown
8.2 TB log storage downsized with 30/90-day retention policies + 28 GB/day staging debug ingestion curtailed = $290.00/month

Assumptions: Reduces ongoing CloudWatch log storage and ingest charges from $410/mo to $120/mo.

Current Configuration

74 CloudWatch Log Groups accumulating 8.2 TB of historical logs with retention policy configured to "Never Expire" ($410/month storage). Staging container clusters generate 28 GB/day of debug logging.

Recommended Action

Apply automated retention policies: 30 days for development/staging log groups, 90 days for standard application logs, and export long-term compliance logs to S3 Glacier at 1/10th the cost. Change staging ECS log level to INFO.

Evidence & Telemetry Analysis
Log groups associated with decommissioned microservices, old ECS task definitions, and abandoned Lambda functions continue to incur $0.03/GB/month storage fees without active queries. Staging services log DEBUG statements continuously in production log groups.
Why It Was Flagged
AWS defaults new CloudWatch log groups to "Never Expire". Without automated retention policies or log-level filters, log storage costs compound every month, retaining obsolete staging logs indefinitely.
Safe Engineering Validation Steps
  1. Review internal security and audit compliance requirements for minimum log retention periods.
  2. Execute an AWS CLI script or Terraform resource to set retention on all 74 log groups.
  3. Verify log expiration kicks in via CloudWatch Metrics (IncomingBytes vs StoredBytes).
  4. Confirm container environment variable LOG_LEVEL=info is active on non-production ECS task definitions.
Finding #07 • Resource Scheduling Amazon EC2 & RDS • us-east-1
Risk: Low Confidence: High Complexity: Medium

24/7 Runtime on Non-Production Dev/Staging Environments

Potential Monthly Savings
$890/month
$10,680/year
Deterministic Calculation Breakdown
500 idle hours saved per instance × 18 EC2 + 3 RDS staging instances = $890.00/month

Assumptions: Non-prod assets shut down outside Monday–Friday 8 AM–7 PM business schedule (~69% runtime reduction).

Current Configuration

18 development and staging EC2 instances (mix of t3.xlarge and m5.large) and 3 staging RDS PostgreSQL databases running 24 hours a day, 7 days a week (720 hours/month). Combined non-prod monthly spend: $1,280/month.

Recommended Action

Deploy AWS Instance Scheduler or an Amazon EventBridge scheduled rule with AWS Lambda to automatically start non-production instances at 8:00 AM and stop them at 7:00 PM Monday through Friday. Tag exceptions with AutoStop=False.

Evidence & Telemetry Analysis
CloudWatch utilization metrics show near-zero network I/O, database connections, and CPU usage (< 1.2%) between 7:00 PM and 7:00 AM on weekdays, and zero activity during weekends (~68% idle runtime across the fleet).
Why It Was Flagged
Engineering teams actively work against staging and QA environments for approximately 50 hours per week (220 hours/month). Running non-production infrastructure 720 hours/month wastes 500 hours of provisioned compute capacity per instance.
Safe Engineering Validation Steps
  1. Tag all non-production instances with Environment=staging and Schedule=business-hours.
  2. Test automated stop/start cycle on a single development instance and verify clean reboot.
  3. Verify staging RDS database resumes connections cleanly upon morning startup without deadlocks.
  4. Provide engineering team with a simple Slack command or AWS SSM document for on-demand evening overrides.
Finding #08 • Commitment Coverage AWS Savings Plans • us-east-1
Risk: Low Confidence: Medium Complexity: Low

Uncovered Steady-State Compute on 100% On-Demand Pricing

Potential Monthly Savings
$320/month
$3,840/year
Deterministic Calculation Breakdown
$1.80/hr committed spend × ~25% blended discount × 730 hrs/month = $328.50/month (sized to $320/mo)

Assumptions: 1-Year No-Upfront Compute Savings Plan covering conservative 65% of steady-state compute floor.

Current Configuration

100% On-Demand billing across all production EC2, AWS Fargate, and Lambda workloads with 0% Savings Plans or Reserved Instance commitment coverage. Total monthly compute baseline: $4,850/month.

Recommended Action

Purchase a conservative 1-Year No-Upfront Compute Savings Plan sized at $1.80/hour (covering ~65% of the proven steady-state floor). Maintain 35% on On-Demand to allow flexibility for upcoming architecture adjustments.

Evidence & Telemetry Analysis
AWS Cost Explorer historical usage analysis over the past 6 months reveals an unwavering compute baseline of at least $2.80/hour that never dips below that floor, even during holiday and weekend traffic troughs.
Why It Was Flagged
Paying purely On-Demand rates for steady-state baseline compute results in paying maximum retail pricing without capturing predictable 25%–35% AWS commitment discounts.
Safe Engineering Validation Steps
  1. Review product engineering roadmap for the next 12 months to verify no major multi-cloud migrations.
  2. Model commitment recommendations in AWS Cost Explorer Savings Plans tool.
  3. Confirm conservative 65% coverage ratio leaves sufficient buffer for future compute rightsizing.
  4. Execute 1-Year No-Upfront purchase in AWS Billing Console (zero upfront capital expenditure).
24 Hours Turnaround • 100% Read-Only

Get Your AWS Cost Audit

Identify waste, quantify potential savings, and give your engineering team an exact remediation roadmap. Backed by our Actionable Savings Guarantee.

Zero commitments • Ephemeral STS access • Full refund if identified savings don't exceed audit fee

Note: The actual delivered report layout, navigation, and information presentation may be slightly different based on the latest version at the time your audit report is generated, but the analytical depth and actionable engineering blueprints are always kept at their best.

Identified Savings $4,180/mo (22.7%)
Get Your AWS Cost Audit