Set Up AWS Billing Safety Alerts

Harden AWS root access and build budget and billing alerts for a $5 target.

Introduction

30 Second Summary

Cloud costs can creep upward long after a quick experiment feels finished. An early warning gives you time to act before a small surprise becomes an unaffordable bill.

In this project, you will build a layered cost-warning system for an AWS learning account after auditing its root profile. The safety net combines AWS Budgets with Amazon CloudWatch notifications delivered through Amazon Simple Notification Service (Amazon SNS).

What You'll Build

You will open your AWS account to a tested warning system that emails you as spending crosses each guardrail.

By the end of this project, you'll have:

An audited account baseline with no root access keys. You can see its Free Plan or Paid Plan status without exposing account details.
Two active budget guardrails that can email you when spending exceeds Free Tier limits or reaches the fixed $5.00 monthly target.
A tested email alarm ladder that warns at three spending levels. The thresholds are $1.00, $2.50, then $4.00. You can explain why the worldwide Billing metric appears only in US East (N. Virginia).
Secret Mission: Add an 80% forecasted warning to the $5 monthly budget.

Are there any prerequisites?

You need a standalone AWS account with root access protected by MFA. You also need an accessible email inbox plus Safari or another working browser.

Before We Start

This is your moment to define the AWS cost safety net you are about to build. You will also connect its $10 boundary to what matters for your learning account.

Audit Root Access and Billing Settings

Cost alerts cannot protect an AWS account when its root credentials are exposed. An unclear account plan also makes every later threshold harder to trust.

Here, you will use the AWS Management Console to secure the root baseline. You will also document the plan status before enabling account-level billing alerts.

In this step, get ready to:

Leave the root user with no root access keys.
Record the account plan with its relevant non-sensitive status.
Enable the two account-level billing alert preferences.

Inspect and remove root access keys

The root user can control every part of the account. Root access keys would give that power to programmatic tools without the protection of your normal console sign-in.

In Safari, go to the AWS Management Console sign-in page.
Sign in as the AWS account root user with MFA.
Open the account menu in the console header.
Choose Security Credentials.
Scroll to the Access keys section.
Inspect the section for any root access keys.

✔️ No access keys exist

Good work. An empty Access keys section confirms that programmatic root access is not available.

ⓧ I see an access key

Deleting a root access key is intentionally irreversible. That is the safe outcome for this learning account because no workload depends on the key.

Select the root access key.
Choose Actions.
Choose Delete.
Choose Deactivate.
Enter the access key ID only inside AWS's deletion dialog.
Choose Delete.
Repeat this deletion flow for each remaining root access key.

You have removed a high-risk credential. The Access keys section should now contain no root access keys.

Refresh the Security Credentials page.
Capture a cropped screenshot showing the empty Access keys section.
Mask the account number.
Mask the root email address.

You should see that no root access keys exist.

Still Seeing a Root Access Key?

Confirm that you completed both the deactivation step and the final deletion step. Deactivation alone leaves the key listed.

If the deletion dialog rejects the confirmation, copy the access key ID directly from that AWS page. Keep it out of notes and screenshots.

Ask for help: Why is my root access key still listed after I tried to delete it?

Record your account plan

AWS Settings shows whether the account uses a Free Plan or Paid Plan. The same page gives you the non-sensitive status needed to understand the account's financial starting point.

Keep This Audit Read-Only

The Upgrade option changes the account plan. Joining AWS Organizations also upgrades a Free Plan account to a Paid Plan.

This audit only records the current status. Leave both plan-changing paths untouched.

Open the account menu in the console header.
Choose AWS Settings.
Choose Billing.
Identify whether the page shows Free Plan or Paid Plan.
Read the remaining Free Tier days and credits if the page shows Free Plan.
Read the current charges if the page shows Paid Plan.
Avoid choosing Upgrade.
Avoid joining AWS Organizations.

You now know which plan governs the account. You also have the relevant status without recording account identifiers.

Capture a cropped screenshot showing the plan label.
Include the relevant non-sensitive status in the crop.
Mask the account number.
Mask the email address.
Mask credit identifiers and payment information.

Enable billing alerts

Billing preferences in AWS Billing and Cost Management control the account's first warning signals. AWS Free Tier usage alerts email an individual account when usage exceeds 85% of a service's Free Tier limit.

