AWS Savings Plans Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Cloud Financial Management

by

Category

Cloud Financial Management

1. Introduction

AWS Savings Plans are a pricing program that can significantly reduce your compute costs when you can commit to a consistent level of usage over time.

In simple terms: you commit to spend a certain amount per hour on eligible compute (for 1 year or 3 years), and AWS automatically applies discounted rates to your usage—often producing savings compared to On-Demand pricing.

Technically, Savings Plans are a billing discount model (not a compute service). After you purchase a plan, AWS’s billing system evaluates your eligible compute usage each hour and applies Savings Plans discounted rates up to your committed hourly spend. Any usage beyond the commitment is billed at regular On-Demand rates.

Savings Plans solve a common FinOps problem: predictable baseline compute spend is expensive on On-Demand, but teams also want flexibility and don’t want to over-engineer reservations for every instance type. Savings Plans offer a structured commitment model with automatic application and reporting, aligning cost optimization with real operational usage.

2. What is Savings Plans?

Official purpose (AWS): Savings Plans provide a way to save on AWS compute costs in exchange for committing to a consistent amount of compute usage (measured as $/hour) for a 1- or 3-year term. AWS then applies discounted Savings Plans rates to eligible usage.

Core capabilities

  • Commitment-based discounts on eligible compute usage for a fixed term.
  • Automatic application of discounts to matching usage without needing to “assign” the plan to resources.
  • Multiple plan types to balance flexibility vs. maximum discount.
  • Payment options that trade cash flow vs. discount level (No Upfront, Partial Upfront, All Upfront).
  • Visibility and governance via Cost Explorer, AWS Budgets, AWS Cost and Usage Report (CUR), APIs/CLI, and AWS Organizations sharing controls.

Major components (conceptual)

  • Plan type (e.g., Compute Savings Plans, EC2 Instance Savings Plans, SageMaker Savings Plans)
  • Hourly commitment (e.g., “commit $X/hour”)
  • Term length (1 year or 3 years)
  • Payment option (No Upfront / Partial Upfront / All Upfront)
  • Offering/rate catalog (AWS-defined discounted rates that vary by attributes like region, instance family, and purchase choices)
  • Benefit application engine (billing logic that applies discounted rates hourly)
  • Reporting & analytics (utilization, coverage, effective cost, amortization)

Service type

  • A Cloud Financial Management program within AWS Billing and Cost Management.
  • Not a resource you deploy into a VPC; it’s a billing construct that impacts how eligible compute usage is charged.

Scope (how it’s “scoped” in AWS)

  • Savings Plans are purchased at the account level.
  • In AWS Organizations with consolidated billing, Savings Plans benefits can typically be shared across member accounts (subject to sharing settings). Exact behavior and administrative controls can differ; verify current behavior in official docs for your organization setup.
  • Not “zonal” in the way a compute resource is; applicability depends on plan type and selected attributes (for example, EC2 Instance Savings Plans are tied to a region and instance family).

How it fits into the AWS ecosystem

Savings Plans sit at the intersection of: – Compute services: Amazon EC2, AWS Fargate, AWS Lambda, and (via SageMaker Savings Plans) Amazon SageMaker eligible usage. – Billing and analytics: AWS Billing console, AWS Cost Explorer, CUR, AWS Budgets. – Governance: AWS Organizations (sharing), IAM permissions, CloudTrail auditing, tagging (where supported by the Savings Plans API).

Official starting points: – Product page: https://aws.amazon.com/savingsplans/ – User guide: https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html

3. Why use Savings Plans?

Business reasons

  • Lower compute spend for stable workloads compared to On-Demand pricing.
  • Predictable budgeting: commitment turns some variable spend into a more predictable baseline.
  • Better unit economics for products with steady traffic patterns or steady platform capacity.
  • Supports FinOps goals: reduce waste, allocate spend responsibly, and forecast accurately.

Technical reasons

  • Automatic discount application reduces operational complexity compared to managing many reservations.
  • Flexibility options (especially Compute Savings Plans) help teams evolve instance families or architectures without losing all committed savings.
  • Works well alongside auto scaling: Savings Plans can cover the baseline, while scaling handles peaks.

Operational reasons

  • Central governance (especially with AWS Organizations): platform teams can purchase commitments centrally and share savings across accounts.
  • Reporting: utilization/coverage views help you manage the commitment as a capacity-like financial instrument.
  • Less reservation micromanagement than per-instance/per-attribute commitments.

Security/compliance reasons

  • Helps implement cost controls that support compliance programs requiring budget oversight and cost governance (for example, chargeback/showback).
  • Supports separation of duties: purchasing can be restricted to billing/admin roles while engineers still deploy resources normally.

Scalability/performance reasons

  • Savings Plans don’t force you into smaller instances; you can still scale up/out as needed. You’re optimizing cost without compromising runtime performance decisions.

When teams should choose Savings Plans

  • You have steady baseline compute usage on EC2/Fargate/Lambda/SageMaker (as applicable).
  • You can commit for 1 or 3 years and expect the platform to keep running.
  • You want a balance of:
  • meaningful discounts, and
  • operational flexibility and simplified management.

When teams should not choose Savings Plans

  • Workloads are highly uncertain, short-lived, or likely to be decommissioned soon.
  • You cannot commit for 1–3 years due to business uncertainty.
  • Your workloads are already mostly on Spot (Savings Plans generally don’t apply to Spot usage; verify current eligibility rules).
  • You lack cost governance maturity and might overbuy commitments, resulting in underutilization (you still pay the commitment).

4. Where is Savings Plans used?

Industries

  • SaaS and internet services with 24/7 production platforms
  • FinTech and regulated industries that prioritize predictable costs and governance
  • Media/streaming with baseline encoding or API traffic
  • E-commerce with consistent platform capacity plus seasonal peaks
  • Gaming with steady backend services
  • Healthcare/life sciences running persistent compute pipelines and inference endpoints
  • Enterprises modernizing data centers to AWS with long-lived workloads

Team types

  • FinOps / Cloud Financial Management teams
  • Platform engineering teams managing shared AWS accounts
  • SRE/DevOps teams running persistent fleets
  • Data engineering teams with steady ETL and orchestration platforms
  • ML platform teams operating continuous training/inference infrastructure (where applicable)

