Static WordPress Authentication Made Simple: Deploy with the AWS SAR Template

Static WordPress Authentication Made Simple: Deploy with the AWS SAR Template

Export WordPress to static files, keep top-tier speed and security on S3+CloudFront — and still protect member areas using CloudFront signed cookies, an API Gateway + Lambda “cookie service,” and no-code Gatey hooks.

Table of Contents

Introduction

Static WordPress websites are fast, cheap, and secure. By exporting your site into static files and hosting them on Amazon S3 + Amazon CloudFront, you remove PHP/MySQL overhead and drastically shrink the attack surface.

But there’s a catch: once your site is static, the native WordPress authentication no longer works. How do you secure premium downloads, member dashboards, or course pages?

Solution: the WordPress Static Site Guardian, deployed from the AWS Serverless Application Repository (SAR). It provides:

  • CloudFront signed cookie protection for selected URL paths
  • API Gateway + Lambda endpoints to issue and clear cookies
  • KMS + SSM backed key management
  • No-code integration with the Gatey plugin for Amazon Cognito login

What this stack does

  • Hosts your static export on S3/CloudFront and restricts paths using CloudFront signed cookies.
  • Issues/clears cookies via API Gateway + AWS Lambda.
  • Automatically provisions Route 53 DNS records (when enabled) — so you don’t have to edit DNS manually.
  • Integrates with Gatey so Sign-In/Sign-Out call the cookie endpoints — no JavaScript needed.

 

Static vs Dynamic WordPress

FeatureDynamic WP (PHP/MySQL)Static WP (S3 + CloudFront)
SpeedServer-rendered, depends on PHP/DBCDN edge-cached, ultra-fast
SecurityCore/plugins = larger attack surfaceMinimal surface (static files)
ScalabilityBound by server resourcesVirtually unlimited via CloudFront
AuthenticationBuilt-in WP loginSAR + Gatey (signed cookies)
MaintenancePatching, DB backupsFile sync + cache invalidation
Deploy from AWS SAR →
Try Gatey Free →

Prerequisites

  • Valid ACM certificate in us-east-1 (covers apex domain + API subdomain)
  • Installed and configured AWS CLI
  • CloudFront key pair (generate below)
  • Registered domain (e.g. via Route 53)
AWS Certificate Manager showing issued SSL certificate for domain and subdomain.
ACM console confirming SSL certificates for kirodev.wpsuite.io and its wildcard subdomain, required for CloudFront and API Gateway.

Generate the CloudFront key pair

Use the provided script to generate an RSA key pair and store the private key securely in SSM (KMS-encrypted). You’ll get the KmsKeyId and PublicKeyContent to pass into the stack. 
				
					# Download the key generation script
curl -O https://raw.githubusercontent.com/smartcloudsol/wordpress-static-site-guardian/refs/heads/main/scripts/generate-cloudfront-keypair.sh
chmod +x generate-cloudfront-keypair.sh

# Generate keys and store in AWS
./generate-cloudfront-keypair.sh --name my-wordpress-keys --region us-east-1
AWS CLI terminal showing CloudFront key pair generation for WordPress Static Site Guardian deployment.
Running the generate-cloudfront-keypair.sh script to create a CloudFront key pair and KMS-backed private key for signed cookie authentication.
References: AWS SSM Parameter Store • Signed cookies

Deploy from AWS SAR

  1. Open AWS Console → Serverless Application Repository and search for WordPress Static Site Guardian or follow this link.
  2. Fill parameters:
    • DomainName → example.com
    • ApiDomainName → api.example.com
    • CertificateArn (ACM in us-east-1)
    • KmsKeyId and PublicKeyContent from the script
    • ProtectedPaths → e.g. /members,/downloads
    • SigninPagePath → e.g. /sign-in
    • CreateDNSRecords → true to auto-create Route 53 DNS records
  3. Click Deploy. The stack provisions S3, CloudFront, API Gateway, Lambda, KMS/SSM, and (optionally) Route 53 records.
