Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of CloudFront with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Tensor9 maps your CloudFront distribution to a Google external Application Load Balancer with Cloud CDN turned on for its backend. A forwarding rule provides the public address, an HTTPS proxy terminates TLS, and a URL map picks the backend. Tensor9 creates these resources in your Google Cloud project; Google operates the cache that answers requests. Your custom domain name keeps working once its DNS record points at the new frontend and its certificate is ready. The CloudFront-generated hostname and the objects already in the CloudFront cache do not move to Google, so expect cache misses during cutover.
A request to your custom domain reaches the Google load balancer, where Cloud CDN answers from cache or forwards the request to the origin.A request to your custom domain reaches the Google load balancer, where Cloud CDN answers from cache or forwards the request to the origin.

​
Origins and caching

A bucket origin becomes a backend bucket with Cloud CDN turned on; a custom HTTP origin becomes a backend service. If the build cannot work out an origin’s address, you must confirm it. Only the first origin is mapped: additional origins and CloudFront origin-group failover need separate configuration, and the build reports them. Supported path behaviors become URL map path matchers. Each backend has a cdn_policy that sets the cache mode, the default, maximum and client TTLs, negative caching, and whether the host, path and query string are part of the cache key. Behaviors that share a backend share its cache policy, so check whether those paths need different policies. The cache mode that follows origin headers respects the origin’s Cache-Control instructions. For example, a policy might set default and client TTLs of 3600 seconds, a maximum of 86400 seconds, and cache a 404 response for 120 seconds; these are illustrations, not deployment defaults. Per-behavior forwarded-header and allowed-method lists are not fully kept. Review the reported differences before you cache authenticated or user-specific responses.

​
Origin access

The load balancer’s backend says where requests go. Being in the same project does not make an origin reachable or private. You configure the network path, firewall rules, DNS and backend access for the origin type you use. A custom origin can sit outside the project and may need extra connectivity. CloudFront origin access control (OAC) authenticates requests to supported origins; it is not a private network connection. On Google, private bucket access uses the bucket IAM grant for the load balancer. An HTTP origin needs its own controls to reject direct or unauthorized requests. Attaching a backend to a load balancer does not make the load balancer the only way to reach it. Tensor9 creates the resources with the deployment’s Google identity. Limit that identity’s permissions separately from the access rules for viewer and origin requests.

​
Signed URLs and cookies

CloudFront signs URLs and cookies with an RSA or ECDSA key pair. Cloud CDN uses a shared HMAC signing key instead. You must update the application that issues signed URLs to use the Cloud CDN format and key. URLs already signed for CloudFront do not validate on Cloud CDN. Checking viewers and protecting the origin are separate jobs. Configure private bucket access where it applies. For an HTTP origin, follow Google’s requirements for validating signed requests, and decide whether to reject unsigned ones. Adding a signing key does not make every path private. Google documents content access control and signed URLs.
Your application signs a URL with the Cloud CDN key, and Cloud CDN checks the signature. Access to the origin needs its own controls.Your application signs a URL with the Cloud CDN key, and Cloud CDN checks the signature. Access to the origin needs its own controls.

​
Web application firewall

The AWS web ACL and geographic restrictions are not translated. If you need those controls, configure Google Cloud Armor yourself. A backend security policy on a backend service supports managed WAF rules, custom rules and rate limiting. A backend bucket supports only the narrower edge security policy, which lacks those managed-rule and rate-limiting features. Choose the policy type for your backend and test both allowed and blocked requests.

​
Custom domains and TLS

Each supported alias gets a Google-managed certificate on the HTTPS proxy. Validate domain ownership and wait until the certificate is ready before you change DNS. An ACM reference supplies no certificate, and the CloudFront minimum TLS version and SSL support method are not copied one for one, so check the TLS policy on the HTTPS proxy. Supported Route 53 aliases are updated to the Google frontend address, and a reference to the distribution’s domain_name or id now points at the frontend too. arn and hosted_zone_id have no Google Cloud equivalent: a reference in an output is removed, and a reference anywhere else causes a build error. Review consumers outside this stack.

​
Limitations