Workloads and architectures

  • Microservices on EC2 Auto Scaling Groups or container platforms
  • Always-on APIs behind load balancers
  • Background workers, queues, and schedulers
  • Lambda-heavy event-driven systems with consistent baseline invocations
  • Fargate workloads with predictable service counts
  • Multi-account architectures using AWS Organizations

Real-world deployment contexts

  • Production: the most common place for Savings Plans due to stable usage.
  • Dev/Test: sometimes, if dev/test is always-on (shared environments) and predictable. Otherwise, consider turning off non-production or using schedules first.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Savings Plans commonly deliver value.

1) Baseline EC2 fleet cost reduction

  • Problem: A stable EC2 fleet runs 24/7; On-Demand costs are high.
  • Why Savings Plans fits: Commit to baseline hourly spend and receive discounted rates automatically.
  • Example scenario: A web tier and API tier run steadily across multiple Auto Scaling Groups; you commit to cover the minimum always-on capacity.

2) Multi-account organizations sharing compute discounts

  • Problem: Different teams run compute in separate AWS accounts; each is too small to optimize alone.
  • Why it fits: With consolidated billing, Savings Plans can typically apply across linked accounts (subject to sharing settings).
  • Example: A platform org buys Savings Plans in the management account to cover baseline usage across 20 product accounts.

3) Migrating instance families without losing discounts (Compute Savings Plans)

  • Problem: You plan to move from one EC2 generation to another (e.g., x86 to Arm) or adjust instance families for cost/perf.
  • Why it fits: Compute Savings Plans are designed to be flexible across eligible compute characteristics.
  • Example: Over 12 months you gradually migrate services from one EC2 family to another; your commitment remains useful.

4) Fargate steady-state services

  • Problem: ECS/EKS services on Fargate run continuously; costs add up.
  • Why it fits: Compute Savings Plans can cover eligible Fargate usage (verify current eligibility).
  • Example: 30 microservices run as always-on Fargate services; Savings Plans cover the baseline tasks.

5) Lambda-heavy platform with predictable baseline traffic

  • Problem: Event-driven architecture has steady invocation volume; On-Demand Lambda cost is meaningful.
  • Why it fits: Compute Savings Plans can apply to eligible Lambda usage (verify current eligibility and regions).
  • Example: Always-on ingestion pipeline uses Lambda + SQS; you cover the baseline compute time with Savings Plans.

6) Centralized procurement with controlled guardrails

  • Problem: Engineers shouldn’t commit the organization to long-term spend.
  • Why it fits: Savings Plans purchasing can be restricted via IAM/SCPs; usage doesn’t require any special permissions.
  • Example: A FinOps role purchases Savings Plans after approvals; developers continue deploying normally.

7) Reducing cost variance for budgeting and forecasting

  • Problem: Monthly bills fluctuate; leadership wants predictable run-rate.
  • Why it fits: The hourly commitment provides a stable baseline charge.
  • Example: Finance uses the commitment charge as a baseline and treats burst as variable.

8) Post-migration optimization after data center exit

  • Problem: After lift-and-shift, teams run too much On-Demand compute.
  • Why it fits: Savings Plans quickly capture savings without needing perfect per-instance reservations.
  • Example: After migrating 500 VMs, you analyze usage and purchase Savings Plans to cover steady servers.

9) Covering baseline while keeping peak flexibility (Auto Scaling)

  • Problem: You need to scale for peak but don’t want to over-commit.
  • Why it fits: Buy commitment for the steady baseline; pay On-Demand for spikes.
  • Example: E-commerce baseline is steady year-round; holiday spikes are paid On-Demand.

10) ML platforms with persistent inference/training capacity (SageMaker Savings Plans)

  • Problem: ML endpoints or processing/training jobs are steady and expensive.
  • Why it fits: SageMaker Savings Plans target eligible SageMaker instance-based usage (verify exact coverage).
  • Example: A recommendation service keeps endpoints running 24/7; a plan covers baseline inference costs.

11) Replace/augment Reserved Instances strategy

  • Problem: Managing Reserved Instances at scale can be complex.
  • Why it fits: Savings Plans can be simpler to manage while still providing strong discounts.
  • Example: You standardize on Savings Plans for baseline compute and reduce RI operational overhead.

12) Chargeback/showback improvements

  • Problem: You need to allocate discount benefits fairly across teams.
  • Why it fits: CUR includes Savings Plans data to attribute effective costs (with the right reporting model).
  • Example: A FinOps team uses CUR + Athena to allocate net-effective compute costs to cost centers.

6. Core Features

Feature 1: Multiple Savings Plans types (flexibility vs. discount)

What it does: Offers plan types such as: – Compute Savings Plans – EC2 Instance Savings Plans – SageMaker Savings Plans

Why it matters: Each type trades flexibility for a potentially higher discount level.

Practical benefit: You can pick a plan type that matches how stable your compute architecture is.

Limitations/caveats: – Eligibility differs by plan type. – Attribute constraints (like region or instance family) may reduce flexibility for some plan types.

Feature 2: Hourly spend commitment model ($/hour)

What it does: You commit to a consistent hourly spend for the plan term.

Why it matters: This is simpler than committing to specific instance counts or capacities.

Practical benefit: Covers a wide variety of usage patterns as long as you have baseline spend.

Limitations/caveats: – If usage falls below commitment, you still pay the commitment (underutilization risk).

Feature 3: Term lengths (1-year or 3-year)

What it does: Choose a 1-year or 3-year commitment.

Why it matters: Longer terms usually provide larger discounts but reduce flexibility.

Practical benefit: Align your cost strategy with business planning cycles.

Limitations/caveats: – Commitment is long-lived; ensure approvals and forecasting discipline.

Feature 4: Payment options (No Upfront / Partial Upfront / All Upfront)

What it does: Lets you choose how you pay: – No Upfront: pay as a recurring charge – Partial Upfront: part upfront + recurring – All Upfront: pay fully upfront

Why it matters: Payment options influence effective discount and cash flow.

