I gave a brief intro about using AWS to our Mozilla Knight News Fellows.

1. AWS Fun

2. A short bit of history
● Not that long ago, a "server" was :
○ One piece of hardware
○ One operating system
○ Physically racked, powered, networked in a
managed datacenter
● People started playing with "virtualization"
○ One piece of hardware
○ Multiple operating systems running independently
○ Physically racked, powered, networked in a
managed datacenter

3. As virtualization was taking off...
● Mid-2000's, Amazon.com buys a TON of
hardware.
● The mantra for the folks building Amazon.
com infrastructure:
Provide service style endpoint access to
infrastructure management for internal use.
EVERYTHING IS AN API

4. At the same
time....
Marketing depts
everywhere go
to town, as
marketing does...
VIRTUALIZE
IT
ALL!!!!

5. Amazon Realizes...
If we run the virtual server hosts...
And we just open up our internal infrastructure
API's to end users...

6. $$$$$$$$$$$$$$$$$$$$$$$$$$

7. Marketing took over,
now everything is Cloud.

8. By Cloud, I mean....
● Must be distributed.
● Must be programatically accessible
● Is multi-tenanted (you are not the only user
of the hardware)

9. In general, what is AWS?
● A collection of commonly used pieces of
software, made easily accessible in:
○ Distributed environment: Multiple Availability zones
per region, multiple regions
○ Programatically accessible infrastructure
For example: Mysql, MS SQL, Memcached, Linux,
Windows,
CDN, DNS Management, User/Admin management,
Firewalls, Load balancers...

10. Common components
of infrastructure
in your old datacenter

11. Common components
of infrastructure
in AWS

12. Some of what this buys us
● We can spin up replica environments
● Easier functional testing...in STAGING
● Load test against prod without touching prod
● Build in automated deployments and testing,
making pushing to prod a breeze for all
devs.
● This makes the feedback loop tighter, faster,
and keeps changes and their inevitable bugs
more in context
● This all wraps up to make you, the devs,
more confident to try new things.

13. Controlling all of that infrastructure

14. Lots of configuration management
options....
● Chef (Opscode)
● Puppet (What I use)
● AMI's (Server images)
● Cloudformation (AWS Service)

16. But wait...isn't the cloud dangerous?
● Yes! Just as dangerous as your datacenter
● Secrets stores in S3, managed by puppet
● Each app has its own key, security groups
● Managing security via security groups, ssh
keys

18. General scaling on AWS
● Use autoscale groups (even if you never
have to autoscale)
● You can trigger autoscaling on any metric
● Use EBS and instance store autoscale
groups
○ 30 seconds to "traffic ready" prebuilt EBS instance
vs. 2-10 min for a instance store
○ Keep a baseline # of instance store nodes, for when
EBS has issues.
○ You can have multiple autoscale groups load into
one ELB (so, app-ebs-fastscale-group and app-
instancestore-noscale-group)

19. General scaling on AWS
● For high IO data (RDS or self-managed
EC2), use provisioned IOPS.
● On EC2, EBS volumes can be RAID10'd...
need a 50k IOPS volume? :D Great way to
vertically scale.
●

20. General scaling on AWS
● Adhere to 12factor.net rules so you can
horiziontally scale
○ CNAME all resources, such as mysql servers. If you
can easily move a resource, you can easily vertically
scale it elsewhere and move to it.
○ Store dependent content away from web tier nodes,
ie media, user uploads. If a web node dies and you
lost anything, you did it wrong.
○ All pieces of app modular, independently scalable
and revvable without retooling

22. General High Availability on AWS
● Multi-Region (Each region has multiple AZ's)
● Multi-Availability Zone for
○ RDS (built in) (takes ~3 min to failover)
○ Load balancing
○ Autoscaling groups (3 AZ's recommended)
● Dynamic DNS
● Health Checks on apps

23. General High Availability on AWS
● Mix in instance store baseline with EBS for
fast scaling for when EBS has issues.
● Health Checks on apps
● Status updates to S3 file, updates app to
point to failover resources... No db? Write
to a SQS queue!
● Oh yeah, use a lot of SQS!

27. CNAME for all the resources (12-
factor friendly)

28. Easier to move, failover, rebuild

29. RDS Tricks
● Multi-AZ, takes ~3 min to failover
● EBS volumes of greater storage get better
performance, always use 300gb for prod,
even for small instances.
● Read slaves have a lot of challenges with
schema changes. It is usually faster to just
rebuild slaves
● For monitoring, grant repl client to user

30. Some other tricks
● ELB's are EBS-backed EC2 Instances...when EBS
alerts go out, be careful!
● Setup ifttt alerts for AWS RSS status updates
● Use New Relic. Please!
● IAM Roles allow for interaction with AWS
infrastructure...think, a monitoring server that tells an
autoscale group to respond to a problem by launching
new nodes
● Route53 is awesome. Alias A records, super reliable,
you can keep low ttl's

31. Pay Amazon Less
● Reserved instances can save a lot of money
● Spot instances are great for batch and
processing, EMR, Cluster Compute
● S3 static hosting is ridiculously inexpensive.
Go that route for anything static.
● For dev work, Heroku is great, no cost for
apps that do not scale

32. Other random advice...

33. Good stuff
● http://www.12factor.net/
● http://paulstamatiou.com/how-to-getting-started-with-
amazon-ec2
● http://loggly.com/blog/2011/05/send-custom-metrics-to-
cloudwatchs-api/
● https://github.com/toolness/fleeting
● AWS Marketplace has a lot of good stuff
● My example repos: https://github.
com/mozilla/sys_config_examples and https://github.
com/mozilla/sys_scripts_examples
● https://help.ubuntu.com/community/CloudInit
● http://awsofa.info/
●

34. Demo time (if there is time)
-Building a new autoscale group/app?
-Managing infrastructure via fabric, jenkins,
puppet
-Show off the puppet systems config setup?