Build AWS Project Cost Guardrails

Set up AWS budgets, anomaly alerts, and project cost allocation tags.

Introduction

30 Second Summary

A cloud bill can tell you what you spent after the money is gone. The harder question is whether you can spot a change early enough to connect it to the project that caused it.

In this project, you will build a lightweight FinOps guardrail around the AWS resources you already run. Your setup turns existing billing data into early warnings with clear project ownership.

What You'll Build

You'll show someone an AWS cost workspace that turns a vague monthly bill into named project costs backed by automatic warnings.

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

An account-wide monthly budget in AWS Budgets that emails you when actual spending reaches 80%. It sends another warning when forecasted spending reaches 100%.
A daily anomaly summary from AWS Cost Anomaly Detection when unusual service spend crosses your chosen threshold.
A project ownership view in AWS Cost Explorer that groups processed costs by the case-sensitive Project tag.
Secret Mission: A tag-filtered budget that gives one project its own spending boundary with dedicated email alerts.

Are there any prerequisites?

You'll need a Windows device with Microsoft Edge plus existing AWS resources to tag. Billing access must come from either a standalone account or an AWS Organizations management account.

Before We Start

Cost guardrails only help when they reflect the real AWS projects you operate. This planning step gives every selected resource a clear owner.

You will confirm Microsoft Edge as your browser. You will also choose stable non-sensitive values for the case-sensitive Project resource tag before anything changes in AWS.

In this step, get ready to:

Confirm Microsoft Edge is available on your Windows device.
Map existing AWS resources to the real projects that own them.
Choose stable non-sensitive values for the case-sensitive Project tag.

Confirm Microsoft Edge

This project uses Microsoft Edge to access the AWS consoles from your Windows device. Confirming the browser now keeps the remaining work installation-free.

Press the Windows key to open the search panel.
Type Microsoft Edge into the search field.
Select Microsoft Edge from the search results.
Check that the browser opens with an address bar.

Good. Microsoft Edge is ready for the AWS console work ahead.

Microsoft Edge Missing From Search?

Stop before entering any AWS sign-in details.

Help me confirm Microsoft Edge on my Windows device.

Map your AWS projects

Project ownership must be known before you tag a resource. This prevents uncertain resources from receiving a misleading label.

Review the existing AWS resources you know well.
Choose one real project that owns at least one of those resources.
Choose a second real project when one exists.
Match each selected resource to exactly one project owner.
Leave every resource with uncertain ownership out of your plan.
Use the checkpoint below to record your project-to-resource matches.

You now have an ownership map based on resources you already understand. That map keeps the later tagging work accurate.

Choose stable Project tag values

Tag keys and values are case-sensitive. A consistent Project key produces useful grouping when every project keeps one stable value.

Choose one stable non-sensitive Project value for each project.
Keep the capitalization of each value consistent.
Exclude account numbers from every value.
Exclude email addresses from every value.
Exclude confidential client details from every value.
Record your planned values in the checkpoint below.

Before you review your plan, do you expect every selected resource to have one known owner plus one stable Project value?

Re-read your project-to-resource matches in the first planning checkpoint.
Confirm every selected resource has one known project owner.
Re-read your planned values in the second planning checkpoint.
Confirm each project has one stable non-sensitive Project value.

You should now have Microsoft Edge ready plus a written ownership map with stable Project values. No AWS workloads or FinOps configurations have changed.

Your browser is ready with a clear ownership plan beside it. Next, you will open AWS Billing and Cost Management to confirm that your account can access its existing cost data.

Open Your Cost Management Workspace

Cost guardrails only help when your account exposes billing data you can inspect. This check proves you can reach that data without installing software or creating resources.

The path stays inside Microsoft Edge. AWS Cost Explorer in the AWS Management Console provides the access check.

In this step, get ready to:

Sign in to the AWS Management Console with billing access.
Open Cost Explorer from AWS Billing and Cost Management.
Confirm existing cost data or record the initial data-preparation state.

Sign in with billing access

Billing data belongs to a restricted account surface. A standalone account or an AWS Organizations management account with billing access can reach it.