Amazon CloudWatch billing alerts start collecting billing metric data for later alarms. This account-level collection covers estimated worldwide charges.

CloudWatch Collection Is Permanent

Enabling CloudWatch billing alerts permanently starts billing metric data collection. AWS cannot disable this collection later.

You can still delete individual billing alarms created later. The underlying account-level collection remains enabled.

Use the AWS Management Console service search to open AWS Billing and Cost Management.
Choose Billing preferences.
Choose Edit under Alert preferences.
Select Receive AWS Free Tier usage alerts.
Select Receive CloudWatch billing alerts.
Choose Update.

The preference update confirms that both warning systems are enabled. CloudWatch billing metric data collection is now permanent for this account.

Allow Time for Billing Data

First-time CloudWatch billing data activation takes about 15 minutes. A short wait during later metric checks is normal while AWS prepares the data.

Before the final review, which alert preferences do you expect to remain selected after a refresh?

Refresh the Billing preferences page.

You should see Receive AWS Free Tier usage alerts and Receive CloudWatch billing alerts selected.

Return to Security Credentials from the account menu.
Confirm that the Access keys section contains no root access keys.
Return to AWS Settings.
Choose Billing.
Confirm that the page still identifies the recorded plan and relevant non-sensitive status.

What Should You See?

The root Access keys section shows that no root access keys exist.

AWS Settings identifies either Free Plan or Paid Plan with the relevant non-sensitive status.

Billing preferences shows both account-level alert choices selected. CloudWatch billing metric data collection remains permanently enabled.

Alert Preferences Not Staying Selected?

Return to Alert preferences and choose Edit. Select both choices again before choosing Update.

Ask for help: Why are my AWS billing alert preferences not staying enabled after refresh?

You have the account baseline locked down. Next, you'll create two budget guardrails for your learning limit.

Create Budget Guardrails

AWS Free Tier usage alerts track service allowances. A personal $5 ceiling needs its own warning layer.

The billing data you enabled in Amazon CloudWatch can take about 15 minutes to become available. In this step, you'll use AWS Budgets to create two guardrails while that data activates.

In this step, get ready to:

Create a zero-spend budget for spending beyond AWS Free Tier limits.
Configure a fixed monthly cost budget with a $5.00 target.
Verify the email recipient for both budget guardrails.

Create the zero-spend budget

The Zero spend budget template warns after spending exceeds AWS Free Tier limits. It gives you the earliest budget signal without requiring a dollar amount.

In the AWS Management Console from earlier, use the top search bar to find AWS Budgets.
Select AWS Budgets from the search results.
Choose Create budget.
Choose Use a template (simplified).
Choose Zero spend budget.
Name the budget zero-spend-guardrail.
Add your accessible email address as the recipient.
Choose Create budget.

Your first guardrail is now in place. It warns after spending exceeds AWS Free Tier limits.

Budget not listed?

Refresh the AWS Budgets list.
Check that the budget name is exactly zero-spend-guardrail.
Return to the creation flow if the budget was not submitted.

Ask for help: My zero-spend budget is missing from AWS Budgets. Can you help me check the creation settings?

Configure the monthly cost target

A monthly cost budget turns your personal ceiling into a fixed amount. Net unblended costs track actual costs after discounts and credits.

On the AWS Budgets list from earlier, choose Create budget.
Choose Customize (advanced).
Choose Cost budget.
Name the budget monthly-cost-target-5-usd.
Set the budget period to Monthly.
Set the renewal option to Recurring budget.
Choose the Fixed method.
Enter $5.00 as the budget amount.

How This Budget Measures Spend

The Fixed method keeps your target at $5.00 each month. Net unblended costs keep the warning tied to costs after discounts and credits.

Keep the budget at the all-account scope.
Select Use net unblended costs.
Set the alert threshold to 100%.
Set the threshold basis to the budgeted amount.
Select Actual.
Add the same accessible email address as the recipient.
Choose Create budget.

The $5.00 boundary now exists. Email delivery becomes dependable after recipient verification.

A Warning Does Not Stop Charges

AWS Budgets sends notifications when a threshold is crossed. It does not impose a spending cap.

Your 100% Actual alert warns when recorded spending reaches the monthly target. Reacting to that message remains your responsibility.

Verify both email recipients

A direct email recipient must be verified before you rely on its alerts. The target recipient status is Active for both budgets.

