Architecting WordPress on AWS Series : Part 2

In first part of this series we dealt with Simple Single Server architecture for WordPress. Now we will see the next most common architecture in WordPress deployment – Multi-tiered architecture. This architecture is better than the Single Server architecture in terms of Stability and Performance.

Architecture 2: Multi-Tiered Setup in AWS

This architecture may sound little complex than Architecture 1 because of bringing RDS MySQL into picture. But on the contrary, it is easier to deploy RDS MySQL into the application than configuring a MySQL. Users or customers with minimum technical knowledge can get this started and running like the previous architecture.

In addition to RDS MySQL, Amazon CloudFront CDN is introduced into this architecture for improving the performance. W3TotalCache Plugin can be configured in WP to use AWS CloudFront for delivering Static assets like CSS, images, JS and themes. W3TotalCache plugin +CDN improves the response time by 3-4X times.

Overall this architecture uses two EC2 instances one for WP, Linux and Apache and second one for RDS MySQL. WP EC2 instance is an EBS backed AMI and it has both the WP mgmt and content running. Both the WP EC2 and RDS should be placed in Same Availability Zone and Same region. This reduces latency and also saves inter-AZ cost. It is minimum recommended to start the WP EC2 with large instance and RDS MySQL Large instance for the DB. WP EC2 large instance is 64-bit vm with better CPU, memory and high IO and bandwidth compared to its smaller counterparts in AWS.

Periodic EBS Snapshot backups can be taken for the WP EC2 instances and moved to S3.  RDS MySQL Dumps and snapshots can be configured in AWS console. RDS MySQL offers point in time recovery and configurable backup retention period. RDS MySQL currently supports only innoDB engine, so developers and implementers should note this before migrating to RDS. Overall AWS managed RDS services will ease the management headache and save significant maintenance cost for the company in long term.

Both the EC2 instance can be enabled with Detailed CloudWatch monitoring in the AWS console. Cloudwatch monitoring can be combined with SNS for System alerts to Email.

This architecture does not factor High Availability or Scalability needs. It is suitable for website serving few thousands pages per day and not suitable for scenarios with heavy traffic serving millions of pages.

Since the MySQL DB and WP EC2 instance are separated into Multi Tiers, each of the tiers operate with their own memory and CPU. This multi-tiered architecture improves the performance over the single server architecture discussed on part 1.

Customers should be aware this architecture has single point of failure at all levels. Since the RDS MySQL is separated from WP EC2 instance, DB and WP EC2 instance failures can be separated. In case of premature EC2 instance shutdown/crash, recovery might take from minutes to hours depending upon the complexity.  RDS can be recovered from the Point in time recovery or snapshots. RDS Recovery usually takes 5-10 minutes for 5 GB DB. Recovered RDS MySQL will have different end point URL and the new URL needs to be again configured in the WP EC2 instance configuration files.

The running infra cost will be around 700 USD per month in AWS (24X7 and not including any licensed software) and may vary depending upon the Data transfer usage/EBS Storage.

Note: Since AWS is constantly reducing their prices, it is better to use their Calculator and find the latest price at the time of reading this article.




Related Articles:


FAQ for Scalable WP architecture can be found here (Must read)
Architecting WordPress in AWS : Part 1 : Single Server Setup
Architecting WordPress in AWS : Part 2 : Multi tiered setup
Scaling WordPress in AWS to serve million page hits

Architecting WordPress on AWS Series : Part 1

WordPress (WP) is one of the most downloaded platforms (over 65 million times) and customers are not just using WP for their blogging needs but also as CMS.  WordPress is used by over 14.7% of Alexa Internet's "top 1 million" websites and as of August 2011 WordPress powers 22% of all new websites

For Last few years AWS has emerged as one of the popular Cloud providers for hosting the WP platform. In this 4-part Architecture Series we are going to see how to build a Highly Available and scalable WP infrastructure in AWS in phases. Let us get into first architecture of this series:

Architecture 1: Single Server setup in AWS

This is the simplest architecture to be setup in AWS. No big Architecture Consultations are required for this setup. AWS provides some standard AMI’s to kick start this architecture quickly. Users with minimum Technical knowledge can get this started up and running on their own in AWS. It uses a single Linux EC2 instance and the entire WordPress (Mgmt + content node), Apache and MySQL are configured on the same Amazon EC2 instance. The EC2 instance can be placed in Single Availability zone in a Single AWS region. If this information is not provided, it creates the instance in default at USA-East region of AWS. Customers who are configuring this architecture should at least start with 64-bit Large instance Type (m1.large) in AWS. Also the IO performance is better in Large instance compared to its smaller counterparts. Since MySQL performs better with more memory, large instance would be better choice to start with. EBS Backed AMI’s are better compared to S3 backed for launching such EC2 instances because at least the data is safe in the EBS in case the Instance terminates. Periodic EBS Snapshot backups and MySQL Dumps can be taken and moved to S3 (this requires some programming effort).  The EC2 instance can be enabled with Detailed CloudWatch monitoring in the AWS console. Cloudwatch monitoring can be combined with SNS for System alerts to Email. This architecture does not factor High Availability or Scalability needs. It is suitable for website serving few hundreds/thousands pages per day and not suitable for scenarios with heavy traffic serving millions of pages. Customers should be aware this architecture has single point of failure at all levels. In case of premature EC2 instance shutdown/crash, recovery might take from minutes to hours depending upon the complexity.

The running infra cost will be around 400 USD per month in AWS (24X7 and not including any licensed software) and may vary depending upon the Data transfer usage/EBS Storage.

Note: Since AWS is constantly reducing their prices, it is better to use their simple Calculator and find the latest price at the time of reading this article.

Related Articles:


FAQ for Scalable WP architecture can be found here (Must read)
Architecting WordPress in AWS : Part 1 : Single Server Setup
Architecting WordPress in AWS : Part 2 : Multi tiered setup
Scaling WordPress in AWS to serve million page hits

FAQ: Scaling WordPress in AWS

Original "Scaling WordPress in AWS " Architecture Post can be viewed here


1) Can EBS be used as the Shared Storage Pool between WP EC2 instances?
Currently Amazon Elastic Block Storage (EBS) can be attached to only one EC2 instance at a point in time. Because of this constraint we cannot attach the same EBS with Multiple WP EC2 instances and use it as a Shared Storage pool.


2) Can S3 be used as the Shared Storage Pool between WP EC2 instances?
S3 can be used as Shared Storage Pool and it requires programming and customization efforts in WordPress front. This is not a common approach.


3) Can the Shared Storage Pool be eliminated by upload all the static contents in CDN?
Shared Storage Pool is not an Alternative for storing contents in CDN. CDN is used to reduce latency and improve performance of the WordPress application , whereas Shared Storage Pool is used for instant communication between WP Mgmt EC2 instance and Auto Scaled WP EC2 instances.


4) What is the Shared Storage Pool Software used in this Architecture?
We used GlusterFS as the Shared Storage Pool in this Architecture.


5) Why GlusterFS for Shared Storage Pool and not NFS?
NFS works fine for Fixed WP EC2 instances. When WP EC2 instances are configured in Auto Scaling mode, new WP EC2 instances are launched whenever load increases automatically and killed when load decreases. Such dynamic launch/Kill has negative effects in the NFS system. We have seen GlusterFS working well in such auto scaling conditions.


6) How Auto Scaling is achieved in this architecture?
Auto Scaling is done only on WP EC2 instances and not on WP Mgmt instances. We used Amazon AutoScaling on WP EC2 instances based on the CPU Utilization. Whenever load increases the CPU utilization also increases and Amazon AutoScaling will trigger the launch process of New WP EC2 instances. These new EC2 instances are configured to automatically get attached to the Load Balancer. When the Load decreases the CPU utilization also reduces and Amazon AutoScaling will trigger the termination of the WP EC2 instances automatically.
For more details about Amazon AutoScaling URL: http://harish11g.blogspot.com/2011/04/auto-scaling-in-aws-cloud.html



