AWS Identity Verification AWS Billing Security Audit

Why Your AWS Bill Is a Security Report (and You’re Ignoring It)

AWS Identity Verification Let’s cut the corporate fluff: your AWS bill isn’t just a monthly invoice—it’s a forensic log of who did what, where, when, and with what permissions. A $47,000 surprise charge isn’t ‘cloud waste.’ It’s a blinking red siren saying, ‘Someone spun up 84 t3.2xlarge instances across three regions using an API key from a GitHub repo you committed in 2021.’ Billing data is high-value, high-risk, and shockingly under-audited. Yet most security teams treat it like cafeteria receipts—filed, forgotten, and occasionally blamed on ‘the devs.’ This isn’t about cost optimization. It’s about threat detection, access hygiene, and regulatory exposure hiding in plain sight: your Cost and Usage Reports, your billing S3 bucket, your root user activity, your unused Reserved Instance reservations masquerading as dormant attack surfaces.

The Five Silent Billing Security Leaks (and How to Find Them)

1. The ‘Billing S3 Bucket’ That Answers to Everyone

Your AWS Cost and Usage Reports (CUR) land in an S3 bucket. By default? It’s private—but only if you didn’t click ‘next’ too fast during setup. We’ve seen buckets with "Principal": "*" in their bucket policies, publicly listing aws-usage-2024-05/ like a digital buffet. Anyone can download raw usage logs: account IDs, resource ARNs, instance launch times, even tags like env:prod or owner:[email protected]. Worse? These files often contain unencrypted PII—think project codes tied to healthcare or finance workloads. Run this now:

aws s3api get-bucket-policy --bucket <your-cu-bucket> 2>/dev/null | jq '.Policy | fromjson | .Statement[] | select(.Effect == "Allow") | select(.Principal == "*")'

If it returns anything—stop reading. Fix it. Then come back. Bonus red flag: if aws s3 ls s3://<your-cu-bucket> --no-sign-request lists objects without credentials, your bucket is waving hello to bots.

2. Root User Still Logging In (Yes, Really)

AWS root user access keys are like giving someone the master key to Fort Knox—and then mailing it to a café in Prague. Yet 63% of compromised accounts in Q1 2024 involved root key usage (per AWS Threat Intelligence). Why? Because someone used it once to enable CloudTrail, forgot, and now it’s rotting in a .env file on a public repo. Audit it in one line:

aws iam get-access-key-last-used --access-key-id <ROOT_KEY_ID> 2>/dev/null | jq '.AccessKeyLastUsed'

If LastUsedDate is within 90 days—or worse, null (meaning it’s never been rotated)—you’re playing Russian roulette with your entire organization. Pro tip: disable root keys *immediately*, enforce MFA on the root console, and delete all root access keys. Not ‘plan to.’ Do it. Now.

3. IAM Roles with ‘Billing:’ Permissions—Given to Lambda Functions

Imagine granting billing:GetBillingData and budgets:ViewBudgets to a Lambda that processes image uploads. Why? Because ‘it needed access.’ But those permissions let that function read every line item in your CUR—even if it’s running in a dev account. Check for overprivileged roles:

aws iam list-attached-role-policies --role-name <role-name> | jq -r '.AttachedPolicies[].PolicyName' | grep -i 'billing\|budget\|cost'

Then cross-check with CloudTrail: aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetBillingData. If you see non-admin roles making those calls—revoke, rotate, and add explicit deny statements in SCPs. Remember: least privilege isn’t a suggestion. It’s your legal defense if auditors ask why ‘image-resizer-lambda’ knew your reserved instance utilization rate.

4. Unencrypted CUR Data Sitting in S3 (With KMS Keys You Can’t Rotate)

You enabled server-side encryption—but chose SSE-S3, not SSE-KMS. Big difference. SSE-S3 uses Amazon-managed keys. You can’t audit them, rotate them, or revoke them. With SSE-KMS, you control the key—and its permissions. Run:

aws s3api get-bucket-encryption --bucket <cur-bucket> | jq '.ServerSideEncryptionConfiguration.Rules[].ApplyServerSideEncryptionByDefault.SSEAlgorithm'

If it says AES256, you’re using SSE-S3. Switch to KMS *and* ensure the KMS key policy doesn’t grant kms:Decrypt to "Principal": "*". Bonus trap: if your KMS key was created by AWS Budgets (not you), you can’t rotate it. Go find it in KMS console—filter by alias alias/aws/billing—and replace it with a customer-managed key.

5. CloudTrail Trails Skipping Management Events (or Missing Entirely)

No CloudTrail = no way to prove who deleted your billing alarm, changed your budget threshold, or disabled your CUR delivery. Yet 41% of medium-sized AWS environments run without a multi-region, organization-wide trail. Verify yours:

aws cloudtrail describe-trails --query 'Trails[?HomeRegion==`us-east-1` && IsMultiRegionTrail==`true` && IncludeGlobalServiceEvents==`true`]' | jq length

If output is 0, you’re flying blind. Also check if trails log management events: aws cloudtrail get-event-selectors --trail-name <trail> | jq '.AdvancedEventSelectors[].FieldSelectors[] | select(.Field == "eventCategory") | .Value' must include "Management". If it’s missing? An attacker could suspend your budget notifications—and you’d only notice when the bill hits $200K.

Your 15-Minute Billing Security Health Check

Grab coffee. Open terminal. Paste this (replace <BUCKET>):

echo "=== S3 CUR Bucket ==="; \
aws s3api get-bucket-policy --bucket <BUCKET> 2>/dev/null | jq -r '.Policy | fromjson | .Statement[] | select(.Effect=="Allow") | select(.Principal=="*") | .Resource'; \
echo "=== Root Key Last Used ==="; \
aws iam list-access-keys --user-name <root-username> --query 'AccessKeyMetadata[?Status==`Active`].AccessKeyId' --output text | xargs -I {} aws iam get-access-key-last-used --access-key-id {} --query 'AccessKeyLastUsed.LastUsedDate' --output text; \
echo "=== Billing Permissions in Roles ==="; \
aws iam list-roles --query 'Roles[].RoleName' --output text | xargs -n1 aws iam list-attached-role-policies --role-name | jq -r '.AttachedPolicies[] | select(.PolicyName | test("(?i)billing|budget|cost")) | .PolicyName' | sort -u; \
echo "=== Trail Coverage ==="; \
aws cloudtrail describe-trails --query 'Trails[?IsMultiRegionTrail==`true` && IncludeGlobalServiceEvents==`true` && HomeRegion==`us-east-1`].Name' --output text

Any output beyond “null” or empty lines? That’s your sprint backlog.

Hardening Checklist (Not ‘Nice-to-Have’—Required)

• ✅ Disable all root access keys. Today.
• ✅ Enforce MFA on root console login—no exceptions.
• ✅ Replace SSE-S3 with customer-managed KMS keys for CUR buckets.
• ✅ Add explicit denies for budgets:* / billing:* / ce:* in all non-finance IAM policies.
• ✅ Enable organization-level CloudTrail with global service logging.
• ✅ Rotate billing-related KMS keys every 90 days (yes, automate it).
• ✅ Scan GitHub, GitLab, and Bitbucket for AKIA.*, aws_access_key_id, and billing-bucket—then purge.

Final Thought: Your CFO Will Thank You (After the Security Team Does)

Billing security isn’t about saving money. It’s about proving you know what ran, who launched it, why it’s still running, and whether it should be. When your next SOC 2 audit asks for evidence of financial controls, your CloudTrail logs—not your spreadsheets—will be the exhibit. And when the incident response team asks how an attacker moved laterally from a compromised dev Lambda to your production RDS cluster, the answer won’t be in VPC Flow Logs. It’ll be in the ce:GetCostAndUsage call made at 2:17 a.m. from an IP in Kyiv. So stop optimizing your bill. Start auditing it—like the security artifact it is.