Your real credentials remain inside the AWS sign-in flow. No password or verification code is recorded in this project.

Switch back to Microsoft Edge.
Navigate to the AWS Management Console.
Sign in with your standalone account or AWS Organizations management account that has billing access.
Complete any verification prompt from your existing sign-in flow.
Wait for the AWS Management Console home page to finish loading.

You'll see the console home page for the billing-enabled account. That gives you the authenticated session this project needs.

Cannot Reach the Billing Account?

Check that you selected the standalone account or AWS Organizations management account with billing access.
Ask your AWS administrator to confirm your billing permissions if the correct account still blocks access.

Help me confirm the AWS account or permission I need for billing access.

Open Cost Explorer

AWS Billing and Cost Management gathers your account's cost tools in one workspace. Cost Explorer turns processed billing data into the chart you need for a spending baseline.

Use the console search to find AWS Billing and Cost Management.
Select AWS Billing and Cost Management from the search results.
Choose Cost Explorer in the left navigation pane.
Choose Launch Cost Explorer if the welcome page appears.
Wait for the main Cost Explorer area to finish opening.

What Happens After Launch?

A first launch starts billing-data preparation. Current-month data is available in about 24 hours.

Older prepared data can take a few more days. Cost Explorer updates at least once every 24 hours.

Enabling Cost Explorer automatically configures an AWS services monitor plus a daily summary alert subscription. AWS creates these defaults as part of Cost Explorer enablement.

Confirm the Cost Explorer state

Cost Explorer now provides the billing-access checkpoint. The main area shows either processed cost data or the documented preparation state.

Before you check, predict whether this account already has cost data ready.

Review the main Cost Explorer area to reveal its current state.

✔️ I see a cost chart

You'll see a chart containing existing account cost data.

Confirm that the chart contains existing account costs.

That's the access check complete. Your billing workspace can now support the cost guardrails you build next.

Chart Looks Empty?

Check that you are using the billing-enabled account identified at the start of this step. Recent billing data can still be processing.

Help me understand why my Cost Explorer chart does not show existing costs.

ⓧ AWS is preparing billing data

You'll see AWS indicate that cost data is being prepared. A first launch commonly needs about 24 hours for current-month data.

Record the activation time here: your Cost Explorer activation time.
Leave Cost Explorer launched while AWS prepares the billing data.

Let Preparation Finish

This preparation state is a valid immediate checkpoint. Creating extra AWS usage would add cost without accelerating billing-data preparation.

ⓧ I cannot access Cost Explorer

The current account does not provide the billing access required for this checkpoint.

Switch to the standalone account or AWS Organizations management account with billing access.
Ask your AWS administrator to confirm billing access if the correct account still blocks Cost Explorer.
Return to AWS Billing and Cost Management after access is confirmed.
Choose Cost Explorer again.

Cost Explorer Still Blocked?

Help me troubleshoot my AWS billing access.

Cost Explorer is launched for the billing account. Existing cost data is visible, or Cost Explorer is in its documented initial data-preparation state with the activation time recorded.

Your cost management workspace is ready. Next, you'll use its service-level chart to expose the missing project ownership dimension.

Review Your Service Cost Baseline

Your AWS Cost Explorer workspace is ready. You can now turn raw billing data into a cost baseline.

A monthly service view shows where account spend is concentrated. This read-only test checks whether that view can identify the internal project that owns each charge.

No workloads are created. No billing settings are changed.

In this step, get ready to:

Create a recent monthly cost view.
Record the service baseline needed for the next guardrail.
Test whether Service grouping reveals internal project ownership.

Set a stable monthly view

Monthly granularity smooths out daily fluctuations. A range containing a completed month gives you a stable reference for later guardrail calculations.

Switch back to the Cost Explorer page from earlier.
Check whether the chart contains cost data.

✔️ I see cost data

Choose a recent date range that contains existing costs.
Include the prior full calendar month in the range.
Set the chart granularity to Monthly.

You will see costs summarized into monthly periods. The completed month gives you a baseline that is unaffected by an unfinished current month.

