AWS SAA-C03 Drill: EC2 Cost Analysis - The Operational Simplicity vs. Depth Trade-off

While preparing for the AWS SAA-C03, many candidates get confused by AWS cost management tools. In the real world, this is fundamentally a decision about Operational Simplicity vs. Analytical Depth. Let’s drill into a simulated scenario.

The Scenario

#

TechFlow Industries, a growing SaaS provider, recently received an alert from their finance team about a 35% month-over-month increase in their AWS bill. Upon investigation, the FinOps team identified that several Amazon EC2 instances have been unnecessarily resized multiple times over the past 60 days—some instances were upgraded from t3.medium to c5.2xlarge and then downgraded to t3.large within the same billing cycle.

The company’s cloud architect needs to quickly generate visual cost comparisons of EC2 spending across different instance types for the past two months and perform root cause analysis to understand these inefficient rightsizing decisions.

Key Requirements

#

Generate EC2 cost comparison visualizations by instance type for the past 2 months and enable deep-dive analysis to identify vertical scaling inefficiencies—all with minimal operational overhead.

The Options

#

• A) Create budget reports using AWS Budgets to compare EC2 costs based on instance type.
• B) Use Cost Explorer’s granular filtering capabilities to analyze EC2 costs in-depth based on instance type.
• C) Leverage the AWS Billing and Cost Management Dashboard charts to compare EC2 costs by instance type over the past 2 months.
• D) Create an AWS Cost and Usage Report (CUR) delivered to an S3 bucket, then use Amazon QuickSight with S3 as the data source to generate interactive instance-type-based visualizations.

Correct Answer

#

Option B.

The Architect’s Analysis

#

Correct Answer

#

Option B: Use Cost Explorer’s granular filtering capabilities to analyze EC2 costs in-depth based on instance type.

Step-by-Step Winning Logic

#

Cost Explorer is AWS’s managed service specifically designed for historical cost analysis with multi-dimensional filtering:

1. Purpose-Built for Historical Analysis: Cost Explorer natively stores up to 13 months of cost data with daily granularity—perfect for the “past 2 months” requirement.

2. Zero Operational Overhead:

   • No infrastructure to provision
   • No data pipelines to build
   • No ETL jobs to maintain
   • Available immediately in the AWS Console

3. Granular Filtering by Instance Type:

   • Can filter by Instance Type dimension specifically
   • Supports grouping by family (t3, c5, m5, etc.)
   • Allows drill-down into specific instance sizes (t3.medium vs. t3.large)

4. Built-in Visualization:

   • Native charting capabilities (bar, line, stacked area)
   • Downloadable CSV reports for further analysis
   • Supports cost and usage metrics simultaneously

5. Deep-Dive Analysis Features:

   • Tag-based filtering for cost allocation
   • Combine filters (instance type + region + tag)
   • Compare time periods side-by-side

This is the textbook definition of “minimal operational overhead” for cost analysis at the Associate level.

The Traps (Distractor Analysis)

#

Why not Option A (AWS Budgets)?

#

AWS Budgets is for alerting, not historical analysis:

• Primary Purpose: Set cost/usage thresholds and receive notifications when approaching limits
• Budget Reports: Only generate periodic summaries sent via email—not designed for interactive deep-dive analysis
• Limitation: Reports show “budget vs. actual” comparisons, not the granular instance-type breakdown needed for root cause analysis
• Exam Trap: AWS Budgets appears in many cost-related questions, but it’s a proactive monitoring tool, not a retrospective analysis tool

Real-World Note: You’d use Budgets to prevent future overspending after Cost Explorer identifies the problem.

Why not Option C (Billing and Cost Management Dashboard)?

#

The Dashboard is too high-level for this requirement:

• Overview Focus: Designed for quick summary views (total spend, top services)
• Limited Filtering: Basic charts don’t offer the “instance type” dimension needed
• No Deep-Dive: Cannot perform the “root cause analysis” the scenario requires
• Exam Trap: The dashboard is the first thing you see in the Billing console, but it’s a summary tool, not an analytical tool

Think of it as: Dashboard = Executive summary, Cost Explorer = Analyst workbench.

Why not Option D (CUR + QuickSight)?

#

This violates the “minimal operational overhead” requirement:

• Infrastructure Required:

  • Configure CUR with S3 bucket
  • Set up IAM roles for CUR delivery
  • Create QuickSight account (additional cost)
  • Build QuickSight data source connection
  • Design custom dashboards
  • Configure refresh schedules

• Time to Value: CUR takes 24 hours for first delivery, then requires manual dashboard creation

• Cost Overhead: QuickSight adds ~$9-24/user/month (Standard/Enterprise editions)

• Operational Overhead:

  • S3 storage costs for CUR files
  • QuickSight dataset maintenance
  • Dashboard version control

When to Use This Approach:

• Enterprise-wide cost analytics across 100+ accounts
• Custom BI integration requirements
• Need for advanced visualizations beyond Cost Explorer’s capabilities
• Combining billing data with operational metrics

Exam Signal: The word “minimal operational overhead” immediately disqualifies multi-service solutions for Associate-level questions.

The Architect Blueprint

#

Diagram Note: Cost Explorer provides a zero-infrastructure path from alert to root cause identification, enabling immediate pattern recognition without custom data pipelines.

Real-World Practitioner Insight

#

Exam Rule

#

“For the AWS SAA-C03 exam, always select Cost Explorer when the requirement is:

• Historical cost analysis (not future forecasting)
• Multi-dimensional filtering (service, instance type, region, tags)
• Minimal operational overhead constraint
• Timeframe ≤ 13 months”

Keyword Signals:

• “Past X months/days” → Cost Explorer
• “Minimal overhead” → Managed service (Cost Explorer)
• “Deep-dive analysis” + “cost” → Cost Explorer (not Budgets)
• “Granular filtering” → Cost Explorer

Real World

#

In production environments, we’d use a layered approach:

1. Cost Explorer for Initial Discovery (Days 1-7):

   • Quick identification of cost anomalies
   • Validate the instance type hypothesis
   • Export data for stakeholder meetings

2. Cost and Usage Report + Athena for Deep Investigation (Week 2+):

   • Once the problem is confirmed, set up CUR for ongoing monitoring
   • Use Athena SQL queries for complex analysis (e.g., correlating instance resizes with application performance metrics)
   • Build automated alerts for future instance type changes

3. AWS Budgets for Prevention (Ongoing):

   • Set budget alerts at the instance family level
   • Create separate budgets for production vs. non-production environments
   • Alert when EC2 costs exceed 10% variance

4. QuickSight Dashboards for Executive Reporting (Month 2+):

   • Build a unified FinOps dashboard combining CUR data, Reserved Instance utilization, and Savings Plans coverage
   • Share with C-suite and department heads

The exam tests your ability to recognize the right starting point—Cost Explorer’s low barrier to entry makes it ideal for this scenario’s urgency.

Additional Practitioner Insights:

• Cost Allocation Tags: In the real world, we’d immediately check if instance type changes correlate with specific teams/projects using tags—Cost Explorer supports tag-based filtering.

• Rightsizing Recommendations: After identifying the problematic instances, Cost Explorer’s Rightsizing Recommendations feature (under the Recommendations tab) can suggest optimal instance types based on actual utilization.

• Savings Plans Impact: We’d also verify if any instances were recently moved out of Savings Plans coverage, causing the cost spike (Cost Explorer shows on-demand vs. SP pricing).