Supported environments
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
On Azure
Azure Front Door Premium
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 AWSweb_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. CloudFrontdomain_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.Azure Front Door Standard
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 theAzureFrontDoor.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 AWSweb_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. CloudFrontdomain_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.On DigitalOcean
DigitalOcean CDN
How it works
Tensor9 maps a CloudFront distribution to onedigitalocean_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 becomesorigin, 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 thedigitalocean_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
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 acdn_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. CloudFrontdomain_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.