Go to your accessible email inbox.
Find the verification message from an @aws.com sender for zero-spend-guardrail.
Check the spam folder if the message is missing.
Use the verification link while signed in to this AWS account.
Return to your email inbox.
Use the verification link for monthly-cost-target-5-usd.

Both recipient confirmations are now submitted. AWS Budgets can update each recipient from Pending to Active.

Before you refresh the budget details, do you expect both recipients to show the same status?

Return to the AWS Budgets list from earlier.
Select zero-spend-guardrail.
Refresh its detail page until the recipient status shows Active.
Return to the AWS Budgets list.
Select monthly-cost-target-5-usd.
Refresh its detail page until the recipient status shows Active.
Return to the AWS Budgets list.

You should see zero-spend-guardrail plus monthly-cost-target-5-usd in the list. The monthly budget should show an amount of $5.00.

That completes your first cost-warning layer. Both budgets now route notifications to an active email recipient.

Recipient Still Pending?

Check the spam folder for another message from an @aws.com sender.
Confirm the recipient address on the budget detail page.
Use the verification link while signed in to the same AWS account.

Ask for help: My AWS Budgets email recipient is still Pending. Can you help me verify it safely?

Protect Your Evidence

Evidence from a root account can expose identifiers. A tight crop keeps your proof safe.

Crop the screenshot to the two budget names plus the $5.00 amount.
Mask any account number or email address that remains visible.

Your budget guardrails are active before any workload exists. Next, you'll test where Amazon CloudWatch exposes the worldwide billing metric.

Reproduce the Regional Metric Trap

Your two budget guardrails are active. They now provide the first warning layer for your $5 target.

The next layer uses Amazon CloudWatch. CloudWatch uses the selected Region to decide which metrics its browser offers.

That regional scope can make worldwide billing monitoring confusing. Testing the metric selector in another Region reveals how the console handles the billing path.

In this step, get ready to:

Select a Region other than US East (N. Virginia).
Test whether the Billing metric path appears in that Region.
Exit the alarm wizard without creating an alarm.

Select a different Region

CloudWatch presents metrics through regional console views. The selected Region appears in the console's top navigation bar.

Return to the Amazon CloudWatch console in your existing root session.
Select the Region name in the top navigation bar.
Choose any Region other than US East (N. Virginia).

The console header should now show the Region you selected.

Inspect the metric browser

The alarm wizard reads the metrics available in the console's selected Region. This attempt keeps the Region you just selected.

Before you open the metric selector, do you think the worldwide billing metric will be available here?

Choose Alarms in the CloudWatch navigation pane.
Choose All alarms.
Choose Create alarm.
Choose Select metric.
Browse AWS Namespaces.
Look for Billing.
Look for Total Estimated Charge.

You will see that Billing is absent in this Region. Total Estimated Charge is therefore absent too.

That missing path is the intended shortfall. Your account-level billing preferences remain enabled.

Why Can a Worldwide Metric Disappear?

CloudWatch filters the metric browser according to the selected Region. A worldwide charge total can still have its metric data stored in one Region.

The selected Region controls visibility in this browser. That scope makes the Billing namespace absent here.

Seeing the Billing Namespace?

Check that the top navigation shows a Region other than US East (N. Virginia).
Return to Select metric after changing the Region.
Refresh the metric selector if it still shows the previous Region's namespaces.

Ask for help: Why can I still see the Billing namespace in the Region I selected?

A root-session screenshot deserves extra care because the console header can expose account details.

Capture a screenshot while the AWS Namespaces list is visible.
Crop the screenshot to the metric browser.
Mask any visible account identifiers.

Cancel the alarm wizard

The wizard remains incomplete because no metric was selected. Leaving it now preserves an alarm-free account.

Before you leave the wizard, what should the alarm list contain after this test?

Choose Cancel to leave the wizard.
Return to All alarms in the CloudWatch navigation pane.
Refresh the alarm list.

You should see no new alarm in All alarms. The console remains set to the Region you selected.

You have reproduced the regional limitation without creating a CloudWatch alarm. No workload resources were launched.

Your two budget guardrails remain unchanged. Both email recipients remain Active.

The regional trap is now documented. Next, you'll apply the regional fix and prove the notification channel with a real email.

Find the Metric and Test SNS Email

Your two AWS budget guardrails are active. The missing Billing namespace now stands between you and the three-level alarm ladder.

