Amazon Elastic Compute Cloud (Amazon EC2) provides resizable compute capacity in the cloud and is often the starting point for your first week using AWS. This session will introduce these concepts, along with the fundamentals of EC2, by employing an agile approach that is made possible by the cloud. Attendees will experience the reality of what a first week on EC2 looks like from the perspective of someone deploying an actual application on EC2. You will follow them as they progress from deploying their entire application from an EC2 AMI on day 1 to more advanced features and patterns available in EC2 by day 5. Throughout the process we will identify cloud best practices that can be applied to your first week on EC2 and beyond.

1. Adrian White
Your First Week on Amazon EC2
Solutions Architect, AWS
Steven Stones-Havas
Senior Developer, Biomatters
Guest presenter:

2. Questions for Your First Week on Amazon EC2
• What is Amazon EC2?
• Where do I start with EC2?
– What are the components of EC2?
– What are the big picture architecture cloud patterns?
– What other Amazon Web Services should I use?
• How do I map my existing infrastructure architecture to EC2?
– How do I configure my environment for high availability?
– How do manage my environment in the cloud?
– How do I monitor my environment in the cloud?

3. An Approach to Your First Week on Amazon EC2
• Leverage what you already know about web architectures
• Understand enough to get started with EC2
• Take an iterative approach
– Refactor and evolve
– Pay for what you use
• Understand and apply cloud best practices
– Capacity on demand
– Elasticity
– Design for failure
– Infrastructure automation

4. Day 1 – Identify and Deploy Application on EC2
Region
Availability Zone
Linux
Apache
Ruby
MySQL
Source Protocol Port
0.0.0.0/0 HTTP 80
0.0.0.0/0 SSH 22

5. Day 1 – Launching Your First EC2 Instance
1. Login to the AWS Management Console and go to the Amazon EC2 console
2. Choose an Amazon Machine Image (AMI)
3. Choose an instance size
4. Create a key pair for SSH access
5. Create port-based security rules
6. Launch instance
7. Upload code

6. Day 1 – Choose AMI

7. Day 1 – Instance Details

8. Day 1 – Tags

9. Day 1 – Create Key Pair

10. Day 1 – Configure Firewall

11. Day 1 – Instance Launched

12. Day 1 – Application Tasks
[laptop]$ ssh -i ~/ec2.pem ec2-user@ec2-54-242-199-31.compute-1.amazonaws.com
__| __|_ )
_| ( / Amazon Linux AMI
___|___|___|
https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
There are 13 security update(s) out of 24 total update(s) available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-40-203-29 ~]$ sudo yum -y -q update
[ec2-user@ip-10-40-203-29 ~]$ sudo yum -y -q install mysql-server ruby19
[ec2-user@ip-10-40-203-29 ~]$ sudo service mysqld start
Starting mysqld: [ OK ]

13. Day 1  Day 2
Day 1 Recap Day 2 Considerations
1. Created an AWS account
2. Identified an application for cloud
deployment
3. Logged into the Amazon EC2 console
4. Chose an AMI
5. Launched an EC2 Instance
6. Set up application
• What options do we have for setting
up a tiered architecture?
• How can we apply security to our
instances?
• Are there options for serving static
content?
• How can we capture our work efforts
to make them repeatable?

14. Day 2 – Create a tiered architecture
Region
Availability Zone
Snapshot Amazon S3
Internet
User
HTTP (80)
Source Protoco
l
Port
0.0.0.0/0 HTTP 80
0.0.0.0/0 SSH 22
Connection Type Details
EC2 Security
Group
web
S3 Bucket

15. Day 2 – Launching a Tiered Web Application
1. Snapshot EC2 Instance
– Stop MySQL
– Bundle New AMI
2. Create a Relational Database (RDS) Instance
– We’ll use MySQL
– Other options: Oracle, SQL Server
3. Configure App to Use RDS MySQL Database

16. Day 2 – Create a snapshot of our AMI

17. Day 2 – RDS DB Instance Details

18. Day 2 – RDS Management Options

19. Day 2 – Granting EC2 App Access to RDS

20. Day 2 – Connect to RDS Database
[ec2-user@ip-10-40-203-29 ~]$ mysql -uroot –p –D devdb
–h nonprod.ctjsifycx3sq.us-east-1.rds.amazonaws.com
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 268
Server version: 5.5.27-log Source distribution
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql>

21. Day 2 – Connect to RDS Database (encrypted)
[ec2-user@ip-10-40-203-29 ~]$ wget https://rds.amazonaws.com/doc/mysql-ssl-ca-cert.pem
[ec2-user@ip-10-40-203-29 ~]$ mysql -uroot –p –D devdb
–h nonprod.ctjsifycx3sq.us-east-1.rds.amazonaws.com
--ssl_ca=rds-ssl-ca-cert.pem
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 269
Server version: 5.5.27-log Source distribution
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql>

