Coverage by target cloud
How the targets compare
Each row compares a capability of CloudFront with its adaptation on each target. A dash means this row is not stated for that target.Infrastructure-only adaptation
On Google Cloud
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.
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 and signed URLs.On Azure
Via 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.Via 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.