ⓧ Cost Explorer is preparing data

This wait can feel uncertain because the chart has no baseline yet. Current-month data is available in about 24 hours after Cost Explorer is enabled.

Older prepared data can take a few more days. Cost Explorer updates its data at least once every 24 hours.

Keep the activation time from earlier as your waiting-period reference.
Return to Cost Explorer after AWS finishes preparing the data.
Avoid creating test usage to force a chart.

You have confirmed billing access successfully. The documented preparation state is a valid checkpoint for this step.

Record the service baseline

This substep applies once the chart contains cost data. A service grouping separates the account total into the AWS services that generated it.

Locate the grouping control above the chart in Cost Explorer.
Select Service.

You will see separate service categories in the chart. Their relative sizes show where account spending is concentrated.

Can't select Service?

Confirm that Cost Explorer has finished preparing billing data.
Remove the current chart grouping before selecting Service.

Help me find the Service grouping in Cost Explorer.

Identify the service with the largest visible cost.
Record the service name plus amount here: service name and visible cost.

The prior full month's unblended total represents a completed billing period. This is the stable account baseline you carry into the next guardrail.

Set the date range to the prior full calendar month.
Confirm that the displayed total uses unblended costs.

You will see the completed month's total for the selected account scope.

Record the completed month's total here: prior full month's unblended total.

No Completed-Month Total?

Record the prior-month baseline as unavailable when the completed month contains no visible cost.
Keep the largest visible service value when one is available.

An unavailable value gives you an honest baseline. A guessed amount would weaken the guardrail calculation.

Test project ownership

Service grouping answers which AWS service generated spend. Project attribution asks which internal project owns that spend.

Before you inspect the chart again, do you think the Service grouping can name one of the real AWS projects you identified earlier?

Inspect the chart labels for one of your real project names.
Inspect the grouping choices for an internal project ownership dimension.

You will see AWS service names. Your internal project names are absent.

That shortfall is the intended result. The missing ownership dimension is Project.

Leave the chart grouped by Service.
Keep your recorded baseline values for the next guardrail.
Crop account identifiers from the screenshot area.

You found the key blind spot in the account baseline. The chart now proves why service totals alone cannot support project ownership.

Your baseline now shows where spending sits by service. Next, you will turn the prior-month total into a recurring monthly warning.

Create a Monthly Budget Guardrail

Your service chart gives you a baseline for the account. It only reports spending after AWS processes it.

AWS Budgets turns that passive baseline into an active warning system. You will create a recurring monthly budget with separate alerts for actual spend and forecasted spend.

In this step, get ready to:

Calculate a monthly budget amount from your existing cost baseline.
Create a fixed recurring budget for the whole account.
Configure email alerts for actual spend plus forecasted spend.

Calculate your monthly budget amount

A useful budget starts slightly above normal monthly spending. This guardrail uses your prior full month as its baseline while keeping a minimum amount for accounts with little available history.

Find the prior full month's unblended total you recorded in Cost Explorer.
Multiply that total by 110% when the historical total is available.
Round the result up to the next whole dollar.
Compare the rounded result with $5.
Use $5 when the historical total is unavailable.
Record the greater amount here: your monthly budget amount.

How does the calculation work?

The extra ten percent gives normal spend a small buffer before the budget reaches its full amount. Rounding up produces a whole-dollar value that is easy to enter.

The minimum keeps the guardrail usable when billing history is missing or lower than $5.

Create the recurring cost budget

A cost budget compares processed account spend with the amount you choose. Keeping its scope unfiltered makes this guardrail cover the whole account.

Return to AWS Billing and Cost Management from earlier.
Choose Budgets from the navigation panel.
Choose Create budget.
Choose Customize (advanced).
Choose Cost budget.

You should now see the form for configuring a cost budget.

Enter FinOps-Monthly-Guardrail as the budget name.
Choose Monthly as the period.
Choose Recurring budget as the budget type.
Choose Fixed for the budgeting method.
Enter your monthly budget amount as the fixed amount.
Set the cost metric to unblended costs.
Leave the budget scope unfiltered.