22. Day 2  Day 3
Day 2 Recap Day 3 Considerations
1. Took a snapshot of AMI as a backup
2. Created an RDS MySQL Database
3. Created and validated security groups
• What tools does AWS provide to
monitor EC2 and RDS?
• How can we better monitor the our
environment (proactive vs. reactive)?
• How can we be notified when our
servers hits certain thresholds?

23. Day 3 – Monitor Environment
Region
Availability Zone
Internet User
S3 Bucket
Amazon
CloudWatch
Users
Alarm
Administrator
Email Notification

24. Day 3 – Create CloudWatch Alarm
1. Select metric to monitor
– Database write latency is an accurate indicator of our application’s health
2. Define a threshold
– Write latency that exceeds 500ms typically requires some intervention on our part
3. Create a topic for our alarm and subscribe to the topic via email

25. Day 3 – Create Alarm

26. Day 3 – Create Alarm

27. Day 3 – Create Alarm

28. Day 3 – Alarm Created

29. Day 3  Day 4
Day 3 Recap Day 4 Considerations
1. Identified CloudWatch metrics
available for EC2 and RDS
2. Created a CloudWatch alarm
3. Set up alarm to email on failure
4. Reviewed CloudWatch dashboard
• What happens if our EC2 instance
fails?
• What happens if an entire AZ is
unavailable?
• How can we elastically scale based
on increased/decreased traffic?
• What happens if our primary RDS
instance fails?

30. Day 4 – Designing for High Availability
Region
Availability Zone
Internet
S3 Bucket
Amazon
CloudWatch
Users
Alarm
Availability Zone
RDS DB Standby
Auto scaling Group

31. Day 4 – Steps to High Availability
1. Create an Elastic Load Balancer (ELB)
– Balances traffic across multiple EC2 instances
– Enables running instances in multiple Availability Zones (AZ’s)
2. Configure Auto Scaling
– Automatically scale up if demand increases
– And scale down to save money
3. Setup RDS Multi-AZ
– Synchronous replication to standby in another AZ
– Automatic fails over if needed
– Also minimizes backup window (slave is used)

32. Day 4 – Define Load Balancer

33. Day 4 – Configure Health Check

34. Day 4 – Add EC2 Instance(s)

35. Day 4 – Elastic Load Balancer is Active

36. Day 4 – Configure Auto Scaling
1. Use the Amazon Machine Image (AMI) we created
2. Leverage multiple Availability Zones
– Distribute instances across two AZ’s
– Ensure at least two instances are up
3. Create an Auto Scaling trigger
– Same concept as CloudWatch alarm from earlier
– Just now we’re proactively taking action

37. Day 4 – Find That AMI We Created

38. Day 4 – Set Up Auto Scaling
[laptop]$ aws autoscaling create-launch-configuration
--launch-configuration-name webcfg
--image-id ami-08dc4461 --instance-type m1.small
--region us-east-1
[laptop]$ aws autoscaling create-auto-scaling-group
--auto-scaling-group-name webscg
--launch-configuration-name webcfg
--availability-zones us-east-1a us-east-1c
--min-size 2 --max-size 10 --load-balancer-names frontlb

39. Day 4 – Check on Our Instances

40. Day 4 – Set Up RDS Multi-AZ
[laptop]$ aws rds modify-db-instance
--db-instance-identifier nonprod
--multi-az --region us-east-1
Yep, that’s it.
No mouse required. :)

41. Day 4  Day 5
Day 4 Recap Day 5 Considerations
1. Spread our application across
Availability Zones.
2. Automated scaling across availability
zone leveraging Auto Scaling.
3. Implemented load balancing via AWS
Elastic Load Balancing.
4. Implemented a highly available
database by applying RDS multi-AZ.
• How do we make use of a custom
DNS domain for our load balancer?
• How can we configure accounts for
other AWS users?
• How can we template and replicate
our server environment?

42. Day 5 – DNS, Identity & Access Management, Deployment Automation
Region
Availability Zone
Internet
S3 Bucket
Amazon
CloudWatch
Users
Alarm
Availability Zone
RDS DB Standby
AWS IAM
www.example.com
AWS Management
Console
AWS
CloudFormation
TemplateStack

43. Day 5 – Route 53 (DNS)

44. Day 5 – Identity & Access Management

45. Day 5 – Deployment Automation