The Billing namespace becomes available when Amazon CloudWatch uses its billing metric Region. A tested Amazon Simple Notification Service (Amazon SNS) channel proves that future alarm notifications can reach your inbox.

In this step, get ready to:

Find the worldwide billing metric in US East (N. Virginia).
Create a Standard SNS topic with a confirmed Email subscription.
Publish a test message that reaches your subscribed inbox.

Find the worldwide billing metric

The Region selector controls which CloudWatch metrics you can browse. Your earlier check proved that the Billing namespace stays hidden outside its designated Region.

Before you switch Regions, do you expect the metric browser to remain empty or reveal a Billing namespace?

In Amazon CloudWatch from earlier, select the current Region name in the top navigation.
Choose US East (N. Virginia).

You should see US East (N. Virginia) in the Region selector.

Choose Alarms in the left navigation.
Choose All alarms.
Choose Create alarm.
Choose Select metric.
Choose AWS Namespaces.
Choose Billing.

You should now see the Billing namespace that was absent in the previous Region.

Choose Total Estimated Charge.
Select the checkbox next to EstimatedCharges.
Choose Select metric.

You should see EstimatedCharges loaded into the alarm setup. This proves that the metric is visible and selectable in the correct Region.

Choose Cancel to leave the alarm wizard.

No CloudWatch alarm has been created. The metric check is complete.

What does the Region change prove?

CloudWatch stores billing metric data in US East (N. Virginia). The EstimatedCharges metric represents estimated worldwide charges.

The Region controls where you configure the alarm. It does not limit the charges included in the metric.

Still missing the Billing namespace?

Confirm that the Region selector shows US East (N. Virginia).
Wait until 15 minutes have passed since you enabled CloudWatch billing alerts.
Refresh the metric selector after the activation period.

Ask for help: Why is the Billing namespace still missing in CloudWatch?

Mask any account identifier before uploading your metric evidence.

Create and confirm the email channel

A publish/subscribe channel separates the service sending a notification from the people receiving it. Your SNS topic becomes the shared destination for every billing alarm in the next step.

Return to the AWS Management Console search bar.
Enter Amazon Simple Notification Service.
Select Amazon Simple Notification Service from the search results.

Amazon SNS uses the Region shown in the console header. Your topic must stay in the same Region as the billing alarms that use it.

Confirm that the Region selector shows US East (N. Virginia).
Choose Topics in the left navigation.
Choose Create topic.
Confirm that Type is set to Standard.
Enter aws-billing-alerts in the Name field.
Choose Create topic.

Good progress. The aws-billing-alerts Standard topic now gives your billing alarms one notification destination.

What does a Standard topic do?

A Standard SNS topic accepts messages from publishers such as CloudWatch. It sends each message to confirmed subscriptions attached to the topic.

Your Email subscription turns those published messages into inbox notifications.

Choose Subscriptions in the left navigation.
Choose Create subscription.
Select the topic ARN for aws-billing-alerts.
Set Protocol to Email.
Enter your accessible email address in the Endpoint field.
Choose Create subscription.

The confirmation step is easy to miss because SNS cannot deliver messages until you use the link in your inbox.

Switch to your accessible email inbox.
Open the subscription message from AWS Notifications.
Choose Confirm subscription in the message.
Return to the Amazon SNS subscription page.
Refresh the subscription list.
Confirm that the Email subscription is confirmed.

That confirmation completes the route from the aws-billing-alerts topic to your inbox.

Missing the confirmation message?

Check the spam folder in your accessible email inbox.
Confirm that the subscription endpoint uses the intended email address.
Confirm that the subscription belongs to aws-billing-alerts in US East (N. Virginia).

Ask for help: Why has my SNS email subscription not been confirmed?

Publish and verify the test message

CloudWatch does not test or validate configured SNS alarm actions. A manual publish proves that the topic can deliver a real message before your alarms depend on it.

Before you publish, do you think a confirmed subscription alone proves that the full delivery path works?

Choose Topics in Amazon SNS.
Select aws-billing-alerts.
Choose Publish message.
Enter AWS billing alert channel test in the Subject field.
Select Identical payload for all delivery protocols.
Enter SNS email delivery is working. as the message.
Choose Publish message.

You should see Your message has been successfully published. in the console. This confirms that Amazon SNS accepted the test message.

