CloudFront real-time logs deliver request events within seconds, making them useful for detecting sudden 4xx and 5xx errors, cache anomalies, automated traffic, deployment failures, and security events. The logs do not automatically become a searchable report. CloudFront sends the selected fields to Amazon Kinesis Data Streams, where a consumer, Firehose, Lambda, or another analytics pipeline must process them.

The three variables that matter most are sampling rate, selected fields, and downstream processing capacity. Enabling 100% sampling with a large field set across every cache behavior can create unnecessary Kinesis throughput, consumer compute, storage, and query costs even when the CloudFront log-line charge itself appears small.

This article was reviewed on August 6, 2026. AWS features and prices may change. Verify current charges on the CloudFront, Kinesis, Firehose, Lambda, S3, and query-service pricing pages before production deployment.

CloudFront Real-Time Logs vs Standard Logs

The two log types are complementary. A common design retains standard logs as the historical record and enables sampled real-time logs for critical paths that require rapid detection.

How the Real-Time Logging Pipeline Works

CloudFront cache behavior → Real-time log configuration → Kinesis Data Stream → Consumer or Firehose → Alerts, storage, and analytics

A real-time log configuration defines:

• Sampling rate: the percentage of eligible requests that produce a record.

• Field list: the request, response, cache, network, and security data included in each record.

• Endpoint: the Kinesis Data Stream that receives the records.

• Associated cache behavior: the paths and origin behavior covered by the configuration.

