AWS CloudFront维护页面配置：部署期间流量路由与静态IP冒烟测试实现方案问询

Got it, let's break down how to handle this maintenance scenario with CloudFront—you need to route all users to a maintenance bucket during deployment, but keep access open for your specific static IP for smoke testing. Here's a step-by-step approach that leverages CloudFront's behavior priority and viewer access controls:

1. Prep Your Maintenance Page Bucket #

First, make sure you have a dedicated S3 bucket for your maintenance page:

• Upload your maintenance HTML, styles, and assets (like logos or loading spinners) to the bucket.
• Enable static website hosting for the bucket (under the "Properties" tab in S3).
• Set up an Origin Access Control (OAC) in CloudFront for this bucket, and update the bucket policy to allow CloudFront to access its contents—this keeps your maintenance page secure without making the bucket public.

2. Update CloudFront Behaviors (Key Step!) #

CloudFront matches behaviors in priority order (highest priority first), so we'll add high-priority rules to let your IP bypass maintenance, then catch all other traffic with the maintenance bucket.

2.1 Add IP-Whitelisted Behaviors for Your Existing Origins

Create two new behaviors (higher priority than your current /api/* and * behaviors) to reserve access for your static IP:

• Behavior 1 (Priority 1: /api/*)

  • Path pattern: /api/*
  • Viewer request policy: Create a new policy (name it something like Allow-My-Smoke-Test-IP)
    • Toggle "Restrict Viewer Access" to Yes
    • Choose "Allow list" and input your static IP (use CIDR format for a single IP, e.g., 192.168.1.10/32)
  • Origin: Select your existing Application Load Balancer origin
  • Copy over any other settings (cache policies, HTTP methods, etc.) from your original /api/* behavior to keep functionality consistent.

• Behavior 2 (Priority 2: *)

  • Path pattern: *
  • Viewer request policy: Use the same Allow-My-Smoke-Test-IP policy you created
  • Origin: Select your original frontend S3 bucket origin
  • Again, mirror your original default behavior's settings for cache, headers, etc.

2.2 Add the Maintenance Page Catch-All Behavior

Create a third behavior to route all non-whitelisted traffic to your maintenance bucket:

• Behavior 3 (Priority 3: *)
  • Path pattern: *
  • Viewer request policy: Use a default policy (no IP restrictions—this is for all regular users)
  • Origin: Select your maintenance S3 bucket origin
  • Set a short cache TTL (e.g., 5 minutes) so once you take down maintenance, users get the live site quickly without waiting for long cache durations.

3. Validate During Deployment #

• From your static IP: Visit your site—you should see the live frontend and be able to hit the /api/* endpoints for smoke testing.
• From any other IP: You'll land on the maintenance page, confirming user traffic is properly redirected.

4. Post-Deployment Cleanup #

Once your deployment is verified and ready to go live:

• Delete the three new behaviors you added (or set their priorities to the lowest to disable them temporarily)
• Wait 5-10 minutes for CloudFront to propagate the config update—users will automatically start hitting the live site again.

Pro Tips for Streamlining This #

• Use Infrastructure as Code (IaC) tools like CloudFormation or Terraform to define these maintenance behaviors as reusable templates. This lets you toggle maintenance mode with a single deploy instead of manual clicks.
• If you need more dynamic control (like updating the allowed IP without changing CloudFront config), use a Lambda@Edge function attached to the viewer request event. The function can check the request's source IP against your whitelist and route to the appropriate origin on the fly.

内容的提问来源于stack exchange，提问作者Jemi Evangeline