Practical benefit: Finance can align payments with budgeting and treasury constraints.

Limitations/caveats: – Upfront payments can improve savings but increase immediate cash outlay.

Feature 5: Automatic application of discounts each hour

What it does: AWS applies Savings Plans rates automatically to eligible usage.

Why it matters: Eliminates manual assignment and reduces operational overhead.

Practical benefit: Engineers don’t need to change deployments to benefit.

Limitations/caveats: – Only eligible usage benefits; other cost components remain unchanged (data transfer, storage, etc.).

Feature 6: Sharing across accounts (AWS Organizations)

What it does: In consolidated billing setups, Savings Plans can be shared across accounts (subject to sharing settings).

Why it matters: Increases utilization by applying commitments across the full organization baseline.

Practical benefit: Central purchases can cover distributed workloads.

Limitations/caveats: – Behavior depends on Organizations configuration and sharing settings; verify in official docs for your exact scenario.

Feature 7: Recommendations (purchase guidance)

What it does: AWS provides Savings Plans recommendations based on historical usage.

Why it matters: Helps prevent overbuying and improves confidence.

Practical benefit: Quickly estimate a commitment level and expected savings.

Limitations/caveats: – Recommendations depend on sufficient and representative historical usage data. – Always sanity-check with your own roadmap (migrations, scaling changes, product changes).

Feature 8: Coverage and utilization reporting

What it does: Reporting shows: – Utilization: how much of your commitment you used – Coverage: what portion of eligible usage was covered by Savings Plans

Why it matters: These are the KPIs that tell you whether you bought the right amount.

Practical benefit: Continuous improvement loop: tune commitments over time.

Limitations/caveats: – Reporting definitions matter (amortized vs unblended); align your organization on one model.

Feature 9: Programmatic access (API/CLI/SDK)

What it does: You can describe Savings Plans, offerings/rates, and retrieve utilization/coverage via APIs.

Why it matters: Enables automation: reporting pipelines, governance checks, approvals, and dashboards.

Practical benefit: Integrate Savings Plans metrics into your FinOps tooling.

Limitations/caveats: – Billing data availability can be delayed vs real-time telemetry. – API rate limits apply.

Official API reference: – https://docs.aws.amazon.com/savingsplans/latest/APIReference/Welcome.html

Feature 10: Tagging (where supported)

What it does: Savings Plans resources can be taggable via the Savings Plans API (for organizing and allocation).

Why it matters: Helps manage multiple plans (by environment, business unit, cost center).

Practical benefit: Better governance and reporting grouping.

Limitations/caveats: – Confirm current tag support and reporting behavior in your accounts/regions in official docs.

7. Architecture and How It Works

High-level architecture

Savings Plans operate in the billing layer: 1. You purchase a Savings Plan with an hourly commitment and term. 2. Each hour, AWS evaluates your eligible compute usage. 3. AWS applies Savings Plans discounted rates up to your hourly commitment. 4. Any remaining eligible usage is billed at On-Demand rates. 5. You analyze utilization and coverage via Cost Explorer/CUR and adjust strategy over time.

Control flow vs. data flow

  • Control flow: Purchase, modify governance settings, and retrieve reports via Billing console, API/CLI, and Organizations settings.
  • Data flow: Usage metering from compute services flows into billing systems; Savings Plans adjustments appear in Cost Explorer and CUR.

Integrations with related services

  • AWS Billing and Cost Management (purchase/management)
  • AWS Cost Explorer (recommendations, coverage, utilization)
  • AWS Budgets (alerts on utilization/coverage)
  • AWS Cost and Usage Report (CUR) (detailed billing line items, Savings Plans fields)
  • AWS Organizations (consolidated billing, sharing)
  • AWS CloudTrail (audit purchase and management API calls)
  • Athena / QuickSight (common pattern: CUR → Athena → dashboards)

Dependency services (practical)

  • You typically rely on:
  • Cost Explorer being enabled
  • CUR for deep chargeback/showback
  • S3 (CUR delivery)
  • Athena (query CUR)
  • SNS/Email (Budgets notifications)

Security/authentication model

  • Access is controlled via IAM and billing access settings.
  • Purchasing requires elevated permissions (and often restricted to finance/platform roles).
  • CloudTrail records relevant API activity for auditing.

Networking model

  • Savings Plans itself is not deployed into a VPC.
  • If you access APIs privately, consider your organization’s approach to AWS API access (for example, from controlled networks). This is general AWS API access; Savings Plans is not a data-plane service.

Monitoring/logging/governance considerations

  • Monitor:
  • Savings Plans utilization and coverage
  • spend anomalies (via Cost Explorer/Cost Anomaly Detection)
  • budget thresholds (AWS Budgets)
  • Log and audit:
  • CreateSavingsPlan and tagging actions in CloudTrail
  • Governance:
  • Use least-privilege IAM
  • Use Organizations SCPs (if applicable) to limit who can purchase
  • Use tagging/cost categories and defined processes for commitment approvals

Simple architecture diagram (Mermaid)

