CloudFront

Last updated: May 27, 2026

Rationale

Amazon CloudFront is the content delivery network we use in front of every public HTTPS endpoint at *.fluidattacks.com, directly fronting our AWS origins (S3 buckets and Lambda Function URLs) and sitting behind Cloudflare as the second tier of the public hosting chain.

The main reasons why we chose it over other alternatives are:

It supports Origin Access Control (OAC), which lets the origin (S3 bucket or Lambda Function URL) cryptographically reject requests that did not come through the distribution — see Public hosting.
It integrates natively with AWS Certificate Manager, auto-issuing and rotating TLS certificates for custom domains at no additional cost.
It supports viewer mTLS / Authenticated Origin Pulls, rejecting any TLS handshake whose client certificate is not signed by a CA in the distribution's trust store. We use this to enforce that every connection terminates from our own Cloudflare zone, closing the *.cloudfront.net direct-access path cryptographically — any other Cloudflare tenant (e.g. via CF Workers) is rejected before any HTTP layer is reached.
It supports CloudFront Functions and Lambda@Edge, sub-millisecond and full-runtime edge functions for viewer-request rewrites, body hashing for OAC SigV4, and similar.
It supports CloudWatch Logs Delivery V2 for access logs, written as JSON to a central S3 logging bucket without requiring any distribution-embedded logging configuration.
It enforces modern TLS policies at the viewer (TLS 1.3) and supports path-based routing between multiple origins within a single distribution, allowing us to serve static assets from S3 and server-rendered content from a Lambda Function URL on the same hostname.
Resources can be written as code using Terraform.
It bills per request and per gigabyte transferred with no base fee, aligning cost with usage for low-traffic consumers.
It complies with several certifications from ISO and CSA.

Alternatives

Below are the alternatives we evaluated before choosing Amazon CloudFront, ordered from most to least interesting based on our specific needs.

Cloudflare alone, without an AWS-side CDN

Cloudflare is our edge provider (WAF, bot management, DDoS shield, proxied DNS), and we continue to use it in front of CloudFront.

It is unmatched at the edge and we are not replacing it — CloudFront sits behind it, not in place of it.
Relying on Cloudflare alone would leave our AWS origins (S3 buckets, Lambda Function URLs) reachable directly over the Internet, with no cryptographic origin restriction.
It does not provide an equivalent of Origin Access Control for AWS services, which is what gives us the AWS-native cryptographic gate on the origin layer.

Cloudflare alone was last reviewed on Apr 23, 2026.

Amazon API Gateway

Amazon API Gateway is the AWS managed service for exposing HTTP, REST, and WebSocket APIs, and was the AWS-side fronting layer for every public service at *.fluidattacks.com before this architecture.

It does not provide a way to cryptographically restrict who reaches the auto-generated *.execute-api.us-east-1.amazonaws.com endpoint. HTTP API v2 has no resource policies, no WAF integration, and no Origin Access Control equivalent; WebSocket API v2 additionally does not support mutual TLS. Anything on the public Internet that resolves the regional hostname reaches the upstream Lambda directly, bypassing Cloudflare.
AWS itself signaled the direction. AWS shipped OAC for Lambda Function URL origins in April 2024 and did not ship the equivalent for API Gateway HTTP API v2 or WebSocket API v2 — closing the origin-restriction story on Lambda URLs and leaving API Gateway as an inherently bypassable upstream.
The fallback patterns we evaluated before settling on CloudFront + OAC — shared-secret authorizers, origin mTLS on API Gateway, and REST API v1 with resource policies — all push origin authentication into application code or per-zone Cloudflare configuration that we would have to operate and rotate ourselves, trading away the AWS-platform-enforced origin guarantee that OAC delivers for free. See Public hosting for the full evaluation of each fallback.
Migrating HTTP services off API Gateway was a straight transport swap. docs.fluidattacks.com, db.fluidattacks.com, infers.fluidattacks.com, and tracks.fluidattacks.com moved from API Gateway HTTP API v2 to a Lambda Function URL fronted by CloudFront + OAC without a protocol change — same payload format v2 events, same handler shape.
Migrating the WebSocket service (fixes) required a protocol rewrite from $connect / $default / $disconnect WebSocket frames to one-shot HTTPS requests with Server-Sent Events streamed responses — Lambda Function URL RESPONSE_STREAM invoke mode, shipped via the AWS Lambda Web Adapter — but the destination shape is the same cdn + Lambda URL + OAC chain every other service uses now.
With every consumer migrated, the api and api-routes Terraform modules at runs/utils/tf-modules/ have zero consumers and are retired, collapsing the public-hosting story to one Terraform module (cdn) and one mental model.

Amazon API Gateway was last reviewed on May 27, 2026.

Fastly, Akamai and other third-party CDNs

Fastly and Akamai are third-party CDN providers.

They provide comparable edge capabilities to CloudFront.
They do not integrate with AWS origin primitives the way CloudFront does. There is no equivalent of Origin Access Control for cryptographically restricting access to an S3 bucket or a Lambda Function URL from an external CDN.
Adopting one would force us back to a shared-secret or IP-allowlist model for origin protection, which the current architecture deliberately avoids.

Fastly, Akamai and other third-party CDNs were last reviewed on Apr 23, 2026.

AWS Global Accelerator

AWS Global Accelerator provides static anycast IPs and TCP/UDP acceleration.

It is not a CDN and does not cache content or provide HTTP-layer features like path-based routing or viewer-request edge functions.
It serves a different use case (improving TCP/UDP latency for global workloads).
It cannot replace CloudFront for our public hosting pattern.

AWS Global Accelerator was last reviewed on Apr 23, 2026.

AWS Elastic Load Balancing

AWS Elastic Load Balancing fronts compute on EC2, ECS, or EKS.

It is not a CDN and does not terminate HTTPS with managed certificates at the edge.
We use it internally for load-balancing our Kubernetes workloads, but not as a public-facing edge.
It cannot front S3 or Lambda Function URLs with cryptographic origin restriction.

AWS Elastic Load Balancing was last reviewed on Apr 23, 2026.

Usage

We use Amazon CloudFront as the distribution layer in front of every public HTTPS endpoint at *.fluidattacks.com. Each consumer gets its own distribution, configured with one or two origins (S3 for static assets, Lambda Function URL for dynamic content, or both with path-based routing), all protected via Origin Access Control. The full architecture is described in Public hosting.