AWS SAR deployment screen for WordPress Static Site Guardian application.
Reviewing and configuring application settings before deploying the WordPress Static Site Guardian stack from the AWS Serverless Application Repository.
AWS CloudFormation console showing successful SAR stack deployment.
The CloudFormation deployment timeline confirms that the WordPress Static Site Guardian SAR stack completed successfully.
More: Deploying apps from SAR

Upload the static WordPress export

  • Export your site (Simply Static, WP2Static, etc.).
  • Upload to the provisioned S3 bucket under the configured wwwroot prefix (e.g. with AWS CLI s3 sync).
  • Invalidate CloudFront after updates (docs).
Heads-up: The stack expects the static site under a non-empty S3 prefix (e.g. wwwroot/). Upload content to s3://<bucket>/wwwroot/, not the bucket root.
WordPress Simply Static plugin generating a static export with logs.
The Simply Static plugin dashboard showing an export log, including generated pages, transferred files, and the destination URL.
AWS CLI uploading static WordPress export to S3 bucket with s3 sync.
Using the aws s3 sync command to push the exported WordPress site into the wwwroot prefix of the SAR-provisioned S3 bucket.

Integrate with Gatey (no JavaScript required)

In WordPress open Gatey → Settings → API and configure:
  • API: backend
  • Sign In Path: /issue-cookie
  • Sign Out Path: /issue-cookie?action=signout
  • With Credentials: enabled
On sign-in Gatey calls /issue-cookie to set CloudFront signed cookies; on sign-out it calls /issue-cookie?action=signout to clear them. No custom JS is needed — hooks run from the admin UI. Helpful: Gatey product page
WordPress Gatey plugin API and hook settings for CloudFront signed cookie integration.
Gatey settings page showing API configuration (backend) and hooks for Sign In and Sign Out paths pointing to /issue-cookie.

End-to-end test

  1. Visit a public page → loads normally.
  2. Visit a protected path → redirects to your /sign-in page.
  3. Sign in via Gatey (Cognito) → the API issues the cookie → reload grants access.
  4. Open a protected download → served with CloudFront signed cookies.
  5. Sign out → cookie cleared → access revoked.

Cookie lifetime, domain & CORS

  • Align cookie TTL with your Cognito refresh token policy (commonly ~30 days).
  • Scope cookies to the apex domain so they’re valid for the site and API subdomain.
  • API Gateway should allow credentials and your site origin in CORS (guide).

Monitoring & rollback

  • Inspect CloudWatch Logs for Lambda + API Gateway.
  • Watch CloudFront metrics (hit/miss, spikes in 403).
  • Rollback by redeploying a previous template version if needed.

Pro Tips & Common Mistakes

Pro tips

  • Automate export → S3 sync → CloudFront invalidation via CI/CD (CodePipeline or GitHub Actions).
  • Add custom 403/404 pages for a polished UX.
  • Alert on 401/403 spikes using CloudWatch alarms.
  • Keep separate stacks for staging vs production.

Common mistakes

  • Uploading files to the bucket root instead of wwwroot/.
  • ACM certificate not in us-east-1 (CloudFront requires it).
  • Mismatched cookie TTL vs Cognito refresh token lifetime.
  • Forgetting to enable “With Credentials” in Gatey API settings.

Pre-publish checklist

  • ACM certificate issued in us-east-1 for domain + API subdomain.
  • CloudFront key pair generated; KmsKeyId + PublicKeyContent recorded.
  • SAR stack deployed with CreateDNSRecords=true (or DNS mapped manually).
  • Static site uploaded under wwwroot/; CloudFront invalidated.
  • Gatey API hooks set to /issue-cookie and /issue-cookie?action=signout with credentials.
  • E2E test: login → cookie → protected access → logout → revoked.

Key takeaways

  • Static WordPress keeps speed and security — SAR + signed cookies bring back access control.
  • One deploy: S3, CloudFront, API Gateway, Lambda, KMS/SSM, and optional Route 53 auto-DNS.
  • Gatey connects Cognito to cookie issuance with admin-configured hooks — no custom JS.
Deploy from AWS SAR →
Try Gatey Free →