﻿
### Slide 1:

![Slide 1](slide_1.png)

::: Notes


#### Instructor notes 

#### Student notes

:::

### Slide 2:

![Slide 2](slide_2.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 3:

![Slide 3](slide_3.png)

::: Notes

Cloud cost management is an operational discipline, not just a financial one: gaining visibility, setting controls, and optimizing spend are all responsibilities that fall to the operations team. The three pillars — awareness, control mechanisms, and optimization — provide a structured framework that applies regardless of cloud maturity level. Ask students which of these three areas they think their organizations do best, and where the largest gaps typically exist in their experience.

#### Instructor notes

#### Student notes

Now that you are familiar with the basics of your company's Amazon Web Services (AWS) infrastructure, you have been tasked to gain insight into the costs and usage. You are asked to implement *control mechanisms* that help manage cost and usage. Last, you are asked to optimize the company's cloud spend and usage.

:::

### Slide 4:

![Slide 4](slide_4.png)

::: Notes

The awareness-control-optimize framework represents a maturity model for cloud cost management. Awareness without control leads to visibility without action; control without optimization leads to spending within budget but at higher cost than necessary; optimization without awareness means you don't know what to optimize. Each phase requires specific tools and processes, and organizations typically need to establish awareness before controls are effective, and controls before optimization efforts are trustworthy.

#### Instructor notes

#### Student notes

Cloud operations plays a vital role in cost management. You must focus on getting insight into your expenditure and usage. Then you must configure control mechanisms that help you manage your costs and usage. You must also optimize workloads to achieve business outcomes so that your organization can maximize its return on investment.

**Awareness** :

* **Current state** : Configure a dashboard that shows current levels of cost and usage. The dashboard should be available in a highly visible place within the work environment (similar to an operations dashboard).
* **Tracking** : Show the current cost and usage against configured goals or targets.
* **Reports** : Summarize all cost and usage information.
* **Analysis** : Provide the capability for team members to perform custom and deep analysis, down to hourly granularity, with all possible dimensions.
* **Forecasts** : Provide the capability to show estimated future costs.

**Control mechanisms** :

* **Detection** : Develop cost and usage goals and targets. This can be in the form of budgets or monitoring thresholds.
* **Notifications** : Provide notifications when cost or usage is outside of defined limits.

**Optimization** :

* **Cost optimizing** : Determine whether other price models can lower your expenditure (Reserved Instances, Saving Plans).
* **Usage optimizing** : Determine whether you have selected the correct resource type, size, and number.

:::

### Slide 5:

![Slide 5](slide_5.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 6:

![Slide 6](slide_6.png)

::: Notes

AWS Billing and Cost Management is the central service for financial visibility in AWS, but by default only the root user can access billing data. Delegating billing access to IAM users and roles is an important operational configuration that enables finance teams, cost managers, and operations staff to access the data they need without sharing the root account. This delegation requires explicit activation by the account owner and appropriate IAM policies — it does not happen automatically when IAM users are created.

#### Instructor notes

#### Student notes

AWS Billing and Cost Management provides useful tools to help you gather information related to your cost and usage. You can use the tools to analyze your cost drivers and usage trends and take action to budget your spending. Billing and Cost Management provides features that you can use to do the following: assess your investments in AWS resources; receive alerts if your costs exceed a threshold that you set; estimate and plan your future AWS costs.

Note: AWS account owners can delegate access to specific AWS Identity and Access Management (IAM) users who need to view or manage the billing and cost management data for an AWS account. If you create a single AWS account, only the AWS account owner (AWS account root user) can view and manage billing information. IAM users cannot access billing data until the account owner activates IAM access and attaches policies that provide billing actions to the user or role. For more information, see "IAM Tutorial: Grant Access to the Billing Console" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html.

:::

### Slide 7:

![Slide 7](slide_7.png)

::: Notes

The four billing data tools form a spectrum from high-level summary to granular detail. The Billing Dashboard and Invoice view provide quick answers to 'how much did we spend?'; Cost Explorer provides interactive analysis for 'why did we spend that?'; and AWS CUR provides the raw data for 'exactly what was charged and when?'. Understanding which tool to use for which question prevents analysts from trying to use the Billing Dashboard for workload-level cost allocation work that requires CUR-level granularity.

#### Instructor notes

#### Student notes

Components are listed from least to most detail around cost and past usage:

* **Billing dashboard** provides a high-level summary overview.
* **Invoice view** is a line-item summary in PDF format.
* **AWS Cost Explorer** is an AWS tool that helps you analyze the spend and usage associated with all accounts in your consolidated accounts. Accounts are updated approximately every 8 hours.
* **AWS Cost and Usage Reports (AWS CUR)** is detailed information on the exact nature of your AWS account spend.

:::

### Slide 8:

![Slide 8](slide_8.png)

::: Notes

The Billing Dashboard provides three instant visual summaries — last month's spend, current month-to-date, and forecast — that answer the most common financial management question: 'are we on track?' The service-level breakdown reveals which services are driving costs, which is the starting point for any cost investigation. However, the dashboard aggregates costs at the service level; for workload-level attribution, tags and Cost Explorer groups provide the necessary granularity.

#### Instructor notes

#### Student notes

The main page of the Billing and Cost Management service displays three dashboards for quick reference:

* **Spend Summary graph** : Shows you how much you spent last month, the estimated costs of your AWS usage for the month-to-date, and a forecast for how much you are likely to spend this month.
* **Month-to-Date Spend by Service graph** : Shows the top services that you use most and the proportion of your costs that the service contributed to.
* **Month-to-Date Top Services by Spend graph** : Shows the services that you use most, along with the costs incurred for the month to date.

:::

### Slide 9:

![Slide 9](slide_9.png)

::: Notes

AWS invoices provide the official billing record for each month, but they are not the best tool for cost analysis. Invoices aggregate charges at the service level, which is sufficient for accounting purposes but not for workload-level cost allocation or anomaly detection. The ability to view estimated charges during the month lets operations teams check whether spending is tracking as expected before the invoice is finalized — enabling corrective action before costs are locked in.

#### Instructor notes

#### Student notes

Reports help you gain awareness of your

cloud spend and usage. However, you need tools, such as AWS invoices, to
view summarized historical spend and usage data. You can view your
invoices in two ways: download PDFs or use the online interactive
invoices. You receive AWS invoices monthly for usage charges and
recurring fees. For one-time fees, such as fees for purchasing an All
Upfront Reserved Instance, you are charged immediately. At any time, you
can view estimated charges for the current month and final charges for
previous months. For more information, see "Viewing Your Bill" in the
AWS Billing User Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/getting-viewing-bill.html.

:::

### Slide 10:

![Slide 10](slide_10.png)

::: Notes

AWS Cost Explorer transforms raw billing data into interactive charts and tables that enable cost analysis without requiring a data warehouse or custom reporting. The ability to group by service, region, account, tag, or usage type allows teams to perform the cost attribution analysis needed for chargeback or showback programs. The 8-hour data refresh lag means Cost Explorer is not suitable for real-time cost alerting — that requires CloudWatch billing alarms, which are covered later in this module.

#### Instructor notes

#### Student notes

AWS Cost Explorer helps you visualize, understand, and manage your AWS costs and usage over a daily or monthly granularity. Use the tool to delve deeper using granular filtering and grouping dimensions, such as Usage Type and Tags. You can also access your data with further granularity by enabling hourly and resource-level granularity.

**Additional details about AWS Cost Explorer** : The data displayed in Cost Explorer depends on the users' configuration as a self-service. The one-time fees and subscription charges (such as Reserved Instances and AWS Support) are assessed separately from usage and recurring charges on the date that they occur. Charges for the current billing period are estimated and may differ from actual charges for the statement period (finalized post bill run). Finally, all charges and prices are in US dollars, and the dates shown are based on Coordinated Universal Time (UTC). For more information, review "Analyzing your costs with Cost Explorer" in the AWS Billing and Cost Management User Guide (https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html).

:::

### Slide 11:

![Slide 11](slide_11.png)

::: Notes

Cost Explorer's time range and granularity settings determine what level of detail you can analyze. Daily granularity reveals cost patterns within a month; hourly granularity (requiring opt-in) reveals the impact of events like instance launches or scaling activities on cost. Calendar-month alignment for 'last 3 months' means the current month is excluded, which is important to understand when comparing historical periods — the current month's partial data behaves differently from completed months.

#### Instructor notes

#### Student notes

**Historical time range options** : In Cost Explorer, months are defined as calendar months. Days are defined as 12:00:00 AM to 11:59:59 PM. Based on these definitions, when you choose Last 3 Months for a date range, you review cost data for three previous months, not including the present month. For example, if you view your chart on June 6, 2017, and select Last 3 Months, your chart includes data for March, April, and May 2017. All times are in UTC. You can choose time ranges for both your past costs and your forecasted future costs.

**Time granularity** : You can choose to view your cost data in hourly, daily, or monthly levels of granularity. To enable hourly granularity, opt in through the Cost Explorer settings page as the management account. When enabled, information for the previous 14 days is available.

**Chart style** : Cost Explorer provides three styles for charting your cost data. You can set the style by using the View option: bar charts (Bar), stacked bar charts (Stack), line graphs (Line).

For more information, review "Modifying your chart" in the AWS Cost Management User Guide (https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-modify.html).

:::

### Slide 12:

![Slide 12](slide_12.png)

::: Notes

Cost Explorer's forecasting capability uses historical usage patterns to project future costs. The ability to display historical and forecasted periods together in the same chart makes it easy to assess whether current spending trends are consistent with expected future costs. Forecasts are most accurate for stable, predictable workloads; they provide less reliable projections for workloads with irregular usage patterns or planned changes to resource configuration.

#### Instructor notes

#### Student notes

**Forecast time range options** : The following list defines each time range option for your forecast costs in AWS Cost Explorer. You can select a Historical time period and a Forecasted period to display together. For example, you can select a Historical period of one month (1M) and select a Forecasted period of three months (3M). Your report includes historical data for the previous month plus forecasted data for the next 3 months. To clear a Historical time period and review only the forecast, choose the Historical period again.

* **Custom** : Displays forecast data for the time range in the From and To dates that you specify with calendar controls.
* **Daily level granularity** :
  * **+1M** : Displays forecast data for the current day plus the next month.
  * **+3M** : Displays forecast data for the current day and the next 3 months.
* **Monthly level granularity** :
  * **+3M** : Displays forecast data for the current month and the next 3 months.
  * **+12M** : Displays forecast data for the current month and the next 12 months.

For more information, review "Forecasting with Cost Explorer" in the AWS Cost Management User Guide (https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-forecast.html).

:::

### Slide 13:

![Slide 13](slide_13.png)

::: Notes


#### Instructor notes

#### Student notes

This chart shows an example with 6

months of historical data and 3 months of forecasted data.

:::

### Slide 14:

![Slide 14](slide_14.png)

::: Notes

AWS Cost and Usage Reports provide the most granular billing data available — individual resource-level charges at hourly granularity. This level of detail enables workload-level cost attribution, anomaly detection, and chargeback calculations that are not possible with Cost Explorer's aggregated view. The trade-off is volume: CUR files can be very large and require a data processing tool like Athena, Redshift, or QuickSight to query efficiently.

#### Instructor notes

#### Student notes

The AWS Cost and Usage Reports (AWS

CUR) helps you access the most detailed information available about your
AWS costs and usage. The CUR can be generated at an hourly or daily
level of granularity. It also provides individual resource-level data
for all services.

:::

### Slide 15:

![Slide 15](slide_15.png)

::: Notes

CUR setup requires an S3 bucket for report delivery and a choice of integration target (Athena, Redshift, or QuickSight). The format chosen at setup time — Parquet for Athena, Gzip CSV for Redshift/QuickSight — determines how efficiently the data can be queried. Athena integration is popular because it enables SQL analysis of CUR data without a running database, paying only for queries executed. Configuring CUR before you need it is important: reports are generated going forward from activation, so historical data before the setup date is unavailable.

#### Instructor notes

#### Student notes

On the Billing and Cost Management console, create Cost and Usage Reports from the Cost & Usage Reports page. To receive billing reports, you must have an Amazon S3 bucket in your AWS account to store your reports. You can specify an existing bucket or create one when you create your report. Reports include details such as the following: which AWS services you used; amount of time that you used the services; amount of data that you transferred in and out of storage; average storage space that you used.

For Time granularity, choose one of the following: Hourly if you want the line items in the report to be aggregated by the hour; Daily if you want the line items in the report to be aggregated by the day; Monthly if you want the line items in the report to be aggregated by month.

For Enable report data integration for, select whether you want to enable your CUR reports to integrate with Amazon Athena, Amazon Redshift, or Amazon QuickSight. The report is compressed in the following formats: Athena — parquet format; Amazon Redshift or Amazon QuickSight — .gz compression.

After your reports are generated, you can use Athena, QuickSight, or Amazon Redshift to query or analyze your data. You can also get a comma-separated values (CSV) file with your cost and usage data. For more information, see the following in the AWS Cost and Usage Reports User Guide: "Creating Cost and Usage Reports" at https://docs.aws.amazon.com/cur/latest/userguide/creating-cur.html; "Querying Cost and Usage Reports Using Amazon Athena" at https://docs.aws.amazon.com/cur/latest/userguide/cur-query-athena.html.

:::

### Slide 16:

![Slide 16](slide_16.png)

::: Notes


#### Instructor notes

#### Student notes

Cost and Usage Reports contain details

about your usage. These are high-level categories of data included in
your reports. For more information, see "Data Dictionary" in the AWS
Cost and Usage Reports User Guide at
https://docs.aws.amazon.com/cur/latest/userguide/data-dictionary.html.

:::

### Slide 17:

![Slide 17](slide_17.png)

::: Notes

This automation pattern — using EventBridge, Lambda, Athena, and SES to deliver scheduled CUR analysis reports — shows how the standard AWS service building blocks can be composed into a complete cost reporting pipeline. The pattern eliminates manual querying by scheduling the analysis and delivering the results automatically by email. It also demonstrates how to apply the same event-driven architecture used for operational automation to financial reporting.

#### Student notes

This is an example of deploying an automatic CUR query and email delivery solution using the following AWS services: Athena, Lambda, Amazon Simple Email Service (Amazon SES), Amazon CloudWatch.

Here is what the diagram shows: Using a CloudWatch Event (time-based), a scheduled Lambda function is invoked. Query Cost and Usage Report. Deliver query results to Amazon S3. Copy query results to Lambda. Using Lambda, process files. Invoke Amazon SES to mail processed report to users.

To practice by implementing this example, see "Level 300: Automated Athena CUR Query and E-mail Delivery" on the AWS Well-Architected Labs, Cost Optimization website at https://wellarchitectedlabs.com/cost/300_labs/300_automated_cur_query_and_email_delivery.

:::

### Slide 18:

![Slide 18](slide_18.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 19:

![Slide 19](slide_19.png)

::: Notes

Cost control tools transform visibility into accountability: without controls, awareness of spending doesn't prevent overruns. Budgets and alarms define the expected spending envelope and notify stakeholders when those bounds are at risk of being exceeded. The ability to take automated actions — such as stopping instances or applying SCPs when budget thresholds are crossed — makes cost control mechanisms active rather than passive.

#### Instructor notes

#### Student notes

These tools help you set parameters on

your spend and help minimize deviations from your business goals. They
can detect possible impacting occurrences and send notifications and
take actions.

:::

### Slide 20:

![Slide 20](slide_20.png)

::: Notes


#### Instructor notes 

#### Student notes

:::

### Slide 21:

![Slide 21](slide_21.png)

::: Notes

AWS Budgets provides goal-based cost and usage tracking: you define what you expect to spend (or use), and Budgets notifies you when actual or forecasted values approach or exceed the goal. Unlike a CloudWatch alarm that triggers when a threshold is crossed, Budgets can also alert based on forecasted spend — giving you advance notice before costs exceed the budget. This proactive forecasting capability is valuable for organizations that want to take corrective action before overruns occur.

#### Instructor notes

#### Student notes

With an emphasis on expenditure

awareness, you can use AWS Budgets to track your current AWS cost and
usage against budget goals.

:::

### Slide 22:

![Slide 22](slide_22.png)

::: Notes

AWS Budgets supports four budget types: cost budgets for total spend control, usage budgets for resource consumption limits, RI utilization budgets for commitment monitoring, and Savings Plans budgets for discount tracking. RI and Savings Plans budgets help ensure that pre-purchased commitments are being fully utilized — underutilized Reserved Instances represent wasted spend as much as overprovisioned On-Demand instances. Organizations with significant Reserved Instance purchases should actively monitor utilization to ensure full value from those commitments.

#### Instructor notes

#### Student notes

You can create budgets to track and take action on your costs and usage. You can also create budgets to track your aggregate Reserved Instance (RI) and Savings Plans utilization and coverage. By default, single accounts, the management account, and member accounts in an AWS Organizations organization can create budgets. For more information, see the following resources in the AWS Cost Management User Guide: "Creating a Budget" at https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-create.html#create-cost-budget; "Creating a Reservation Budget" at https://docs.aws.amazon.com/cost-management/latest/userguide/create-reservation-budget.html; "Creating a Savings Plans Budget" at https://docs.aws.amazon.com/cost-management/latest/userguide/create-savingsplans-budget.html.

:::

### Slide 23:

![Slide 23](slide_23.png)

::: Notes

Budget period selection defines the reset cycle for tracking: monthly budgets reset at the start of each calendar month and are appropriate for recurring operational expenses; quarterly or annual budgets suit capital expenditure commitments. The fixed versus variable budget option allows for planned spending variations — for example, budgeting higher spend in months with scheduled deployments or events. Planning for variable budgets requires knowing the spending schedule in advance.

#### Instructor notes

#### Student notes

In this section, you configure the

dollar amount for this budget. For Period, choose how often you want the
budget to reset the actual and forecasted spend. You can also set custom
future budgeted amounts for Monthly and Quarterly by using the Budget
Planning feature. For Budget amount, choose Fixed or Monthly Budget
Planning. For a fixed budget, in Budgeted amount, enter the total amount
that you want to spend for this budget period. For Monthly Budget
Planning, enter the amount that you want to spend for each planned
period.

:::

### Slide 24:

![Slide 24](slide_24.png)

::: Notes

Budget filters enable scoping a budget to a specific workload, team, or project rather than the entire account. Tag-based filtering is the most powerful option for multi-workload accounts: if resources are tagged consistently with a project tag, you can create per-project budgets that track costs for just that set of resources. This only works if the tagging discipline is in place; inconsistent tagging produces inaccurate budget scoping.

#### Instructor notes

#### Student notes

You can narrow the scope of your budget

by choosing additional filters. If you want to set a cost budget for all
resources tagged within a specific project, you can filter by tags. For
more information, see "Budget Filters" in the AWS Cost Management User
Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-create-filters.html.

:::

### Slide 25:

![Slide 25](slide_25.png)

::: Notes

Budget alert configuration determines both what triggers a notification and what happens in response. Threshold-based alerts on actual spend notify after the money has been spent; forecast-based alerts provide lead time for corrective action. Budget actions — applying IAM policies, SCPs, or stopping instances — can automate the response to budget exceedance, but their use requires careful design: an overly aggressive action (stopping production instances) could cause an outage more costly than the overspend it was preventing.

#### Instructor notes

#### Student notes

In this section of the budget creation, you can configure alerts. To create a notification for actual spend, choose Actual. To create a notification for your forecasted spend, choose Forecast. For Alert threshold, enter the amount at which you want to be notified. This can be an absolute value or a percentage. For Email recipients, enter the email addresses that you want to send notifications to and choose Add email contact. Separate multiple email addresses with a comma. A notification can have up to 10 email addresses. For SNS topic ARN, enter the Amazon Resource Name (ARN) for your Amazon Simple Notification Service (Amazon SNS) topic and then choose Verify. You can receive your AWS Budget alerts in Amazon Chime or Slack by using AWS Chatbot. To configure an action with this budget, choose Add a budget action. You can choose to apply an IAM policy or a service control policy (SCP). Or you can target specific Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Relational Database Service (Amazon RDS) instances (stop targeted instances). You can apply multiple budget actions to a single threshold. Only a management account can apply SCPs. For more information, see "Receiving Budget Alerts in Amazon Chime and Slack" in the AWS Cost Management User Guide at https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/sns-alert-chime.html.

:::

### Slide 26:

![Slide 26](slide_26.png)

::: Notes

CloudWatch billing alarms provide a simple mechanism for alerting when cumulative monthly charges exceed a defined threshold. An important design constraint: billing metrics are stored only in the US East (N. Virginia) region, so billing alarms must be created in that region regardless of where your workloads run. Billing alarms trigger on actual charges, not projections — if you want an early warning before the threshold is reached, AWS Budgets with forecast-based alerting is a better fit.

#### Instructor notes

#### Student notes

You can monitor your estimated AWS

charges by using Amazon CloudWatch. When you enable the monitoring of
estimated charges for your AWS account, the estimated charges are
calculated and sent several times daily to CloudWatch as metric
data. Data on billing metrics is stored in the US East (N. Virginia)
Region and represents worldwide charges. This data includes the
estimated charges for every service in AWS that you use, in addition to
the estimated overall total of your AWS charges. The alarm is invoked
when your account billing exceeds the threshold you specify. It is
invoked only when actual billing exceeds the threshold. It does not use
projections based on your usage so far in the month. If you create a
billing alarm at a time when your charges have already exceeded the
threshold, the alarm goes to the ALARM state immediately.

:::

### Slide 27:

![Slide 27](slide_27.png)

::: Notes

Enabling billing alerts is a one-way operation: once enabled, it cannot be disabled. This is by design — AWS wants to ensure that billing data collection, once started, continues reliably. The 15-minute delay before billing data appears after first activation is a one-time initialization delay; subsequent updates occur throughout the day. Because billing alarms are created after the data collection is active, the alarm threshold must be set relative to charges that have already accumulated, not from zero.

#### Instructor notes

#### Student notes

Before you can create an alarm for your

estimated charges, you must enable billing alerts. By enabling alerts,
you can monitor your estimated AWS charges and create an alarm using
billing metric data. When the billing alerts feature is enabled, you
cannot disable data collection. However, you can delete any billing
alarms that you created. After you enable billing alerts for the first
time, it takes about 15 minutes before you can view billing data and set
billing alarms. For more information, see "Create a Billing Alarm to
Monitor Your Estimated AWS Charges" in the Amazon CloudWatch User Guide
at
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html.

:::

### Slide 28:

![Slide 28](slide_28.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 29:

![Slide 29](slide_29.png)

::: Notes

Rightsizing recommendations in Cost Explorer identify the most immediate cost reduction opportunity: paying for compute capacity you're not using. Underutilized or idle instances represent wasted spend that can be reduced by downsizing or terminating, often without any workload impact. The analysis is based on historical utilization metrics, so recommendations are only as accurate as the workload's historical behavior — instances with seasonal or unpredictable workloads may appear underutilized during off-peak periods but need full capacity at peak.

#### Instructor notes

#### Student notes

The rightsizing recommendations in AWS

Cost Explorer identify instances that are underutilized or idle. It also
provides the potential savings associated with the recommendations. For
more information, see "Optimizing Your Cost with Rightsizing
Recommendations" in the AWS Cost Management User Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html.

:::

### Slide 30:

![Slide 30](slide_30.png)

::: Notes

Savings Plans represent a commitment to a consistent hourly spend level in exchange for discounted rates — they trade flexibility for cost reduction. Unlike Reserved Instances, Savings Plans apply at the hourly spend level across instance families and even operating systems, making them less rigid but also less targeted. The key design question is how much of your baseline compute usage is predictable and consistent enough to commit to for 1-3 years. The Savings Plans recommendation in Cost Explorer uses your past 30 days of usage to calibrate the commitment amount, balancing maximum savings with risk of underuse.

#### Instructor notes

#### Student notes

To help you save money, AWS provides customized Savings Plans recommendations based on your past usage. You can use these recommendations to understand what you can save.

**Savings Plans compared to Reserved Instances** : Savings Plans are a commitment to a specific level of spending each month on compute resources within a given AWS account for 1--3 years. Unlike Reserved Instances, which are a commitment to a specific level of compute capacity, a Savings Plan can be applied only at the Regional level instead of the Availability Zone level. The plans also differ from Reserved Instances in that you cannot resell your Savings Plan to other customers after you have made the commitment. By contrast, you can sell Reserved Instances to other customers through the AWS Marketplace. Finally, Savings Plans differ from Reserved Instances in that they do not commit you to the use of a particular operating system.

In this example, you could save an estimated \$25 monthly by purchasing the recommended compute Savings Plan. Based on your past 30 days of usage, AWS recommends purchasing one Savings Plan with a total commitment of \$0.085/hour for a 1-year term. With this commitment, AWS projects that you could save an average of \$0.03/hour, which represents a 25% savings compared to On-Demand Instances. To account for variable usage patterns, this recommendation maximizes your savings by leaving an average \$0.02/hour of On-Demand Instances spend. Recommendations require up to 24 hours to update after a purchase. For more information, see "Understanding Your Savings Plans Recommendations" in the Savings Plans User Guide at https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html.

:::

### Slide 31:

![Slide 31](slide_31.png)

::: Notes

Reserved Instance recommendations in Cost Explorer fill the gap for services where Savings Plans don't apply, such as ElastiCache, OpenSearch, and Redshift. The recommendations use historical usage to identify instances that run consistently enough to benefit from a commitment. Regional scoping for EC2 RI recommendations provides more flexibility than AZ-scoped RIs — regional RIs can be applied to any instance in any AZ within the region, avoiding the risk of an RI being unused because a workload moved to a different AZ.

#### Instructor notes

#### Student notes

Cost Explorer also provides recommendations about the potential savings available to you by using Reserved Instances (RIs). These recommendations are based on the historical usage patterns within an account or organization over the past 7, 30, or 60 days. Cost Explorer ignores usage that is already covered by an RI. Amazon EC2, Amazon ElastiCache, Amazon OpenSearch Service, and Amazon Redshift recommendations are for RIs scoped to Region, not Availability Zones. Your estimated savings reflect the application of those RIs to your usage. Amazon RDS recommendations are scoped to either Single-AZ or Multi-AZ RIs. Cost Explorer updates your
recommendations at least once every 24 hours. For more information, see
"Accessing Reserved Instance Recommendations" in the AWS Cost Management
User Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html.

:::

### Slide 32:

![Slide 32](slide_32.png)

::: Notes

Trusted Advisor cost optimization checks provide account-level analysis across multiple resource types, identifying waste that may span multiple services. Unlike Cost Explorer rightsizing, which focuses on EC2, Trusted Advisor covers a broader range including EBS volumes, RDS instances, and Elastic IP addresses. The coverage level of Trusted Advisor checks depends on the AWS Support tier: some checks are available on all plans, while the full set requires Business or Enterprise support.

#### Instructor notes

#### Student notes

You can use the Trusted Advisor

Recommendations page of the Trusted Advisor console to review check
results for your AWS account. One of the check categories is cost
optimization. These recommendations that can potentially save you money.
These checks highlight unused resources and opportunities to reduce your
bill. Some of the checks for the cost optimization category are as
follows:Amazon EC2 Reserved Instances optimizationThis check provides
recommendations on which RIs will help reduce costs incurred from using
On-Demand Instances. 
Low utilization Amazon EC2 instancesThis checks the
Amazon EC2 instances that were running at any time during the last 14
days. The check alerts you if the daily CPU utilization was 10% or less
and the network I/O was 5 MB or less on 4 or more days. Underutilized
Amazon EBS volumesThis checks Amazon Elastic Block Store (Amazon EBS)
volume configurations and warns when volumes appear to be underused.
Amazon RDS idle DB instancesChecks the configuration of your Amazon
Relational Database Service (Amazon RDS) for any database (DB) instances
that appear to be idle. Savings PlanThis checks your usage of Amazon EC2,
AWS Fargate, and AWS Lambda over the last 30 days. The check provides
Savings Plan purchase recommendations. Following these recommendation,
you can commit to a consistent usage amount measured in dollars per hour
for a 1-year or 3-year term in exchange for discounted rates. For more
information, see "AWS Trusted Advisor Check Reference" in the AWS
Support User Guide at
https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html.

:::

### Slide 33:

![Slide 33](slide_33.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 34:

![Slide 34](slide_34.png)

::: Notes

AWS Compute Optimizer uses machine learning to analyze actual utilization metrics and identify the optimal instance type for each workload — not just underutilized instances, but also overprovisioned ones that are degrading performance. Unlike Trusted Advisor's simple utilization threshold checks, Compute Optimizer models the relationship between utilization patterns and instance specifications to recommend specific alternative types. Overprovisioning and underprovisioning are both problems: the former wastes money, the latter wastes performance.

#### Instructor notes

#### Student notes

AWS Compute Optimizer recommends more

efficient AWS Compute resources for your workloads to reduce costs and
improve performance. It does this by using machine learning to analyze
historical utilization metrics. Compute Optimizer generates
recommendations for the following resources:Amazon EC2 instancesAmazon
EC2 Auto Scaling groupsAmazon EBS volumesLambda
functionsOverprovisioning compute can lead to unnecessary infrastructure
cost. Underprovisioning compute can lead to poor application
performance. Compute Optimizer helps you choose the most effective EC2
instance types, including those that are part of an Amazon EC2 Auto
Scaling group, based on your utilization data. For more information, see
"What Is AWS Compute Optimizer?" in the AWS Compute Optimizer User Guide
at
https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html.

:::

### Slide 35:

![Slide 35](slide_35.png)

::: Notes

The Compute Optimizer dashboard provides an account-level summary of optimization status across all analyzed resources. The 12-hour initialization window is an important operational note: newly enrolled accounts or recently launched resources won't have recommendations immediately. The dashboard categories — underprovisioned, overprovisioned, and optimized — give a quick assessment of the overall efficiency posture without requiring analysis of individual resource recommendations.

#### Instructor notes

#### Student notes

The Compute Optimizer dashboard

provides an overview of the optimization opportunities for your AWS
resources. The view is based on the data that's been collected and
analyzed for your account (or accounts if you are currently signed in to
the primary account of your organization). If you recently enabled
Compute Optimizer, there's a chance that no optimization information is
displayed. You might need to wait up to 12 hours for your data to be
analyzed. For more information, see "Viewing the AWS Compute Optimizer
Dashboard" in the AWS Compute Optimizer User Guide at
https://docs.aws.amazon.com/compute-optimizer/latest/ug/viewing-dashboard.html.

:::

### Slide 36:

![Slide 36](slide_36.png)

::: Notes


#### Instructor notes

#### Student notes

This example shows a recommendation for

an overprovisioned instance. Compute Optimizer recommends that you
downsize from an instance type of m5.8xlarge to r5.4xlarge. Implementing
this recommendation can save you \$36.71 per month.

:::

### Slide 37:

![Slide 37](slide_37.png)

::: Notes

Compute Optimizer's finding categories provide nuanced guidance: an instance may be overprovisioned on CPU but underprovisioned on memory, which makes the recommendation more complex than a simple 'downsize.' The categorization logic prevents false positives by only flagging an instance as overprovisioned when it is overprovisioned on at least one dimension without being underprovisioned on any other. This prevents recommendations that would improve cost but degrade performance in a less visible way.

#### Instructor notes

#### Student notes

Compute Optimizer offers

recommendations for EC2 instances and Amazon EC2 Auto Scaling groups.
The findings are categorized as follows. Amazon EC2
instancesUnderprovisioned -- An EC2 instance is considered
underprovisioned when at least one specification of your instance, such
as CPU, memory, or network, does not meet your workload performance
requirements. Underprovisioned EC2 instances might lead to poor
application performance. Overprovisioned -- An EC2 instance is
considered overprovisioned when at least one specification of your
instance, such as CPU, memory, or network, can be sized down while still
meeting your workload performance requirements, and when no
specification is underprovisioned. Overprovisioned EC2 instances might
lead to unnecessary infrastructure cost. Optimized -- An EC2 instance is
considered optimized when all specifications of your instance, such as
CPU, memory, and network, meet your workload performance requirements,
and the instance is not overprovisioned. An optimized EC2 instance runs
your workloads with better performance and infrastructure cost. For
optimized resources, Compute Optimizer might sometimes recommend a new
generation instance type. Amazon EC2 Auto Scaling groupsNot optimized --
An Auto Scaling group is considered not optimized when Compute Optimizer
has identified a recommendation that can provide better performance or
cost for your workload. Optimized -- An Auto Scaling group is considered
optimized when Compute Optimizer determines that the group is correctly
provisioned to run your workload, based on the chosen instance type. For
optimized resources, Compute Optimizer might sometimes recommend a new
generation instance type. For more information, see "Optimizing Your
Cost with Rightsizing Recommendations" in the AWS Cost Management User
Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html.

:::

### Slide 38:

![Slide 38](slide_38.png)

::: Notes

Latest-generation EC2 instances provide a cost-performance improvement that is easy to overlook when workloads are running stably. AWS regularly releases new instance generations (e.g., m5 → m6i → m7i) with better price-performance ratios, meaning the same workload costs less per hour on a newer generation. The operational overhead of evaluating and migrating to newer generations is real, but deferring the migration also has a cost — both direct (higher hourly rate) and indirect (eventual forced migration on a tighter timeline).

#### Instructor notes

#### Student notes

Upgrading to the latest generation

instances can yield two cost benefits:Newer generations cost less per
hour to operate compared to earlier generations. Newer generations
provide better performance, which can result in using fewer
instances. Choosing the right resource from the beginning requires
minimal effort. Upgrading later requires operational overhead and
analysis that might not be financially feasible. For more information,
see "It Just Got Easier to Discover and Compare EC2 Instance Types" in
the AWS Compute Blog at
https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/.

:::

### Slide 39:

![Slide 39](slide_39.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 40:

![Slide 40](slide_40.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 41:

![Slide 41](slide_41.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 42:

![Slide 42](slide_42.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 43:

![Slide 43](slide_43.png)

::: Notes


#### Instructor notes 

#### Student notes

:::

### Slide 44:

![Slide 44](slide_44.png)

::: Notes


#### Instructor notes

#### Student notes

This lab will take you through the

following process:Creating an Amazon SNS topicCreating an Amazon
EventBridge ruleDetecting drift in a stackRemediating with an AWS
Systems Manager document (SSM document)Creating an AWS Config
ruleFinding noncompliant resourcesSetting up automatic remediation

:::

### Slide 45:

![Slide 45](slide_45.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 46:

![Slide 46](slide_46.png)

::: Notes


#### Instructor notes

#### Student notes

AWS Cost Explorer helps you visualize,

understand, and manage your AWS costs and usage over a daily or monthly
granularity. Use the tool to delve deeper using granular filtering and
grouping dimensions, such as usage type and tags. You can also access
your data with further granularity by enabling hourly and resource-level
granularity.Additional details about AWS Cost Explorer The data
displayed in Cost Explorer depends on the users' configuration as a self
service. The one-time fees and subscription charges (such as Reserved
Instances and AWS Support) are assessed separately from usage and
recurring charges on the date that they occur. Charges for the current
billing period are estimated and may differ from actual charges for the
statement period (finalized post bill run). Finally, all charges and
prices are in US dollars, and the dates shown are based on Coordinated
Universal Time (UTC). For more information, see "Analyzing Your Costs
with AWS Cost Explorer" in the AWS Billing and Cost Management User
Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html.

:::

### Slide 47:

![Slide 47](slide_47.png)

::: Notes


#### Instructor notes

#### Student notes

Historical time range optionsIn AWS

Cost Explorer, months are defined as calendar months. Days are defined
as 12:00:00 AM to 11:59:59 PM. Based on these definitions, when you
choose Last 3 Months for a date range, you review cost data for three
previous months, not including the present month. For example, if you
view your chart on June 6, 2017, and select Last 3 Months, your chart
includes data for March, April, and May 2017. All times are in UTC. You
can choose time ranges for both your past costs and your forecasted
future costs. Time granularity You can choose to view your cost data in
hourly, daily, or monthly levels of granularity. To enable hourly
granularity, opt in through the AWS Cost Explorer settings page as the
management account. When enabled, information for the previous 14 days
is available. Chart styleAWS Cost Explorer provides three styles for
charting your cost data. You can set the style by using the View option.
Bar charts (Bar)Stacked bar charts (Stack)Line graphs (Line) For more
information, see "Modifying Your Chart" in the AWS Billing and Cost
Management User Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-modify.html.

:::

### Slide 48:

![Slide 48](slide_48.png)

::: Notes


#### Instructor notes

#### Student notes

Forecast time range optionsThe

following list defines each time range option for your forecast costs in
Cost Explorer. You can select a Historical time period and a Forecasted
period to display together. For example, you can select a Historical
period of 1 month (1M) and select a Forecasted period of 3 months (3M).
Your report includes historical data for the previous month plus
forecasted data for the next 3 months. To clear a Historical time period
and review only the forecast, choose the Historical period again.
CustomDisplays forecast data for the time range in the From and To dates
that you specify with calendar controlsDaily level granularity +1M --
Displays forecast data for the current day plus the next month+3M --
Displays forecast data for the current day and the next 3 monthsMonthly
level granularity+3M -- Displays forecast data for the current month and
the next 3 months+12M -- Displays forecast data for the current month
and the next 12 monthsFor more information, see "Forecasting with Cost
Explorer" in the AWS Billing and Cost Management User Guide at
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-forecast.html.

:::

### Slide 49:

![Slide 49](slide_49.png)

::: Notes


#### Instructor notes

#### Student notes

This chart shows an example with 3

months of historical data and 3 months of forecasted data.

:::
