Specification: CloudFront Routing for WordPress Homepage Migration

Objective

Migrate the homepage and general content management for yoyacoo.jp to a WordPress system running on a new EC2 instance, while keeping the existing Next.js web application for the app routes (/user*, /customer*) served by the current ALB.

bourne-design.jp is dropped from the migration. The WP site will be served from a fresh EC2 origin accessed via CloudFront at the new hostname wp.yoyacoo.jp.

Current Architecture

Production

• Domain: yoyacoo.jp
• CDN: CloudFront Distribution E1J6MUY16GJP2C
• Primary Origin: Production ALB (prod-yoyacoo-alb-...)

Staging

• Domain: stg.yoyacoo.jp
• CDN: CloudFront Distribution E3QN4AIIY399LD
• Primary Origin: Staging ALB (stg-yoyacoo-alb-...)

Proposed Architecture

The new EC2 origin is a single Ubuntu 24.04 instance per environment running the full WordPress stack in Docker. Same hostname (wp.yoyacoo.jp) for both prod and stg, pointing to two separate EC2 instances. This means stg and prod share the same WordPress content; staging is used for deploys/infrastructure changes, not isolated content edits.

Technical Requirements

1. CloudFront Configuration Changes (apply to both distributions)

A. Add New Origin

B. Update Cache Behaviors

