CloudFront

Last updated: Nov 3, 2026

Rationale

Amazon CloudFront is the content delivery network that Fluid Attacks uses in front of each public HTTPS endpoint at *.fluidattacks.com. It is directly in front of the AWS origins of Fluid Attacks (S3 buckets and Lambda Function URLs), and behind Cloudflare, as the second tier of the public hosting chain.

These are the primary reasons why Fluid Attacks selected it and not other alternatives:

It supports Origin Access Control (OAC). With OAC, the origin (S3 bucket or Lambda Function URL) cryptographically rejects the requests that did not come through the distribution. Read Public hosting.
It has native integration with AWS Certificate Manager. Thus, it automatically issues and rotates TLS certificates for custom domains, without more cost.
It supports viewer mTLS / Authenticated Origin Pulls. Thus, it rejects each TLS handshake with a client certificate that a CA in the trust store of the distribution did not sign. Fluid Attacks uses this function to make sure that each connection comes from its own Cloudflare zone. Thus, the direct-access path through *.cloudfront.net is closed cryptographically. The distribution rejects all other Cloudflare tenants (for example, through CF Workers) before they get to the HTTP layer.
It supports CloudFront Functions and Lambda@Edge. These are sub-millisecond and full-runtime edge functions for viewer-request rewrites, body hashing for OAC SigV4, and similar tasks.
It supports CloudWatch Logs Delivery V2 for access logs. It writes these logs as JSON to a central S3 logging bucket, without a logging configuration inside the distribution.
It applies modern TLS policies at the viewer (TLS 1.3). It also supports path-based routing between more than one origin in one distribution. Thus, Fluid Attacks can serve static assets from S3 and server-rendered content from a Lambda Function URL on the same hostname.
You can write the resources as code with Terraform.
It charges for each request and for each gigabyte that it transfers, without a base fee. Thus, the cost agrees with the use for consumers with low traffic.
It complies with many certifications from ISO and CSA.

Alternatives

These are the alternatives that Fluid Attacks examined before it selected Amazon CloudFront. The list starts with the alternative that is most interesting for the requirements of Fluid Attacks.

Cloudflare alone, without an AWS-side CDN

Cloudflare is the edge provider of Fluid Attacks (WAF, bot management, DDoS shield, proxied DNS), and Fluid Attacks continues to use it in front of CloudFront.

It is the best at the edge, and Fluid Attacks does not replace it. CloudFront is behind it, not in its place.
With only Cloudflare, the AWS origins of Fluid Attacks (S3 buckets, Lambda Function URLs) would be directly accessible on the Internet, without a cryptographic origin restriction.
It does not give an equivalent of Origin Access Control for AWS services. OAC gives Fluid Attacks the AWS-native cryptographic gate on the origin layer.

Fluid Attacks last reviewed Cloudflare alone on Apr 23, 2026.

Amazon API Gateway

Amazon API Gateway is the AWS managed service to expose HTTP, REST, and WebSocket APIs. Before this architecture, it was the AWS-side front layer for each public service at *.fluidattacks.com.

It does not give a method to cryptographically restrict who gets to the auto-generated *.execute-api.us-east-1.amazonaws.com endpoint. HTTP API v2 does not have resource policies, WAF integration, or an Origin Access Control equivalent. Also, WebSocket API v2 does not support mutual TLS. All the persons on the public Internet who resolve the regional hostname get to the upstream Lambda directly, and they go around Cloudflare.
AWS also showed the direction. AWS released OAC for Lambda Function URL origins in April 2024, and it did not release the same function for API Gateway HTTP API v2 or WebSocket API v2. Thus, Lambda URLs have origin restriction, but you can always go around API Gateway.
Before Fluid Attacks selected CloudFront + OAC, it examined other patterns: shared-secret authorizers, origin mTLS on API Gateway, and REST API v1 with resource policies. All these patterns put origin authentication into application code or into the Cloudflare configuration of each zone, and Fluid Attacks would have to operate and rotate them. They give up the origin guarantee that the AWS platform applies, which OAC gives without cost. For the full evaluation of each pattern, read Public hosting.
To move HTTP services from API Gateway, Fluid Attacks only changed the transport. 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 behind CloudFront + OAC, without a protocol change. They use the same payload format v2 events and the same handler shape.
To move the WebSocket service (fixes), Fluid Attacks had to rewrite the protocol. It changed $connect / $default / $disconnect WebSocket frames to one-shot HTTPS requests with Server-Sent Events streamed responses (Lambda Function URL RESPONSE_STREAM invoke mode, through the AWS Lambda Web Adapter). But the result is the same cdn + Lambda URL + OAC chain that all the other services use at this time.
After Fluid Attacks moved all the consumers, the api and api-routes Terraform modules at develops/utils/terraform-modules/ have no consumers, and Fluid Attacks retired them. Thus, public hosting uses only one Terraform module (cdn) and one mental model.

Fluid Attacks last reviewed Amazon API Gateway on May 27, 2026.

Fastly, Akamai and other third-party CDNs

Fastly and Akamai are third-party CDN providers.

They give edge capabilities that are similar to CloudFront.
They do not integrate with AWS origin primitives as CloudFront does. There is no equivalent of Origin Access Control to cryptographically restrict access to an S3 bucket or a Lambda Function URL from an external CDN.
If Fluid Attacks used one of them, it would have to go back to a shared-secret or IP-allowlist model for origin protection. The current architecture prevents this model on purpose.

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

AWS Global Accelerator

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

It is not a CDN. It does not cache content, and it does not give HTTP-layer features, for example, path-based routing or viewer-request edge functions.
It is for a different purpose (better TCP/UDP latency for global workloads).
It cannot replace CloudFront for the public hosting pattern of Fluid Attacks.

Fluid Attacks last reviewed AWS Global Accelerator on Apr 23, 2026.

AWS Elastic Load Balancing

AWS Elastic Load Balancing is in front of compute on EC2, ECS, or EKS.

It is not a CDN, and it does not terminate HTTPS with managed certificates at the edge.
Fluid Attacks uses it internally to balance the load of its Kubernetes workloads, but not as a public-facing edge.
It cannot be in front of S3 or Lambda Function URLs with cryptographic origin restriction.

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

Usage

Fluid Attacks uses Amazon CloudFront as the distribution layer in front of each public HTTPS endpoint at *.fluidattacks.com. Each consumer has its own distribution, with one or two origins (S3 for static assets, Lambda Function URL for dynamic content, or both with path-based routing). Origin Access Control protects all of them. Public hosting explains the full architecture.