Where CloudFront and Cloud CDN differ
  • Edge function code is not supported. Cloud CDN does not run Lambda@Edge or CloudFront Functions code. A distribution that associates either causes a build error. Move the code to a suitable runtime and reconnect it to the request flow.
  • CloudFront signed URLs are not supported. A cache behavior that names CloudFront trusted signers or key groups causes a build error. Set up Cloud CDN signing with its own HMAC key and issue new URLs.
  • Field-level encryption is not supported. CloudFront field-level encryption encrypts selected request fields at the edge. Cloud CDN has no equivalent, and a distribution that uses it causes a build error.
  • WAF and geographic restrictions are not translated. The AWS web ACL and country restrictions are not kept. Configure Cloud Armor for the backend type you use.
  • Only the first origin is mapped. Additional origins and origin-group failover are reported and left out. Configure them separately on Google Cloud.
  • Cache behaviors behave differently. Behaviors that share a backend share one cache policy. Per-behavior forwarded-header and allowed-method lists are not fully kept, and the build reports each difference.
  • Price classes are not supported. Cloud CDN serves from Google’s own edge locations, so a CloudFront price class is dropped.
  • You must attach policy resources to a distribution. A standalone cache, origin-request or response-headers policy, a monitoring subscription, or an origin access identity with no supported attachment cannot be translated and causes a build error.

​
Other considerations

  • Before going live. Confirm origin addresses, set up origin access and Cloud Armor, validate each custom domain and wait for its certificate, then change DNS. Review the reported per-behavior differences together with the distribution.
  • What to monitor. Configure Cloud Logging and Cloud Monitoring for Cloud CDN; AWS access-log and additional-metrics settings are not copied. After cutover, watch cache hits, origin requests and errors.
  • Moving from AWS. Nothing in the CloudFront cache is copied. Make sure the origin can take the extra load while the cache fills.

​
On Azure

​
Via Azure Front Door Premium

​
How it works

Tensor9 maps your CloudFront distribution to an Azure Front Door Premium profile with an endpoint, an origin group, origins, a route and a rule set. Microsoft operates the edge cache that answers your customers’ requests. You control the origin and Front Door’s configuration, and Tensor9 is not in the request path. Your custom domain names keep working once their DNS records and certificates are ready on Front Door. The CloudFront-generated hostname and the objects already in the CloudFront cache do not move. Expect more requests to reach your origin while the new cache fills.
A request to your custom domain reaches Front Door, which applies the route and cache rules and sends cache misses to a healthy origin in the origin group.A request to your custom domain reaches Front Door, which applies the route and cache rules and sends cache misses to a healthy origin in the origin group.

​
Origins and routing

Front Door’s endpoint provides the public hostname. A route connects the endpoint to an origin group and to the rules applied to each request. Each origin host in the distribution becomes an origin in the group, and Front Door uses health probes to choose an available origin. This is not the same as CloudFront origin-group failover, so check how failover and origin selection behave for your traffic. If the build cannot work out an origin’s address, you must confirm it. An S3 origin points at the storage endpoint that the S3 bucket maps to in this deployment. Check the origin host header, TLS and network access against that endpoint; do not keep an AWS-specific address.

​
Origin access

Front Door Premium can reach supported origins through Private Link. Traffic then travels to the origin over a private connection on Microsoft’s network, and no connector process runs inside your application cluster. For a Kubernetes service, you provide a compatible Azure Private Link service and load balancer, then approve Front Door’s managed private endpoint. Choosing Premium does not by itself make an arbitrary private cluster reachable. The origin must accept the private traffic, and your platform team must close any public or alternate paths to the origin that you do not want. CloudFront origin access identity (OAI) and origin access control (OAC) authenticate requests to supported origins; OAC is not a private network connection. On Front Door, use the access controls that suit each origin type. Microsoft describes them in securing Front Door origins.
Front Door Premium reaches a supported origin through an approved Private Link connection, and the origin checks the request.Front Door Premium reaches a supported origin through an approved Private Link connection, and the origin checks the request.

​
Web application firewall

The distribution’s WAF rules go into a Front Door firewall policy, which a security policy attaches to the endpoint. Supported AWS custom match and rate-limit rules become Front Door conditions and actions, and a geographic restriction becomes a country-match rule. An AWS web_acl_id only refers to an AWS web ACL; it does not become an Azure policy on its own. Premium supports Microsoft-managed WAF rule sets and bot protection as well as custom rules. AWS managed rule groups are not the same rule sets: choose the matching Front Door protections and test their effect. The build reports any complex AWS condition that has no matching Front Door expression.

​
Cache behavior