Switch to your subscribed email inbox.
Open the email with the subject AWS billing alert channel test.
Confirm that the body shows SNS email delivery is working..

You have now proven the complete notification path. A message published to aws-billing-alerts reaches the confirmed inbox.

Test email not arriving?

Confirm that the Email subscription remains confirmed.
Check the spam folder for the test message.
Confirm that you published to aws-billing-alerts in US East (N. Virginia).

Ask for help: Why was my SNS test published successfully without reaching my inbox?

Mask the recipient email address before uploading your evidence.
Keep the test subject visible in the cropped screenshot.

Your billing metric is visible in the correct Region. Your tested SNS channel is ready for the $1.00, $2.50, and $4.00 alarm ladder next.

Build the Billing Alarm Ladder

Your tested Amazon Simple Notification Service (Amazon SNS) topic can deliver a real email. Now you can connect it to a three-level Amazon CloudWatch alarm ladder.

One high threshold leaves little reaction time before the unaffordable $10 boundary. Thresholds at $1.00. $2.50. $4.00. These levels provide escalating warnings while charges are still below that boundary.

In this step, get ready to:

Create the first billing alarm at $1.00.
Add billing alarms at $2.50 plus $4.00.
Verify the completed alarm ladder before ending the root session.

Create the $1.00 warning

A billing alarm changes state when EstimatedCharges crosses a static threshold. The first rung creates an early warning after estimated charges become greater than $1.00.

Switch back to the Amazon CloudWatch console from earlier.
Confirm that the Region selector still shows US East (N. Virginia).
Choose Alarms in the navigation pane.
Choose All alarms.
Choose Create alarm.
Choose Select metric.
Choose Billing under AWS Namespaces.
Choose Total Estimated Charge.

Select the checkbox beside EstimatedCharges.
Choose Select metric.

You should see the Specify metric and conditions page. Its graph displays the estimated worldwide charges reported in USD.

Choose Maximum for Statistic.
Choose 6 hours for Period.
Choose Static for Threshold type.
Choose Greater for the comparison.
Enter 1.00 as the threshold value.

The preview graph should now show a static threshold at $1.00. This line marks the point where the alarm enters ALARM.

Choose Additional Configuration.
Set Datapoints to alarm to 1 out of 1.
Set Missing data treatment to Treat missing data as missing.
Choose Next.

The next page connects this threshold to the email channel you already tested. That test proves the topic can deliver before an alarm depends on it.

Select In alarm under Notification.
Choose Select an existing SNS topic.
Select aws-billing-alerts.
Choose Next.
Enter aws-billing-20pct-1usd under Name and description.
Choose Next.
Confirm the settings under Preview and create.
Choose Create alarm.

Good progress. You should see aws-billing-20pct-1usd in the alarm table with Actions enabled.

How does this alarm react?

The alarm evaluates the current estimated charges with the Maximum statistic every 6 hours. One datapoint above the static threshold can move it into ALARM.

An immediate ALARM state is valid when current estimated charges already exceed $1.00. A new alarm can also show OK or INSUFFICIENT_DATA.

Cannot create the first alarm?

Confirm that the console still shows US East (N. Virginia).
Check that the selected metric is EstimatedCharges under Total Estimated Charge.
Confirm that aws-billing-alerts is available as the existing SNS topic.

Ask for help: Help me check why my $1.00 CloudWatch billing alarm is not being created with the expected metric or SNS action.

Add the $2.50 and $4.00 warnings

The next two alarms reuse the same metric behavior. Their higher thresholds create the middle plus upper rungs of the warning ladder.

Reuse the alarm recipe

Each alarm watches Billing with the Total Estimated Charge metric path.
Each alarm evaluates EstimatedCharges with the Maximum statistic over 6 hours.
Each alarm uses a Static threshold with the Greater comparison.
Each alarm requires 1 out of 1 datapoints with Treat missing data as missing.
Each alarm sends its In alarm notification to aws-billing-alerts.

Start with the middle rung. This alarm represents 50% of the fixed $5.00 monthly target.

Return to All alarms.
Choose Create alarm.
Repeat the earlier metric-selection path until the page displays EstimatedCharges.
Choose Maximum for Statistic.
Choose 6 hours for Period.
Choose Static for Threshold type.
Choose Greater for the comparison.
Enter 2.50 as the threshold value.

The preview graph should now place its static threshold at $2.50.

