DEV Community

Akhileshpm
Akhileshpm

Posted on

Understanding WordPress Architecture on AWS: It’s Simpler Than You Think

"To understand complexity, first break it into its simplest components."

Take a look at this architecture for hosting WordPress on Amazon:

Image description

Do you understand this diagram? If yes, excellent—this blog will be a good refresher for you. If not, no worries. By the end of this blog, you’ll be able to understand it clearly.

Let's break down the key building blocks.

  • Amazon Route 53 & CloudFront (DNS and CDN)
    Route 53 is the domain name service offered by AWS. It acts as the website's "phone directory," ensuring that when a user types in your website’s name, they are directed to the correct resources in the cloud.
    Amazon CloudFront, the content delivery network (CDN), ensures that static content like images and CSS are delivered quickly by caching them closer to the user’s location, improving speed and performance.

  • S3 for Static Assets
    Think of Amazon S3 as a storage locker where your WordPress static files, such as media and theme assets, are kept. S3 is highly reliable and accessible, ensuring that files are stored redundantly across multiple locations and are always available to serve users.

  • VPC and Subnets
    The Virtual Private Cloud (VPC) is like a gated community for your resources. Public subnets allow web traffic from users to reach your application, while private subnets isolate sensitive resources (such as your database) from the outside world, keeping them secure. This segmentation ensures that your WordPress site is both accessible and protected.

  • NAT Gateway
    The NAT (Network Address Translation) Gateway is like a secure tunnel that allows resources in private subnets (like your database or backend servers) to access the internet without exposing themselves directly. For instance, WordPress instances may need to download updates or plugins from the internet, and the NAT Gateway allows this outbound communication while keeping the servers themselves private and hidden from outside threats.

  • Application Load Balancer
    ALB acts as a smart traffic controller. When multiple users visit your WordPress site, the load balancer distributes incoming requests across multiple servers (WordPress instances) to prevent any single server from being overwhelmed. This ensures that your site can handle increased traffic without slowing down.
    The WordPress application itself runs on EC2 instances. The beauty of AWS Auto Scaling is that it automatically adjusts the number of EC2 instances based on traffic patterns. So, during high-traffic periods, additional instances are launched to handle the load, and when traffic decreases, instances are terminated to save costs.

  • Elastic File System (EFS)
    WordPress instances need to share files (such as media uploads) across all servers. Amazon EFS provides a scalable and shared file system that can be accessed by multiple WordPress instances at the same time. This ensures that every server has access to the same files, keeping your website consistent across instances.

  • ElastiCache (Memcached)
    To improve performance, frequently accessed data (such as user sessions or query results) can be cached in memory rather than being fetched from the database each time. ElastiCache for Memcached is used for this purpose, acting like a temporary storage that makes your site load faster by reducing the need for repetitive database queries.

  • RDS for MySQL with Read Replicas
    At the heart of WordPress is the MySQL database. Amazon RDS (Relational Database Service) manages the database, taking care of backups, scaling, and updates. With read replicas, you can scale the database’s read operations to different servers, allowing more users to access your content simultaneously without performance bottlenecks.

  • Region
    AWS is divided into multiple geographic regions, each consisting of multiple isolated locations. Each region is independent, allowing for low latency and compliance with local laws. Regions are named after their geographical locations (e.g., US East (N. Virginia), EU (Frankfurt)). Choosing the right region can optimize performance and costs based on user location.

  • Availability Zones (AZ)
    Each region contains multiple Availability Zones (typically 2 to 6). AZs are distinct data centers with their own power, cooling, and physical security. They are designed to be isolated from failures in other AZs, providing high availability and fault tolerance.Services deployed across multiple AZs can improve reliability and performance by distributing workloads.

Architecture Walkthrough

  1. DNS Request (Amazon Route 53)
    When a user types in the website URL, Amazon Route 53 routes the request to the Application Load Balancer (ALB). Route 53 works as the domain name service, directing the user to the correct web resources within AWS.

  2. Content Delivery (Amazon CloudFront)
    Amazon CloudFront, the Content Delivery Network (CDN), checks if the requested static content is cached at an edge location. If it’s available, it delivers static files like images, CSS, or JS directly to the user. If not, the request moves to the origin (WordPress servers). These static files are stored in AWS S3.

  3. An internet gateway enables resources in your public subnets (such as EC2 instances) to connect to the internet if the resource has a public IPv4 address or an IPv6 address.

  4. Application Load Balancer (ALB)
    The Application Load Balancer (ALB) receives the request and forwards it to one of the WordPress EC2 instances running in either Availability Zone 1 (AZ1) or AZ2. The ALB ensures traffic is balanced between instances, preventing overloading of a single server.

  5. NAT Gateway (AZ1 & AZ2)
    When the EC2 instances in private subnets need to access the internet (e.g., downloading WordPress updates), they use the NAT Gateway. This ensures secure outbound internet access for EC2 instances in both AZ1 and AZ2, while still keeping them private and unreachable from external sources.

  6. Auto Scaling & EC2 Instances (AZ1 & AZ2)
    The EC2 instances in AZ1 and AZ2 are where WordPress runs. Auto Scaling dynamically adjusts the number of these EC2 instances based on traffic levels. During high traffic, more instances are launched; during low traffic, they are terminated to save costs. This setup ensures redundancy across two Availability Zones for high availability.

  7. Caching (ElastiCache)
    To improve response times, frequently accessed data (such as session data or popular blog posts) is cached in ElastiCache (using Memcached). This reduces the load on the database by serving cached data directly from memory, avoiding repeated database queries for the same content.

  8. Database Queries (RDS MySQL)
    For dynamic content (such as posts and comments), requests are sent to the Amazon Aurora database. The RDS instance manages the database operations, while read replicas are used to improve performance by offloading read operations. Write operations happen on the primary RDS instance, but read-heavy workloads are distributed across read replicas in both AZ1 and AZ2.

  9. EFS for Shared Files
    All WordPress instances in both AZ1 and AZ2 access a shared Elastic File System (EFS), ensuring that all media uploads and shared WordPress files are accessible to each server. This ensures that when one instance uploads an image or stores a file, all other instances can immediately access it, maintaining a consistent user experience.

Now that you’ve gotten a grasp of the core components, revisit the diagram—you’ll likely have a clearer understanding of the architecture and how it all fits together.

Top comments (0)