At Puppet Labs, we're running our own Drupal web infrastructure on AWS. This talk will describe the architectural decisions we've made, our operational experience, and specific implementation details. This will be an advanced talk for developers with modest operational experience, or a beginner-to-intermediate-level talk for people with strong web operations experience.

Specifically, we'll walk through the puppetlabs.com infrastructure and talk about:

why we're hosting our own, rather than using one of the many excellent Drupal hosting services
what AWS services we're using (RDS MySQL, EFS for NFS) and why we decided to run our own haproxy failover cluster rather than using Elastic Load Balancers
why we got rid of varnish and memcached
how we use haproxy to mitigate high-volume account registration spam attempts
how our puppet-based workflow has allowed web developers to drive changes to production, without blocking (much) on operations
how puppet-based provisioning of AWS resources allows us to treat infrastructure as disposable, ephemeral nodes
how we trace problems thorughout the stack by injecting UUID headers at the load balancer
where our solution falls short compared to hosted options we've evaluated
The objective of this talk is to share our experiences and thought processes. The particular decisions we made may not be appropriate for everybody, but the questions that drove those decisions will apply to nearly everybody who's deciding whether to host their own infrastructure on AWS or outsource it to a hosted service.