Anatomy of an AWS Bill Shock — LLMjacking, and the Costs You Never See

I recently heard about a company whose AWS account got hacked. No servers hijacked, no data stolen. The damage was the invoice: Amazon Bedrock API calls alone were burning close to ₩100 million (about $70,000) a day.

My first reaction was disbelief. Then I checked the numbers. In 2024, Sysdig estimated that abusing Claude 3 Opus across regional quota limits could exceed $100,000 per day.¹² That figure was a potential upper-bound estimate based on the pricing and quotas at the time, not a measured victim invoice.

That incident prompted this write-up: how the attack actually gets in, and the account management, key management, and cost guardrails we treat as table stakes in cloud operations.

How the attack gets in: LLMjacking

Sysdig named this attack LLMjacking in May 2024.¹ The mechanics are simple.

1. A developer's access key leaks: a .env file swept into a public GitHub commit, environment variables printed in CI logs, or an infostealer on a laptop.
2. The attacker creates no resources. They quietly verify InvokeModel permission.
3. The stolen Bedrock access gets wired into a reverse proxy and resold as a $30-a-month "unlimited LLM" service.²
4. Traffic from buyers worldwide flows through the victim's account, and charges climb to the quota ceiling in every enabled region.

What makes it dangerous is the silence. A cryptomining compromise spins up dozens of EC2 instances; a glance at the console gives it away. LLMjacking creates nothing. The only traces are API logs and the invoice, and most teams read the invoice a month later.

How fast does the bill reach ₩100M?

Let's check the scale. The table applies the Claude Opus 4.5 launch price snapshot from November 2025: $5 per million input tokens and $25 per million output tokens.³ At ₩1,400 to the dollar, ₩100 million is about $71,000.

The table shows billing arithmetic, not time to impact. Actual timing varies widely with model-specific TPM and TPD quotas, cross-Region inference, response length, and latency, so concurrency alone cannot establish it. The important point is that token usage can create a large bill without creating any infrastructure resources.

Account management essentials: remove the keys worth stealing

A common starting point for LLMjacking is a credential leaked from code, logs, or a developer machine. Long-lived IAM access keys give an attacker a wider window for abuse. Here is the baseline we apply to every account:

• Root account: enable MFA, and never create root access keys. Delete them if they exist.
• Humans: sign in through IAM Identity Center (SSO) instead of IAM users. Credentials expire with the session.
• Workloads: obtain short-lived STS credentials through IAM roles — EC2 instance profiles, IRSA on EKS, Lambda execution roles. No key ever needs to live in code or config.
• Audit: enable CloudTrail in all regions, and let GuardDuty flag anomalous API activity.

Nothing here is new or expensive. Yet most credential leaks happen exactly where this baseline is missing.

Bedrock key management: design for revocation, not issuance

Bedrock adds one more trap: Bedrock API keys, introduced in July 2025.⁴ They exist for developer convenience, and the two variants behave completely differently.

A long-term key is effectively one more IAM user credential that may never expire. Wiz flagged it as "a new type of long-lived key on AWS."⁵ We enforce three rules:

• Production workloads call Bedrock through IAM roles + STS, never API keys.
• If your organization has no need for long-term keys, block their creation outright. AWS shipped IAM condition keys in September 2025 that govern key generation, expiration, and type.⁶
• Turn on model invocation logging to record who calls which model and how much.⁷ Alongside CloudTrail, it is the first dataset you reach for in an investigation. Because invocation logging can store request and response bodies, define retention and access controls for sensitive data first.

Guardrails that cap the blast radius

Even if key management fails, the damage should stop at pocket change, not ₩100 million a day. This is no longer prevention; it is blast radius engineering.

• Deny unused Regions and models with SCPs and IAM policies. This narrows attacks that exploit quota across Regions,² and a Seoul-only organization has no reason to allow a high-cost model elsewhere.
• Cap calls and tokens in the application. Instead of treating default Service Quotas as a configurable spending ceiling, use a model allowlist, per-principal rate limits, and a max_tokens cap.
• Alarm on Bedrock runtime metrics. Monitor Invocations, InputTokenCount, and OutputTokenCount by model and Region, and send usage outside the normal range directly to operations.⁸
• Use AWS Budgets as a delayed financial backstop. A Marketplace-filtered budget can apply IAM or SCP actions,⁹ but cost data commonly refreshes every 8–12 hours and can lag by a day.¹⁰ Cost Anomaly Detection can also take up to 24 hours and does not monitor AWS Marketplace charges for Anthropic Claude on Bedrock.¹¹

For a broader method that ties these controls to release decisions and named operating owners, see the six gates from AI PoC to production.

Already compromised? The response runbook

1. Kill the credentials first. Deactivate the leaked key and invalidate the principal's active sessions. Root-cause analysis comes second.
2. Scope the damage with CloudTrail. Which keys, which regions, which APIs. For Bedrock, read the invocation logs alongside.
3. Hunt for backdoors. Enumerate every IAM user, role, and access key the attacker may have planted.
4. Contact AWS Support immediately. Report unauthorized use and unexpected charges, and submit the relevant logs and containment steps. Any billing adjustment is case-specific and not guaranteed.¹²
5. Apply the sections above, in order.

The bomb isn't only hackers: costs that leak quietly

A hack stands out because it costs ₩100 million a day. The more common face of cloud cost trouble is the opposite: nobody broke in, yet money leaks every month, for years. The invisible costs:

• NAT Gateway data processing fees on every byte that passes through
• Cross-AZ data transfer that no architecture diagram shows
• EBS snapshots orphaned by deleted instances, and detached Elastic IPs
• CloudWatch Logs accumulating forever with no retention policy
• Development and staging environments running all night

The interesting part is how the remedies overlap. Resource tagging and service-level usage and cost alarms let operations examine sudden abuse and structural waste in one control system. Cost visibility is also a security control.

The AWS invisible-cost guide continues with the cost structure and diagnostic sequence behind each item.

Design account, SCP, and cost controls with Cloud & Infrastructure, and Bedrock observability and application caps with Data & ML Engineering.

References