The form should now show a fixed monthly budget for the whole account. Its amount should match your monthly budget amount.

Does the amount look too low?

Return to your recorded prior full month's unblended total. Confirm that you rounded the result upward after applying 110%.

Use $5 whenever that calculation produces a smaller amount.

Help me check my budget calculation.

Add actual and forecasted alerts

An Actual alert compares the threshold with processed spend. A Forecasted alert warns when AWS projects that spending will reach its threshold.

Record the email address for your budget alerts here: your alert email address.
Choose Add an alert threshold.
Choose % of budgeted amount as the threshold type.
Enter 80% as the threshold.
Choose Actual as the alert basis.
Enter your alert email address under Email recipients.

The first alert should now show an Actual threshold at 80% with your email as its recipient.

Choose Add an alert threshold again.
Choose % of budgeted amount as the second threshold type.
Enter 100% as the second threshold.
Choose Forecasted as the second alert basis.
Enter your alert email address under Email recipients.

The alert summary should now contain two email thresholds. One tracks processed spend at 80%.

The other tracks forecasted spend at 100%.

Keep This Guardrail Lightweight

Amazon SNS stays unconfigured. Chat alerts stay unconfigured.

Budget reports stay unused. Budget actions stay unused.

No workload is created. This budget only monitors costs from resources that already exist.

Review the notification summary.

Only your alert email address should appear as a notification destination.

Creating this budget does not launch any AWS resources. AWS Budgets monitoring plus notifications are free.

Create the configured guardrail by choosing Create budget.

Your account-wide guardrail is now configured. The passive service chart has become a recurring warning system.

Switch to the inbox for your alert email address.
Open the verification message from AWS.
Follow the verification link in the message.

Before you inspect the finished budget, do you expect its details to show one alert or two?

Return to the Budgets page from earlier.
Open FinOps-Monthly-Guardrail from the budget list.

You should see FinOps-Monthly-Guardrail as a recurring monthly fixed cost budget for the whole account. Its amount should match your monthly budget amount.

The details should show an Actual alert at 80%. They should also show a Forecasted alert at 100% for your verified email address.

Budget or Email Missing?

Refresh the Budgets list if the new budget is missing.
Confirm that you are viewing the same billing account used for Cost Explorer.
Check the spam folder if the verification message has not reached your inbox.
Open the budget details to confirm that the email address has no typing errors.

Help me troubleshoot my missing AWS budget or verification email.

Your monthly spending baseline now has a recurring guardrail. Next, you will add monitoring for unusual service-level spending that a fixed limit can miss.

Set Up Daily Anomaly Alerts

Your account-wide budget is live with actual and forecasted email alerts. It now warns you as monthly spend approaches your fixed limit.

A fixed budget measures progress toward one monthly limit. AWS Cost Anomaly Detection uses machine learning to flag service spending that looks unusual even when total spend remains below that limit.

In this step, get ready to:

Reuse an existing AWS services cost monitor or create one when none exists.
Calculate an absolute impact threshold from your monthly budget amount.
Create a daily email summary without Amazon SNS individual alerts.

Inspect the AWS services monitor

Enabling Cost Explorer can automatically configure an AWS services monitor. Checking first prevents you from creating a duplicate.

In the AWS Billing and Cost Management workspace from earlier, choose Cost Anomaly Detection in the left navigation.
Choose the Cost monitors tab.
Check whether the monitor list already contains an AWS services monitor.

✔️ An AWS services monitor already exists

The existing AWS-managed monitor already watches spending across AWS services. Reuse it for this project.

Keep the existing AWS services monitor available for the alert subscription.

ⓧ No AWS services monitor exists

The monitor list has no AWS services monitor. Create the project monitor now.

Choose Create monitor.
Choose Managed by AWS.
Select AWS services as the monitor type.
Enter FinOps-Service-Anomalies as the monitor name.
Choose Create monitor.

You should see FinOps-Service-Anomalies in the monitor list with the AWS services monitor type.

