Using the CloudWatch console, find the Metrics sub-menu. Here we have the Billing category we will be using it to specify billing alarms per service:

And then use the By Service metrics, these metrics are automatically aggregated under service namespaces by CloudWatch.

Here you will see a list of every metered service, use the filter to search for s3.

The Graphed metrics tab provides with configuration parameters like statistics and actions like the creation of alarms. Use the bell icon to perform the alarm configuration.

In the Create Alarm window, specify the name and description for the alarm (2). And the SNS topic to be used for notifications, update the EstimatedCharges value for any number that makes sense to you. Now you are ready to create the alarm for S3 spending.

All Cloudwatch alarms can be in one of the following statuses:

• OK: The metric is within the defined threshold and has not exceeded the limit expression.
• ALARM: The metric is outside of the defined threshold. Actions must be taken.
• INSUFFICIENT_DATA: The alarm has just started, the metric is not available, or not enough data is available for the metric to determine the alarm state.

Navigate to the Alarms sub-menu and you can see the current alarms created for this region, both alarms are in the OK state, so we are within budget.

An interesting feature of CloudWatch alarms is the ability to change their state programmatically. The set-alarm-state API action is used for this purpose so let's try it out by alarming the S3Spend alarm.

aws cloudwatch set-alarm-state --alarm-name S3Spend --state-value ALARM --state-reason "testing notification behavior"

The preceding command will trigger the notification in your email inbox and change the alarm status in the console.

This way you can test how alarms are being executed and design robust notification systems maintaining all stakeholders accountable.