allBlogsList

Deploying Sitecore on Amazon Web Services AWS

Overview

Sitecore’s Customer Engagement Platform (Sitecore) is an enterprise class web content management system that provides an elegant, integrated solution for content management for websites, engagement automation and analytics. Amazon Web Services (AWS) is a leader in reliable, scalable, and inexpensive cloud computing services. AWS offers an excellent platform for hosting and running Sitecore in a cloud environment.

This blog discusses design considerations and techniques for deploying Sitecore on AWS. Following areas are covered:

  • General Sitecore architecture
  • AWS Sitecore architecture
  • Additional AWS considerations
  • Estimating AWS cost

Following areas have been left out from this blog:

  • Build and change management
  • Disaster Recovery
  • Active Directory integration
  • VPN connectivity and configuration with internal network
  • Clustered MS SQL database

General Sitecore Architecture

Basic Sitecore Setup (Two-Servers)

A basic Sitecore setup has two servers

CMS server (application server)

  • Windows Server running IIS
    • IIS runs Sitecore content delivery (CD) server – the actual website
    • IIS also runs Sitecore content management (CM) server – the content authoring environment

Database server (generally MS SQL, Oracle is supported as well) running following databases

  • Master – The Master database is the authoring database – it contains all versions of any content or assets
  • Core – The Core database contains Sitecore application items and settings, as well as the tables containing the .Net membership provider (i.e. users/roles contained in the Sitecore repository)
  • Web – The Web database is only the latest published version of the content that is driving the live web site. Therefore it is a subset of the master database, optimized for size and speed. When content is published, or goes through the publishing task of a workflow, the latest content version is copied from the master to the web database.
  • Analytics – The Analytics database holds all information related to Sitecore Digital Marketing Suite – analytics, personalization, etc.

The recommended hardware requirements for these servers are:

  • 4 core processor
  • 4 GB of RAM

For smaller sites and development/integration/QA instances, it is common to run both the CMS server and database server on a single server.

Figure 1. Basic Sitecore Setup

For more information on installing Sitecore please refer to: [Sitecore Installation Guide](http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%207/Installation.aspx "Sitecore Installation Guide")

Six-Server Sitecore Setup

For mid to enterprise sites, six servers setup is a standard practice.

Figure 2. Six-Server Sitecore Setup

Integration Environment

  • Integration environment is used by the development team for running the latest code, content and services
  • Generally a deployment server will do automated builds and deployment to the integration server
  • Developers’ instances of Sitecore will reference the integration Sitecore database in order to ensure a single version of Sitecore data
  • Sitecore CM and CD server and database server will be deployed on a single server

QA Environment

  • QA server is used for testing latest code releases, content and services
  • Generally deployment server will do automated builds and deployment to the QA server.
  • Sitecore packages will be deployed from Integration to QA
  • Sitecore CM and CD server and database server will be deployed on a single server

Production Content Management (CM) Environment

  • Tested code and Sitecore packages are deployed to the Content Management (CM) server for final UAT
  • This environment is also used by content authors to create and edit pages/content, and preview and test them
  • Generally deployment server will do automated builds and deployment to the CM server
  • Sitecore CM and database server will be deployed on a single server

Production Content Delivery (CD) Environment

  • Content Delivery (CD) server runs the actual site
  • It is recommended that 2 CD servers be used with a load balancer for scalability and higher up-time
  • Generally deployment server will do automated builds and deployment to the CD servers
  • Approved content can be published from CM server to multiple CD servers manually or using a workflow
  • Each CD server will be deployed on a separate server (total 2 servers) and database server will be deployed on a separate server

Note: Additional information on standard Sitecore server configuration and scaling can be found on

AWS Sitecore Architecture

Mapping Six-Server Configuration to AWS

*Depending on the website traffic, content and analytics, the database size will vary.

AWS Architecture

Figure 3. Six-Server Sitecore AWS Setup

  1. EC2: Elastic Compute Cloud
  2. VPC: Virtual Private Cloud
  3. VPN: Virtual Private Network
  4. S3: Simple Storage Service
  5. EBS: Elastic Block Storage
  6. RDS: Relational Database Service
  7. The AWS setup assumes all servers are setup in a single region and availability zone
  8. The overall environment is setup as a virtual private cloud (VPC)
  9. Integration, QA, CM, CD and CD RDS are setup as individual VPC subnets
  10. Not covered in this post, but any connectivity to client network can be done using VPN
  11. Internet gateway is used for handling any public traffic (generally to the CD servers over port 80 and 443)
  12. EC2 CD1 and CD2 servers will be load balanced using an Elastic Load Balancer (ELB)
  13. RDS CD will serve as the production database for the two CD servers. Note: AWS does offer multi-AZ RDS which is not covered in this post
  14. RDS CD will have its own VPC subnet
  15. All EBS instances will be backed-up to Simple Storage Service (S3) using backup scripts or 3rd-party tools
  16. Not covered in this post, but security and access can be configured using Identity Access Management (IAM), Access Control Lists (ACLs) and routing rules and tables
  17. This post assumes DNS is managed outside of AWS

Pricing AWS Configuration

Elements Considered for Pricing

Region

US-East / Virginia

Elastic Compute Cloud (EC2) Instances

  1. Used for Integration, QA, CM and 2 CD servers (5 instances)
  2. M3.xlarge (M3.xlarge (4 vCPU, 15 GiB, 2 * 40 GB SSD), EBS optimized
  3. Windows 2008 R2, 64-bit
  4. MS SQL 2008 Web Edition, 64-bit
  5. 3 years heavy reserved instance
  6. 100 GB EBS volumes attached to each EC2 instance
  7. 5 elastic IPs
  8. 10 GB/month data transfer out
  9. 10 GB/month data transfer in

Elastic Load Balancer (ELB)

  1. 1 ELB
  2. Total data processed 20 GB/month

Simple Storage Service (S3)

  1. Storage 100 GB
  2. Put/Copy/Post/List Requests 10,000
  3. Get and other requests 100

Relational Database Service (RDS)

  1. 1 instance for production database (note: another option would be to run regular MS SQL Web server on EC2 instance)
  2. db.m3.xlarge (4 vCPU, 15 GiB, Standard IOPS)
  3. SQL Server Web
  4. 100 GB storage
  5. 3 years heavy reserved instance
  6. Backups are managed by AWS up to 100 GB

Virtual Private Cloud

  1. 1 VPC
  2. 100% utilized
  3. Data transfer out 100 GB/month
  4. Data transfer in 10 GB/month

Support

Basic support

3-Year Pricing

Note: These are estimated representative pricing. For more information please visit the AWS pricing calculator used for this model: [AWS Pricing Calculator](http://calculator.s3.amazonaws.com/index.html#r=IAD&key=calc-FD546A4C-46B8-4722-B000-0EA40710869B "AWS Pricing Calculator")

Elements not considered in pricing

  1. No Simple Email Service (Most of the sites need some email service/access to SMTP server)
  2. No BYOL (Bring Your Own License) for SQL or Windows (AWS allows this and this can reduce the overall cost)
  3. No Route 53 (AWS DNS service)
  4. No caching (AWS CloudFront)
  5. Basic monitoring, no CloudWatch
  6. Basic support (Premium support is available)
  7. No anti-virus
  8. No IDS (Intrusion Detection System)
  9. No Disaster Recovery site
  10. No multi-region, multi-availability zone setup