Your AWS services monitor is ready. It provides the service-level signal that your account-wide budget cannot provide.

Can't see an AWS services monitor?

Refresh the Cost monitors tab.
Confirm that the project-created monitor uses the AWS services monitor type.

If the monitor still does not appear, help me check my Cost Anomaly Detection monitor setup.

Calculate the alert threshold

Your anomaly threshold should scale with the monthly guardrail while still catching meaningful changes on smaller accounts. You will use the greater of $1 or 10% of the FinOps-Monthly-Guardrail amount.

Calculate 10% of the monthly amount configured in FinOps-Monthly-Guardrail.

This result is your budget-scaled candidate threshold.

Compare the candidate threshold with $1.
Record the larger result here: your anomaly threshold in dollars.

Create the daily summary subscription

A Daily summaries subscription emails the top 10 alerts from the previous day. Its threshold controls email delivery while lower-impact anomalies remain visible in the console.

Choose the Alert subscriptions tab.
Choose Create a subscription.

You'll see the subscription form where you define the email digest.

Enter FinOps-Daily-Anomalies as the subscription name.
Choose Daily summaries as the frequency.

The subscription now targets one daily email digest instead of individual alerts.

Enter your verified email address as the recipient.
Enter your anomaly threshold in dollars as the absolute impact threshold.

The form should now show your verified email recipient and the budget-scaled absolute threshold.

Select the AWS services cost monitor you confirmed in the previous substep.
Leave Amazon SNS individual alerts unconfigured.

The subscription should now point to one AWS services monitor with email as its notification channel.

Choose Create subscription.

Your daily anomaly subscription is saved. You now have unusual service spending covered alongside the monthly budget guardrail.

Before you inspect the result, which saved settings do you expect to prove that the alert uses the right monitor and threshold?

Select FinOps-Daily-Anomalies on the Alert subscriptions tab.

You should see Daily summaries with your verified email recipient. You should also see your anomaly threshold in dollars as the absolute impact threshold.

You should see the AWS services monitor attached to the subscription. No Amazon SNS individual alerts should be configured.

Subscription missing or incomplete?

Refresh the Alert subscriptions tab.
Confirm that FinOps-Daily-Anomalies does not already exist before creating it again.
Check that the subscription has an email recipient and an attached AWS services monitor.

If the saved settings still look wrong, help me troubleshoot my daily anomaly subscription.

Your monthly budget now catches planned drift while the daily anomaly subscription watches for unusual service spending. Next up, you'll use Project tags to connect processed costs with their owners.

Activate Project Cost Allocation

Your monthly budget and daily anomaly subscription now watch account spending from two angles. The next job is to connect each existing resource to the project that owns its cost.

The Cost Explorer chart still groups charges by AWS service. It cannot show your internal project ownership.

A consistent Project tag creates that missing dimension. Tag Editor lets you apply the tag to existing resources without creating a new workload.

In this step, get ready to:

Find existing cost-accruing resources across the relevant Regions.
Apply consistent Project values one project at a time.
Activate Project for cost allocation.

Find existing resources by project

Tag Editor searches existing resources across the AWS Regions you choose. A broad resource-type search helps you find resources from several services in one place.

Your selection needs a clear ownership boundary. Include only existing cost-accruing resources whose project ownership you know.

Switch back to the AWS Management Console tab in Microsoft Edge.
Use the search box at the top of the console to open Tag Editor.
Select every Region that contains resources you want to attribute.
Choose All resource types for the resource type.
Choose Search resources.

You should see existing resources from the selected Regions in the results. This gives you one place to compare resource ownership before changing any tags.

Review the results for resources that generate costs.
Select only the resources owned by your first project.

Cannot find an expected resource?

Check that every relevant Region is included in the search.
Confirm that All resource types remains selected.

Ask for help with the search results: Why is my existing AWS resource missing from Tag Editor?

Apply Project tags one project at a time

Tag keys and values are case-sensitive. The key must be exactly Project for every selected resource.

Tagging one project at a time prevents mixed ownership values. Each value should stay stable over time without exposing sensitive information.

