基于AWS为客户配置多自定义域名的实现方案咨询

Hey there, let's walk through a production-ready, scalable solution to build this domain deployment system on AWS—one that supports thousands of customers, lets them manage everything via your app's UI, and handles both default subdomains and custom Pro-tier domains.

核心架构组件 #

First, let's outline the key AWS services you'll need (chosen for scalability, ease of automation, and tight integration):

• Route 53: Manages DNS records for your base domain, customer subdomains, and validates custom domain ownership.
• AWS Certificate Manager (ACM): Automatically issues and renews SSL certificates (critical for HTTPS support on all domains).
• CloudFront: Acts as your global CDN, routes traffic to the correct customer resources, and enforces HTTPS.
• Lambda + API Gateway: Powers your app's UI backend—handles subdomain creation, custom domain validation, and infrastructure updates.
• S3: Stores static customer content (HTML/CSS). For PHP apps, use ECS Fargate or AWS App Runner (containerized/serverless PHP hosting) to keep things scalable.
• Lambda@Edge: Runs code at CloudFront's edge locations to route traffic based on the incoming Host header (so each domain points to the right customer's site).

1. Default Subdomain Workflow (their-site.mydomain.com) #

This is fully automatable and straightforward for new customers:

Step 1: Pre-configure Base Infrastructure #

• Create a Route 53 hosted zone for your base domain (mydomain.com).
• Request a wildcard SSL certificate (*.mydomain.com) via ACM—validate it using Route 53 (this happens automatically if your domain is managed in Route 53).
• Set up a CloudFront distribution:
  • Point the origin to your S3 bucket (for static content) or your PHP hosting endpoint (ECS/App Runner).
  • Attach the wildcard ACM certificate to the distribution.
  • Enable a Lambda@Edge function in the Viewer Request phase that parses the Host header, extracts the customer subdomain (e.g., their-site from their-site.mydomain.com), and routes traffic to the corresponding customer's S3 prefix or PHP service.

Step 2: Customer Onboarding via Your UI #

When a customer signs up:

• Let them choose a unique subdomain prefix (e.g., their-site). Your app checks if the subdomain is taken by querying Route 53.
• If available, your app calls an API Gateway endpoint that triggers a Lambda function. This function:
  • Creates a CNAME record in Route 53: their-site.mydomain.com → your CloudFront distribution's domain.
  • Sets up the customer's S3 prefix (e.g., s3://your-bucket/their-site/) or provisions their PHP service instance.
• Notify the customer once the subdomain is live (Route 53 propagates records in ~60 seconds usually).

2. Pro Tier Custom Domain Workflow #

This requires validating customer ownership of their domain and configuring SSL + routing:

Step 1: Customer Initiates Custom Domain Setup #

• In your UI, the Pro customer enters their custom domain (e.g., example.com or blog.example.com).
• Your app first checks if the domain is already in use by another customer (via your internal database).

Step 2: Domain Ownership Validation #

To prevent abuse, verify the customer owns the domain:

• Your Lambda function generates a unique TXT record (e.g., _acme-challenge.example.com with a random token).
• Display this record to the customer, instructing them to add it to their domain's DNS provider (could be Route 53, GoDaddy, etc.).
• Your app polls DNS periodically to check if the TXT record exists. Once verified, proceed.

Step 3: Issue SSL Certificate #

• Use ACM to request a certificate for the customer's custom domain. Choose DNS validation, and generate the required TXT record for verification.
• Display this TXT record to the customer and wait for ACM to confirm validation (this usually takes 5-10 minutes).
• Once the certificate is issued, attach it to your CloudFront distribution (or create a new distribution if you hit the 100-custom-domain limit per distribution).

Step 4: Configure Customer's DNS #

• Instruct the customer to add either:
  • An A record pointing to CloudFront's IPv4 addresses (pull these from your distribution's settings).
  • A CNAME record pointing to your CloudFront distribution's domain (e.g., d1234567890.cloudfront.net).
• Your app can verify this setup by checking if the customer's domain resolves to your CloudFront IPs.

Step 5: Route Traffic to Customer's Site #

• Update your Lambda@Edge function to recognize the new custom domain and route traffic to the corresponding customer's S3 prefix or PHP service. Alternatively, use CloudFront's Cache Behavior rules to map the custom domain to the correct origin.

3. Scalability Tips for Thousands of Domains #

• CloudFront Distribution Limits: Each CloudFront distribution can have up to 100 alternate domain names. For thousands of domains, create multiple distributions (e.g., one per 100 domains) and use Route 53 to route custom domains to the appropriate distribution.
• ACM Certificate Optimization: Group multiple custom domains into a single ACM certificate (up to 10 domains per certificate) to stay under the 1000-certificate per account limit.
• S3 Organization: Use a single S3 bucket with customer-specific prefixes (e.g., s3://your-bucket/customer-123/) instead of individual buckets—this simplifies management and reduces costs.
• PHP Hosting Scalability: For PHP apps, use ECS Fargate with an auto-scaling group, or AWS App Runner (which handles scaling automatically). Route traffic to the correct customer's PHP container using the Host header in your load balancer rules.

4. UI/UX Best Practices #

• Real-Time Status Updates: Show customers clear progress indicators (e.g., "Checking subdomain availability..." → "Creating DNS record..." → "Subdomain live!").
• Clear Instructions: For custom domains, provide copy-pasteable DNS records and simple guides for common DNS providers (e.g., "How to add a TXT record in GoDaddy").
• Error Handling: If a subdomain is taken, or DNS validation fails, give specific, actionable messages (e.g., "Subdomain 'their-site' is already in use—try another one").
• Testing Tools: Add a "Check Domain Status" button so customers can verify if their custom domain is correctly configured.

5. Security Considerations #

• Enforce HTTPS: Set CloudFront's Viewer Protocol Policy to "HTTPS Only" to redirect all HTTP traffic to HTTPS.
• Restrict Origin Access: For S3, use an Origin Access Control (OAC) to ensure only CloudFront can access the bucket (no public access). For PHP services, use security groups to allow traffic only from CloudFront.
• Rate Limiting: Add rate limiting to your API Gateway endpoints to prevent abuse of subdomain/custom domain creation.
• Domain Whitelisting: Optional—let Pro customers add only domains they own (verified via the TXT record step) to prevent misuse.

内容的提问来源于stack exchange，提问作者Surjith S M