7) Is WP mgmt EC2 and WP EC2 are separate EC2 instances ?
Yes,they are separate EC2 instances in this architecture. WP mgmt EC2 instance is used for theme , plugins and content publishing. Auto Scaled WP EC2 instances automatically pick up all these changes from the common storage pool shared between WP mgmt EC2 and WP EC2 instances.



8) What Algorithm should be configured in Amazon ELB for Scaling?
Amazon ELB can be configured with Round Robin Session Sticky Algorithm.


9) Is RDS Read Replica’s mandatory in this architecture?
No, RDS Read Replicas are not mandatory in this Architecture. They are advised only for Read Intensive production deployments.


10) Why RDS MySQL and not MySQL on EC2?
RDS MySQL is a managed service from Amazon Web Services. It is easy to configure and maintain.


11) What are recommended Instance Types / Capacities for the following Layers?
We recommend the following instance types for production deployments based on this architecture
WP content EC2 instances: Large Instance Types (m1.large)
WP mgmt EC2 instance Large Instance Types (m1.large)
GlusterFS Storage Pool: Large Instance Types (m1.large)
RDS MySQL: Large Instance Types to start with




12) What Plugins are used for Performance Improvement?
We use W3TotalCache plugin with AWS Cloudfront CDN for offloading static content delivery and gain better response times
APC (or) Xcache plugin can be used for PHP opscode caching


13) Can you throw some ideas to make this architecture Cost effective?


p1) Amazon Auto Scaling built into this architecture aligns the number of EC2 WP instances according to the traffic demands there by cutting unwanted EC2 usage costs.


To get more insights about Amazon Auto Scaling check this URL: Http://harish11g.blogspot.com/2011/04/auto-scaling-in-aws-cloud.html


Http://harish11g.blogspot.com/2011/12/aws-cloud-tour-2011-technical-track.html


p2) Also the WP mgmt EC2 instance can be launched only during deployments and can be shutdown other times for further cost savings.


p3) we have built HA for all layers in this architecture. If you want to trade off HA and achieve only Scalability, then reduce HA EC2 instances in GlusterFS and RDS Layers. This again reduces the monthly infrastructure cost.


p4) Usage of RDS Read Replicas are optional in this architecture and are dependent upon Use cases. This can further reduce cost if used appropriately



14) Is w3totalCache plugin a must in this architecture ?
Yes , This architecture is dependent upon W3totalcache with Cloudfront CDN. If this is not used , all static assets will be accessed from the GlusterFS and it will add additional burden to the GlusterFS . This will decrease the overall performance of the entire architecture. So in our past experience , we have observed using W3TotalCache plugin with CDN is very effective in this architecture.



15) Any specific care while configuring ELB ?
Yes , Configuring a  lesser unhealthy threshold value with aggressive response time out + Health Check interval in ELB , will mark WP EC2 instance unhealthy quickly and will stop sending requests. In addition , will send a signal to Amazon Auto Scaling to relaunch this WP EC2 instance. Even though you had requested Amazon Auto Scaling to maintain minimum of 2 instances , you will find some EC2 instances getting frequently restarted. If you maintain W3TotalCache in these WP EC2 instances (Web servers) to offload the traffic from DB servers and Gluster Servers , such frequent WP EC2 web server restarts will not give enough time for cache warming. This will add burden to the WP EC2 instances in web layer, DB servers etc and overall bring down the entire infrastructure.

Scaling WordPress in AWS to serve million page hits

Why this presentation ?

• WordPress is used by over 14.7% of Alexa Internet's "top 1 million" websites
• As of August 2011 WordPress powers 22% of all new websites
• As of December 2011, version 3.0 had been downloaded over 65 million times
• Provide some architectural insights to build Highly Scalable and Available WordPress sites in AWS
• Help startups and companies who are new to AWS- WordPress with some blueprints