Choose Additional Configuration.
Set Datapoints to alarm to 1 out of 1.
Set Missing data treatment to Treat missing data as missing.
Choose Next.
Select In alarm under Notification.
Choose aws-billing-alerts as the existing SNS topic.
Choose Next.

Enter aws-billing-50pct-2-50usd under Name and description.
Choose Next.
Confirm the configuration under Preview and create.
Choose Create alarm.

You should now see aws-billing-50pct-2-50usd in the alarm table with Actions enabled.

The upper rung represents 80% of the $5.00 monthly target. Its warning still leaves a buffer before charges reach $10.

Return to All alarms.
Choose Create alarm.
Repeat the earlier metric-selection path until the page displays EstimatedCharges.
Choose Maximum for Statistic.
Choose 6 hours for Period.
Choose Static for Threshold type.
Choose Greater for the comparison.
Enter 4.00 as the threshold value.

The preview graph should now place its static threshold at $4.00.

Choose Additional Configuration.
Set Datapoints to alarm to 1 out of 1.
Set Missing data treatment to Treat missing data as missing.
Choose Next.
Select In alarm under Notification.
Choose aws-billing-alerts as the existing SNS topic.
Choose Next.

Enter aws-billing-80pct-4usd under Name and description.
Choose Next.
Confirm the configuration under Preview and create.
Choose Create alarm.

Your three-level ladder now exists. The alarm table should include the $1.00. $2.50. $4.00 thresholds.

Missing one of the new alarms?

Return to All alarms to check whether the alarm was created.
Open the missing alarm to confirm its threshold value.
Check that its notification uses aws-billing-alerts.

Ask for help: Help me compare my $2.50 or $4.00 billing alarm with the required shared configuration.

Review the ladder and sign out

Before you refresh the alarm list, which three alarm names do you expect to see?

Return to All alarms.
Refresh the page.

You should see aws-billing-20pct-1usd. aws-billing-50pct-2-50usd. aws-billing-80pct-4usd. Each row should show Actions enabled.

The current billing data determines each alarm state. You may see OK. ALARM. INSUFFICIENT_DATA.

Open aws-billing-20pct-1usd.
Confirm that its threshold is greater than $1.00.
Confirm that its In alarm action uses aws-billing-alerts.
Return to All alarms.
Open aws-billing-50pct-2-50usd.
Confirm that its threshold is greater than $2.50.
Confirm that its In alarm action uses aws-billing-alerts.

Return to All alarms.
Open aws-billing-80pct-4usd.
Confirm that its threshold is greater than $4.00.
Confirm that its In alarm action uses aws-billing-alerts.
Return to All alarms.

That completes the safety net. Three enabled alarms now route escalating billing warnings through the email channel you already proved.

Capture one cropped screenshot showing all three alarm names.
Include the thresholds in the crop.
Include the states in the crop.
Include the enabled actions in the crop.
Mask any account-specific links.
Mask any account identifiers.

The cost controls are complete. Ending the root session now limits how long these powerful credentials remain active.

Open the account menu in the AWS Management Console.
Choose the sign-out option for the root session.

You should return to an AWS sign-in screen. Your billing alarm ladder remains active after the root session ends.

Secret mission

Add a Forecasted Warning

Your $5 monthly budget already warns you after recorded spend reaches its target. Add a forecasted warning at 80% while keeping the original actual-spend protection at 100%.

Clean Up Your Resources

Choose whether to keep your guardrails active, pause their notifications, or remove them completely. This project is expected to cost $0 while its three Amazon CloudWatch alarm metrics plus its small number of Amazon Simple Notification Service (Amazon SNS) messages remain within the available monthly free allowances.

Cost warning

AWS Budgets monitoring is free. Its notifications are also free.

The three standard-resolution alarms use three of CloudWatch's 10 free alarm metrics. The project uses only a few messages within the Amazon SNS monthly free allowances.

Existing account usage can reduce these allowances. These alerts send notifications. Charges continue until you stop or delete the services creating them.

Resources you used:

AWS Budget zero-spend-guardrail.
AWS Budget monthly-cost-target-5-usd with an Actual alert at 100% plus a Forecasted alert at 80%.
Amazon SNS Standard topic aws-billing-alerts in US East (N. Virginia).
Confirmed email subscription attached to aws-billing-alerts.
CloudWatch billing alarm aws-billing-20pct-1usd.
CloudWatch billing alarm aws-billing-50pct-2-50usd.
CloudWatch billing alarm aws-billing-80pct-4usd.

