What Can AWS CloudFront See When Tor Is Part of the Architecture?

What AWS can inspect depends on how the application is built. For ordinary HTTP content, CloudFront can process requests and responses and may generate logs and metrics, while AWS retains the distribution and origin configuration. If the payload is additionally encrypted or tunneled by the application, CloudFront may only see metadata and an opaque request body, limiting caching and content-aware WAF inspection. Network-level details such as the immediate origin would still be visible.

CloudFront can be configured to contact an ordinary Internet endpoint, an AWS service, or an intermediary proxy. In that case, AWS definitely knows the immediate origin, but it may not know what lies beyond that proxy. If the proxy forwards requests into Tor, CloudFront would generally just see the proxy as another origin and would not necessarily be able to identify the ultimate hidden-service backend.

The unusual part is that CloudFront cannot resolve or reach an onion address by itself. A Tor-related deployment would therefore need a bridge between CloudFront and the Tor network, or the onion service could be connecting outward to a regular CloudFront endpoint. Either arrangement is possible in principle, but it is not a direct CloudFront-to-onion connection and often defeats much of the normal CDN or WAF benefit.

CloudFront cannot directly connect to a .onion service. A conventional setup would need an intermediary such as a server running a Tor client or a separate proxy. AWS would know the origin configured in the distribution, including its hostname or address and any AWS resources involved. Tor may obscure a further hop, but it does not hide CloudFront’s own configuration from AWS.