Choose one stable non-sensitive value for the first project: your first project tag value.
Choose Manage tags of the selected resources.
Choose Add tag.
Enter Project in the tag key field.
Enter your first project tag value in the tag value field.
Choose Review and apply changes.
Choose Apply changes to all selected.
Keep Tag Editor open until it reports success or failure.

You should see a green success banner when the first project's tags are applied. The selected resources now share one ownership value.

Record when Tag Editor applied the first project's tags: time you applied the Project tag.
Return to the Tag Editor resource search if a second real project exists.
Select only the resources owned by the second project.
Choose a stable non-sensitive value for the second project: your second project tag value.
Repeat the tagging workflow above using your second project tag value.

If you tagged a second project, you should see another green success banner. Its resources now carry a different stable ownership value.

Did a tag change fail?

Confirm that your signed-in role can tag the affected resource types.
Retry only the failed resources after the permission is corrected.

Get help with a failed tag update: Why did Tag Editor fail to apply my Project tag?

Good work. Your existing resources now carry consistent ownership labels without adding a workload.

Activate the cost allocation tag

A user-defined tag must be activated before it can appear in billing views. AWS Billing and Cost Management controls that activation for your standalone account or AWS Organizations management account.

This part can be slow. AWS can take up to 24 hours to list a newly applied tag key for activation.

Return to AWS Billing and Cost Management from earlier.
Choose Cost allocation tags.
Locate Project in the user-defined tag list.

Choose the path that matches the status you see.

✔️ Project is listed

Select Project.
Choose Activate.
Record when you selected Activate: time you activated the Project tag.

The tag is now selected for activation. It can show Active immediately or remain in activation processing for up to 24 hours.

ⓧ Project is not listed yet

AWS is still discovering the newly applied key. Use time you applied the Project tag as the start of the documented wait.

Return to Cost allocation tags after up to 24 hours.
Select Project once it appears.
Choose Activate.
Record the activation selection time: time you activated the Project tag.

AWS can take up to another 24 hours to activate the tag.

ⓧ Project activation is processing

Record the activation selection time if you have not already: time you activated the Project tag.
Return to Cost allocation tags after up to 24 hours.

A processing state is a valid immediate checkpoint. Keep the project configuration in place while AWS completes activation.

Before you check the current status, do you expect Project to be Active already or still processing?

Read the current status shown next to Project.

You should see Active or a pending state within the documented wait. Either result confirms that the cost allocation checkpoint is on track.

Activation makes the tag eligible for billing views. Allow up to 24 hours for new tagged usage to reach the processed cost data.

Before you apply the grouping, which charges do you expect to appear without a Project value?

Return to Cost Explorer after Project is active and new tagged usage has been processed.
Set the Cost Explorer grouping to Tag.
Choose Project as the tag key.

You should see your stable project values plus any untagged cost. This view provides the project ownership dimension that the service-only chart was missing.

No Project values in Cost Explorer?

Confirm that Project shows Active under Cost allocation tags.
Wait for normal tagged usage to reach the billing data.
Use a date range containing usage from after the resources were tagged.
Avoid creating test usage just to populate the chart.

A tag assigned for the first time does not add project values to older costs.

Ask for help with the delayed billing view: Why are my active Project tags missing from Cost Explorer?

That closes the attribution gap. Your ownership metadata now has a path into processed project costs.

Secret mission

Add a Project-Specific Budget

Give one tagged project its own monthly spending boundary. You will scope a recurring budget to exactly one user:Project value and add email alerts for actual and forecasted spend.

Clean Up Your Resources

These persistent guardrails create no compute or storage workload with an expected incremental cost of $0. Decide whether to keep monitoring active, pause the console session, or delete the project settings.

Resources you used:

A recurring account-wide budget named FinOps-Monthly-Guardrail in AWS Budgets with 80% Actual and 100% Forecasted email alerts.
A recurring project-filtered budget named FinOps-Project-Guardrail for one user:Project value with 80% Actual and 100% Forecasted email alerts.
A daily-summary subscription named FinOps-Daily-Anomalies in AWS Cost Anomaly Detection.
A monitor named FinOps-Service-Anomalies only if this project created one instead of reusing the pre-existing AWS services monitor.
Case-sensitive Project tags applied to selected existing resources through Tag Editor.
An active user-defined cost allocation tag for the Project key.