flowchart LR
  A[EC2 / Fargate / Lambda / SageMaker usage] --> B[AWS Billing Metering]
  B --> C[Savings Plans Benefit Application]
  C --> D[Billing Console & Cost Explorer]
  C --> E[Cost and Usage Report (CUR)]
  D --> F[AWS Budgets Alerts]
  E --> G[Analytics (Athena/BI)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Org[AWS Organizations]
    MA[Management / Payer Account\n(Central FinOps)]
    A1[Workload Account A]
    A2[Workload Account B]
    A3[Workload Account C]
  end

  subgraph Compute[Compute Workloads]
    EC2A[EC2 Auto Scaling]
    FargateA[ECS/EKS on Fargate]
    LambdaA[AWS Lambda]
    SM[AWS SageMaker (eligible usage)]
  end

  A1 --> EC2A
  A2 --> FargateA
  A2 --> LambdaA
  A3 --> SM

  Compute --> Bill[AWS Billing & Cost Management]
  MA -->|Purchase Savings Plans\n(guardrailed IAM)| Bill

  Bill --> SP[Savings Plans Discounts\napplied hourly]
  SP --> CE[Cost Explorer\n(Utilization/Coverage/Recommendations)]
  SP --> CUR[CUR delivered to S3]

  CUR --> S3[(Amazon S3\nCUR Bucket)]
  S3 --> ATH[Athena]
  ATH --> BI[Dashboards (QuickSight / BI Tool)]

  CE --> Bud[AWS Budgets\nSP utilization/coverage alerts]
  Bud --> Notify[SNS/Email/Ticketing]
  MA --> CT[CloudTrail Auditing]

8. Prerequisites

Account / billing requirements

  • An AWS account with access to Billing and Cost Management.
  • If using AWS Organizations, understand whether you purchase from the management account or member accounts and how sharing is configured (verify current org behavior in official docs).

Permissions / IAM

At minimum: – Permissions to view billing and cost data (Cost Explorer, CUR, Budgets). – Permissions to manage Savings Plans (if you will purchase/manage them), typically restricted to a small set of roles.

Common IAM considerations: – Many organizations require enabling IAM access to Billing information in the account settings so non-root principals can access billing features. – Consider separating: – Billing viewer (read-only) – FinOps operator (reports + budgets) – Savings Plans purchaser (create/manage plans, tightly controlled)

Tools

  • AWS Management Console (Billing + Cost Explorer)
  • Optional but useful:
  • AWS CLI v2 (for describing Savings Plans and pulling metrics)
  • Spreadsheet/BI tool or Athena for CUR analytics

AWS CLI installation: – https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Region availability

  • Savings Plans are an AWS billing program; eligibility depends on service and region. Refer to official docs for current region/service eligibility:
  • https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html

Quotas / limits

  • Savings Plans is primarily a billing construct; there are API throttling limits and possibly program limits (verify in official documentation and AWS CLI/API references).
  • If you use CUR/Athena/QuickSight, those services have their own quotas.

Prerequisite services (recommended for production)

  • Cost Explorer enabled
  • AWS Budgets for alerts
  • CUR delivered to S3 for detailed allocation and auditing
  • CloudTrail enabled organization-wide for auditing purchases and changes

9. Pricing / Cost

Savings Plans are not priced like a typical service with per-request charges. The “cost” is the commitment you purchase, and the “benefit” is discounted rates applied to eligible usage.

Pricing dimensions (what you pay for)

  1. Hourly commitment ($/hour)
    You are charged according to your plan’s commitment for every hour in the term.

  2. Term length (1-year or 3-year)
    Longer terms typically provide larger discounts, but reduce flexibility.

  3. Payment option (No Upfront / Partial Upfront / All Upfront)
    Changes cash flow and usually changes effective savings.

  4. Plan type and attributes
    Plan type (Compute, EC2 Instance, SageMaker) and selected attributes affect eligible rates and discounts.

Official pricing page: – https://aws.amazon.com/savingsplans/pricing/

AWS Pricing Calculator (for modeling overall workloads): – https://calculator.aws/

Free tier

  • There is no “free tier” for Savings Plans. Purchasing a plan is a paid commitment.

Primary cost drivers

  • Your chosen commitment level (too high → underutilization waste).
  • Workload stability (stable baseline → high utilization; volatile workloads → risk).
  • Plan type (more flexibility can mean lower discounts than a more constrained plan).
  • Payment option (upfront options affect total effective cost).

Hidden or indirect costs

  • Underutilization: If your usage doesn’t use the hourly commitment, you still pay.
  • Organizational/process overhead: approvals, forecasting, and periodic review.
  • Analytics costs: CUR storage in S3, Athena queries, QuickSight dashboards, etc.

Network/data transfer implications

Savings Plans typically apply to compute usage charges, not to: – data transfer (inter-AZ, inter-region, internet egress) – storage (EBS, S3) – managed service add-ons not covered by plan eligibility

Always validate which line items are eligible in official documentation and in your CUR.

How to optimize cost with Savings Plans

  • Start with a conservative commitment covering baseline usage.
  • Prefer flexibility (Compute Savings Plans) if you anticipate architecture changes.
  • Use recommendations, but validate with:
  • product roadmap changes
  • migrations (e.g., containers, serverless, instance family changes)
  • seasonality
  • Monitor continuously:
  • utilization (are we wasting commitment?)
  • coverage (are we missing savings opportunities?)

Example low-cost starter estimate (math, not AWS pricing)

Even small commitments become meaningful over a year:

  • If you commit $1/hour for 1 year, the commitment charge is roughly:
  • $1 × 24 × 365 ≈ $8,760/year (ignoring leap years and excluding taxes)

This is not a Savings Plans “price” quote—just the arithmetic of a commitment. Minimum commitments and available offerings vary; verify in the AWS console and pricing pages.

Example production cost considerations

For production, your key questions are: – What is our baseline eligible compute spend (per hour) across accounts? – What commitment level would yield high utilization even during low-traffic periods? – Are we comfortable with a 1-year commitment, or is 3-year acceptable? – Do we have governance to prevent overbuying and to monitor outcomes?

10. Step-by-Step Hands-On Tutorial

Objective

Set up a practical Savings Plans workflow in AWS: 1. Ensure billing visibility and Cost Explorer access. 2. Inspect existing Savings Plans (if any). 3. Establish governance: least-privilege IAM boundaries and alerts. 4. Use Cost Explorer to evaluate Savings Plans coverage/utilization and recommendations. 5. (Optional) Prepare for purchase with approval guardrails.

This lab is designed to be low-risk and does not require purchasing a Savings Plan. Purchasing is optional and clearly marked, because it creates a long-term financial commitment.

Lab Overview

You will: – Enable/confirm Cost Explorer access. – Create a read-only IAM policy for Savings Plans visibility (optional but recommended). – Use the console to review recommendations and set AWS Budgets alerts. – Validate that reporting is available and CloudTrail captures relevant events.

Step 1: Confirm billing access and enable Cost Explorer

  1. Sign in to the AWS Console with a principal that can manage billing.
  2. Go to Billing and Cost Management.
  3. Locate Cost Explorer and enable it if it’s not already enabled.

Expected outcome:
Cost Explorer is enabled. You can open Cost Explorer without an access error.

Verification: – Open Cost Explorer and ensure it loads and can display at least basic cost charts.

Common issue: – If you see an access error, verify: – IAM user/role billing access is enabled in account settings (if applicable). – Your role has permissions such as ce:* (for Cost Explorer) and any required billing permissions.

Step 2: (Recommended) Create a read-only IAM policy for Savings Plans visibility

Create a policy that allows FinOps/engineering leads to view Savings Plans data without being able to purchase.

  1. Go to IAM → Policies → Create policy.
  2. Use JSON and create a policy similar to the following (adjust to your org standards).
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSavingsPlans",
      "Effect": "Allow",
      "Action": [
        "savingsplans:DescribeSavingsPlans",
        "savingsplans:ListTagsForResource"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ReadCostExplorerSavingsPlansMetrics",
      "Effect": "Allow",
      "Action": [
        "ce:GetSavingsPlansCoverage",
        "ce:GetSavingsPlansUtilization",
        "ce:GetSavingsPlansUtilizationDetails",
        "ce:GetCostAndUsage"
      ],
      "Resource": "*"
    }
  ]
}