FAQ for this architecture can be found here

Architecting an Highly Available and Scalable WordPress Site in AWS

View more presentations from Harish Ganesan

FAQ for this architecture can be found here

WordPress Architecture Requirements in AWS

• Ability to Serve millions of Pages per day
• Ability to scale out/down dynamically depending upon traffic
• Ability to perform well even with scaling demands 
• Should be Highly available without Single Points of Failure
• Automated Operations – Backup and Monitoring
• Cost effective 

Why AWS is better for WordPress Scaling?

• AWS provides flexibility to Scale up and Scale out
• AWS provides Building block services which is inherently robust and fault tolerant
• AWS provides full range of options from CDN , OS flavors , Storage Pool , Database , Load Balancers , Monitoring etc
• Pay as you go – Save cost by leveraging Auto Scaled WordPress EC2 instances
• We can start small and grow big in AWS

AWS building blocks used

• Amazon Route53 for managing and answering DNS queries
• Amazon Elastic Load Balancer for load balancing HTTP/S requests to WordPress Instances
• RDS MySQL Database Server for storing the WordPress content
• Simple Storage Service (S3) for storing the WordPress application assets , snapshots and log files
• Amazon CloudFront CDN for delivering the application static assets from nearest edge locations
• Amazon CloudWatch for monitoring and sending SNS alerts

Highly Scalable Architecture for WordPress application

Load Balancing Tier

• Amazon Elastic Load Balancing will Load balance the http requests to WordPress EC2 instances
• ELB will direct the requests to WordPress EC2 across Multiple Availability Zones ( for HA)
• Health check , LB algorithms and SSL termination will be done by the Load Balancer
• Amazon Elastic Load Balancing can keep expanding its capacity automatically depending upon the traffic 
• Amazon ELB works with Route 53 and Auto Scaling seamlessly
• Amazon ELB is priced @“ Pay for use” model
• Amazon ELB is a managed service , so No Maintenance headaches , SW/HW upgrades ,Capacity planning  and manual intervention for expansion

How scalable is this architecture ?

• Scalability and Elasticity is built in most of the layers in this architecture
• WordPress EC2 instances can be scaled out and down depending upon the traffic 
• We can expand the number of WordPress EC2 instances from 1 to 100+ automatically during load peaks
• We can reduce the number of WordPress EC2 instances from 100+ to 1 automatically during valleys
• Can serve millions of pages with ease 
• Pay only for the EC2 instance hours used
• Read Scalability is built in the Database layer with RDS Read Replicas
• New RDS Read Replicas can be added / removed with ease
• Tips:  During Campaigns alone we can run more RDS Read Replicas , Not more than max 5 RDS Read replicas are recommended , Keep Read Replica’s and RDS Master same EC2 size for better performance.

• Clustered + Distributed File System of the Storage pool layer can be manually scaled in case needed
• Minimum 2 EC2 Large instances should be used for Storage Pool Layer ( for HA and better IO)
• Design the Storage Pool Layer with HA (very critical)
• AWS building blocks like S3 , CloudFront , CloudWatch , SNS used in this architecture  are inherently designed for scalability

How High Availability and Fault tolerance is built in this Architecture ?

• HA @ WordPress Layer
• Multiple WordPress EC2 instances avoid single point of failure
• WordPress EC2 instances are launched across multiple –AZ’s inside a region for High Availability
• HA @ DB Layer
• RDS MySQL Master and Standby are launched in 2 different availability zones for High Availability
• RDS Read Replicas are created in Multiple –AZ’s
• HA @ Storage Pool Layer
• GlusterFS is used for the Storage Pool Layer
• Two EC2 instances used for Storage Pool Layer
• Storage Pool is setup in replicated mode for High Availability 
• AWS building blocks like S3 , Cloud Front , CloudWatch , ELB , SNS ,EBS used in this architecture are inherently designed for Fault tolerance and HA

