Reserved Instances and Savings Plans in AWS - Time & Space Complexity
We want to understand how the time to manage Reserved Instances and Savings Plans changes as the number of instances or plans grows.
Specifically, how does the number of API calls or operations increase when handling more reservations or plans?
Analyze the time complexity of the following operation sequence.
# List all Reserved Instances
aws ec2 describe-reserved-instances
# List all Savings Plans
aws savingsplans describe-savings-plans
# For each Reserved Instance, check usage
for reservedInstance in reservedInstances:
aws ec2 describe-instance-usage --instance-id reservedInstance.id
# For each Savings Plan, check applicable usage
for savingsPlan in savingsPlans:
aws savingsplans describe-usage --savings-plan-id savingsPlan.id
This sequence lists all Reserved Instances and Savings Plans, then checks usage details for each one.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Checking usage details for each Reserved Instance and Savings Plan.
- How many times: Once per Reserved Instance and once per Savings Plan.
As the number of Reserved Instances and Savings Plans increases, the number of usage checks grows proportionally.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | ~20 (10 RI + 10 SP usage checks) |
| 100 | ~200 (100 RI + 100 SP usage checks) |
| 1000 | ~2000 (1000 RI + 1000 SP usage checks) |
Pattern observation: The number of API calls grows linearly with the number of Reserved Instances and Savings Plans combined.
Time Complexity: O(n)
This means the time to process usage checks grows directly in proportion to the number of Reserved Instances and Savings Plans.
[X] Wrong: "Checking usage for all Reserved Instances and Savings Plans takes the same time no matter how many there are."
[OK] Correct: Each instance or plan requires a separate usage check, so more items mean more API calls and longer total time.
Understanding how operations scale with the number of cloud resources helps you design efficient management scripts and anticipate costs in real projects.
"What if we batch usage checks for multiple Reserved Instances or Savings Plans in a single API call? How would the time complexity change?"
Practice
Solution
Step 1: Understand the purpose of Reserved Instances and Savings Plans
Both are pricing models that offer discounts in exchange for a commitment to use AWS resources for a period.Step 2: Identify the main benefit
The main benefit is cost savings by committing to usage, not performance or support features.Final Answer:
They reduce cloud costs by committing to usage over time -> Option CQuick Check:
Cost savings = C [OK]
- Thinking Reserved Instances improve instance speed
- Confusing cost savings with free support
- Assuming automatic scaling is included
Solution
Step 1: Recall Savings Plan characteristics
Savings Plans offer flexible discounts that apply to compute usage regardless of instance type or region.Step 2: Match the correct description
A flexible pricing model that applies to compute usage regardless of instance type correctly describes Savings Plans as flexible pricing models, unlike Reserved Instances which are specific.Final Answer:
A flexible pricing model that applies to compute usage regardless of instance type -> Option AQuick Check:
Savings Plans = Flexible pricing = A [OK]
- Confusing Savings Plans with Reserved Instances
- Thinking Savings Plans are one-time payments
- Assuming Savings Plans are free trials
Solution
Step 1: Understand Reserved Instance scope
Standard Reserved Instances apply to specific instance types and regions. m5.large is different from m5.xlarge.Step 2: Check discount application
The discount partially applies because m5.xlarge is double the size of m5.large; the RI covers the equivalent of one m5.large unit.Final Answer:
The discount applies partially, covering the m5.large portion of the m5.xlarge -> Option AQuick Check:
RI discount partial for larger instance = D [OK]
- Assuming full discount on different instance sizes
- Thinking discount applies across regions
- Believing discount applies to any instance type
Solution
Step 1: Understand Savings Plan coverage
Compute Savings Plans apply discounts to supported compute services like EC2, Fargate, and Lambda.Step 2: Identify billing mismatch cause
If instances run on unsupported services or outside the plan scope, discounts won't apply, causing billing to be higher than expected.Final Answer:
You purchased a Compute Savings Plan but launched instances outside supported services -> Option BQuick Check:
Discounts apply only to supported services = A [OK]
- Confusing Reserved Instances with Savings Plans
- Assuming multi-region must be enabled always
- Ignoring service eligibility for discounts
Solution
Step 1: Analyze workload and flexibility needs
The workload is steady and predictable, so committing to usage saves money. Flexibility to change instance types is important.Step 2: Compare options
Standard RIs are less flexible; Convertible RIs allow changes but require longer commitment. Compute Savings Plans offer flexibility across instance types and families with 1-year commitment.Step 3: Choose best option
Compute Savings Plan balances cost savings and flexibility best for this scenario.Final Answer:
Purchase a 1-year Compute Savings Plan covering the equivalent usage -> Option DQuick Check:
Flexibility + cost savings = Compute Savings Plan = B [OK]
- Choosing Standard RIs despite flexibility needs
- Ignoring commitment length impact
- Assuming On-Demand is cheapest for steady workloads
Ready to prove it?
Pass the test and this pattern moves unknown