Keep everything running

No action is needed. Choose this if you want the cost-warning system to protect future AWS projects.

Both budget guardrails continue emailing the verified recipient when their alert conditions are met.
The Forecasted alert can require approximately five weeks of usage history before it can trigger.
The three CloudWatch alarms continue monitoring the $1.00, $2.50, and $4.00 thresholds.
The tested SNS topic remains ready to deliver CloudWatch alarm notifications.
The confirmed email subscription remains attached to the SNS topic.
CloudWatch billing data collection remains enabled because that preference cannot be reversed.

Pause - I'll come back to this later

Silence the notification paths while keeping the guardrails configured. The alarms can still count toward billable usage if your free alarm allowance is already consumed.

Sign back in to the AWS Management Console as the root user with MFA.
Switch Amazon CloudWatch to US East (N. Virginia).
Select Alarms in the left navigation.
Choose All alarms.
Select the checkbox beside aws-billing-20pct-1usd.
Select the checkbox beside aws-billing-50pct-2-50usd.
Select the checkbox beside aws-billing-80pct-4usd.
Open the Actions menu.
Choose Disable actions.

You should see disabled alarm actions on all three rows. The alarm configurations remain available for later use.

Return to AWS Budgets.
Edit the notifications for monthly-cost-target-5-usd.
Remove the verified email recipient from the Actual alert at 100%.
Remove the verified email recipient from the Forecasted alert at 80%.
Save the budget.
Edit the notification for zero-spend-guardrail.
Remove the verified email recipient from the zero-spend notification.
Save the budget.

Both budgets remain configured without an email recipient. Your cost-warning emails are now paused.

Sign out of the root session from the account menu.

Delete - I don't want to use this again

Deleting these guardrails permanently removes their configurations. CloudWatch billing data collection remains enabled because that preference cannot be reversed.

Sign back in to the AWS Management Console as the root user with MFA.
Switch Amazon CloudWatch to US East (N. Virginia).
Select Alarms in the left navigation.
Choose All alarms.

Select the checkbox beside aws-billing-20pct-1usd.
Select the checkbox beside aws-billing-50pct-2-50usd.
Select the checkbox beside aws-billing-80pct-4usd.
Open the Actions menu.

CloudWatch asks you to confirm before it removes the selected alarms.

Choose Delete.
Confirm the alarm deletion.
Refresh the alarm list.

You should no longer see any of the three billing alarm names.

Return to AWS Budgets.
Open zero-spend-guardrail.
Choose Delete.
Confirm the budget deletion.
Open monthly-cost-target-5-usd.
Choose Delete.
Confirm the budget deletion.
Refresh the budget list.

You should no longer see either budget name in the list.

Return to Amazon SNS in US East (N. Virginia).
Choose Subscriptions in the left navigation.
Select the confirmed email subscription attached to aws-billing-alerts.
Choose Delete.
Confirm the subscription deletion.
Refresh the subscription list.

You should no longer see the subscription for the billing-alert topic.

Choose Topics in the left navigation.
Select aws-billing-alerts.
Choose Delete.
Confirm the topic deletion.
Refresh the topic list.

You should no longer see aws-billing-alerts. That closes every teardown path while leaving the permanent billing-data collection preference enabled.

Sign out of the root session from the account menu.

Nice Work!

Excellent work! Your AWS account now has an audited root profile plus a layered billing safety net.

You can monitor a strict $5 monthly target through verified budget emails plus three escalating billing alarms.

You learned how to:

Established an account security baseline by confirming that no root access keys exist. The baseline also records the account plan plus both enabled billing alert preferences.
Created two AWS Budgets guardrails with an Active email recipient. One warns after spending exceeds Free Tier limits. The other warns at 100% of a fixed $5 monthly target.
Diagnosed the Regional billing metric trap by reproducing the missing Billing namespace outside US East (N. Virginia). You found EstimatedCharges in the correct Region. You tested email delivery through Amazon Simple Notification Service (Amazon SNS). You connected the confirmed topic to three Amazon CloudWatch alarms at $1.00, $2.50, or $4.00.
Secret Mission: Added an 80% forecasted warning to monthly-cost-target-5-usd. The existing Actual alert at 100% remains intact.

Ready to quiz yourself?