Expected outcome:
A policy exists that provides read-only Savings Plans visibility.

Verification: – Attach the policy to a test role/user and confirm the user can open Cost Explorer Savings Plans pages but cannot purchase.

Notes and caveats: – Billing permissions can be nuanced. Some billing console views require additional permissions or account settings. Verify in official IAM docs and your org’s baseline policies.

Step 3: Install and configure AWS CLI (optional)

If you want command-line verification:

  1. Install AWS CLI v2: – https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  2. Configure credentials (use SSO or short-lived credentials where possible): – https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html

Then verify identity:

aws sts get-caller-identity

Expected outcome:
CLI returns your account and principal ARN.

Step 4: Check whether you already have Savings Plans

Using CLI (optional):

aws savingsplans describe-savings-plans

Expected outcome:
– If you have Savings Plans, you’ll see one or more plans with state and term details. – If you have none, you’ll see an empty list.

Verification (console): – Billing console → Savings Plans → view your inventory/purchases (menu names can vary slightly).

Common issue: – AccessDeniedException: your role lacks savingsplans:DescribeSavingsPlans or billing access isn’t enabled for IAM principals in the account settings.

Step 5: Review Savings Plans utilization and coverage (Cost Explorer)

  1. Go to Cost Explorer.
  2. Find the Savings Plans section: – Utilization report (how much of your commitment was used) – Coverage report (how much eligible usage was covered)

Expected outcome:
– If you have plans, you see utilization and coverage metrics. – If you have no plans, you may see empty metrics, which is still a valid baseline.

Verification: – Confirm the report’s time range and granularity (daily/monthly). – If you have Savings Plans, confirm utilization is >0% and not consistently low.

Step 6: Review Savings Plans recommendations (no purchase required)

  1. In Cost Explorer, open Savings Plans recommendations.
  2. Choose: – Plan type recommendation (Compute vs EC2 Instance vs SageMaker where applicable) – Term (1-year or 3-year) – Payment option (No Upfront, Partial Upfront, All Upfront)
  3. Review: – recommended hourly commitment – estimated savings (based on your historical usage)

Expected outcome:
You can see a recommended commitment and projected savings—if your account has sufficient historical eligible usage.

Verification: – If recommendations show “insufficient data,” wait until you have enough usage history, or verify that eligible services are present.

Step 7: Create AWS Budgets alerts for Savings Plans (governance)

Set alerts so you’re notified when: – utilization is too low (overbought commitment risk) – coverage is too low (missed savings opportunity)

  1. Open AWS Budgets (from Billing console).
  2. Create budget → choose a budget type related to Savings Plans utilization or Savings Plans coverage (names may vary slightly in the UI).
  3. Configure: – threshold(s), e.g. alert if utilization drops below a target – notification channels (email/SNS)

Expected outcome:
A budget exists that alerts the right team when Savings Plans KPIs drift.

Verification: – Budgets list shows the new budget. – Notification subscribers are correct.

Common issue: – Notifications going to the wrong distribution list. Use a central mailbox or ticketing integration.

Step 8 (Optional): Set purchase guardrails (recommended before buying)

Before purchasing, implement guardrails: – Restrict savingsplans:CreateSavingsPlan to a small role. – Require MFA for console sessions used for purchasing. – Use approvals (ticket/change management). – For AWS Organizations, consider SCPs to restrict purchasing from non-approved accounts (verify and test SCP effects carefully).

Expected outcome:
Only approved principals can purchase Savings Plans.

Step 9 (Optional, High-impact): Purchase a Savings Plan

Purchasing creates a long-term commitment. Do this only in a sandbox or with formal approval.

  1. Billing console → Savings Plans → Purchase Savings Plan
  2. Choose: – plan type – term and payment option – commitment $/hour
  3. Review the summary carefully and confirm.

Expected outcome:
A new Savings Plan appears in your Savings Plans inventory, and coverage/utilization reporting will reflect it after billing data updates.

Important:
There is typically no “delete” or “undo” for a purchased Savings Plan. Treat this as a financial commitment.

Validation

Use this checklist: – Cost Explorer enabled and accessible. – You can view Savings Plans utilization/coverage pages. – You can view recommendations (if eligible history exists). – Budgets alerts created and routed to the right owners. – (If purchased) Savings Plan appears in inventory and is in an active/pending state as expected.

Optional CLI checks: – Inventory: bash aws savingsplans describe-savings-plans – CloudTrail auditing (example approach; event names vary): – Review CloudTrail Event History in the console and filter for Savings Plans actions.

Troubleshooting

Problem: “You don’t have permission to view billing” – Enable IAM access to billing information in account settings (if your org uses this setting). – Ensure your role includes ce:* for Cost Explorer views and appropriate billing permissions.

Problem: Cost Explorer pages are empty – New accounts may have limited cost history. – CUR and Cost Explorer data can take time to populate.

Problem: Recommendations show insufficient data – Ensure you have enough eligible compute usage history. – Validate that the services you use are eligible for the plan type you’re evaluating.

