> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CloudFront
> CloudFront APIs with Cloud Adapter.
This page describes how CloudFront maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.
## Supported environments
| Environment | Mapping |
| ------------ | -------------- |
| Azure | Infrastructure |
| DigitalOcean | Infrastructure |
| Google Cloud | Infrastructure |
| Scaleway | Infrastructure |
API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.
## How the targets compare
Each row compares a capability of CloudFront with its adaptation on each target.
A dash means this profile does not state the capability for that target.
### Cloud Adapter
| Capability | CloudFront | Azure · Azure Front Door Premium | Azure · Azure Front Door Standard | DigitalOcean | Google Cloud | Scaleway |
| ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Edge network · who serves the traffic | CloudFront's global PoPs | Azure Front Door's global edge | Azure Front Door Standard's global edge | DigitalOcean's CDN edge | Google Cloud CDN on the external load balancer | - |
| Origins · origin domains → backend | Yes - multiple origins + origin groups with failover | Partial - origin-group members selected by health probes | Partial - origin-group members selected by health probes; public endpoints required | Partial - the first origin's domain becomes the CDN origin; additional origins and origin groups drop and are flagged during the build | Partial - first HTTP backend service or bucket backend; additional origins and groups are reported | - |
| Cache behaviors · paths, TTLs, cache key | Yes - path patterns, per-behavior TTLs, cache key, methods | Partial - path rules with one cache duration and query-string behavior; separate min/max TTL and header/method differences remain | Partial - path rules with one cache duration and query-string behavior; separate min/max TTL and header/method differences remain | Partial - the default behavior's default TTL is preserved; path patterns, min/max TTL, and methods drop and are flagged during the build | Partial - backend cache policy with default/max/client TTLs, negative caching and cache keys; header/method differences remain | - |
| Compression · automatic gzip/brotli | Yes - automatic edge compression | Yes - the route's compression setting | Yes - the route's compression setting | Partial - there is no configurable compression setting; DigitalOcean's CDN edge may apply gzip automatically when the client requests it | Yes - the backend's compression mode | - |
| HTTPS redirect · viewer protocol policy | Yes - redirect-to-https / https-only | Yes - the route's HTTPS-redirect setting | Yes - the route's HTTPS-redirect setting | Partial - the viewer protocol policy has no counterpart; the DigitalOcean CDN endpoint serves over HTTPS by default | Yes - a url\_map HTTPS redirect rule | - |
| Custom domains + TLS · aliases + certificate | Yes - alternate domain names + ACM viewer certificate | Partial - target-managed certificate after domain validation; ACM material and TLS settings require review | Partial - target-managed certificate after domain validation; ACM material and TLS settings require review | Partial - the first alias becomes the CDN custom domain; additional aliases drop, and the viewer certificate becomes a DigitalOcean-managed certificate you attach | Partial - target-managed certificate after domain validation; ACM material and TLS settings require review | - |
| WAF / geo restrictions · web ACL + geo | Yes - AWS WAF web ACL + geo restrictions | Partial - custom match, rate-limit and country rules; Microsoft-managed rule selection differs from AWS groups | Partial - custom match, rate-limit and country rules; managed rules and bot protection require Premium | No - no attached-WAF or geo surface on the DigitalOcean CDN endpoint; dropped and flagged during the build | No - Cloud Armor configured separately; no automatic AWS web ACL or geo translation | - |
| Origin access & signed URLs · origin and viewer authorization | Yes - OAI / OAC + trusted-signer signed URLs | Partial - approved Private Link access to supported origins; viewer signed-URL verification requires a separate application design | Partial - public origin with separate access controls; no Private Link or CloudFront viewer-signature verification | - | Partial - Cloud CDN signed URLs require a new HMAC signer; private bucket access or HTTP-origin controls are configured separately | - |
| Edge functions · Lambda\@Edge / Functions | Yes - Lambda\@Edge + CloudFront Functions | No - rule conditions and actions; no arbitrary function runtime | Partial - header, URL and redirect rules; no arbitrary function runtime | No - no edge-compute analog; associations drop and standalone functions cause a build error | No - no function runtime; unsupported associations reported and standalone functions rejected | - |
| API coverage | full | high | high | minimal | high | minimal |
| Origin access & signed URLs · locked-down origin | Yes - OAI / OAC + trusted-signer signed URLs | - | - | No - the origin access control companion is removed and flagged during the build; a standalone origin access identity causes a build error | - | - |
| The backend stage needs to know WHAT it points at · and a CloudFront origin does not say | origin.domain\_name, an FQDN | - | - | - | - | one of s3 / lb / container / function backend config |
| Every path gets the DEFAULT cache behavior · the one most likely to surprise | ordered\_cache\_behavior, per path pattern | - | - | - | - | one cache stage for the whole pipeline |
| There is a WAF stage, and your WAF association does not reach it · worth separating from 'no analog' | a WAFv2 web ACL associated with the distribution | - | - | - | - | an unwired waf stage |
| Access logs do not follow the distribution · they move products | logging\_config writing to an S3 bucket | - | - | - | - | Cockpit, not wired by the build |
## On Azure
### Azure Front Door Premium
| Operation | Area | Support | Depth | Notes |
| -------------------------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Origin access (OAI / OAC) | Access control | Partial | Most usage | Premium can connect to a supported origin through an approved Private Link endpoint. Configure the compatible origin and close unwanted alternate access paths. A standalone origin access identity without a supported translation causes a build error |
| Signed URLs & trusted keys | Access control | Out of scope | Most usage | CloudFront signed URLs and signed cookies use RSA or ECDSA signatures that Front Door cannot verify; it is a different request authorization scheme, out of this option's scope and flagged during the build |
| WAF & geo restrictions | Access control | Partial | Most usage | Custom match, rate-limit and country rules become target WAF rules attached through a security policy. Premium supports Microsoft-managed rules and bot protection; AWS managed groups require target-specific rule selection. |
| Cache behaviors | Cache | Partial | Most usage | Path-matched rules retain cache duration and query-string behavior. CloudFront default TTL supplies a single duration; separate minimum/maximum constraints and per-behavior header/method differences are reported. |
| Content delivery | Content delivery | Supported | Common | served on Azure Front Door: Tensor9 provisions a Front Door profile and endpoint that front your origin, with an origin group and origins pointing at your backend; Microsoft operates the edge |
| DNS cutover | Content delivery | Supported | Common | Supported Route 53 aliases point to the target frontend. CloudFront domain\_name, arn and hosted\_zone\_id are not target identifiers; unsupported output references are removed and active configuration references cause a build error. |
| Custom domains + TLS | Domains & TLS | Partial | Most usage | Custom domains use target-managed certificates. Complete domain validation before cutover; an ACM ARN supplies no certificate material. Minimum TLS-version and SSL support-method differences are reported. |
| Edge logic (Lambda\@Edge / CloudFront Functions) | Edge logic | Out of scope | Most usage | Rules engine conditions can express headers, URL changes and redirects, but cannot run arbitrary function code. Unsupported associations are omitted and reported; standalone functions cause a build error. |
| Policy & monitoring facets (cache / origin-request / response-headers policies, monitoring subscription) | Facets | Out of scope | Full surface | these resources are not supported by this mapping; the build reports an error |
| Origins | Origins | Partial | Common | Origin hosts become members of an origin group. Confirm unresolved addresses and review differences between source failover conditions and Front Door health-probe selection. |
#### How it works
Tensor9 translates the CloudFront distribution into an Azure Front Door Premium profile, endpoint, origin group, origins, route and rule set. Microsoft operates the edge cache and serves requests. The customer controls the origin and the target configuration.
A custom DNS name can remain after its record and certificate are ready for Front Door. The CloudFront-generated hostname and cached objects do not transfer. Expect origin requests as the new cache fills.
#### Origins and routing
The endpoint supplies the public host. A route associates that endpoint with an origin group and the rules applied to requests. Each declared origin host becomes an origin; the group uses health probes to select available origins. This differs from CloudFront origin-group failover, so review failover conditions and origin selection.
Confirm any origin address that compilation cannot resolve. An S3 origin follows the selected storage mapping to the target endpoint. Validate the origin host header, TLS and network access against that endpoint rather than retaining an AWS-specific address.
#### Origin access
Front Door Premium can reach supported origins through Private Link. For a Kubernetes service, provide the compatible Azure Private Link service and load balancer arrangement, then approve Front Door's managed private endpoint. An arbitrary private cluster is not reachable merely because the profile uses Premium.
Traffic reaches the origin through a private connection over Microsoft's network. The origin still needs to accept that private traffic, and the platform team must close any unwanted public or alternate access paths. Private Link does not require a connector process inside the application cluster.
CloudFront OAI and OAC govern authenticated access to supported origins; OAC is not a general private-network connection. The target requires the access controls appropriate to its origin type. Neither Standard nor Premium verifies existing CloudFront viewer signed-URL or signed-cookie signatures; that viewer-authorization scheme needs a separate application design.
#### Web application firewall
A Front Door firewall policy contains the target WAF rules; a security policy attaches it to the endpoint. Supported custom AWS match and rate-limit rules are expressed using Front Door conditions and actions, and geographic restrictions use country-match rules. An AWS `web_acl_id` is a reference, not an Azure policy.
Premium supports Microsoft-managed WAF rule sets and bot protection as well as custom rules. AWS managed groups are not the same rule sets: select the corresponding target protections and test their effect. Complex AWS conditions without a matching Front Door expression remain a reported limitation.
#### Cache behavior
Default and ordered cache behaviors become rules matched by path. A route-configuration override sets the cache duration and query-string behavior; compression is configured on the route. Check the query parameters included in the cache key, especially for personalized responses.
CloudFront's minimum, default and maximum TTLs do not map to three independent Front Door settings. The default TTL supplies the single cache duration; separate minimum and maximum constraints are reported during compilation. Forwarded-header lists and allowed-method lists also have differences. Verify the effective cache key and request handling rather than assuming that two source requests always remain distinct.
#### Rules and application code
The Rules engine can express header changes, URL or path rewrites and redirects. Those behaviors can be implemented with target rule conditions and actions on both Front Door tiers; arbitrary Lambda\@Edge or CloudFront Functions code does not run there.
Function associations that cannot be translated are omitted and reported. A standalone CloudFront function without a supported translation causes a build error. Move required application logic to a suitable runtime before cutover. CloudFront field-level encryption also has no equivalent in this mapping.
#### Domains and certificates
Each alias becomes a Front Door custom domain with a managed certificate. Complete domain validation and wait for certificate readiness before updating DNS. Front Door issues and renews that certificate; it does not copy an ACM certificate from its ARN. Review minimum TLS version and SSL support-method differences.
Supported Route 53 aliases are updated to the Front Door endpoint. CloudFront `domain_name`, `arn` and `hosted_zone_id` do not become Azure identifiers. References without a target equivalent are removed from outputs or rejected in active configuration. Update external DNS consumers and allowlists separately.
#### Operations and remaining limits
Azure's edge locations replace CloudFront price classes. Use Azure Monitor and diagnostic settings for access logs and metrics; an AWS monitoring subscription is not a Front Door setting. Review cache hit rates, origin health, latency and errors after cutover.
Cache, origin-request and response-headers policy resources need a supported distribution attachment and translation. Standalone policies, monitoring subscriptions and origin-access identities without one cause a build error. Resolve those resources together with the behavior they configure.
Provider reference: [securing Front Door origins](https://learn.microsoft.com/en-us/azure/frontdoor/origin-security).
### Azure Front Door Standard
| Operation | Area | Support | Depth | Notes |
| ------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Origin access & signed URLs | Access control | Partial | Most usage | Standard reaches public origins. Restrict origin network access and validate configured origin headers; a secret header is not private networking. Private Link requires Premium. Existing CloudFront viewer signatures are not verified. |
| Signed URLs | Access control | Out of scope | Most usage | CloudFront trusted-signer and trusted-key-group signed URLs are a different request authorization scheme (Front Door cannot verify CloudFront's RSA or ECDSA signatures), so signed URLs have no counterpart and are flagged during the build |
| WAF / geo restrictions | Access control | Partial | Most usage | Custom match, rate-limit and country rules become target WAF rules attached through a security policy. Microsoft-managed rules and bot protection require Premium. Unsupported source conditions are reported. |
| Cache behaviors | Cache | Partial | Most usage | Path-matched rules retain cache duration and query-string behavior. CloudFront default TTL supplies a single duration; separate minimum/maximum constraints and per-behavior header/method differences are reported. |
| Content delivery | Content delivery | Supported | Common | served on Azure Front Door Standard: Tensor9 provisions a Front Door Standard profile and endpoint that front your origin, with an origin group and origins pointing at your backend; Microsoft operates the edge |
| DNS cutover | Content delivery | Supported | Common | Supported Route 53 aliases point to the target frontend. CloudFront domain\_name, arn and hosted\_zone\_id are not target identifiers; unsupported output references are removed and active configuration references cause a build error. |
| Custom domains + TLS | Domains & TLS | Partial | Most usage | Custom domains use target-managed certificates. Complete domain validation before cutover; an ACM ARN supplies no certificate material. Minimum TLS-version and SSL support-method differences are reported. |
| Declarative edge logic (Rules engine) | Edge logic | Partial | Most usage | Header, URL and redirect behavior can use Rules engine conditions and actions. Arbitrary function code, external calls and request-body inspection are outside this translation; unsupported associations are reported and standalone functions rejected. |
| Policy & monitoring facets (standalone cache / origin-request / response-headers policies, monitoring subscription) | Facets | Out of scope | Full surface | a cache, origin-request, or response-headers policy referenced by a behavior is re-expressed in that behavior's route and rules; a standalone policy claimed by no distribution, and the monitoring subscription, have no compiler and cause a build error |
| Origins | Origins | Partial | Common | Origin hosts become members of an origin group. Confirm unresolved addresses and review differences between source failover conditions and Front Door health-probe selection. Standard requires a public origin endpoint. |
#### How it works
Tensor9 translates the CloudFront distribution into an Azure Front Door Standard profile, endpoint, origin group, origins, route and rule set. Microsoft operates the edge cache and serves requests. The customer controls the origin and the target configuration.
A custom DNS name can remain after its record and certificate are ready for Front Door. The CloudFront-generated hostname and cached objects do not transfer. Expect origin requests as the new cache fills.
#### Origins and routing
The endpoint supplies the public host. A route associates that endpoint with an origin group and the rules applied to requests. Each declared origin host becomes an origin; the group uses health probes to select available origins. This differs from CloudFront origin-group failover, so review failover conditions and origin selection.
Confirm any origin address that compilation cannot resolve. An S3 origin follows the selected storage mapping to the target endpoint. Validate the origin host header, TLS and network access against that endpoint rather than retaining an AWS-specific address.
#### Origin access
Front Door Standard needs an origin reachable through a public endpoint; it does not support Private Link origins. Use Premium with a compatible Private Link arrangement when the origin must have no public endpoint.
Restrict direct access to a public origin. The backend can validate a shared secret inserted in an origin request header, but that secret must be protected and rotated. Azure's origin-security guidance also combines the `AzureFrontDoor.Backend` network selector with validation of the expected `X-Azure-FDID` value. A header alone is not network isolation.
CloudFront OAI and OAC govern authenticated access to supported origins; OAC is not a general private-network connection. The target requires the access controls appropriate to its origin type. Neither Standard nor Premium verifies existing CloudFront viewer signed-URL or signed-cookie signatures; that viewer-authorization scheme needs a separate application design.
#### Web application firewall
A Front Door firewall policy contains the target WAF rules; a security policy attaches it to the endpoint. Supported custom AWS match and rate-limit rules are expressed using Front Door conditions and actions, and geographic restrictions use country-match rules. An AWS `web_acl_id` is a reference, not an Azure policy.
Standard supports custom match rules, rate limits and country-based rules. Microsoft-managed rule sets and bot protection require Premium. A source web ACL that depends on managed groups therefore needs a different protection plan; custom rules alone do not reproduce those groups.
#### Cache behavior
Default and ordered cache behaviors become rules matched by path. A route-configuration override sets the cache duration and query-string behavior; compression is configured on the route. Check the query parameters included in the cache key, especially for personalized responses.
CloudFront's minimum, default and maximum TTLs do not map to three independent Front Door settings. The default TTL supplies the single cache duration; separate minimum and maximum constraints are reported during compilation. Forwarded-header lists and allowed-method lists also have differences. Verify the effective cache key and request handling rather than assuming that two source requests always remain distinct.
#### Rules and application code
The Rules engine can express header changes, URL or path rewrites and redirects. Those behaviors can be implemented with target rule conditions and actions on both Front Door tiers; arbitrary Lambda\@Edge or CloudFront Functions code does not run there.
Function associations that cannot be translated are omitted and reported. A standalone CloudFront function without a supported translation causes a build error. Move required application logic to a suitable runtime before cutover. CloudFront field-level encryption also has no equivalent in this mapping.
#### Domains and certificates
Each alias becomes a Front Door custom domain with a managed certificate. Complete domain validation and wait for certificate readiness before updating DNS. Front Door issues and renews that certificate; it does not copy an ACM certificate from its ARN. Review minimum TLS version and SSL support-method differences.
Supported Route 53 aliases are updated to the Front Door endpoint. CloudFront `domain_name`, `arn` and `hosted_zone_id` do not become Azure identifiers. References without a target equivalent are removed from outputs or rejected in active configuration. Update external DNS consumers and allowlists separately.
#### Operations and remaining limits
Azure's edge locations replace CloudFront price classes. Use Azure Monitor and diagnostic settings for access logs and metrics; an AWS monitoring subscription is not a Front Door setting. Review cache hit rates, origin health, latency and errors after cutover.
Cache, origin-request and response-headers policy resources need a supported distribution attachment and translation. Standalone policies, monitoring subscriptions and origin-access identities without one cause a build error. Resolve those resources together with the behavior they configure.
Provider reference: [securing Front Door origins](https://learn.microsoft.com/en-us/azure/frontdoor/origin-security).
## On DigitalOcean
### DigitalOcean CDN
| Operation | Area | Support | Depth | Notes |
| -------------------------------------------------------------------------------------------------------- | -------------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Origin access (OAI / OAC) | Access control | Out of scope | Most usage | origin access controls are omitted and reported during the build; a standalone origin access identity has no compiler and causes a build error |
| WAF / geo restrictions / signed URLs | Access control | Out of scope | Most usage | the WAF association and geo restrictions drop and are reported during the build; trusted signers / key groups drop under the cache-behavior issue |
| Cache behaviors | Caching | Partial | Common | the default behavior's default TTL is applied; other settings (path patterns, protocol policy, methods, forwarded values, min/max TTL) drops and are reported during the build |
| Content delivery | Data plane | Supported | Common | DigitalOcean's CDN edge serves the traffic from a CDN endpoint fronting one origin FQDN; only the first origin, default TTL, and first custom domain are mapped |
| Custom domains + TLS | Domains & TLS | Partial | Most usage | the first alias becomes the CDN custom domain; any further aliases are left behind; the viewer certificate drops with a surfaced operator step to attach a DigitalOcean-managed certificate |
| Edge logic (Lambda\@Edge / CloudFront Functions) | Edge logic | Out of scope | Most usage | associations are not translated, and drop under the blanket cache-behavior issue; a standalone cloudfront\_function resource has no compiler and causes a build error |
| Policy & monitoring facets (cache / origin-request / response-headers policies, monitoring subscription) | Facets | Out of scope | Full surface | these resources are not supported by this mapping; the build reports an error |
| Logging / price class / http version / root object | Observability | Out of scope | Full surface | dropped and are reported during the build |
| Origins | Origins | Partial | Common | the first origin's literal domain becomes the CDN origin; an expression-based origin becomes a configuration value you must confirm; additional origins and origin groups drop and are reported during the build |
#### How it works
Tensor9 maps a CloudFront distribution to one `digitalocean_cdn` endpoint. It copies the **first origin's domain**, the default behavior's **default TTL**, and the **first custom domain**. DigitalOcean's edge serves the requests directly.
Additional origins, ordered cache behaviors, WAF rules, and edge functions do not transfer. The build reports unsupported settings. Attach the DigitalOcean-managed certificate after the endpoint is provisioned.
Your customers reach the same content; the CloudFront distribution collapses to a single thin DigitalOcean CDN endpoint over your first origin's domain, which DigitalOcean's edge serves. Tensor9 compiles it at release and is not in the serving path.
#### Supported configuration
The first origin's domain becomes `origin`, the default behavior's default TTL becomes `ttl`, and the first alias becomes `custom_domain`. The diagram shows how these three settings map. The limitations below list the settings that are omitted and reported during the build.
The distinct DigitalOcean move: your CloudFront distribution funnels down to a single CDN endpoint that has three fields: the first origin becomes origin , the default TTL becomes ttl , and the first alias becomes custom\_domain . Additional settings falls away as a flagged drop.
#### How traffic flows
Once built, your customers' requests reach **DigitalOcean's CDN edge**, which serves from your **first origin**, the bucket or app behind the distribution. DigitalOcean operates the edge and Tensor9 is not in the serving path. A **Route 53 alias** that pointed at the distribution **retargets to the `digitalocean_cdn` endpoint**, so the name your customers resolve is unchanged; only its target moves.
What consumers depend on survives: the CDN's **endpoint and its id** are passed through to anything that read them. What is left behind is the distribution's own edge identity: `domain_name`, `arn`, and `hosted_zone_id` have no DigitalOcean equivalent. A reference to one resolves only **inside an output** (the output is removed with a flagged issue); anywhere else it **causes a build error** rather than resolving to the wrong host.
Requests reach DigitalOcean's CDN edge, which serves from your first origin. A Route 53 alias that pointed at the distribution retargets to the digitalocean\_cdn endpoint, and the endpoint and its id are passed through to your consumers.
#### Limitations
△ Where CloudFront and DigitalOcean CDN diverge, limitations
* **Additional origins & origin groups.** Only your first origin's domain becomes the CDN origin; additional origins and origin-group failover drop and are flagged during the build.
* **Path patterns & ordered behaviors.** A distribution routes by path pattern across ordered behaviors; the CDN endpoint has one behavior, so the patterns and their ordering drop and are flagged during the build.
* **Per-behavior and min/max TTLs.** Only the default behavior's default TTL becomes the endpoint's `ttl`; per-behavior TTLs and the separate minimum and maximum TTLs drop and are flagged during the build.
* **Allowed & cached methods.** The allowed- and cached-method lists have no knob on the CDN endpoint; they drop and are flagged during the build.
* **The redirect-to-HTTPS viewer policy.** The DigitalOcean CDN endpoint serves over HTTPS by default; CloudFront's configurable viewer-protocol-policy knob (redirect-to-HTTPS / HTTPS-only) is not an endpoint setting here, so the knob drops and is flagged during the build.
* **WAF & geo restrictions.** An attached AWS WAF web ACL and geo restrictions have no attach point on the CDN endpoint; they drop and are flagged during the build.
* **Origin access & signed URLs.** Origin access (OAI / OAC) and trusted-signer signed URLs drop; the origin-access companion is removed with a flagged issue, and a standalone origin access identity causes a build error.
* **Edge functions.** Lambda\@Edge and CloudFront Functions associations have no edge-compute analog on DigitalOcean's CDN; they drop, and a standalone function causes a build error.
* **Price class, logging, HTTP version, root object.** DigitalOcean serves from its own edge footprint, so there is no price-class tier selector; the logging config, HTTP-version toggle, and default-root-object rewrite drop and are flagged during the build.
* **The viewer certificate has no equivalent.** The ACM viewer certificate has no equivalent; the endpoint takes a DigitalOcean-managed certificate for its custom domain instead.
#### Other considerations
* **DNS cutover.** A Route 53 alias that pointed at the distribution retargets to the digitalocean\_cdn endpoint; the name your customers resolve is unchanged, only its target moves. Cutting that record over is a step you own, and the CDN's endpoint and its id are passed through to any consumer that read them.
* **Attach the managed certificate.** The endpoint takes a DigitalOcean-managed certificate for its custom domain, and the build flags an operator step to attach it, a one-time action you complete after the CDN is provisioned.
* **One distribution maps to one endpoint.** The CDN endpoint stands in for a single distribution. Where a distribution cannot collapse cleanly (a standalone edge function or origin access identity with no distribution to attach to, or several distributions spread across modules), the build stops rather than guessing, and asks you to restructure so one distribution maps to one endpoint.
## On Google Cloud
### Cloud CDN
| Operation | Area | Support | Depth | Notes |
| -------------------------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Origin access (OAI / OAC) | Access control | Partial | Most usage | configure private bucket IAM or the HTTP origin's access controls separately. Attaching a backend to the load balancer does not prevent direct access. An origin access identity without a supported translation causes a build error |
| Signed URLs | Access control | Partial | Most usage | Cloud CDN uses HMAC signed URLs and cookies. Replace the CloudFront RSA/ECDSA signer and issue new URLs; configure origin access separately. |
| WAF & geo restrictions | Access control | Out of scope | Most usage | Automatic WAF/geo translation is outside this mapping. Configure Cloud Armor separately; backend buckets support a narrower edge security policy than backend services. |
| Cache behaviors | Cache | Partial | Most usage | Backend cdn\_policy retains cache mode, default/max/client TTLs, negative caching and cache-key settings. URL-map matches select paths; per-behavior header forwarding and method differences are reported. |
| Content delivery | Content delivery | Supported | Common | served on Google Cloud CDN: enable\_cdn = true plus a cdn\_policy on the external load balancer's backend inside your Google Cloud project; the load balancer fronts it with a URL map, HTTPS proxy, and forwarding rule |
| DNS cutover | Content delivery | Supported | Common | Supported Route 53 aliases point to the target frontend. CloudFront domain\_name, arn and hosted\_zone\_id are not target identifiers; unsupported output references are removed and active configuration references cause a build error. |
| Custom domains + TLS | Domains & TLS | Partial | Most usage | Custom domains use target-managed certificates. Complete domain validation before cutover; an ACM ARN supplies no certificate material. Minimum TLS-version and SSL support-method differences are reported. |
| Edge logic (Lambda\@Edge / CloudFront Functions) | Edge logic | Out of scope | Most usage | Cloud CDN does not run Lambda\@Edge or CloudFront Functions code. Unsupported associations are omitted and reported; standalone functions cause a build error. |
| Policy & monitoring facets (cache / origin-request / response-headers policies, monitoring subscription) | Facets | Out of scope | Full surface | these resources are not supported by this mapping; the build reports an error |
| Origins | Origins | Partial | Common | The first HTTP origin becomes a backend service; a bucket origin becomes a backend bucket. Confirm unresolved origin addresses. Additional origins and origin groups are omitted and reported. |
#### How it works
Tensor9 translates the CloudFront distribution into a Google external Application Load Balancer with Cloud CDN enabled on its backend. A forwarding rule supplies the public address, an HTTPS proxy terminates TLS, and a URL map selects the backend. Google operates the cache and serves requests; Tensor9 provisions the resources in the customer's project.
A custom DNS name can remain in use after its record points to the new frontend and its certificate is ready. The CloudFront-generated hostname and existing cached objects do not move to Google. Plan for cache misses during cutover.
#### Origins and cache configuration
A bucket origin uses a CDN-enabled backend bucket; a custom HTTP origin uses a backend service. Confirm any origin address that compilation cannot resolve. This mapping selects the first origin; additional origins and CloudFront origin-group failover require separate configuration and are reported during compilation.
Supported path behaviors become URL-map matchers. Each backend has a `cdn_policy` for cache mode, default, maximum and client TTLs, negative caching, and the cache key's host, path and query settings. Behaviors sharing a backend also share its cache policy. Check whether the source needs different policies for those paths.
The origin-headers cache mode respects the origin's `Cache-Control` instructions. For example, a policy might set default and client TTLs to 3600 seconds, a maximum of 86400 seconds, and cache a 404 response for 120 seconds; these are illustrative settings, not promised deployment defaults. Per-behavior forwarded-header lists and allowed-method lists are not fully preserved. Review the reported differences before caching authenticated or user-specific responses.
#### Origin connectivity and access
The load balancer's backend configuration identifies where requests go; being in the same project does not make an origin reachable or private. Configure the network path, firewall rules, DNS, and backend access for the selected origin type. A custom origin can be outside the project and may need additional connectivity.
CloudFront origin access control authenticates requests to supported origins; it is distinct from a private network connection. On Google, private bucket access uses the appropriate bucket IAM grant. An HTTP origin needs its own controls to reject direct or unauthorized requests. Attaching a backend to a load balancer does not, by itself, make that load balancer the only way to reach it.
Provisioning uses the deployment's Google identity. Limit that identity's resource permissions separately from the access rules governing viewer and origin requests.
#### Signed URLs and cookies
CloudFront signed URLs and cookies use a public/private key pair: RSA or ECDSA. Cloud CDN uses a shared HMAC signing key. Update the application that issues signed URLs to use the Cloud CDN format and key; previously issued CloudFront signatures will not validate there.
Viewer authorization and origin protection are separate. Configure private bucket access where applicable. For an HTTP origin, follow Google's requirements to validate signed requests and decide whether to reject unsigned requests. Adding a signing key alone does not make every path private.
#### Web application firewall
This distribution mapping does not automatically translate the AWS web ACL or geographic restrictions. Configure Google Cloud Armor separately if those controls are required.
A backend security policy supports managed WAF rules, custom rules and rate controls on a backend service. A backend bucket supports the narrower edge security policy, which does not provide the same managed-rule and rate-limiting features. Choose the policy type for the selected backend and test both allowed and blocked requests.
#### Edge functions and encryption
Cloud CDN does not execute Lambda\@Edge or CloudFront Functions code. Move application code to a suitable runtime and reconnect the request flow when that behavior is required. The translation reports omitted function associations; a standalone CloudFront function without a supported translation causes a build error.
CloudFront field-level encryption encrypts selected request fields at the edge. It is a separate feature, not a customer function runtime, and this mapping does not reproduce it.
#### Custom domains, TLS and cutover
Each supported alias receives a Google-managed certificate on the HTTPS proxy. Validate domain ownership and wait for certificate readiness before changing DNS. An ACM reference does not supply certificate material; the source minimum TLS version and SSL support method are not copied field for field. Verify the target TLS policy.
Supported Route 53 aliases are updated to the Google frontend address. CloudFront `domain_name`, `arn`, and `hosted_zone_id` are not native Google identifiers. References without a target equivalent are removed from outputs or rejected in active configuration; review consumers outside the translated stack.
#### Operations and remaining limits
Google's edge locations replace CloudFront's price-class selection. Configure Cloud Logging and Cloud Monitoring for the target; AWS access-log and additional-metrics settings are not copied as distribution attributes. Monitor cache hits, origin requests and errors after cutover.
Standalone cache, origin-request, response-headers policy, monitoring-subscription, or origin-access-identity resources that have no supported attachment cannot be translated. Review those resources and the per-behavior differences with the distribution before deployment.
Provider references: [content access control](https://docs.cloud.google.com/cdn/docs/authenticate-content) and [signed URLs](https://docs.cloud.google.com/cdn/docs/using-signed-urls).
## On Scaleway
### Scaleway Edge Services
| Operation | Area | Support | Depth | Notes |
| ------------------------------------------------ | -------------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Origin access (OAI / OAC) | Access control | Out of scope | Most usage | origin access controls are not projected |
| WAF / geo restrictions / signed URLs | Access control | Out of scope | Most usage | Edge Services HAS a waf stage, but the build does not emit one from a CloudFront WAF association; geo restrictions and signed-URL key groups have no mapping |
| Cache behaviors | Caching | Partial | Common | the default behavior's default TTL becomes the cache stage's TTL; per-path ordered cache behaviors are NOT mapped, so the default behavior applies to every path |
| Price class / HTTP version / default root object | Configuration | Out of scope | Full surface | not projected |
| Content delivery | Data plane | Supported | Common | Scaleway's edge serves the traffic through an Edge Services PIPELINE rather than a single endpoint resource: a pipeline plus a backend stage, a cache stage and a DNS stage, each its own resource |
| Custom domains + TLS | Domains & TLS | Partial | Most usage | the first alias becomes the DNS stage's domain; the viewer certificate's ACM ARN, minimum protocol version and SNI mode do not project field-for-field |
| Edge logic (Lambda\@Edge / CloudFront Functions) | Edge logic | Out of scope | Most usage | edge function associations are not translated |
| Access logging | Observability | Out of scope | Full surface | CloudFront's S3 access logging has no Edge Services stage analog - Scaleway surfaces edge logs through Cockpit instead, and the build does not wire that |
| Origins | Origins | Partial | Common | the first origin's domain becomes the backend stage's origin; an expression-based origin is threaded as a build variable you set. See the backend-stage note below - which KIND of backend the stage points at is not inferred from a hostname |
## Existing data and credentials
Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.
## Configure, tune and debug
Start with [setup](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.
