CDN – Amazon CloudFront Setup

Amazon CloudFront Integration

Amazon CloudFront is AWS’s global content delivery network with edge locations in over 90 cities worldwide. Cyclone Static integrates directly with CloudFront using the AWS API — no AWS SDK installation required. When Cyclone regenerates a cached page, it automatically creates a CloudFront cache invalidation for that URL.

What You Need

  • An AWS account
  • A CloudFront Distribution in front of your WordPress origin
  • An IAM user with cloudfront:CreateInvalidation permission
  • The IAM user’s Access Key ID and Secret Access Key
  • Your CloudFront Distribution ID

Step 1: Create a CloudFront Distribution

If you haven’t set up CloudFront for your site yet:

  1. In the AWS Console, go to CloudFront → Distributions → Create distribution.
  2. Set Origin domain to your site’s domain (e.g. scifi.radio).
  3. Set Protocol to HTTPS only (or Match Viewer if your origin is HTTP).
  4. Under Cache key and origin requests, choose CachingOptimized for static assets, but for HTML pages you’ll want a behavior that includes cache bypass for logged-in users.
  5. Under Settings, add your domain name(s) under Alternate domain names (CNAMEs).
  6. Select your SSL certificate (use AWS Certificate Manager — free for CloudFront).
  7. Create the distribution. Note the Distribution ID (e.g. EDFDVBD6EXAMPLE) shown on the distribution detail page.

Already have a CloudFront distribution? Skip to Step 2 and grab your existing Distribution ID.

Step 2: Create a Least-Privilege IAM User

Never use your AWS root account credentials or a user with full admin access for a plugin integration. Create a dedicated IAM user with only the permission Cyclone needs.

  1. In the AWS Console, go to IAM → Users → Create user.
  2. Give the user a name like cyclone-static-purge.
  3. On the Permissions step, choose Attach policies directly.
  4. Instead of using an existing policy, click Create policy and enter the following JSON:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "arn:aws:cloudfront::YOUR_ACCOUNT_ID:distribution/YOUR_DISTRIBUTION_ID"
    }
  ]
}

Replace YOUR_ACCOUNT_ID with your 12-digit AWS account number (found under your account menu in the top-right corner) and YOUR_DISTRIBUTION_ID with your distribution ID. This policy grants permission to create invalidations for only this one distribution.

  1. Name the policy CycloneStaticCloudfrontInvalidation, save it, and attach it to your new user.
  2. Finish creating the user.

Step 3: Generate Access Keys

  1. Click on the user you just created.
  2. Go to the Security credentials tab.
  3. Under Access keys, click Create access key.
  4. Select Application running outside AWS as the use case.
  5. Click through to the final step where AWS shows you the key pair.
  6. Copy both the Access key ID and the Secret access key. The secret key is shown only once — save it in a password manager now.

Step 4: Configure Cyclone Static

  1. Go to Cyclone Static → Settings.
  2. Under CDN Integration, set the provider dropdown to Amazon CloudFront.
  3. Enter your Access Key ID (begins with AKIA).
  4. Enter your Secret Access Key.
  5. Enter your Distribution ID (e.g. EDFDVBD6EXAMPLE).
  6. Click Verify Connection. Cyclone creates a test invalidation for a non-existent path (/cyclone-verify) to confirm credentials and permissions are correct. This costs a trivial amount (AWS includes 1,000 free invalidation paths per month).
  7. Click Save Settings.

How Invalidation Works

When Cyclone regenerates a static file, it calls the CloudFront API to create an invalidation for that URL path. CloudFront marks the cached object as expired at all edge locations and re-fetches it from your origin on the next request.

When you click Clear All Cache, Cyclone creates a wildcard invalidation for /*, expiring all objects in the distribution.

About AWS invalidation pricing: AWS includes the first 1,000 invalidation paths per month at no charge. After that, each path costs $0.005. For most WordPress sites with active publishing, monthly invalidation costs are well under $1. High-frequency publishers on large sites should monitor AWS Cost Explorer.

Wildcard invalidations (/*) count as a single path regardless of how many files they match — so full cache clears are cheap.

CloudFront Cache Behavior Setup

For Cyclone Static to work optimally with CloudFront, your distribution’s cache behavior needs to be configured to:

  • Cache HTML responses — CloudFront defaults to not caching HTML. Set your cache behavior’s TTL settings or use a CachePolicy that allows HTML caching.
  • Forward cookies for logged-in bypass — Configure a cache policy or behavior that forwards the wordpress_logged_in_ cookie and does not cache requests that include it. This ensures logged-in users get live WordPress.

Recommended CachePolicy approach:

  1. Go to CloudFront → Policies → Cache and create a custom policy.
  2. Set minimum TTL to 0, default TTL to 86400 (1 day), maximum TTL to 604800 (1 week).
  3. Under Cache key settings, include the Accept-Encoding header (so CloudFront serves gzip or Brotli variants correctly).
  4. Attach this policy to your distribution’s default behavior.

Logged-in user bypass via Origin Request Policy or Functions:

The most reliable approach is to use a CloudFront Function or Lambda@Edge to check for the wordpress_logged_in_ cookie and return a cache miss for those requests. This is more advanced — refer to the AWS documentation on CloudFront Functions if you need this level of control. A simpler alternative: use a Cache Behavior with /wp-admin/* and /wp-login.php paths set to pass all traffic to origin, and for logged-in user detection, rely on Cyclone’s .htaccess rules on the origin to handle the bypass before CloudFront sees the user.

Security Best Practices

  • The IAM user you create should have only the cloudfront:CreateInvalidation permission, scoped to your specific distribution ARN.
  • Never commit your AWS credentials to version control.
  • Rotate the access key periodically. When rotating: create the new key, update Cyclone’s settings, verify the connection, then deactivate and delete the old key.
  • Enable AWS CloudTrail to log all CloudFront API calls for auditing.

Troubleshooting

Verify Connection fails with “Access Denied”: The IAM user lacks the cloudfront:CreateInvalidation permission, or the policy’s Resource ARN doesn’t match your distribution. Double-check the account ID and distribution ID in the policy JSON.

Verify Connection fails with “The security token included in the request is invalid”: The Access Key ID or Secret Access Key is incorrect. Regenerate the access key in IAM and update both values in Cyclone Settings.

Invalidations succeed but CloudFront still serves old content: Propagation time is usually under 60 seconds. For distributions with many edge locations, global propagation can take up to 5 minutes. Check the Invalidation status in CloudFront → Distributions → [your distribution] → Invalidations. Status “Completed” means propagation is done.

“The specified distribution does not exist” error: Confirm the Distribution ID is correct. It starts with a letter and is about 14 characters (e.g. EDFDVBD6EXAMPLE). It is not the same as your domain name or the distribution’s domain (d1234abcd.cloudfront.net).

High invalidation costs: If you’re seeing unexpectedly high invalidation counts, ensure Cyclone’s regeneration triggers are not firing excessively. Widget, menu, or Customizer changes trigger a full site regeneration — be mindful of how often you make those changes. Avoid clicking Generate All repeatedly in quick succession.