Hosting Drupal on
Amazon Web Services (AWS)
Heather Wozniak, Ph.D.
Questions, questions
• How many servers and Drupal sites do we
support?
• Why did we choose AWS?
• How much does it cost?
• How do we manage the servers?
How many servers do we support?
• Staging server (micro) – 24x7
• Production server (medium) – 24x7
How many Drupal sites do we support?
• In production, as of 5/14/2014
16
• On staging, as of 5/14/2014
25
• Combined prod + staging
41
• Our web team does all the technical support and Drupal
configuration. Departmental staff only add and manage
content. We have trained 75+ web editors.
The path to AWS…
• depts.washington.edu– Can’t have multisites + custom subdomains + SSL – Performance and stability issues
– Each custom subdomain costs $50 per year
• Standard Managed Server
– Too expensive for a pilot project
– Pricing not competitive with third-party managed VPS – Still requires some server ops knowledge
• Managed VPS
– Still requires some server ops knowledge – Long wait for support to make changes
The path to AWS…(cont.)
• We have to do this ourselves. Yikes!– Buy our own box? – Non-managed VPS?
– Standard Hosted Server? Wasn’t available yet. – Cloud computing?
• Let’s try AWS
– Minimal cost + maximum flexibility
– About a month to get everything fully configured – AMI (Amazon
Machine Image) with LAMP, backup scripts, virtual hosts, APC, Drupal multisites, etc.
How much does it cost?
• 2 continuous servers + ad hoc dev servers +
local backups + AWS snapshot backups =
$1,977.30 over last 12 months
$164.78 average per month
$4.05-$6.48 per prod site, per month
How does that compare to SMS and SHS?
• If one slice for staging and two for production (similar to AWS micro and medium instance), not including snapshots or off-site backups, or ad hoc instances:
• Standard Managed Servers:
Approx. $466/month + initial setup ($1100 x 2) • Standard Hosted Servers:
How do we manage the servers?
• A single AMI serves as base for all servers.• The AMI has an instance volume, containing the OS and
LAMP stack, and a data volume, containing the MySQL data, Drupal/web directories, and local backups.
• Three layers of backups:
– Data volumes are backed up nightly via AWS snapshot.
– MySQL databases and web files are backed up nightly on the local data volume.
How do we manage the servers?
• All changes that should persist are made on the AMI.– Examples: add new virtual hosts, add new SSL certificate,
update backup scripts.
• Some AMI configuration files are stored in git repos.
• Occasionally we launch new instances from the AMI. Backup scripts and cronjobs are manually configured each time.
• Each server has a single IP address.
– A single SSL certificate is shared across all servers.
How do we manage the Drupal sites?
• Majority of Drupal sites belong to one multisite installation • Every site has a drush alias• Drupal core and contrib modules are managed in a git repo
– Drupal core updates are fetched and merged from Drupal remote – Contrib modules are updated via drush
• Custom modules are added to the repo as git submodules
– Each custom module has its own project history
– Custom modules can be installed independently on other sites
Pro’s of AWS
• Lots of flexibility• Create dev and testing servers on the fly, without worrying about breaking things
• Identical staging/dev/production servers
• Not affected by local weather/power outages
• Cost effective, no setup fees, no lifecycle/replacement costs • Increase instance and data volume size according to need • Room for growth – RDS, autoscaling, cross region
Con’s of AWS
• Had to learn server ops• Server maintenance takes away from Drupal dev/support • Risk – are we doing it right?
• Responsibility if it fails
• AWS adds some overhead on top of standard server ops • Local dev is harder – doesn’t mirror server
