6.1 - Cost and performance optimization
AWS SysOps Administrator objective 6.1 covers optimizing cost and performance. AWS Cost Explorer analyzes and forecasts spend, AWS Budgets alerts and can act on cost, usage, Reserved Instance or Savings Plans thresholds, and the Cost and Usage Report feeds Athena or QuickSight; cost allocation tags and Cost Anomaly Detection pinpoint drivers. Trusted Advisor checks cost, performance, security, fault tolerance and service limits, and Compute Optimizer recommends right-sizing for EC2, Auto Scaling groups, EBS and Lambda. You commit with Savings Plans or Reserved Instances for steady workloads and use Spot for interruptible ones, choose gp3 over gp2 and modify volumes online, move S3 data to the right storage class with lifecycle rules or Intelligent-Tiering, delete idle resources, and add caching to cut latency and cost. Expect scenario questions about a cost spike or slow workload, and ask which optimization tool or action fits.
Analyze and forecast spend = Cost Explorer; alert or act on a threshold = Budgets. Right-sizing recommendations = Compute Optimizer. Commit for steady use = Savings Plans; interruptible = Spot.
Practice questions
1. Finance asks to be emailed when the monthly AWS bill is forecast to exceed a set amount. Which native combination meets this most simply?
- A billing alarm on EstimatedCharges wired to an SNS email topic (correct answer)
- A Lambda function that scrapes the console invoice page each hour and emails it
- A high-resolution custom metric published from a homemade billing script
- Detailed monitoring enabled on the payer account's root user login
A CloudWatch billing alarm on EstimatedCharges (in us-east-1) that publishes to an SNS email topic is the simplest native alerting path. Scraping the console with Lambda is fragile and unnecessary; detailed monitoring is unrelated to billing.
2. A cost review finds detailed monitoring enabled on 500 rarely-used dev instances. What is the cost implication and the cleanest fix?
- It bills per instance monthly; disable it where 5-minute data is enough (correct answer)
- It is always free of charge, so there is nothing to change on the instances
- It only affects retention, so simply lower the retention setting instead
- It is billed per console API call, so open the dashboards less often
Detailed monitoring carries a per-instance monthly charge, so on rarely-used dev instances that do not need 1-minute data, disabling it (reverting to free 5-minute basic monitoring) cuts cost. It is not free and is not about retention.
3. Which choice increases CloudWatch custom-metric costs the most for the same underlying data?
- Publishing at high resolution (1-second) instead of standard 1-minute (correct answer)
- Grouping several unrelated values under a single shared metric name field
- Adding a longer, more descriptive metric name string to the metric
- Viewing the metric on a shared dashboard more frequently each day
High-resolution custom metrics cost more than standard-resolution ones for the same data because of the finer 1-second granularity. Metric name length and dashboard viewing frequency do not change custom-metric charges.
4. You want capacity provisioned just before demand using machine-learned daily and weekly cycles, avoiding cold-start lag. Which option fits?
- Predictive scaling on history (correct answer)
- Simple scaling with a long cooldown
- A fixed desired capacity set to the peak
- Manual scheduled actions each week
Predictive scaling forecasts load from history and provisions ahead of the curve, cutting cold-start lag. Fixing desired capacity at peak wastes money off-peak, and simple or manual options are reactive or laborious.
5. An Auto Scaling group uses Spot Instances. Which two measures reduce disruption when Spot capacity is reclaimed? (Choose TWO.)
- Enable Capacity Rebalancing (correct answer)
- Restrict the group to only a single instance type
- Disable all health checks
- Use a mixed instances policy with many types (correct answer)
Capacity Rebalancing proactively launches a replacement on a Spot interruption warning, and a diverse mixed instances policy widens the pool so reclaims hurt less. A single type shrinks the pool, and disabling health checks harms reliability.
6. You want steady baseline capacity at low cost plus cheap burst capacity for spikes in one Auto Scaling group. Which configuration fits?
- All On-Demand Instances kept at the maximum group size
- A mixed instances policy: On-Demand base plus Spot (correct answer)
- All Spot Instances with no base
- Reserved Instances scaled manually
A mixed instances policy sets an On-Demand base for reliability and fills bursts with cheaper Spot, balancing cost and resilience. All On-Demand costs more, all Spot risks the baseline, and manual Reserved scaling is not elastic.