1. Home
  2. Docs
  3. Infrastructure
  4. CloudFront


We use CloudFront for non-images CDN. For images CDN, we use Cloudimage.

Distribution Configuration

Viewer Protocol Policy: Redirect HTTP to HTTPS. This is standard now that even .app domains requires it.


Create cache policy WordPressCachePolicy. Please ensure you whitelist these headers, otherwise apps will not work correctly:

Object Caching: Customize.

Cache key contents > Cookies > All-Except: (will also need session affinity in Kubernetes nginx-ingress)

  • __utm*
  • _ga

Below is a list of cookies that WordPress Core uses. However, other plugins especially WooCommerce, Dokan, etc. may use other cookies. That is why the default recommendation is to use All-Except for cookies cache key.

  • wordpress_*
  • wp-settings-*
  • commenter_*

Query String Forwarding and Caching: All-Except:

  • utm_source
  • utm_medium
  • utm_campaign
  • utm_term
  • utm_content

Origin request policy: Managed-AllViewer

Smooth Streaming: No. (only set to Yes if streaming video from S3)


WordPress/WooCommerce Configuration & Visual Editor

To reduce chances of getting stuck in WordPress Maintenance Mode (“Briefly unavailable for scheduled maintenance. Check back in a minute.”):

  1. Go to AWS CloudFront, edit the origin
  2. Set Origin response timeout to 60 seconds.

Note that you will get stuck anyway if the update operation takes more than 60 seconds. A better way is to use WP CLI.

WordPress/WooCommerce requires User-Agent header to be passed by CloudFront in order to enable the visual editor. There are several ways to work-around this, but our best practice is to add additional behavior for path pattern /wp-admin/*.

WebSocket (and SSL)

CloudFront supports WebSocket by default. However be aware there is a potential issue with nginx-ingress.


Someday we will move to StackPath CDN and WAF. However, before that time, configuring AWS WAF is recommended as follows. (Note that the entire managed rule groups below costs $8/mo+WAF costs)

For WordPress/WooCommerce, use AWSManagedRulesCommonRuleSet and AWSManagedRulesWordPressRuleSet. But with the default rules you will get:

  • 403 Error when accessing /wp-json (weDocs REST API) blocked by GenericRFI_BODY
  • 403 Error when accessing: /wp-admin/post.php?post=7733&action=edit blocked by SizeRestrictions_BODY
  • 403 Error when accessing: /wp-admin/async-upload.php blocked by SizeRestrictions_BODY
  • 403 Error when Publishing WooCommerce product: /wp-admin/post.php blocked by AWS#AWSManagedRulesCommonRuleSet#CrossSiteScripting_BODY
  • 403 Error for Xendit callback /?xendit_mode=xendit_invoice_callback blocked by AWS#AWSManagedRulesCommonRuleSet#NoUserAgent_HEADER
  • 403 Error when accessing: /wp-admin/admin-ajax.php blocked by AWS-AWSManagedRulesCommonRuleSet > GenericLFI_BODY
  • 403 Error when accessing: /wp-login.php?redirect_to=https%3A%2F%2Fprodukindo.com%2Fwp-admin%2F&reauth=1 blocked by AWS-AWSManagedRulesCommonRuleSet > GenericRFI_QUERYARGUMENTS


  • You need to exclude (i.e. “Override rules action”) in AWS-AWSManagedRulesCommonRuleSet: GenericRFI_BODY, SizeRestrictions_BODY, CrossSiteScripting_BODY, NoUserAgent_HEADER, GenericLFI_BODY, GenericRFI_QUERYARGUMENTS
  • You cannot use AdminProtectionRuleSet because it only has one rule (AWS#AWSManagedRulesAdminProtectionRuleSet#AdminProtection_URIPATH) and blocks WordPress Admin for editing posts.

Some issues with AWS WAF:

  1. Cost: $1/managed rule and $1/custom rule, plus AWS WAF capacity.
  2. Only sampling: It’s not possible to view latest blocked requests directly, just sampled requests. Logging can only be enabled by setting up Kinesis.
  3. Managed rules are opaque. We can’t know why they’re blocking the requests.
  4. The managed rules seem to be too strict.

Was this article helpful to you? Yes No

How can we help?