Problem: Low utilization after purchase – Commitment is too high or workload shifted. – Consider reducing future purchases; there may not be a way to reduce the current commitment. Build governance to avoid repeats.

Cleanup

Because the lab does not require purchasing, cleanup focuses on governance artifacts:

  • Delete the AWS Budgets budgets you created (if they were only for testing).
  • Detach and remove any test IAM policies/roles created for the lab.
  • If you enabled SNS topics for notifications, delete those topics (only if they were lab-only).

If you purchased a Savings Plan as part of testing: – There is typically no cleanup that removes the commitment. Treat that as permanent for the term. Validate policies and approvals before purchasing.

11. Best Practices

Architecture best practices

  • Buy Savings Plans to cover your baseline compute, not your peaks.
  • Pair with:
  • Auto Scaling (for demand elasticity)
  • Rightsizing (reduce baseline waste)
  • Spot Instances (for interruptible/batch workloads where appropriate)

IAM/security best practices

  • Use least privilege:
  • Separate view vs purchase permissions.
  • Restrict savingsplans:CreateSavingsPlan.
  • Require MFA for high-privilege billing roles.
  • For organizations, consider SCP guardrails to prevent purchases in unapproved accounts (test thoroughly).

Cost best practices (FinOps)

  • Start conservative; iterate monthly.
  • Track KPIs:
  • Utilization (avoid underutilization)
  • Coverage (avoid missed savings)
  • Use Cost Explorer recommendations as an input, not a decision.
  • Use CUR + Athena for deeper chargeback/showback, especially in multi-account setups.
  • Define an internal policy for:
  • term selection (1-year vs 3-year)
  • payment option selection
  • who approves commitments
  • how often you re-evaluate

Performance best practices

  • Don’t compromise instance sizing for the sake of commitment utilization.
  • Optimize performance first, then buy commitments for the resulting stable footprint.

Reliability best practices

  • Remember: Savings Plans do not reserve capacity.
  • If you need capacity guarantees, use capacity tools appropriate to your compute service (verify current best practice for your workload).

Operations best practices

  • Create budgets/alerts on utilization and coverage.
  • Implement monthly review:
  • compare plan utilization to forecast
  • detect workload shifts (migrations, scaling, architecture changes)
  • Maintain a register of:
  • plan IDs, terms, owners, renewal dates, and rationale

Governance/tagging/naming best practices

  • Tag Savings Plans (where supported) with:
  • CostCenter, BusinessUnit, Owner, Environment, FinOpsProgram
  • Use consistent naming in your internal documentation:
  • “SP-COMPUTE-1YR-NOUPFRONT-BASELINE-PLATFORM”

12. Security Considerations

Identity and access model

  • Savings Plans are managed via IAM and billing permissions.
  • Follow separation of duties:
  • viewers (read-only) vs purchasers (create/manage)
  • In AWS Organizations, centralize purchase authority where possible.

Encryption

  • Savings Plans themselves are a billing construct; encryption concerns are mostly about billing data:
  • CUR delivered to S3 should use SSE-S3 or SSE-KMS.
  • Restrict S3 bucket access tightly; CUR contains sensitive financial metadata.

Network exposure

  • No inbound network exposure; you interact with console/API endpoints.
  • Secure access to AWS APIs using your organization’s network controls and identity controls.

Secrets handling

  • Prefer AWS IAM Identity Center (SSO) and short-lived credentials for CLI access.
  • Avoid long-lived access keys in CI/CD for billing operations unless strictly necessary and tightly controlled.

Audit/logging

  • Use CloudTrail to audit Savings Plans purchasing and management actions.
  • Use CUR as a source of truth for detailed billing line items and effective cost allocation.

Compliance considerations

  • Billing data can be sensitive: it can reveal architecture scale and spend patterns.
  • Restrict access under least privilege, and treat CUR datasets as sensitive.

Common security mistakes

  • Allowing broad roles (like developer roles) to purchase Savings Plans.
  • Storing CUR data in S3 without encryption, lifecycle policies, or restricted access.
  • No alerting for utilization drops (which can mask waste).

Secure deployment recommendations

  • Require approvals (ticketing/change management) for any Savings Plans purchase.
  • Centralize purchase privileges in a dedicated billing/FinOps account role.
  • Apply SCPs or permission boundaries to prevent accidental purchases (verify fit with your org).

13. Limitations and Gotchas

  • Long-term commitment: Purchasing typically can’t be “undone.” Underutilization becomes real spend.
  • Not capacity reservation: Savings Plans reduce cost; they generally do not guarantee capacity.
  • Eligibility boundaries: Not all services/charges are covered. Verify which usage types are eligible for each plan type.
  • Doesn’t cover non-compute charges: data transfer, storage, and many managed-service add-ons remain unchanged.
  • Reporting delays: Billing data is not real-time; utilization/coverage may lag.
  • Org sharing complexity: Multi-account sharing is powerful but can complicate chargeback/showback.
  • Overbuying risk: Commitments based on unusually busy periods can lead to low utilization later.
  • Workload migration risk: If you migrate away from eligible usage (or change regions/architectures in ways that reduce eligibility), utilization can drop.
  • Discount interactions: If you also use Reserved Instances or other discount programs, AWS applies billing rules to determine which discount applies. Validate the exact precedence/behavior in official documentation and with your CUR.

14. Comparison with Alternatives

Savings Plans are one tool in a broader Cloud Financial Management toolkit. Here’s how they compare.

Key alternatives in AWS

  • Reserved Instances (RIs): Traditional commitment model often tied more tightly to specific attributes; strong savings for stable EC2 usage.
  • Spot Instances: Deep discounts for interruptible workloads; not a commitment but requires interruption-tolerant design.
  • Compute optimization (rightsizing): Reduces required baseline usage; often complementary to Savings Plans.
  • Auto Scaling and scheduling: Reduce “always-on” waste in dev/test or variable workloads.

Alternatives in other clouds

  • Microsoft Azure Reservations / Azure savings options: Commitment-based discounts (details differ; verify current Azure offerings).
  • Google Cloud Committed Use Discounts (CUDs): Commitment-based discounts for steady usage.

Comparison table

