The AWS Bill Decoder

Internet data transfer out

You are being charged per gigabyte for data leaving an AWS region to the public internet.

This is the single most common line item on almost every AWS bill: any response an EC2 instance, load balancer, or API sends back to a browser, mobile app, or external API counts as egress. It often shows up bundled under "EC2-Other" in Cost Explorer even when the traffic originated from another service that routes through EC2-managed infrastructure.

Spikes usually trace to a new public-facing feature (video/image delivery, large API payloads, backups pushed to an external destination), a bot or scraping wave hitting an unprotected endpoint, or serving large static assets directly instead of through a CDN.

$0.09 per GB (first 10 TB/month tier) — us-east-1, applies after the AWS-wide free tier; as of 2026-07

Inter-region data transfer

You are being charged for data sent from one AWS region (here, us-east-1) to a different AWS region (here, us-west-2).

This appears whenever resources in different regions talk to each other: cross-region database replication or read replicas, multi-region S3 replication, a service in one region calling an API hosted in another, or disaster-recovery jobs.

It's confusing because AWS emits two line items for every transfer — a "{Source}-{Dest}-AWS-Out-Bytes" on the source side and a "{Dest}-{Source}-AWS-In-Bytes" on the destination side — but only the outbound side from the source region actually carries a charge; the inbound side is $0.

Cross-AZ (regional) data transfer

You are being charged for data moving between Availability Zones within the same AWS region — billed on both the sending and the receiving side.

Same-AZ traffic over private IPs is free, but the moment two communicating resources land in different AZs, every byte is billed twice: once as the sender's outbound leg and once as the receiver's inbound leg.

Common triggers: an auto-scaled fleet or Kubernetes cluster spreading instances across AZs for high availability, a NAT gateway that exists in only one AZ while resources run in others, or chatty microservice/service-mesh traffic that isn't AZ-aware.

$0.01 per GB, in each direction — us-east-1; billed as two separate $0.01/GB charges (in + out) for each transfer; as of 2026-07

NAT gateway data processing

You are being charged per gigabyte for every byte that passes through your NAT gateway, on top of its flat hourly uptime charge and on top of any standard data-transfer charge the traffic would incur anyway.

NAT gateways are the default egress path for private-subnet resources, so anything a private instance, a task, or a function does over the internet — pulling container images, calling third-party APIs, downloading OS/package updates — is metered here, often invisibly to the engineer who wrote the code.

The classic spike is container image pulls: registry layers, base OS images, and CI/CD artifact downloads routed through NAT can dwarf actual application traffic, especially in clusters with frequent deploys or aggressive auto-scaling.

$0.045 per GB processed — us-east-1; separate from the flat $0.045/hour NAT gateway uptime charge and from any standard data-transfer charge on the same bytes; as of 2026-07

Public IPv4 address charge

You are being charged hourly for every public IPv4 address you hold — whether it's actively attached and serving traffic, or allocated but unattached and idle.

AWS began charging for all public IPv4 addresses on February 1, 2024 — previously only "extra"/idle Elastic IPs were charged. This now covers the default public IP on every internet-facing instance, every Elastic IP, NAT gateway public IPs, and public IPs on AWS-managed resources, not just Elastic IPs.

Bills spike when accounts accumulate unattached Elastic IPs left over from decommissioned instances, or when a large fleet of instances or NAT gateways each get their own public IP instead of sharing egress through fewer public endpoints.

$0.005 per hour per address — us-east-1 (uniform across commercial AWS regions); identical whether the address is in-use or idle; as of 2026-07

VPC interface endpoint (PrivateLink)

You are being charged an hourly fee per endpoint per Availability Zone, plus a per-gigabyte fee for data processed through an interface VPC endpoint (AWS PrivateLink).

This appears when you've deliberately added interface endpoints to avoid NAT gateway or internet routing for AWS-service traffic, or when a third-party product exposes itself via PrivateLink.

It surprises people two ways: the endpoint itself has an always-on hourly cost per AZ even at zero traffic, and teams sometimes deploy endpoints redundantly (one per AZ per service, per account) without realizing the hourly costs multiply.

Transit Gateway attachment and data processing

