Research-backed calculator guide

Amazon Bedrock Invocation Logging Cost: CloudWatch vs S3 Attribution

Estimate the destination cost of Amazon Bedrock invocation logging by separating CloudWatch Logs ingestion and retention from S3 storage, requests, queries, and model inference spend.

What Amazon Bedrock invocation logging actually bills

Bedrock model invocation logging is an account-and-Region configuration that is disabled by default. After it is enabled, AWS says logs remain until the logging configuration is deleted. The supported destinations are Amazon S3 and CloudWatch Logs, and the destination must be in the same account and Region as the Bedrock logging configuration. ^[1] Those facts matter for cost modeling because retention is a policy choice, while the service destination owns the relevant storage and request meters.

The log record is more than a token counter. AWS’s example schema includes the timestamp, account and Region, request ID, operation, model or inference-profile ID, caller identity, optional request metadata, input and output bodies, and input and output token counts. ^[1] This richness improves bedrock per request cost attribution, but it also makes average payload size workload-specific. Text-only calls with short prompts can be inexpensive to retain. Long prompts, long responses, documents, images, and video can produce a very different ledger.

For smaller input and output data, AWS supports delivery to S3, CloudWatch Logs, or both. AWS documents a 100 KB inline limit for input and output bodies. Larger JSON bodies and binary data are stored as separate S3 objects when an S3 destination for large data delivery is configured; otherwise those large payloads are not published to CloudWatch Logs. ^[1] This is a key attribution boundary. A CloudWatch-only design is not necessarily a complete copy of the data generated by multimodal calls, and an S3 data prefix can become a meaningful part of bedrock invocation logs S3 pricing.

The destination choice is operational as well as financial. AWS Prescriptive Guidance describes CloudWatch Logs as useful for metric filters, alarms, dashboards, and near-real-time operations, while it describes S3 as suitable for longer-term storage and replication. The reference pattern provisions both destinations, an S3 bucket, CloudWatch log group, IAM role, Lambda configuration function, and KMS resources. ^[3] Those extra resources are not all “logging storage,” so keep one-time infrastructure and encryption-key administration outside the simple per-invocation ledger unless you have measured them.

The AWS FinOps guidance separates native billing attribution, native metrics, and invocation logging. CloudWatch metrics, Cost and Usage Reports, Cost Explorer, budgets, IAM-based allocation, and application inference profiles answer different attribution questions from raw request and response logs. ^[2] Use the log stream to explain what happened in a request; use billing data to reconcile what AWS charged. A log record containing token counts is evidence for analysis, not a replacement for the billable usage line.

A practical cost model

Use four layers so your estimate remains auditable:

1. Inference spend. This is the model charge for input and output units, modality, model, and service tier. Amazon Bedrock pricing is model- and provider-dependent, so it must be selected separately for the model and Region you use. ^[6]
2. CloudWatch destination spend. Estimate log ingestion, retained log storage, and any Logs Insights scan or other analysis charges. CloudWatch notes that prices vary by Region and that its free-tier table includes 5 GB of Logs ingestion, archive storage, and data scanned by Logs Insights per month for eligible usage. ^[4]
3. S3 destination spend. Estimate the stored GB-month, PUT or other request counts, retrievals, lifecycle transitions, and any query or analytics service. S3 explicitly bills requests by type and charges storage separately from requests. ^[5]
4. Supporting controls. Include KMS requests, cross-Region transfer, replication, Athena or Glue, QuickSight, Lambda, or OpenSearch only when your design actually uses them. These are not automatically included in the Bedrock logging toggle.

A robust estimate starts with a sampling window. Capture at least a few hundred representative calls across text, embedding, image, and video paths if you use them. For each path, record invocation count, uncompressed log bytes, whether the body is inline, S3 object count, and retention days. Calculate a weighted average by traffic share. Do not use a single average payload if a small number of image or document calls dominate the storage tail.

Worked cost example

Assume the following for one month in a US Region. The rates below are explicit modeling inputs, not a promise of the amount on an AWS invoice. CloudWatch’s published examples use $0.50 per GB for log ingestion and $0.03 per GB-month for log storage; AWS says to check the pricing page for your Region. ^[4] For S3, use the Standard storage and request assumptions shown in the AWS pricing examples, including $0.023 per GB-month for Standard storage, $0.005 per 1,000 PUT requests, and $0.0004 per 1,000 GET requests. ^[5]

The small difference from rounding is intentional: the displayed S3 line items sum to $0.44, so the combined estimate is $21.64. If eligible CloudWatch usage receives a 5 GB free-tier offset, subtracting 5 GB from the modeled ingestion volume would reduce that line by $2.50, producing an illustrative combined estimate of about $19.14. Do not apply that offset blindly: confirm account eligibility, the billing period, Region, and what other CloudWatch Logs usage consumes the allowance. ^[4]

The example excludes Logs Insights scan charges because query volume is not supplied. Add a separate line such as monthly GB scanned × applicable Logs Insights rate. This keeps an infrequent investigation workload distinct from a dashboard that scans the same log group every few minutes. It also excludes KMS, data transfer, lifecycle transitions, S3 replication, Athena, Glue, QuickSight, OpenSearch, Lambda, and support or operational labor.