Option Best For Strengths Weaknesses When to Choose
AWS Savings Plans Baseline compute across EC2/Fargate/Lambda/SageMaker (as eligible) Flexible (especially Compute Savings Plans), automatic application, strong reporting Long commitment; underutilization risk; not capacity reservation You have steady baseline compute and want reduced management overhead
AWS Reserved Instances (EC2 RIs) Very stable EC2 usage with known attributes Strong discounts; well-understood in many orgs More configuration constraints; managing at scale can be complex EC2 footprint is stable and you can manage reservations precisely
AWS Spot Instances Batch, stateless, fault-tolerant workloads Very high discounts Interruptions; requires architecture changes You can tolerate interruptions and want maximum unit-cost reduction
Rightsizing / Compute Optimizer Any environment with inefficiencies Cuts waste without long commitments Requires engineering action; may impact performance if done poorly You suspect overprovisioning and want to shrink baseline first
Azure commitments (Reservations / savings plans) Azure-based compute baselines Similar commitment economics Not applicable to AWS usage You run primarily on Azure
GCP Committed Use Discounts GCP-based compute baselines Similar commitment economics Not applicable to AWS usage You run primarily on Google Cloud

15. Real-World Example

Enterprise example: Multi-account platform with centralized FinOps

Problem:
A large enterprise runs hundreds of always-on services across 40 AWS accounts. On-Demand compute spend is high, and each team’s usage is too distributed for consistent per-team optimization. Finance requires predictable run-rate and auditable governance.

Proposed architecture: – AWS Organizations with consolidated billing. – FinOps purchases Savings Plans centrally (management account or designated billing account per org policy). – Savings Plans benefits shared across accounts (where configured). – CUR delivered to a central S3 bucket with SSE-KMS encryption. – Athena queries allocate effective costs; dashboards show: – utilization/coverage by account, environment, and business unit – AWS Budgets alerts on utilization drops and coverage gaps. – CloudTrail used for audit of purchases and tagging.

Why Savings Plans was chosen: – Central purchase + sharing increases utilization across varied workloads. – Compute Savings Plans provide flexibility for ongoing modernization initiatives. – Cost Explorer and CUR give measurable KPIs and auditability.

Expected outcomes: – Reduced baseline compute spend without requiring teams to change deployments. – Better forecasting and monthly variance control. – A repeatable governance model with measurable utilization targets.

Startup/small-team example: Serverless + containers with predictable baseline

Problem:
A startup runs an event-driven system: API + background jobs + steady Lambda invocations and some always-on containers. Spend is growing; the team wants savings without operational complexity.

Proposed architecture: – Compute Savings Plans to cover baseline eligible Lambda and Fargate/EC2 usage (verify eligibility for your services/regions). – Budget alerts if utilization drops (to avoid overcommitting). – Monthly review using Cost Explorer coverage/utilization.

Why Savings Plans was chosen: – Small team can’t spend time managing many reservations. – Compute Savings Plans keep flexibility as the architecture evolves.

Expected outcomes: – Lower unit compute cost while maintaining engineering agility. – Clear monthly KPI review process to avoid long-term waste.

16. FAQ

1) What is AWS Savings Plans in one sentence?

A commitment-based discount program that reduces eligible AWS compute costs when you commit to a consistent hourly spend for 1 or 3 years.

2) Do Savings Plans reserve capacity?

Generally, no—Savings Plans are a pricing benefit, not a capacity reservation mechanism. If you need capacity guarantees, use the appropriate capacity features for your compute service (verify current AWS guidance).

3) What are the main types of Savings Plans?

Common types include Compute Savings Plans, EC2 Instance Savings Plans, and SageMaker Savings Plans. Eligibility differs by type.

4) How does the $/hour commitment work?

You commit to spend a certain amount per hour. Each hour, AWS applies discounted Savings Plans rates to eligible usage up to that commitment.

5) What happens if I use less than my commitment?

You still pay the commitment. This is called underutilization and is the main risk of overbuying.

6) What happens if I use more than my commitment?

Eligible usage above the commitment is billed at regular On-Demand rates (or other applicable discounts if they apply under AWS billing rules).

7) Can I cancel a Savings Plan early?

Typically no. Treat Savings Plans as a long-term financial commitment. Verify current terms in official documentation before purchasing.

8) Is a 3-year Savings Plan always better than a 1-year plan?

Not always. A 3-year term usually increases discount potential but increases lock-in risk. Choose based on workload and business certainty.

9) Do Savings Plans apply to data transfer or storage?

Generally they apply to eligible compute usage, not data transfer, storage, or many non-compute line items.

10) Can Savings Plans apply across multiple AWS accounts?

In AWS Organizations with consolidated billing, Savings Plans benefits can typically be shared across accounts depending on sharing settings. Verify your org’s configuration.

11) Are Savings Plans the same as Reserved Instances?

No. Both are commitment-based savings mechanisms, but Savings Plans use an hourly spend commitment model and can be more flexible depending on plan type.

12) Do Savings Plans apply to Spot Instances?

Savings Plans generally target On-Demand eligible usage; Spot is a separate discounted purchase model. Verify current eligibility rules in official docs.

13) How do I know how much to buy?

Use: – Cost Explorer Savings Plans recommendations (based on historical usage) – internal forecasts/roadmaps – conservative baseline coverage targets
Then monitor utilization/coverage after purchase.

14) How can I track Savings Plans performance?

Track: – Utilization (commitment used) – Coverage (eligible usage covered) via Cost Explorer, Budgets, and CUR.

15) How do I set alerts for low utilization or low coverage?

Use AWS Budgets to create Savings Plans utilization/coverage budgets and notifications.

16) Do Savings Plans automatically apply or do I need to attach them to instances?

They are designed to apply automatically to eligible usage based on billing rules; you do not attach them to resources.

17) Can I use Savings Plans in dev/test?

Yes, but only if dev/test usage is stable enough to justify a long-term commitment. Otherwise, scheduling/off-hours shutdown may save more.

17. Top Online Resources to Learn Savings Plans

