AWS Account Monitoring Checklist for New Accounts

Simple explanation

When you create a new AWS account, nothing is watching it by default. No one is tracking who logs in, what gets created, how much it costs, or whether anything suspicious is happening.

In practice, “monitoring” means turning on a handful of AWS services that record activity, measure spending, and alert you when something looks wrong. The rest of this page walks through each one.

What to set up first

If you only have fifteen minutes, set up these three things in order. They cover the highest-impact risks on a new account:

1. A billing alert so you find out before a surprise bill arrives. Use AWS Budgets for the simplest setup.

2. CloudTrail so every API call in the account is logged. This is your audit trail if anything goes wrong.

3. GuardDuty so AWS automatically watches for compromised credentials, crypto-mining instances, and other common threats.

Once those are done, come back and complete the full checklist below: root-user alarms, Cost Explorer, and the remaining hardening steps.

How AWS account monitoring works

Five services do most of the work. Each one fills a different gap.

CloudTrail (the audit log)

CloudTrail records every API call made in your account: who made it, when, from which IP address, and whether it succeeded. If someone creates an EC2 instance, deletes an S3 bucket, or changes an IAM policy, CloudTrail captures it. Without CloudTrail you have no way to investigate a security incident or trace an operational mistake back to its source.

CloudWatch (metrics and alarms)

CloudWatch collects numeric metrics from AWS services (CPU usage, request counts, error rates, estimated charges) and lets you set alarms when a metric crosses a threshold. It is also where you send logs (including CloudTrail logs) when you want to filter, search, or create metric filters on log data.

GuardDuty (automated threat detection)

GuardDuty analyzes CloudTrail logs, VPC Flow Logs, and DNS query logs using machine learning and threat intelligence. It flags findings like “IAM credentials are being used from an unusual country” or “an EC2 instance is communicating with a known command-and-control server.” You enable it and it works with no rules to write.

AWS Budgets (spending guardrails)

AWS Budgets lets you set a monthly dollar cap and receive email alerts when actual or forecasted spending crosses thresholds you choose. It is the simplest way to avoid surprise bills on a new account.

Cost Explorer (spending visibility)

Cost Explorer shows where your money is going, broken down by service, region, or tag. It needs to be enabled before it starts collecting data, and it takes up to 24 hours for the first data to appear, so turn it on early.

Step-by-step setup

Step 1: Enable CloudTrail

Create a multi-region trail that captures API activity across all regions, not just your default one. This is important because compromised credentials are often used in regions you do not normally work in.

# Create an S3 bucket to store CloudTrail logs
aws s3 create-bucket \
  --bucket my-account-cloudtrail-logs \
  --region us-east-1

# Block all public access on the bucket
aws s3api put-public-access-block \
  --bucket my-account-cloudtrail-logs \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Create a multi-region trail
aws cloudtrail create-trail \
  --name my-account-trail \
  --s3-bucket-name my-account-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

# Start logging
aws cloudtrail start-logging --name my-account-trail

# Confirm the trail is active
aws cloudtrail get-trail-status \
  --name my-account-trail \
  --query '{IsLogging:IsLogging,LatestDelivery:LatestDeliveryTime}'

Step 2: Set up a billing alert

There are two ways to get notified about spending: AWS Budgets and CloudWatch billing alarms. They are not the same thing.

• AWS Budgets is a standalone budgeting tool in the Billing console. You set a dollar amount and choose alert thresholds (50%, 80%, 100%). It can also alert on forecasted spend before you actually hit the limit. This is the easier option for beginners.

• CloudWatch billing alarm watches the EstimatedCharges metric in the AWS/Billing namespace and fires when estimated charges cross a dollar value. It is lower-level and integrates with other CloudWatch workflows.

For a new account, start with AWS Budgets. You can set it up entirely in the console in under two minutes. For the full walkthrough, see Budgets and billing alerts.

If you prefer the CLI or want a CloudWatch alarm (for example, to integrate with an existing SNS topic), here is the CloudWatch approach. Note that billing metrics are only available in us-east-1 regardless of which regions you use.

# Create an SNS topic for billing notifications
aws sns create-topic --name billing-alerts --region us-east-1

# Subscribe your email (replace with your actual email)
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:YOUR_ACCOUNT_ID:billing-alerts \
  --protocol email \
  --notification-endpoint you@example.com

# Create a CloudWatch alarm on the EstimatedCharges metric
# This fires when estimated monthly charges reach $10
aws cloudwatch put-metric-alarm \
  --region us-east-1 \
  --alarm-name Billing-EstimatedCharges-10 \
  --alarm-description "Estimated monthly charges exceeded $10" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 10 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:YOUR_ACCOUNT_ID:billing-alerts

Step 3: Enable GuardDuty

GuardDuty requires no configuration after you enable it. Turn it on and it starts analyzing your account activity automatically.

# Enable GuardDuty in your primary region
aws guardduty create-detector --enable --region us-east-1

# Verify it is running
DETECTOR_ID=$(aws guardduty list-detectors \
  --region us-east-1 \
  --query 'DetectorIds[0]' \
  --output text)

aws guardduty get-detector \
  --detector-id "$DETECTOR_ID" \
  --region us-east-1 \
  --query '{Status:Status,CreatedAt:CreatedAt}'

# Enable in additional regions you use
aws guardduty create-detector --enable --region eu-west-1
aws guardduty create-detector --enable --region us-west-2

GuardDuty findings are published to Amazon EventBridge. From there you can route them to SNS for email alerts, or to a ticketing system. For more on enabling regional services like GuardDuty, see the enabling services guide.