The default and ordered cache behaviors become rules matched by path. A route configuration override sets each rule’s cache duration and query-string behavior, and compression is set on the route. Check which query parameters are part of the cache key, especially for personalized responses. Front Door has one cache duration where CloudFront has minimum, default and maximum TTLs. The default TTL becomes the cache duration, and the build reports the separate minimum and maximum. Forwarded-header lists and allowed-method lists also differ. Check the effective cache key and request handling; do not assume that two requests CloudFront kept apart stay separate.

​
Domains and certificates

Each alias becomes a Front Door custom domain with a certificate that Front Door issues and renews. Front Door does not copy an ACM certificate from its ARN. Complete domain validation and wait until the certificate is ready before you change DNS. The minimum TLS version and SSL support method differ, so check them. Supported Route 53 aliases are updated to point at Front Door’s endpoint, and a reference to the distribution’s domain_name or id now points at the endpoint too. arn and hosted_zone_id have no Azure equivalent: a reference in an output is removed, and a reference anywhere else causes a build error. Update DNS consumers and allowlists outside the stack yourself.

​
Limitations

Where CloudFront and Front Door Premium differ
  • Edge function code is not supported. Front Door does not run Lambda@Edge or CloudFront Functions code. A distribution that associates either causes a build error. Express header changes, URL rewrites and redirects as Front Door rules, and move other logic to a suitable runtime before cutover.
  • CloudFront signed URLs and cookies are not supported. Front Door cannot check CloudFront’s RSA or ECDSA signatures. A cache behavior that uses trusted signers or key groups causes a build error, and viewer authorization needs a separate application design.
  • Field-level encryption is not supported. A distribution that uses CloudFront field-level encryption causes a build error.
  • TTLs behave differently: one cache duration per rule. The default TTL becomes the cache duration. Separate minimum and maximum TTLs, including a minimum above the default, are reported and not enforced.
  • Custom error responses behave differently. A CloudFront custom error response, such as serving /index.html for a 404, becomes a URL rewrite applied to the request rather than to the origin’s status code. Check your single-page-app routes.
  • Price classes are not supported. Front Door serves from Azure’s own edge locations, so a CloudFront price class is dropped.
  • You must attach policy resources to a distribution. A standalone cache, origin-request or response-headers policy, a monitoring subscription, or an origin access identity with no supported attachment causes a build error.

​
Other considerations

  • Before going live. Confirm origin addresses, approve the Private Link connection where you use one, validate each custom domain and wait for its certificate, then change DNS. Check that the origin cannot be reached by a path that bypasses Front Door.
  • What to monitor. Use Azure Monitor and diagnostic settings for access logs and metrics; an AWS monitoring subscription is not a Front Door setting. After cutover, watch cache hit rate, origin health, latency and errors. Test allowed and blocked requests against the firewall policy.
  • Moving from AWS. Nothing in the CloudFront cache is copied. Make sure the origin can take the extra load while Front Door’s cache fills. Origin data moves through its own service’s mapping.

​
Via Azure Front Door Standard

​
How it works

Tensor9 maps your CloudFront distribution to an Azure Front Door Standard profile with an endpoint, an origin group, origins, a route and a rule set. Microsoft operates the edge cache that answers your customers’ requests. You control the origin and Front Door’s configuration, and Tensor9 is not in the request path. Your custom domain names keep working once their DNS records and certificates are ready on Front Door. The CloudFront-generated hostname and the objects already in the CloudFront cache do not move. Expect more requests to reach your origin while the new cache fills.
A request to your custom domain reaches Front Door, which applies the route and cache rules and sends cache misses to a healthy origin in the origin group.A request to your custom domain reaches Front Door, which applies the route and cache rules and sends cache misses to a healthy origin in the origin group.

​
Origins and routing

Front Door’s endpoint provides the public hostname. A route connects the endpoint to an origin group and to the rules applied to each request. Each origin host in the distribution becomes an origin in the group, and Front Door uses health probes to choose an available origin. This is not the same as CloudFront origin-group failover, so check how failover and origin selection behave for your traffic. If the build cannot work out an origin’s address, you must confirm it. An S3 origin points at the storage endpoint that the S3 bucket maps to in this deployment. Check the origin host header, TLS and network access against that endpoint; do not keep an AWS-specific address.

​
Origin access