Resource Type Name Why It Is Useful
Official product page AWS Savings Plans — https://aws.amazon.com/savingsplans/ High-level overview, plan types, and positioning
Official documentation Savings Plans User Guide — https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html Canonical definitions, eligibility, and how it works
Official pricing Savings Plans Pricing — https://aws.amazon.com/savingsplans/pricing/ Explains the pricing model and purchase dimensions
Official API reference Savings Plans API Reference — https://docs.aws.amazon.com/savingsplans/latest/APIReference/Welcome.html Programmatic management and reporting capabilities
Official Cost Explorer docs Cost Explorer — https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html How to view utilization/coverage and recommendations
Official Budgets docs AWS Budgets — https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html Alerts and governance (including Savings Plans-related budgets)
Official CUR docs Cost and Usage Report — https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html Detailed billing line items for allocation and audit
Architecture guidance AWS Well-Architected Cost Optimization Pillar — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html Best practices to combine Savings Plans with broader cost optimization
Videos (official) AWS YouTube Channel — https://www.youtube.com/@AmazonWebServices Search for “Savings Plans”, “Cost Optimization”, and “FinOps” sessions
Community (reputable) AWS Cloud Financial Management (blog category) — https://aws.amazon.com/blogs/aws-cloud-financial-management/ Practical cost management patterns and updates

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, architects, FinOps teams AWS cost optimization, governance, operational practices Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers DevOps, cloud fundamentals, process and tooling Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud operations teams Cloud operations, governance, cost management practices Check website https://www.cloudopsnow.in/
SreSchool.com SREs, platform teams Reliability + operations practices, cost awareness Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams adopting automation AIOps concepts, monitoring/ops automation foundations Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content (verify current offerings) Engineers seeking practical guidance https://rajeshkumar.xyz/
devopstrainer.in DevOps training and coaching (verify current offerings) Beginners to working professionals https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps services/training platform (verify current offerings) Teams seeking hands-on help https://www.devopsfreelancer.com/
devopssupport.in DevOps support/training (verify current offerings) Ops/DevOps teams needing practical support https://www.devopssupport.in/

20. Top Consulting Companies

Company Name Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify specific services) FinOps processes, AWS governance, delivery automation Savings Plans governance setup, CUR analytics pipeline, multi-account cost allocation https://cotocus.com/
DevOpsSchool.com DevOps and cloud consulting/training Cloud cost optimization, platform engineering practices Implement utilization/coverage KPIs, budgets/alerts, operational playbooks https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify service catalog) DevOps transformation, cloud operations Cost governance, CI/CD + cost controls, reporting dashboards https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Savings Plans

  • AWS billing basics: On-Demand vs discounts, invoices, consolidated billing
  • Core compute pricing concepts:
  • EC2 instance pricing components
  • Fargate pricing dimensions
  • Lambda pricing dimensions
  • AWS Cost Explorer basics and reporting terms (unblended vs amortized concepts—verify your org’s reporting model)
  • IAM fundamentals and least-privilege policy design
  • AWS Organizations basics (if you operate multi-account)

What to learn after Savings Plans

  • CUR deep analytics with S3 + Athena + dashboards (QuickSight/BI)
  • Cost allocation strategies: tagging standards, cost categories, chargeback/showback
  • FinOps operating model: forecasting, anomaly detection, KPI reviews
  • Automation and governance:
  • policy guardrails
  • scheduled reporting
  • continuous optimization loops

Job roles that use Savings Plans

  • FinOps Analyst / Cloud Financial Analyst
  • Cloud Architect / Solutions Architect
  • Platform Engineer
  • SRE / DevOps Engineer
  • Cloud Governance / Cloud Center of Excellence (CCoE)

Certification path (relevant AWS certs)

AWS does not have a certification specifically for Savings Plans, but these certifications align well: – AWS Certified Cloud Practitioner (billing fundamentals) – AWS Certified Solutions Architect – Associate/Professional (architecture + cost tradeoffs) – AWS Certified DevOps Engineer – Professional (operations + governance)

(Verify current certification names and exam guides on the AWS Training and Certification site.)

Project ideas for practice

  • Build a CUR → Athena cost dashboard showing:
  • Savings Plans utilization/coverage over time
  • effective cost allocation by account/team
  • Create an internal policy and approval workflow for purchasing commitments.
  • Implement budgets that alert when utilization drops below a target threshold.
  • Run a monthly cost optimization review: rightsizing + Savings Plans tuning.

22. Glossary

  • Savings Plans: AWS commitment-based discount program for eligible compute usage.
  • Commitment ($/hour): The hourly amount you commit to pay for the plan term.
  • Term: The duration of the plan (commonly 1 year or 3 years).
  • Payment option: How you pay for the plan (No Upfront, Partial Upfront, All Upfront).
  • Utilization: How much of your Savings Plans commitment was used by eligible usage.
  • Coverage: The percentage of eligible usage that received Savings Plans discounted rates.
  • Eligible usage: Compute usage types that qualify for Savings Plans discounts (varies by plan type).
  • On-Demand pricing: Pay-as-you-go pricing without a long-term commitment.
  • AWS Organizations (consolidated billing): A structure to manage multiple AWS accounts with centralized billing and potential sharing of discount benefits.
  • CUR (Cost and Usage Report): Detailed billing dataset delivered to S3, often used for allocation and analytics.
  • FinOps: Cloud financial management discipline combining finance, engineering, and operations.

23. Summary

AWS Savings Plans are a core Cloud Financial Management tool that reduces eligible AWS compute costs through a 1- or 3-year hourly spend commitment. They matter because they can lower baseline compute spend substantially while keeping operations simple through automatic discount application and strong reporting (utilization and coverage).

In AWS architecture terms, Savings Plans live in the billing layer and integrate with Cost Explorer, AWS Budgets, CUR, CloudTrail, and AWS Organizations for multi-account governance. The key cost risk is underutilization—you still pay the commitment even if usage drops—so strong governance, conservative baseline sizing, and continuous monitoring are essential.

Use Savings Plans when you have stable baseline compute and can commit responsibly; avoid them when workloads are uncertain or likely to change dramatically without clear eligible usage replacement. Your next best learning step is to pair Savings Plans with a CUR-based analytics pipeline and a monthly FinOps review process so you can measure coverage/utilization and continuously improve your commitment strategy.