46. First Week on Amazon EC2
• Evolution from Day 1  Day 5
– Single AMI  Monitored  Tiered  HA  DNS, IAM, Automation
• Cloud architecture best practices implemented in week 1 on EC2
– Proactive scaling – Auto scaling triggers
– Elasticity – EC2
– Design for failure – ELB, Auto scaling groups, Availability Zones
– Decouple your components – EC2, RDS
– Infrastructure automation – CloudFormation

47. …and Beyond
• Moving beyond week 1 on EC2
– AWS Management Console is great but you have other options
• Command Line Interface
• API
– Other AWS Services
• Elasticache, OpsWorks, Beanstalk, DynamoDB, SQS
– Operational Checklist
• http://media.amazonwebservices.com/AWS_Operational_Checklists.pdf
– Deployment Automation
• http://aws.amazon.com/cloudformation/aws-cloudformation-articles-and-tutorials/
– Links to whitepapers and architectures
• http://aws.amazon.com/whitepapers/
• http://aws.amazon.com/architecture/

48. And now, a customer who went beyond…

49. BIOMATTERS
Steven Stones-Havas
Senior Developer, Biomatters

50. • Founded in 2003
• Sophisticated, intuitive Visualisation and Interpretation of
Genetic data
• Targeted Analysis Workflows
• Actionable Results
• We’d love to talk to you!

52. Genome Browser - Requirements
• Smooth, intuitive experience in the browser
– JavaScript/HTML5
– Mobile friendly
• Tile Rendering
– Like Google Maps
– Requires fast database lookups
• Secure
– Data must be encrypted at rest and in transit
• Local-deployable
– Some customers not ready for cloud

53. Architecture
• Initial Architecture
– On EC2
– One autoscaling group (and ELB)
– One Availability Zone
• Revised Architecture
– VPC across two Availability Zones
– Private subnets for security

54. VPC Architecture
ELB
Public Subnets Private Subnets
AZ 1
AZ 2
MASTER
MIN=0 MAX=2
MIN=1 MAX=3
DB Cluster
Internet
NAT

55. Web Stack
• Tomcat behind Apache
• Session info stored in Elasticache
• Monitoring
– Healthcheck Ping URL for the load balancer
– Cloudwatch CPU alarms for autoscaling
• Autoscaling
– Scales from 2 to 6 machines depending on load
– For > 6 machines, the database becomes the bottleneck
• Deployment
– Automatic deployment with no downtime

56. Automatic Deployment
1. Deploy latest code to master web node (through Tomcat
manager)
2. Shutdown master tomcat
3. Take AMI snapshot
4. Restart master webnode, and wait for ping URL to respond
5. Teardown existing autoscaling config
6. Set up new autoscaling config

57. Database
• Local Deployment Requirement
– Can’t use RDS or Dynamo
• MongoDB
– Highly scalable NoSQL
– Supports Advanced features

58. Database
• Base unit – pair of 50GB volumes in Raid0
• 100GB Logical Volume (LVM)
• Encryption Layer
• XFS File System
– Can grow without unmounting
• Scaling
– Storage scaling is manual
– Performance scaling could be automatic
• Need to scale preemptively

59. Job Processing
DB Cluster
Incoming Job QueueWeb App
Processing Node
Completed Job Queue
Notification Node
S3
Status=NEW
Status=PROCESSINGStatus=COMPLETE
Status=NOTIFIED

60. Overview
• Multi-Availability Zone VPC with public and private subnets
• ELB in front of Auto-Scaling web nodes
• Statically scaled MongoDB Cluster
• Encrypted volumes
• Simple Queue Service for job processing
• We’d love to talk to you!

61. AWS Support
Steven Day
Site Leader, AWS Support

62. Built on top of Legacy of Customer Obsession

63. AWS Support is a Global Organization
with an Australian presence
Current Sites
2013 Expansion
Remote TAM
Our team consists of professional,
highly skilled engineers with
locations in North America,
Europe, Australia, Asia and Africa.

64. Support Product Feature
Matrix
• Different levels of support to
match the support needs of our
customers

65. More Than Just Break-fix
• AWS Support is much more than traditional, reactive troubleshooting.
• In addition to 24/7/365 reactive break-fix with highly skilled engineers,
support subscriptions includes an unlimited number of cases to:
1. Help you get started with AWS
2. Get recommendations to be more secure, lower cost, and more available
3. Discuss your architecture and best practices
4. Ask questions on how to successfully integrate the 150+ annual AWS feature releases
5. Configuration help for a growing list of 3rd Party Software

66. Support Center & Trusted Advisor APIs
• Customers can use their existing ticketing systems to manage their
support cases, receive case updates, and access AWS TA results.
• April 30th: Announcing General Availability of Support Center and
Trusted Advisor APIs

67. Thank you!