You are being charged an hourly fee for each attachment (VPC, VPN, Direct Connect, peering) connected to your Transit Gateway, plus a per-gigabyte fee for data processed through it.

Transit Gateway is the common hub-and-spoke pattern for connecting many VPCs, accounts, and on-prem networks, so its cost scales with both how many VPCs you've attached (hourly, per attachment) and how much traffic actually flows through the hub (per GB).

Costs balloon in large multi-account organizations as more accounts/VPCs are onboarded to a shared Transit Gateway, or when high-volume, chatty services route large data volumes through the hub instead of communicating more directly.

Load balancer hourly usage and LCU charge

You are being charged an hourly rate for each load balancer provisioned, plus a rate per Load Balancer Capacity Unit (LCU) consumed — LCUs are driven by whichever dimension (new connections, active connections, processed bytes, or rule evaluations) is highest that hour, not by a simple sum.

The flat hourly charge is predictable, but LCUs are the confusing part: AWS bills on the single highest-consuming dimension per hour, so a spike in new-connection rate or in processed bytes can drive cost up even if the other dimensions look normal.

Bills also climb simply from running more load balancers than needed — one per microservice or environment instead of consolidating with listener rules or path-based routing on shared load balancers.

CloudFront data transfer and requests

You are being charged per gigabyte for content CloudFront serves from its edge locations to end users, plus a per-10,000-requests charge, with rates varying by the edge-location group (US, EU, AP, and so on) that served the request.

This looks similar to plain internet egress on the bill but is a distinct, usually cheaper, product line keyed off the edge location that answered the request rather than the origin's AWS region — so the prefix here is a broad geography code, not the fine-grained region codes used elsewhere.

Costs climb with cache-miss rate (uncacheable or short-TTL dynamic content forces more origin fetches), high request-per-second traffic from bots or scrapers, and serving traffic from higher-cost edge-location groups rather than cheaper tiers.

EBS General Purpose SSD storage (gp2/gp3)

Billing for the provisioned capacity (GB-month) of General Purpose SSD EBS volumes — gp2 or its newer, usually cheaper sibling gp3.

Every attached — and every unattached, un-deleted — gp2/gp3 volume bills continuously by provisioned size, not by data actually used, so oversized volumes or orphaned volumes left behind by terminated instances keep charging quietly.

gp2 is being phased out in favor of gp3, which is typically priced lower per GB and decouples performance from capacity, so heavy gp2 usage here usually flags an easy migration win.

EBS Provisioned IOPS charge (io1/io2)

A separate per-IOPS-month charge for the performance you provisioned on io1/io2 volumes, billed apart from the volume's GB-month storage charge.

io1/io2 volumes bill storage and performance separately — capacity on one line, provisioned IOPS on this one — so teams provisioning IOPS "for headroom" often don't realize it's billed continuously whether or not that performance is ever used.

Because it's a distinct line item from storage, it can spike independently of any storage growth — a temporary IOPS bump for a migration or load test that never gets scaled back down.

EBS snapshot storage

GB-month charge for EBS snapshots in the Standard tier, billed incrementally on the changed blocks each snapshot stores.

Automated backup schedules can accumulate hundreds of snapshots with no expiration, and because snapshots are incremental, each one keeps referencing changed blocks indefinitely until deleted.

The console's per-snapshot size figure overstates what deleting any single snapshot would actually free, since it's shared incremental data — teams often mis-estimate cleanup savings as a result.

S3 Standard storage

The core "you store data, you pay for it" charge — GB-months of object data and metadata held in S3 Standard storage, billed hourly and averaged over the month.

It's usually the single largest line on an S3 bill and grows silently: versioning-enabled buckets keep every prior object version, and incomplete multipart uploads consume storage without showing up in a normal object listing.

Because usage is measured in byte-hours but invoiced in GB-months, steady daily upload growth compounds across a billing cycle in a way that's easy to underestimate from a quick console glance. Note: this exact usage-type string is reused by several other AWS services too (DynamoDB and CloudWatch Logs among them) — the Service column, not the code alone, tells you which one you're looking at.

S3 Standard-Infrequent Access storage

GB-month storage charge for objects held in the S3 Standard-IA class — cheaper per-GB than Standard, but with per-GB retrieval fees and a 30-day minimum storage duration per object.