Real-time logging is not simply a distribution-wide switch. Associate the configuration with the cache behaviors that need observation, such as /api/*, /video/*, or the default behavior. Different paths can use different field sets and sampling rates.

What Must Be Prepared Before Configuration?

1. Create a Kinesis Data Stream

CloudFront real-time logs use Kinesis Data Streams as their endpoint. Under the current AWS documentation, the stream used for CloudFront real-time logs must be located in US East (N. Virginia), identified as us-east-1.

Select a capacity mode based on expected throughput and operational requirements. Estimate peak records per second and average record size. If write capacity or consumer capacity is insufficient, the monitoring pipeline may become delayed or incomplete.

2. Create an IAM Role for CloudFront

CloudFront uses an IAM role to write records to the target stream. The trust policy must allow the CloudFront service to assume the role. The permission policy should grant only the required Kinesis write operations on the specific stream.

Do not grant administrative access to every Kinesis resource merely to simplify setup. Use least privilege and avoid sharing one unrestricted role across unrelated production workloads.

3. Estimate Log Throughput

Real-time records per second ≈ CloudFront requests per second × Sampling rate

If peak traffic is 20,000 requests per second and sampling is set to 10%, the estimated rate is approximately 2,000 real-time records per second. Kinesis planning must also consider record size, write limits, bursts, partition distribution, and consumer throughput.

How Should You Select Log Fields?

More fields are not automatically better. A larger record increases parsing, transfer, storage, indexing, and query costs. Select fields according to the problem being solved.

Basic Access and Performance Fields

• timestamp: request time.

• c-ip: client IP address; treat it as sensitive data.

• cs-method: HTTP request method.

• cs-protocol: request protocol.

• cs-host: requested hostname.

• cs-uri-stem: URI path.

• sc-status: HTTP status returned to the viewer.

• time-taken: time CloudFront spent processing the request.

Cache and Troubleshooting Fields

• x-edge-location: edge location that processed the request.

• x-edge-result-type: request result classification.

• x-edge-response-result-type: response-stage result classification.

• x-edge-request-id: identifier useful for tracing an individual request.

• time-to-first-byte: time to first byte for latency analysis.

Security and Client Identification Fields

• cs-user-agent: client User-Agent.

• cs-referer: referring page.

• cs-protocol-version: HTTP protocol version.

• ssl-protocol and ssl-cipher: TLS protocol and cipher.

• WAF, geolocation, or request-header fields required by the actual detection use case.

Query strings, cookies, authorization data, IP addresses, and User-Agent values may contain personal or sensitive information. Do not collect them merely because they might be useful later. Field selection, masking, access controls, and retention must comply with applicable privacy and regulatory requirements.

Recommended Fields for Four Common Use Cases

What Sampling Rate Should You Use?

CloudFront supports a real-time log sampling rate from 1% to 100%. A 100% rate is not necessarily the best default.

• 1%–5%: useful for trend monitoring and initial capacity testing on high-traffic workloads.

• 10%–25%: useful for cache, latency, and error analysis while limiting downstream volume.

• 50%–100%: useful for critical paths, temporary incident investigation, or cases requiring near-complete capture.

These ranges are deployment suggestions, not AWS requirements. Low sampling can miss rare errors or user-specific events. High sampling increases Kinesis and downstream processing load.

A more controlled approach is to set rates by cache behavior:

• Use a lower rate for ordinary static assets.

• Use a higher rate for login, checkout, or critical APIs.

• Temporarily increase sampling during an incident.

• Confirm Kinesis and consumer capacity before increasing the rate.

How to Configure Real-Time Logs in the Console

1. Create or select a Kinesis Data Stream in us-east-1.

2. Create an IAM role that allows CloudFront to write to that stream.

3. Open the CloudFront real-time log configuration page.

4. Create a configuration and assign a clear name.

5. Set the sampling rate.

6. Select the required fields and confirm their order.

7. Select the Kinesis endpoint and IAM role.

8. Associate the configuration with the intended distribution cache behavior.

9. Wait for deployment and verify that records reach the Kinesis consumer.

An “Enabled” status in the console does not prove the complete pipeline works. Verify stream writes, consumer lag, parser errors, alerts, and final storage.

How Should the Kinesis Consumer Be Designed?

Kinesis is the streaming entry point, not the final analytics system. Common downstream patterns include:

• Real-time alerts: aggregate status codes, paths, and latency over short windows and trigger notifications.

• Lambda processing: parse and transform records, while controlling batch size, concurrency, retries, and cost.

• Firehose delivery: batch processed data into S3, an analytics platform, or another supported destination.

• Long-term analysis: store compressed, partitioned data in object storage and query it with an analytics engine.

Consumers should be idempotent and handle malformed records. Do not assume that every record will be processed exactly once, and do not allow one invalid record to block an entire batch.

How to Monitor 4xx and 5xx Errors

Do not alert only on the total number of 4xx or 5xx responses. Group events by:

• Status code, such as 403, 404, 502, 503, or 504.

• URI path or normalized route.

• CloudFront result type.

• Edge location and viewer geography.

• HTTP method and hostname.

• Deployment version or change window.

Alerts should combine counts with rates. Ten 5xx errors per minute may be critical for a low-volume API but insignificant for a static service receiving hundreds of thousands of requests per second. Use an error-count threshold, error-rate threshold, sustained time window, and minimum sample size together.

How to Investigate a Cache Hit Ratio Drop

When cache performance drops, aggregate real-time records by URI, query parameter, result type, and time window. Check whether:

1. A broad cache invalidation was executed.

2. The origin changed Cache-Control or Expires.

3. A cache policy began including additional cookies, headers, or query parameters.

4. Objects started returning uncacheable statuses or authorization-dependent responses.

5. The issue appears in all regions or only specific edge locations.

6. Cache misses correlate with higher TTFB or origin 5xx errors.

Real-time logs reveal the timing and scope of the change, but the root cause should be confirmed against CloudFront configuration, response headers, and origin logs.

How Much Do CloudFront Real-Time Logs Cost?

As of the review date, the AWS CloudFront pricing page lists real-time logs at $0.01 for every 1,000,000 log lines generated. This price covers the CloudFront real-time log records only, not the complete processing pipeline.

CloudFront real-time log charge = Generated records ÷ 1,000,000 × $0.01

For example, if a distribution receives 3 billion requests per month and uses a 10% sampling rate, it would generate approximately 300 million records:

300 million ÷ 1 million × $0.01 = $3

This example excludes:

• Kinesis Data Streams capacity, writes, and reads.

• Enhanced fan-out or other Kinesis features.

• Lambda invocations, duration, and concurrency.

• Firehose processing and delivery.

• S3 requests, storage, and lifecycle transitions.

• Log-platform ingestion, indexing, and retention.

• Athena or other query-engine data scanning.

• Applicable cross-Region or other data transfer.

The most important cost controls are often field minimization, sampling, compression, retention, and query design—not the CloudFront price per million records.

Eight Ways to Control Real-Time Logging Cost

1. Start with a low sampling rate: validate value and capacity before increasing it.

2. Limit logging to critical cache behaviors: avoid capturing every small static object by default.

3. Select fewer fields: retain only fields used by alerts, troubleshooting, or reports.

4. Increase sampling temporarily: restore the normal rate after an incident.

5. Store long-term data in a compressed columnar format: reduce storage and scan costs.

6. Apply lifecycle rules: retain operational data briefly and archive or delete older data.

7. Aggregate before expensive indexing: avoid sending every raw record to a high-cost search platform.

8. Set budgets and capacity alarms: monitor log volume, Kinesis throughput, consumer lag, and downstream charges.

Common Configuration Mistakes

Creating the Kinesis Stream in the Wrong Region

The Kinesis Data Stream for CloudFront real-time logs should be in us-east-1. Do not place it in the origin Region merely because the origin runs there.

Using Excessive IAM Permissions or an Invalid Trust Policy

Excessive permissions increase risk, while an incorrect trust relationship or stream policy prevents delivery. Restrict access to the intended stream and test actual writes.

Starting at 100% Without a Capacity Test

Kinesis and consumers may fall behind during a peak. Capacity planning should use peak traffic, not daily average traffic.

Collecting Tokens and Personal Data

Query strings, cookies, IP addresses, and other fields may expose sensitive data. Minimize collection and apply masking and access controls.

Collecting Logs Without Alerts or Retention Rules

Records entering Kinesis do not create value by themselves. Define who consumes them, which alerts are generated, how long data is retained, and how failures are handled.

Production Checklist

1. Confirm that the use case requires second-level monitoring rather than only historical logs.

2. Define the collection scope by cache behavior.

3. Select the smallest useful field set.

4. Review sensitive data, privacy requirements, and retention periods.

5. Create the Kinesis Data Stream in us-east-1.

6. Configure a least-privilege IAM role and correct trust policy.

7. Plan throughput using peak request rate and record size.

8. Begin with lower sampling and verify end-to-end delivery.

9. Monitor Kinesis, consumers, alerts, and storage.

10. Calculate CloudFront, Kinesis, processing, storage, and query costs separately.

Frequently Asked Questions

Do CloudFront real-time logs record every request?

That depends on the sampling rate and associated cache behaviors. At 100%, CloudFront attempts to log all eligible requests within the configured scope. A lower percentage records a sample.

Can real-time logs be written directly to S3?

The direct endpoint is Kinesis Data Streams. To retain the data in S3, add a consumer or delivery service downstream.

Can real-time logs replace standard CloudFront logs?

Usually not. Real-time logs are designed for monitoring and incident response, while standard logs are better suited to complete historical records and offline analysis.

Can a 10% sample be used to calculate an exact request total?

It can support trend estimates, but it should not be treated as exact billing or audit data. Rare events, individual paths, and short bursts may be distorted by sampling.

Why can the total bill increase when the CloudFront log-line charge is low?

The CloudFront record charge is only one component. Kinesis, consumer compute, log-platform ingestion, storage, indexing, and queries may cost much more.

Conclusion

CloudFront real-time logs send CDN request events into a streaming pipeline within seconds, enabling faster detection of 4xx and 5xx errors, cache degradation, latency changes, and abnormal traffic. They are designed for monitoring and response rather than as a simple replacement for standard access logs.

Start with selected cache behaviors, a minimal field set, and a lower sampling rate. Increase coverage only after confirming Kinesis and consumer capacity. Cost planning must include CloudFront records, Kinesis, processing, storage, indexing, and query services.

CloudFlew provides CloudFront-based CDN services. A logging pipeline should be designed around request volume, record size, sampling rate, retention, alerting requirements, and applicable product terms.

References

1. AWS CloudFront Developer Guide: Real-time logs, reviewed August 6, 2026

2. AWS CloudFront Developer Guide: Understanding real-time log configurations, reviewed August 6, 2026

3. AWS CloudFront Developer Guide: Kinesis endpoint requirements, reviewed August 6, 2026

4. AWS: Amazon CloudFront Pricing, reviewed August 6, 2026