The 35% compression factor, 20 KB payload, 20,000 S3 objects, 60,000 reads, and 30-day retention are assumptions to replace with observed values. S3 delivery is batched, so object count can differ materially from invocation count. Large bodies and binary assets can create separate S3 objects, which makes the tail more important than the average. ^[1] Run the ledger once with CloudWatch only, once with S3 only, and once with both. That comparison shows whether the operational value of real-time CloudWatch queries is worth the incremental destination cost for your traffic shape.

CloudWatch versus S3 for attribution

Choose CloudWatch Logs when the primary job is alerting, short-window troubleshooting, metric filters, or Logs Insights investigations. Set an explicit retention policy. Otherwise, a log group can retain data longer than the period used by your operational team, turning a debugging aid into an unbounded archive.

Choose S3 when you need durable history, large payload delivery, lifecycle transitions, Athena queries, or a downstream analytics lake. Define a prefix by account, Region, model, environment, and date only if that partitioning serves a query or governance need. Extra objects and transitions can add request and management costs, while an overly broad prefix can increase query scans and access risk.

Use both when there is a defensible split between hot operational telemetry and long-term evidence. Keep the copies in separate ledger columns. The fact that a record appears in both destinations does not make it two model invocations, but it can make it two destination cost paths. For financial reconciliation, join the log record’s request ID, model ID, identity, and token counts to billing exports or application inference-profile dimensions rather than summing log bytes as if they were inference units. AWS’s FinOps guidance specifically positions billing attribution and invocation logs as complementary layers. ^[2]

For a broader model-cost comparison, see the Model pricing comparison. If retrieval is part of your Bedrock workflow, the RAG, embedding and vector database cost calculator helps separate retrieval infrastructure from model and logging spend. For a fully loaded deployment view, use the Self-hosted GPU inference cost calculator and the AI agent development cost estimator, while keeping their infrastructure or build assumptions separate from Bedrock’s managed-service invoice.

FAQ

Does Amazon Bedrock charge a separate per-invocation logging fee?

The practical answer is to budget the destination services rather than assume a separate flat Bedrock logging fee. Bedrock’s invocation logging configuration publishes supported records to CloudWatch Logs, S3, or both. CloudWatch and S3 then meter their own ingestion, storage, requests, queries, and related services. The model’s inference charge remains a separate line. Confirm the current service pages and your Region before committing to a rate. ^{[1] [4] [5] [6]}

Is S3 cheaper than CloudWatch for Bedrock invocation logs?

There is no universal winner. S3 is often attractive for compressed long-term retention, large payloads, and batch analytics, while CloudWatch can be valuable for near-real-time queries and alarms. The answer depends on payload size, retention, query frequency, object count, retrieval pattern, and whether you need both. Compare a measured sample with the four-layer ledger rather than comparing only a storage rate.

Does CloudWatch receive the full prompt and response?

Not always. AWS documents inline input and output bodies up to 100 KB. Larger JSON bodies and binary data require an S3 large-data destination to be published as separate objects; otherwise the large data is not published to CloudWatch Logs. The invocation record still contains metadata and token fields, but a CloudWatch-only design should not be treated as a complete payload archive for multimodal traffic. ^[1]

Can invocation logs prove the exact Bedrock invoice amount for each request?

They can improve attribution but should not be treated as the invoice by themselves. Logs expose request IDs, model IDs, identities, optional request metadata, and token counts. Billing exports and cost-allocation features use billing meters and allocation dimensions that may not equal raw logged bytes or a simple token multiplication. Reconcile the two datasets by request, model, identity, profile, time window, and Region, then investigate variance instead of forcing every row to match.

What should I include in a Bedrock logging cost calculator?

Include monthly invocations, traffic mix, average and percentile logged bytes, CloudWatch ingestion, CloudWatch retention days, Logs Insights GB scanned, S3 compressed GB-month, S3 PUT/GET/LIST requests, large-object count, retrieval and lifecycle activity, KMS and transfer where applicable, plus any Athena, Glue, QuickSight, OpenSearch, or Lambda usage. Keep inference pricing in its own section. A calculator that accepts only “requests per month” hides the payload and retention drivers that usually determine the destination bill.

Limitations and assumptions

This page uses pricing observations checked on 2026-11-02 and illustrates US-oriented units. AWS pricing varies by Region, account, service tier, free-tier eligibility, storage class, and contract. The worked example is an estimate, not a quote. It assumes decimal GB for the simple volume conversion, 30-day retention, no replication, no lifecycle transition, no KMS or transfer charge, no query scan charge, and representative text-heavy payloads. Replace every assumption with measured billing and delivery data before using the result for a budget or chargeback policy.

Logging can also contain sensitive prompts, responses, identities, and binary outputs. Apply access controls, encryption, retention, and deletion policies that fit your data requirements. A lower logging bill is not a reason to retain data that the application does not need. Conversely, disabling large-data delivery to avoid S3 cost may remove evidence needed for debugging or governance. Treat privacy, operational coverage, and cost as one design decision.