Front Door Standard reaches an origin only through a public endpoint; Private Link origins are not supported. If the origin must have no public endpoint, use Front Door Premium with a compatible Private Link setup. You must restrict direct access to the public origin. Azure’s guidance combines the AzureFrontDoor.Backend service tag in network rules with a check of the expected X-Azure-FDID header value. The origin can also check a shared secret that Front Door adds as an origin request header; you must protect and rotate that secret. A header check alone does not isolate the network. CloudFront origin access identity (OAI) and origin access control (OAC) authenticate requests to supported origins; OAC is not a private network connection. On Front Door, use the access controls that suit each origin type. Microsoft describes them in securing Front Door origins.
Front Door Standard sends origin requests to a public endpoint. Network rules and request checks at the origin restrict who can reach it.Front Door Standard sends origin requests to a public endpoint. Network rules and request checks at the origin restrict who can reach it.

​
Web application firewall

The distribution’s WAF rules go into a Front Door firewall policy, which a security policy attaches to the endpoint. Supported AWS custom match and rate-limit rules become Front Door conditions and actions, and a geographic restriction becomes a country-match rule. An AWS web_acl_id only refers to an AWS web ACL; it does not become an Azure policy on its own. Standard supports custom match rules, rate limits and country rules. Microsoft-managed rule sets and bot protection require Premium. If your web ACL relies on AWS managed rule groups, you need a different protection plan, because custom rules alone do not reproduce those groups.

​
Cache behavior

The default and ordered cache behaviors become rules matched by path. A route configuration override sets each rule’s cache duration and query-string behavior, and compression is set on the route. Check which query parameters are part of the cache key, especially for personalized responses. Front Door has one cache duration where CloudFront has minimum, default and maximum TTLs. The default TTL becomes the cache duration, and the build reports the separate minimum and maximum. Forwarded-header lists and allowed-method lists also differ. Check the effective cache key and request handling; do not assume that two requests CloudFront kept apart stay separate.

​
Domains and certificates

Each alias becomes a Front Door custom domain with a certificate that Front Door issues and renews. Front Door does not copy an ACM certificate from its ARN. Complete domain validation and wait until the certificate is ready before you change DNS. The minimum TLS version and SSL support method differ, so check them. Supported Route 53 aliases are updated to point at Front Door’s endpoint, and a reference to the distribution’s domain_name or id now points at the endpoint too. arn and hosted_zone_id have no Azure equivalent: a reference in an output is removed, and a reference anywhere else causes a build error. Update DNS consumers and allowlists outside the stack yourself.

​
Limitations

Where CloudFront and Front Door Standard differ
  • Edge function code is not supported. Front Door does not run Lambda@Edge or CloudFront Functions code. A distribution that associates either causes a build error. Express header changes, URL rewrites and redirects as Front Door rules, and move other logic to a suitable runtime before cutover.
  • CloudFront signed URLs and cookies are not supported. Front Door cannot check CloudFront’s RSA or ECDSA signatures. A cache behavior that uses trusted signers or key groups causes a build error, and viewer authorization needs a separate application design.
  • Field-level encryption is not supported. A distribution that uses CloudFront field-level encryption causes a build error.
  • Private origins are not supported on Standard. A distribution whose origin is locked with OAC or OAI cannot map to Standard, because Standard has no Private Link. Map it to Front Door Premium instead.
  • TTLs behave differently: one cache duration per rule. The default TTL becomes the cache duration. Separate minimum and maximum TTLs, including a minimum above the default, are reported and not enforced.
  • Custom error responses behave differently. A CloudFront custom error response, such as serving /index.html for a 404, becomes a URL rewrite applied to the request rather than to the origin’s status code. Check your single-page-app routes.
  • Price classes are not supported. Front Door serves from Azure’s own edge locations, so a CloudFront price class is dropped.
  • You must attach policy resources to a distribution. A standalone cache, origin-request or response-headers policy, a monitoring subscription, or an origin access identity with no supported attachment causes a build error.

​
Other considerations

  • Before going live. Confirm origin addresses, validate each custom domain and wait for its certificate, then change DNS. Restrict direct access to the public origin, and check that it rejects requests that do not come through Front Door.
  • What to monitor. Use Azure Monitor and diagnostic settings for access logs and metrics; an AWS monitoring subscription is not a Front Door setting. After cutover, watch cache hit rate, origin health, latency and errors. Test allowed and blocked requests against the firewall policy.
  • Moving from AWS. Nothing in the CloudFront cache is copied. Make sure the origin can take the extra load while Front Door’s cache fills. Origin data moves through its own service’s mapping.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.