Keep everything running

No action is needed. Choose this option to keep receiving budget warnings and daily anomaly summaries.

AWS Budgets monitoring and notifications are free. AWS Cost Anomaly Detection is available at no additional cost.

Leave FinOps-Monthly-Guardrail active for account-wide monitoring.
Leave FinOps-Project-Guardrail active for project-specific monitoring.
Leave FinOps-Daily-Anomalies active for daily anomaly summaries.
Keep the Project tags active for ongoing project-cost allocation.

Pause - I'll come back to this later

Pause the learning session by closing the console. Your budgets and anomaly monitoring continue without an open browser session.

Close the AWS Management Console tab in Microsoft Edge.
Return after AWS refreshes your billing data to review new Project values and untagged costs.

There is no compute workload to stop. Your monitoring configurations continue sending alerts while the console is closed.

Delete - I don't want to use this again

Removing these guardrails is permanent. Your existing AWS resources remain untouched until you manage them separately.

Remove the budgets:

Return to AWS Billing and Cost Management in Microsoft Edge.
Choose Budgets.
Select FinOps-Monthly-Guardrail.
Choose Actions.
Choose Delete.
Choose Confirm.
Select FinOps-Project-Guardrail.
Choose Actions.
Choose Delete.
Choose Confirm.

That clears both spending boundaries. Their associated email notifications are removed with them.

Remove the anomaly monitoring:

Choose Cost Anomaly Detection in AWS Billing and Cost Management.
Choose the Alert subscriptions tab.
Select FinOps-Daily-Anomalies.
Use the subscription's deletion control.
Confirm the deletion in the console.
Choose the Cost monitors tab only if this project created FinOps-Service-Anomalies.
Select FinOps-Service-Anomalies.
Use the monitor's deletion control.
Keep the pre-existing AWS-managed AWS services monitor if Cost Explorer created it.

You should no longer see FinOps-Daily-Anomalies on the Alert subscriptions tab. You should no longer see FinOps-Service-Anomalies when you deleted the project-created monitor.

Remove the project attribution settings:

Determine whether another billing process relies on the case-sensitive Project tag.
Keep the resource tags and active cost allocation tag if another billing process relies on them.
Continue with the remaining tag cleanup only when no other process relies on Project.
Return to Tag Editor in the AWS Management Console.
Choose the same Regions you used earlier.
Choose All resource types.
Choose Search resources.
Select only the existing resources whose Project tags you want to remove.
Choose Manage tags of the selected resources.
Use the tag-removal control beside Project.
Choose Review and apply changes.
Choose Apply changes to all selected.
Stay on the page until you see the green success banner.

Your selected resources no longer carry the project attribution added in this project. Existing workloads continue running without those tags.

Return to AWS Billing and Cost Management.
Choose Cost allocation tags.
Select Project.
Use the available page control to deactivate the selected cost allocation tag.
Confirm that Project no longer shows Active.

Your project-created budgets and monitoring subscription are now gone. Your pre-existing AWS resources remain available for separate management.

Nice Work!

You did it! You built an AWS FinOps guardrail around the resources you already operate without creating a new workload.

You've learned how to:

Built an account-wide monthly guardrail in AWS Budgets from a real cost baseline. Added email alerts at 80% Actual spend and 100% Forecasted spend.
Added service-level anomaly monitoring with AWS Cost Anomaly Detection. Configured FinOps-Daily-Anomalies to send daily email summaries above your calculated impact threshold.
Applied stable Project tags to existing resources with Tag Editor. Activated Project for cost allocation. Used Cost Explorer to separate project values from untagged cost after processing.
Completed the Secret Mission by creating FinOps-Project-Guardrail. Scoped the budget to exactly one user:Project value. Added 80% Actual and 100% Forecasted email alerts for that project.

Ready to quiz yourself?