Lifecycle rules that auto-transition objects to IA to save money can backfire if the workload actually re-reads that data often — retrieval fees plus the minimum-duration penalty can make it more expensive than leaving it in Standard.

Small objects are a hidden trap: anything under roughly 128 KB is billed as if it were that minimum size, so transitioning many small files to IA can increase, not reduce, total storage cost.

S3 Glacier Flexible Retrieval storage

GB-month storage charge for archived objects held in the S3 Glacier Flexible Retrieval class, AWS's low-cost long-term archive tier.

Glacier's low per-GB rate is the headline, but it carries a 90-day minimum storage commitment and separate per-GB retrieval fees (priced very differently by speed tier) that show up on other bill lines, not this one.

Lifecycle policies that archive data too aggressively — logs a job still queries monthly, say — turn an intended storage saving into a net cost increase once retrieval and early-delete charges are added back in.

S3 request charges (PUT/COPY/POST/LIST and GET)

Per-request API charges — Tier1 covers PUT, COPY, POST, and LIST calls; a separate Tier2 line covers GET and most other read requests — billed per thousand requests.

The GET-request tier in particular blindsides teams: high-traffic static sites, CDN cache misses falling through to S3, or an application re-fetching objects in a loop can generate tens of millions of GET requests a month for what looks like a small bucket.

The write-request tier usually spikes from write-heavy patterns — one PUT per event or log line instead of batching — which multiplies request costs even while total bytes stored stay small.

S3 Glacier early-deletion charge

A prorated penalty charged when an object archived to S3 Glacier Flexible Retrieval is deleted, overwritten, or transitioned before its 90-day minimum storage commitment ends (parallel early-delete charges exist for the Instant Retrieval and Deep Archive classes).

One of the least-expected line items on an S3 bill: a lifecycle rule that archives to Glacier and a shorter-than-90-day expiration or re-transition rule layered on top will trigger this automatically, with no separate confirmation step.

The charge is calculated against the Glacier storage rate for the remaining days of the commitment, so it can effectively bill close to the full commitment period even though the object only sat there briefly — turning an intended archive-to-save move into a net loss.

CloudWatch Logs ingestion

Charges for every byte of log data your applications, agents, or functions push into CloudWatch Logs.

Verbose application logging, debug-level log levels left on in production, or an agent shipping full request/response bodies inflates this line fast — it is metered per GB with no built-in cap, so one noisy service can dominate the entire CloudWatch bill.

Because it bills under the generic CloudWatch service line, teams often don't realize a single log group is responsible until they group Cost Explorer by both usage type and resource.

$0.50 per GB ingested (Standard log class) — us-east-1, as of 2026-07

CloudWatch vended logs

The per-GB charge for logs that other AWS services generate and deliver into CloudWatch Logs on your behalf — VPC flow logs, DNS query logs, CDN logs, WAF logs — billed separately from logs your own code writes.

VPC flow logs in particular can generate enormous, continuous volume once enabled across every network interface in a busy VPC, and it's common to turn them on for a single investigation and forget to turn them back off.

Vended logs are priced and tracked separately from custom application logs, so a spike here points specifically at an AWS-managed logging feature rather than your own application code.

CloudWatch custom metrics

The per-metric-per-month charge for every unique custom metric (and dimension combination) published to CloudWatch, whether from your own application, embedded metric format logs, or detailed instance monitoring.

Custom metrics are billed per unique dimension combination, not per metric name, so tagging a metric with a high-cardinality dimension (a request ID, a user ID, a container ID) can quietly generate thousands of billable metric series from what looks like a single metric.

Detailed monitoring and the CloudWatch embedded metric format both bill through this same usage type, so a spike can come from infrastructure nobody thought of as "custom metrics" at all.

$0.30 per metric per month (first 10,000 custom metrics) — us-east-1, as of 2026-07

CloudWatch alarms

The per-alarm hourly charge (prorated to per-month) for every standard-resolution metric alarm that exists in your account, whether or not it has ever fired.

Alarms created by infrastructure-as-code stacks or auto-scaling configurations often outlive the resources they monitor, sitting in an insufficient-data state and billing indefinitely until someone notices and deletes them.