How the Database Tier is Architected ?

• RDS Master and Standby provide High availability
• RDS Read Replicas provide Read performance
• HyperDB plugin is configured to use multiple endpoints like RDS master and RDS read replicas in this architecture
• DB security groups will allow DB access only to WordPress EC2 instances
• Periodic Dumps , Snapshots and Point in time recovery is possible in this architecture

What performance aspects are taken care in this Architecture ?

• APC (or) Xcache plugin can be used for PHP opscode caching
• W3TotalCache+CloudFront (or) BatCache+Memcached can be used for Page caching
• Multiple RDS Read Replicas for Read performance
• RDS Master and Read Replicas are separated to get independent write and read performance
• Amazon ELB + Auto Scaling improves the overall Site performance when the load increases

Content Delivery Network

• Amazon CloudFront will be the Content Delivery Network (CDN) 
• W3TotalCache plugin will be configured to use Amazon CloudFront for enhanced performance and reduced latency
• Static assets , templates , themes , images etc will delivered from the nearest edge locations of the CDN

Deployment

• Distributed File Storage Pool is configured between WordPress Management and Content instances
• WordPress Management and Content instances share the common storage pool for files and plugins
• Deployment of files and plugins will happen through the WordPress management node
• Files and plugins will be immediately available for use in the auto scaled WordPress EC2 instances

Monitoring and Alerts

• Amazon CloudWatch will monitor the CPU and Network utilization of the entire setup
• Amazon CloudWatch alarms configured with Amazon SNS provides Email/SMS alerts to System Administrators

Backups

• Custom ops scripts will backup the necessary files from Storage pool to S3 periodically
• S3 can be configured to remove old backups automatically
• RDS MySQL is configured to take periodic data dumps and DB snapshots
• RDS layer can be recovered point in time from the backups

Security

• Suitably hardened OS for WordPress Mgmt and WordPress instances
• Firewall (or) AWS security groups configured between all the layers in the architecture
• SFTP/FTP access only to the WordPress management node
• AWS IAM policies to manage user account access
• Install WordPress Security plugins 

Advantages

• Highly Available and Scalable architecture
• Can elastically scale out to serve millions of hits in a day
• Can grow with load demands in future
• Usage of inherently fault tolerant AWS building blocks adds Stability
• High performance using CDN and suitable cache plugins
• Monitoring , Backup and Recovery is built in
• Pay for use 

Disadvantages

• Complex to setup and maintain
• Will not be ideal for smaller sites that do not need scale
• Will not be cost efficient for sites that have less traffic

Key Points to Remember 

• Log files generated in WordPress EC2 instances have to rotated 
• Use Amazon EBS for Storage Pool and WordPress EC2 instances 
• Start with EC2 m1.Large Instances for the storage pool and WordPress instances
• More Memory – Better Performance for DB
• Start with RDS Large for Master 
• Keep RDS Master and RDS Read Replica’s in same size to improve read performance
• RDS MySQL supports only Innodb engine
• Separate the WordPress Management and WordPress Content instances for scalability
• Do not Scale out/down rapidly in a hour, it will cost more in AWS
• Combine AWS On-Demand and Reserved Instance pricing to get more savings per month
• Amazon Availability Zones(AZ’s) are distinct physical locations with Independent power , cooling ,network and security having Low latency network connectivity between them inside the same region
• Leverage them in WordPress , Storage Pool and DB layers for HA as mentioned in the architecture 

Related Articles:


FAQ for this architecture can be found here (Must read)
Architecting WordPress in AWS : Part 1 : Single Server Setup
Architecting WordPress in AWS : Part 2 : Multi tiered setup
Scaling WordPress in AWS to serve million page hits

Architecting an Highly Available and Scalable WordPress Site in AWS

Why this presentation ?