Note: separate /_next/* rules are not required. /user* and /customer* already cover their respective basePath-prefixed asset paths.

C. No CloudFront Functions

Body and path rewrites are not needed. The vendor’s clean WP install + correct siteurl / home handles URL consistency. The only first-party hostnames in HTML should be yoyacoo.jp and stg.yoyacoo.jp.

2. WordPress Origin (new EC2 per environment)

A. Instance

B. Networking

• Public IP at launch: enabled (needed to fetch the cert on first boot)
• Security group (initial): 22 from vendor IP, 80 and 443 from 0.0.0.0/0
• Security group (after CloudFront is wired up): 22 from vendor IP, 443 from CloudFront managed prefix list (com.amazonaws.global.cloudfront.origin-facing) only, 80 closed

C. Stack (Docker, three services in /opt/yoyacoo-wp/docker-compose.yml)

Shared named volume wp_html mounted read-write in wordpress and read-only in nginx, so nginx serves static assets (/wp-content/uploads/*, theme CSS/JS) directly without round-tripping to PHP.

D. Host nginx config (/opt/yoyacoo-wp/nginx.conf)

server {
  listen 80;
  server_name wp.yoyacoo.jp;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl;
  http2 on;
  server_name wp.yoyacoo.jp;

  ssl_certificate     /etc/letsencrypt/live/wp.yoyacoo.jp/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/wp.yoyacoo.jp/privkey.pem;

  root /var/www/html;
  index index.php;
  client_max_body_size 64m;

  location ~* \.(js|css|png|jpe?g|gif|webp|ico|svg|woff2?)$ {
    expires 30d;
    access_log off;
    try_files $uri =404;
  }

  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  location ~ \.php$ {
    fastcgi_pass wordpress:9000;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_read_timeout 60s;
  }
}

E. WordPress configuration

Set via WORDPRESS_CONFIG_EXTRA env var in the wordpress container:

define('WP_HOME',    'https://yoyacoo.jp');   // viewer domain
define('WP_SITEURL', 'https://yoyacoo.jp');

Other WP settings:

• Site title: yoyacoo
• Admin email: ops contact
• Timezone: Asia/Tokyo
• Locale: ja
• Permalink structure: /%postname%/

F. Database

G. SSL

• Let’s Encrypt via certbot on the host (not in a container).
• Issued with --standalone challenge against wp.yoyacoo.jp (or wp-stg.yoyacoo.jp for stg).
• Cert path: /etc/letsencrypt/live/<hostname>/ (mounted read-only into the nginx container).
• Auto-renewal cron: 0 3 * * * running certbot renew --quiet --deploy-hook "docker exec $(cd /opt/yoyacoo-wp && docker compose ps -q nginx) nginx -s reload".

3. DNS

DNS must be propagated before certbot runs on first boot.

4. Required WordPress Plugins

• SEO: Rank Math or Yoast
• Security: Wordfence or equivalent
• Better Search Replace (for the URL migration step in §5)
• WP fail2ban or equivalent login throttling
• Disable: Hello Dolly, Akismet (unless requested)

5. Content Migration

• Export content from https://bourne-design.jp/yoyacoo/ using a migration tool (All-in-One WP Migration, Duplicator, or similar).
• Import into the new EC2 WordPress install.
• Run Better Search Replace to convert:
  • http://bourne-design.jp/yoyacoo/ → https://yoyacoo.jp/
  • https://bourne-design.jp/yoyacoo/ → https://yoyacoo.jp/
• Verify no bourne-design.jp references remain in the DB.
• Verify no http:// media URLs remain.

6. Hardening

• SSH: key-only auth, password login disabled, root login disabled, vendor IP allowlist
• ufw enabled with the same rules as the security group
• Fail2ban installed and running
• WordPress auto-updates enabled for minor versions
• Plugin/theme updates: weekly cadence

7. Backups

• Daily EBS snapshot of the root volume, retained 7 days
• Daily DB dump to S3, retained 7 days
• Daily wp-content tar to S3, retained 7 days

Vendor Scope

A third-party vendor handles the EC2 setup. The vendor is responsible for items 2–7 above. The internal team (us) is responsible for:

• CloudFront configuration changes
• DNS record creation
• Smoke testing the cutover

Rollback Plan

• To rollback, change the Default (*) behavior back to the ALB Origin. The EC2 and WP install stay in place; nothing to clean up. Re-apply the change once the issue is understood.

Success Criteria

Infrastructure

1. https://yoyacoo.jp/ returns 200 with WP content.
2. https://yoyacoo.jp/price/ returns 200 with WP content.
3. https://yoyacoo.jp/wp-content/uploads/... returns 200 with image/* content type.
4. https://yoyacoo.jp/robots.txt returns 200.
5. https://yoyacoo.jp/sitemap.xml returns 200.

App routes preserved

6. https://yoyacoo.jp/user/login continues to serve the Next.js login page.
7. https://yoyacoo.jp/customer/lp/... continues to serve the Next.js LP.

Content integrity

8. HTML body of https://yoyacoo.jp/ contains no bourne-design.jp references.
9. HTML body of https://yoyacoo.jp/ contains no http:// mixed-content URLs.
10. HTML body of https://yoyacoo.jp/ contains yoyacoo.jp links.

Security

11. Direct request to https://wp.yoyacoo.jp/ from a non-CloudFront IP is blocked (timeout or connection refused).

Out of Scope (for this migration)

• WAF rules on CloudFront (add later as a follow-up)
• wp-admin IP allowlist
• Cache policy optimization (start with default; WP Cache-Control headers respected)
• Migration of the existing ALB-backed /user and /customer apps
• Content editing or design changes (marketing team)

Pre-Cutover Checklist

1. EC2s (stg + prod) provisioned per §2.
2. DNS CNAMEs in place and propagated (dig +short wp.yoyacoo.jp returns the Elastic IP).
3. Vendor has migrated content, set WP_HOME/WP_SITEURL, and scrubbed the DB per §5.
4. SEO plugin active; robots.txt and sitemap.xml accessible.
5. Cert auto-renewal cron installed (crontab -l | grep certbot).
6. Test the EC2 directly (with a temporary security group rule for the tester’s IP) — /, /price/, sample media all return 200.
7. CloudFront origin added; cache behaviors configured; deployed to stg.
8. Stg smoke test passes (all 11 criteria above, against stg.yoyacoo.jp).
9. Same CloudFront deploy to prod distribution.
10. Prod smoke test passes.
11. Remove any temporary security group rules used for direct EC2 testing.