Step 4: Alert on root-user activity

After initial setup, the root user should almost never be used. Day-to-day work belongs to IAM users or roles. An alarm that fires when the root user signs in or makes any API call is one of the highest-value security controls you can set up.

This alarm works by creating a metric filter on CloudTrail logs that have been delivered to CloudWatch Logs. That means you need two things in place first:

1. A CloudTrail trail (you set this up in Step 1).

2. That trail configured to deliver logs to a CloudWatch Logs log group. This is what the commands below set up.

CloudTrail delivers log files to S3 by default, but it does not automatically send them to CloudWatch Logs. You need to explicitly configure the trail to do this by specifying a log group and an IAM role that grants CloudTrail permission to write to CloudWatch Logs.

# 1. Create a CloudWatch Logs log group for CloudTrail
aws logs create-log-group \
  --log-group-name CloudTrail/AccountActivity

# 2. Create an IAM role that allows CloudTrail to write to CloudWatch Logs.
#    If you already have a role for this, skip to step 3 and use its ARN.
#    See the AWS docs for the trust policy and permissions policy:
#    - Trust policy: allows cloudtrail.amazonaws.com to assume the role
#    - Permissions policy: allows logs:CreateLogStream and logs:PutLogEvents

# 3. Update your trail to deliver logs to CloudWatch Logs
aws cloudtrail update-trail \
  --name my-account-trail \
  --cloud-watch-logs-log-group-arn arn:aws:logs:us-east-1:YOUR_ACCOUNT_ID:log-group:CloudTrail/AccountActivity:* \
  --cloud-watch-logs-role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/CloudTrail-CloudWatch-Role

# 4. Create a metric filter that matches root user API calls
aws logs put-metric-filter \
  --log-group-name CloudTrail/AccountActivity \
  --filter-name RootUserActivity \
  --filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }' \
  --metric-transformations \
    metricName=RootUserEventCount,metricNamespace=CloudTrailMetrics,metricValue=1

# 5. Create a CloudWatch alarm on the metric
aws cloudwatch put-metric-alarm \
  --alarm-name Root-User-Activity \
  --alarm-description "Any root user activity detected" \
  --metric-name RootUserEventCount \
  --namespace CloudTrailMetrics \
  --statistic Sum \
  --period 60 \
  --evaluation-periods 1 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:YOUR_ACCOUNT_ID:billing-alerts

Step 5: Enable Cost Explorer

Enable it from the AWS Billing console: Billing > Cost Explorer > Enable Cost Explorer. Once active, you can:

• See which services are costing the most
• Break down costs by region, tag, or linked account
• View a 12-month forecast based on current usage
• Spot unusual spending patterns before they become big bills

You can also query Cost Explorer from the CLI. This example shows your top five most expensive services for the current month:

# Get the current month's start and end dates dynamically
START_DATE=$(date -u +"%Y-%m-01")
END_DATE=$(date -u -d "+1 month" +"%Y-%m-01")

# Query top services by cost
aws ce get-cost-and-usage \
  --time-period Start="$START_DATE",End="$END_DATE" \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'sort_by(ResultsByTime[0].Groups, &Metrics.UnblendedCost.Amount)[-5:].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
  --output table

For more on reading and customizing these reports, see Cost Explorer reports.

CloudTrail vs CloudWatch vs GuardDuty

These three services come up together often, and beginners frequently confuse them. Here is how they differ:

AWS Budgets vs CloudWatch billing alarms

Both alert you about spending, but they work differently:

• AWS Budgets lives in the Billing console. You set a monthly budget amount and choose percentage thresholds. It supports forecasted spend alerts, meaning it can warn you before you actually hit your limit. Easier for beginners.

• CloudWatch billing alarms use the EstimatedCharges metric in the AWS/Billing namespace. They only fire on actual estimated charges, not forecasts. They are useful when you want billing alerts integrated into a broader CloudWatch alerting workflow.

For most new accounts, start with AWS Budgets. Add CloudWatch billing alarms later if your monitoring setup grows. See how billing works for the full picture of AWS cost management tools.

When to use this

This checklist applies to any AWS account where you want basic visibility and protection. Here are the scenarios where it matters most:

• Brand-new accounts. Set up monitoring before you create any other resources. It is far easier to enable CloudTrail on an empty account than to backfill after an incident.

• Sandbox and lab accounts. Students and experimenters often skip monitoring because the account feels temporary. But sandbox accounts with Free Tier access are still real AWS accounts with real billing. A forgotten EC2 instance or NAT Gateway generates real charges.

• Small side-project accounts. A personal project with a single Lambda function still benefits from a $5 billing alert and GuardDuty. The setup cost is near zero and the downside protection is significant.

• Early-stage production accounts. If you are launching a product on AWS, this checklist is the minimum. Production accounts should also add application-level alerts, centralized logging, and access reviews, but this page covers the account-level foundation.

Full new-account monitoring checklist

Everything covered in this guide, in recommended order:

1. Enable MFA on the root user (Console: IAM > Security Credentials)
2. Create an IAM user or role for day-to-day work
3. Create a multi-region CloudTrail trail with logs stored in S3
4. Set up a billing alert using AWS Budgets or a CloudWatch alarm
5. Enable GuardDuty in all regions where you have or plan to have workloads
6. Configure CloudTrail to deliver logs to CloudWatch Logs
7. Create a CloudWatch alarm for root-user activity
8. Enable Cost Explorer
9. Activate cost allocation tags for any tags you plan to use
10. Enable S3 Block Public Access at the account level
11. Confirm all SNS email subscriptions are active