• WordPress is used by over 14.7% of Alexa Internet's "top 1 million" websites
• As of August 2011 WordPress powers 22% of all new websites
• As of December 2011, version 3.0 had been downloaded over 65 million times
• Provide some architectural insights to build Highly Scalable and Available WordPress sites in AWS
• Help startups and companies who are new to AWS- WordPress with some blueprints

Architecting an Highly Available and Scalable WordPress Site in AWS

View more presentations from Harish Ganesan

FAQ for this architecture can be found here

WordPress Architecture Requirements in AWS

• Ability to Serve millions of Pages per day
• Ability to scale out/down dynamically depending upon traffic
• Ability to perform well even with scaling demands 
• Should be Highly available without Single Points of Failure
• Automated Operations – Backup and Monitoring
• Cost effective 

Why AWS is better for WordPress Scaling?

• AWS provides flexibility to Scale up and Scale out
• AWS provides Building block services which is inherently robust and fault tolerant
• AWS provides full range of options from CDN , OS flavors , Storage Pool , Database , Load Balancers , Monitoring etc
• Pay as you go – Save cost by leveraging Auto Scaled WordPress EC2 instances
• We can start small and grow big in AWS

AWS building blocks used

• Amazon Route53 for managing and answering DNS queries
• Amazon Elastic Load Balancer for load balancing HTTP/S requests to WordPress Instances
• RDS MySQL Database Server for storing the WordPress content
• Simple Storage Service (S3) for storing the WordPress application assets , snapshots and log files
• Amazon CloudFront CDN for delivering the application static assets from nearest edge locations
• Amazon CloudWatch for monitoring and sending SNS alerts

Highly Scalable Architecture for WordPress application

Load Balancing Tier

• Amazon Elastic Load Balancing will Load balance the http requests to WordPress EC2 instances
• ELB will direct the requests to WordPress EC2 across Multiple Availability Zones ( for HA)
• Health check , LB algorithms and SSL termination will be done by the Load Balancer
• Amazon Elastic Load Balancing can keep expanding its capacity automatically depending upon the traffic 
• Amazon ELB works with Route 53 and Auto Scaling seamlessly
• Amazon ELB is priced @“ Pay for use” model
• Amazon ELB is a managed service , so No Maintenance headaches , SW/HW upgrades ,Capacity planning  and manual intervention for expansion

How scalable is this architecture ?

• Scalability and Elasticity is built in most of the layers in this architecture
• WordPress EC2 instances can be scaled out and down depending upon the traffic 
• We can expand the number of WordPress EC2 instances from 1 to 100+ automatically during load peaks
• We can reduce the number of WordPress EC2 instances from 100+ to 1 automatically during valleys
• Can serve millions of pages with ease 
• Pay only for the EC2 instance hours used
• Read Scalability is built in the Database layer with RDS Read Replicas
• New RDS Read Replicas can be added / removed with ease
• Tips:  During Campaigns alone we can run more RDS Read Replicas , Not more than max 5 RDS Read replicas are recommended , Keep Read Replica’s and RDS Master same EC2 size for better performance.

• Clustered + Distributed File System of the Storage pool layer can be manually scaled in case needed
• Minimum 2 EC2 Large instances should be used for Storage Pool Layer ( for HA and better IO)
• Design the Storage Pool Layer with HA (very critical)
• AWS building blocks like S3 , CloudFront , CloudWatch , SNS used in this architecture  are inherently designed for scalability

How High Availability and Fault tolerance is built in this Architecture ?

• HA @ WordPress Layer
• Multiple WordPress EC2 instances avoid single point of failure
• WordPress EC2 instances are launched across multiple –AZ’s inside a region for High Availability
• HA @ DB Layer
• RDS MySQL Master and Standby are launched in 2 different availability zones for High Availability
• RDS Read Replicas are created in Multiple –AZ’s
• HA @ Storage Pool Layer
• GlusterFS is used for the Storage Pool Layer
• Two EC2 instances used for Storage Pool Layer
• Storage Pool is setup in replicated mode for High Availability 
• AWS building blocks like S3 , Cloud Front , CloudWatch , ELB , SNS ,EBS used in this architecture are inherently designed for Fault tolerance and HA