Alarms built on metric-math expressions or anomaly-detection bands are charged per underlying metric referenced, not per alarm, so one alarm in the console can quietly bill as several.

CloudWatch API requests

The per-1,000-request charge for CloudWatch API calls beyond the free tier — most visibly reads of metric data — billed once you exceed the free allotment.

Third-party dashboards and monitoring tools that poll CloudWatch on a schedule across every region in your account generate a steady stream of metric-read calls — the exact irony that a tool bought to give you visibility can itself become a line item on the bill.

AWS's own documentation calls this out directly: frequent programmatic reads of metric data can noticeably increase cost, and third-party monitoring tools often drive it by pulling data on a tight schedule to generate their own dashboards.

AWS Config configuration item recording

The per-item charge AWS Config bills every time it detects and records a change to a tracked resource's configuration — metered by how often your infrastructure actually changes, not a flat monthly fee.

Ephemeral or auto-scaled infrastructure can each generate several configuration items per launch — the resource itself, plus the network interfaces, groups, and attachments it creates — so a workload that churns instances hourly can dwarf its own compute cost in Config charges alone.

Because billing tracks activity rather than resource count or uptime, a resource stuck in a create/delete loop can spike this line from a few dollars to hundreds within a billing period with no corresponding change in what you're actually running.

CloudTrail data events

A per-100,000-events charge for CloudTrail data events — fine-grained, resource-level API activity such as object reads or function invocations — once data-event logging is turned on for a trail; management events are logged free by default.

Data events log every individual object- or resource-level API call, not just control-plane changes, so turning them on for a high-traffic bucket or a busy function can generate an enormous, continuously billed event volume compared to the free management-events tier.

The charge multiplies further with multi-region or organization-wide trails that replicate the same data-event logging across every account and region in scope, and can duplicate other access logging already delivering the same information.

Bedrock input tokens (per model)

Every token sent into a Bedrock model as part of the prompt — system instructions, chat history, retrieved context, few-shot examples — is metered and billed separately per model, distinct from output tokens.

Input-token spend climbs fastest when prompts carry more context than the task needs: long system prompts, unpruned chat history, or retrieval that stuffs in whole documents instead of relevant chunks.

Because the usage type is per-model, a silent model switch or an A/B test can quietly double the number of these line items without the aggregate number appearing to move.

Bedrock output tokens (per model)

Tokens the model generates in its response are billed as a separate line item from input tokens, usually at a materially higher per-token rate.

Output cost spikes with verbose responses, reasoning-style generation, or a maximum-output ceiling set far higher than the task needs, which lets occasional runaway completions run up the bill.

Retried requests — timeouts, malformed output, agent loops — each generate a full new completion, so a flaky integration can multiply output-token cost without any increase in genuinely useful responses.

Bedrock prompt-cache read tokens

Tokens served from Bedrock's prompt cache — instead of being reprocessed as full input — appear as their own usage type, billed at a steep discount versus a normal input token.

This line item shows up as soon as an application uses prompt caching on a supported model; teams who didn't know caching was enabled are often confused to see a brand-new, unfamiliar usage type appear on the bill even though it represents savings, not new spend.

The savings only materialize if the cache is actually being hit: for a bursty, low-repeat workload where cache-write volume dominates over cache-read, the cache overhead can cost more than it saves.

SageMaker real-time endpoint hours

Billed for every hour a SageMaker real-time inference endpoint's instance is running, regardless of whether it's actively serving prediction traffic.

GPU endpoints are among the most expensive per-hour instance types available, and they're commonly left running around the clock after a demo, proof of concept, or project winds down, because nothing prompts anyone to delete the endpoint.

Endpoints are also frequently over-provisioned — sized, or replicated across multiple instances, for peak load that only shows up occasionally, so most hours are billed at the full GPU rate for near-idle capacity.

SageMaker notebook instance hours

Billed for every hour a classic SageMaker notebook instance sits in an active state, independent of whether anyone is actively working in it.

Data scientists routinely start a notebook instance for a task and leave it running overnight, over a weekend, or indefinitely after the analysis is finished — there's no default timeout, so the meter keeps running.

Larger instance types, including GPU ones, get picked for a single heavy job and then never scaled back down for routine day-to-day notebook work.