Static WordPress with CloudFront: Creating a High-Performance Website Infrastructure [Technical]

Static WordPress with CloudFront: Creating a High-Performance Website Infrastructure

Introduction

In the ever-evolving landscape of web development, there’s a growing trend toward static website hosting for improved performance, security, and cost-efficiency. In this article, we’ll explore a real-world infrastructure setup that leverages Static WordPress with CloudFront to host content generated from WordPress. This approach combines the user-friendly content management capabilities of WordPress with the speed and scalability benefits of static site hosting on AWS CloudFront.

Fun fact: The very blog you’re reading right now, along with the entire expertcloudandai website, is powered by this exact Static WordPress with CloudFront architecture! As you navigate through this site, you’re experiencing firsthand the performance benefits we’ll be discussing.

The Problem with Traditional WordPress Hosting

WordPress powers approximately 43% of all websites on the internet, but traditional WordPress hosting comes with several challenges:

• Performance issues: Dynamic page generation can slow down site loading
• Security vulnerabilities: WordPress sites are common targets for attacks
• Scaling complexities: High traffic requires complex caching and server scaling
• Ongoing maintenance: Regular updates and database management are required

The Static WordPress with CloudFront Solution

Static site generators solve these problems by pre-rendering all pages as static HTML files. This results in:

• Lightning-fast page loads
• Reduced security vulnerabilities
• Simplified scaling
• Lower hosting costs

But what if you want to keep WordPress as your content management system while enjoying the benefits of static hosting? That’s where the Static WordPress with CloudFront approach comes in, giving you the best of both worlds.

Architecture Overview

The infrastructure we’re examining uses AWS CloudFormation to create a robust, scalable Static WordPress with CloudFront platform. Here’s the high-level architecture:

1. Content Storage: Amazon S3 bucket for hosting static files
2. Content Delivery: CloudFront CDN for global distribution
3. Domain Management: Route53 for DNS configuration
4. Security: ACM for SSL/TLS certificates
5. CI/CD: GitLab CI/CD pipeline for automated deployments

Let’s dive deeper into each component and how they work together.

The Infrastructure as Code

The infrastructure is defined using AWS CloudFormation templates, which provide several advantages:

• Reproducibility: The entire infrastructure can be recreated with a few commands
• Version control: Infrastructure changes can be tracked in Git
• Consistency: Eliminates configuration drift between environments
• Documentation: The templates serve as documentation for the infrastructure

The project contains three main CloudFormation templates:

1. expertcloud_infra.yaml: Defines the S3 and CloudFront resources
2. route53.yaml: Sets up DNS zones and records
3. certificate_stack.yaml: Creates and validates SSL/TLS certificates

ACM Certificate Provisioning in us-east-1

One critical aspect of this Static WordPress with CloudFront infrastructure is the provisioning of SSL/TLS certificates through AWS Certificate Manager (ACM). An important detail that often trips up developers is that ACM certificates used with CloudFront must be created in the us-east-1 region (N. Virginia), regardless of where the rest of your infrastructure is deployed.

Looking at the GitLab CI/CD pipeline, we can see this requirement is explicitly handled:

deploy_certificate:
  # ...
  variables:
    AWS_DEFAULT_REGION: "us-east-1"  # Specifically set to us-east-1
    CERTIFICATE_STACK_NAME: "ExpertCloudCertificateStack"
    AWS_ROLE_ARN: "arn:aws:iam::xxxxxxxxxxxx:role/GitLabDeploymentRole"
  # ...

While the rest of the infrastructure resources (S3 buckets, Route53 configurations) are deployed in ap-southeast-2 (Sydney), the certificate must be provisioned in us-east-1. The pipeline elegantly handles this multi-region deployment by:

1. First deploying the Route53 resources in ap-southeast-2
2. Then deploying the certificate in us-east-1, using the Route53 zone IDs for DNS validation
3. Finally deploying the main infrastructure in ap-southeast-2, referencing the certificate ARN

This approach has several advantages:

• Clean separation of concerns: Each deployment stage focuses on a specific set of resources
• Region-specific requirements are respected: Certificate creation happens in the required region
• Cross-region references are handled properly: The certificate ARN is passed to the main infrastructure stack

The pipeline uses environment variables and artifacts to pass information between stages, ensuring that the certificate’s ARN is available when deploying the CloudFront distribution:

CERT_ARN=$(aws cloudformation describe-stacks \
  --stack-name "$CERTIFICATE_STACK_NAME" \
  --query 'Stacks[0].Outputs[?OutputKey==`CertificateArn`].OutputValue' \
  --output text)
echo "CERT_ARN=$CERT_ARN" >> certificate.env

This certificate is then used in the CloudFront distribution configuration:

ViewerCertificate:
  AcmCertificateArn: !Ref CertificateArn
  SslSupportMethod: sni-only
  MinimumProtocolVersion: TLSv1.2_2021

Building a Static WordPress with CloudFront Workflow

This is the workflow:

1. WordPress Setup: Content is created and managed in a WordPress instance
2. Static Export: A plugin or tool exports the WordPress site as static HTML files – In our case we used Simply Static
3. Content Deployment: The static files are stored in the website_content/ directory
4. Automated Deployment: The GitLab CI/CD pipeline deploys the content to AWS

Popular tools for generating static files from WordPress include:

• Simply Static
• WP2Static
• Static HTML Output

These tools crawl your WordPress site and generate a complete static version while maintaining URLs, links, and assets, making them perfect for a Static WordPress with CloudFront implementation.

The Deployment Pipeline

The .gitlab-ci.yml file defines a comprehensive CI/CD pipeline with five stages:

1. deploy_route53: Creates the DNS zones for the website domains
2. deploy_certificate: Sets up and validates SSL/TLS certificates
3. deploy_infra: Deploys the main infrastructure (S3 and CloudFront)
4. update_route53: Updates DNS records with the CloudFront distribution
5. deploy_content: Syncs the static website content to S3

The most interesting stage for our discussion is deploy_content, which synchronizes the static website files to the S3 bucket:

deploy_content:
  # ...configuration omitted...
  script:
    - S3_BUCKET=$(aws cloudformation describe-stacks \
        --stack-name "$CFN_STACK_NAME" \
        --query 'Stacks[0].Outputs[?OutputKey==`S3BucketName`].OutputValue' \
        --output text)
    
    - echo "Syncing website content to S3..."
    - SYNC_OUTPUT=$(aws s3 sync website_content/ s3://$S3_BUCKET/ --delete --size-only 2>&1)
    
    # Creates CloudFront invalidation if files changed

This script:

1. Retrieves the S3 bucket name from CloudFormation outputs
2. Synchronizes the website content to the S3 bucket
3. Creates a CloudFront invalidation if any files were changed

CloudFront Optimization for Static WordPress

The infrastructure includes several optimizations for the CloudFront distribution in this Static WordPress with CloudFront setup:

1. Default Directory Index Function: Automatically adds index.html to directory requests
2. Custom Error Pages: Routes 403 and 404 errors to the main index page (perfect for single-page applications)
3. Compression: Enables Gzip compression for faster content delivery
4. Cache Settings: Configures appropriate TTL values for caching

Multi-Domain Support

A notable feature of this Static WordPress with CloudFront infrastructure is its support for multiple domains:

• expertcloudandai.com
• expertcloudandai.com.au
• expertcloud.co

Each domain (including www subdomains) points to the same CloudFront distribution, allowing for a unified content delivery strategy across multiple brand domains.

Benefits of Static WordPress with CloudFront

By using static WordPress exports with AWS CloudFront, this infrastructure achieves:

1. Performance: Static files delivered via CloudFront are incredibly fast
2. Security: Reduced attack surface with no PHP or database to exploit
3. Cost-Efficiency: Pay only for storage and data transfer, not server time
4. Scalability: Automatically handles traffic spikes with no additional configuration
5. Maintainability: Infrastructure defined as code for easier updates and changes

Challenges and Considerations

While this Static WordPress with CloudFront approach offers many benefits, there are some challenges to consider:

1. Dynamic Content: Forms, comments, and other dynamic features require JavaScript or third-party services
2. Frequent Updates: If content changes very frequently, you’ll need to automate the export process
3. WordPress Customization: Some WordPress plugins may not work with static exports
4. Initial Setup: The initial infrastructure setup requires AWS expertise

Accelerated Development with AI

One of the most interesting aspects of this project was the development approach itself. The CloudFormation templates, CI/CD pipeline, and documentation were developed using Cursor IDE with Claude-3.7 Sonnet AI assistance. This combination dramatically accelerated the development process while maintaining high code quality.

LLM-Enhanced Infrastructure as Code

The entire infrastructure was coded in a fraction of the time it would traditionally take, thanks to the capabilities of Large Language Models (LLMs) like Claude-3.7 Sonnet. Here’s how LLMs enhanced the development process:

1. Rapid Prototyping: Initial CloudFormation templates were generated and refined through iterative prompting, reducing days of work to hours
2. Error Prevention: The AI helped identify potential issues and best practices in AWS infrastructure design
3. Documentation Automation: Documentation was generated alongside code, ensuring comprehensive and up-to-date explanations
4. Pipeline Optimization: The CI/CD pipeline was iteratively improved with AI-suggested optimizations

For example, the CloudFront Function to handle directory indexes—a component that would typically require careful testing and refinement—was generated in minutes with proper error handling and edge cases already considered.

Enterprise LLM Implementation

While our team leveraged public LLM tools for this project, enterprises with sensitive data or regulatory requirements can achieve similar benefits with proper implementation strategies:

1. Private LLM Deployments: Organizations can deploy models like Claude on private infrastructure or leverage enterprise-grade solutions with appropriate data protection
2. Domain-Specific Fine-Tuning: LLMs can be specialized with company-specific code patterns and practices
3. Airgapped Development: For highly sensitive environments, models can operate in completely isolated environments
4. Contextual Guardrails: Enterprise implementations can include guardrails ensuring code meets company standards and security requirements

Measurable Development Acceleration

The entire infrastructure described in this article—from initial design to fully functioning CI/CD pipeline—was developed in approximately 2 days rather than the 2-3 weeks it would typically require. This represents an estimated 85% reduction in development time without compromising quality or security.

This acceleration is particularly valuable for enterprises in several ways:

1. Reduced Time-to-Market: Products and features can be launched significantly faster
2. Cost Efficiency: Development resources are utilized more effectively
3. Consistency at Scale: Infrastructure patterns can be standardized and replicated easily
4. Focus on Innovation: Developers spend less time on boilerplate code and more on unique business challenges
5. Enhanced Quality: With AI assisting in code reviews and best practices, overall code quality improves

Organizations that successfully implement LLM-assisted development while respecting their data protection and regulatory requirements are positioned to achieve significant competitive advantages through this kind of development acceleration.

Conclusion

The Static WordPress with CloudFront infrastructure examined in this article represents a powerful approach to modern web hosting. By combining the content management capabilities of WordPress with the performance and security benefits of static hosting on AWS CloudFront, it offers the best of both worlds.

This architecture is particularly well-suited for content-heavy websites that don’t require extensive dynamic functionality. For businesses looking to improve website performance, reduce hosting costs, and enhance security, the Static WordPress with CloudFront approach demonstrated by this codebase provides an excellent blueprint to follow.

As mentioned at the beginning, this isn’t just theoretical—the very website you’re browsing right now (expertcloudandai.com) uses this exact infrastructure! Our team manages content through WordPress for its excellent editorial workflow, exports it as static HTML, and deploys it through the automated pipeline described in this article. The result? A blazing-fast, secure, and highly available website that costs a fraction of traditional WordPress hosting to maintain.

Whether you’re managing a corporate website, a blog, or an e-commerce site, consider how static exports from WordPress combined with CloudFront distribution might benefit your digital presence. And if you’re looking to accelerate your own infrastructure development, consider how AI-assisted development might transform your team’s productivity.

You can find all the code for this solution in our GitLab repository.