How the Database Tier is Architected ?

• RDS Master and Standby provide High availability
• RDS Read Replicas provide Read performance
• HyperDB plugin is configured to use multiple endpoints like RDS master and RDS read replicas in this architecture
• DB security groups will allow DB access only to WordPress EC2 instances
• Periodic Dumps , Snapshots and Point in time recovery is possible in this architecture

What performance aspects are taken care in this Architecture ?

• APC (or) Xcache plugin can be used for PHP opscode caching
• W3TotalCache+CloudFront (or) BatCache+Memcached can be used for Page caching
• Multiple RDS Read Replicas for Read performance
• RDS Master and Read Replicas are separated to get independent write and read performance
• Amazon ELB + Auto Scaling improves the overall Site performance when the load increases

Content Delivery Network

• Amazon CloudFront will be the Content Delivery Network (CDN) 
• W3TotalCache plugin will be configured to use Amazon CloudFront for enhanced performance and reduced latency
• Static assets , templates , themes , images etc will delivered from the nearest edge locations of the CDN

Deployment

• Distributed File Storage Pool is configured between WordPress Management and Content instances
• WordPress Management and Content instances share the common storage pool for files and plugins
• Deployment of files and plugins will happen through the WordPress management node
• Files and plugins will be immediately available for use in the auto scaled WordPress EC2 instances

Monitoring and Alerts

• Amazon CloudWatch will monitor the CPU and Network utilization of the entire setup
• Amazon CloudWatch alarms configured with Amazon SNS provides Email/SMS alerts to System Administrators

Backups

• Custom ops scripts will backup the necessary files from Storage pool to S3 periodically
• S3 can be configured to remove old backups automatically
• RDS MySQL is configured to take periodic data dumps and DB snapshots
• RDS layer can be recovered point in time from the backups

Security

• Suitably hardened OS for WordPress Mgmt and WordPress instances
• Firewall (or) AWS security groups configured between all the layers in the architecture
• SFTP/FTP access only to the WordPress management node
• AWS IAM policies to manage user account access
• Install WordPress Security plugins 

Advantages

• Highly Available and Scalable architecture
• Can elastically scale out to serve millions of hits in a day
• Can grow with load demands in future
• Usage of inherently fault tolerant AWS building blocks adds Stability
• High performance using CDN and suitable cache plugins
• Monitoring , Backup and Recovery is built in
• Pay for use 

Disadvantages

• Complex to setup and maintain
• Will not be ideal for smaller sites that do not need scale
• Will not be cost efficient for sites that have less traffic

Key Points to Remember 

• Log files generated in WordPress EC2 instances have to rotated 
• Use Amazon EBS for Storage Pool and WordPress EC2 instances 
• Start with EC2 m1.Large Instances for the storage pool and WordPress instances
• More Memory – Better Performance for DB
• Start with RDS Large for Master 
• Keep RDS Master and RDS Read Replica’s in same size to improve read performance
• RDS MySQL supports only Innodb engine
• Separate the WordPress Management and WordPress Content instances for scalability
• Do not Scale out/down rapidly in a hour, it will cost more in AWS
• Combine AWS On-Demand and Reserved Instance pricing to get more savings per month
• Amazon Availability Zones(AZ’s) are distinct physical locations with Independent power , cooling ,network and security having Low latency network connectivity between them inside the same region
• Leverage them in WordPress , Storage Pool and DB layers for HA as mentioned in the architecture 

Related Articles:


FAQ for this architecture can be found here (Must read)
Architecting WordPress in AWS : Part 1 : Single Server Setup
Architecting WordPress in AWS : Part 2 : Multi tiered setup
Scaling WordPress in AWS to serve million page hits