Your First Week with Amazon EC2

Don Southard

Solutions Architect

April 18, 2013

Your First Week on Amazon EC2

A hands on approach to understanding

Amazon EC2 and the cloud

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?

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

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

148.20.57.0/24 SSH 22

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

Day 1 – Choose AMI

Day 1 – Instance Details

Day 1 – Instance user-data

Day 1 – Tags

Day 1 – Create Key Pair

Day 1- Configure Firewall

Day 1 – Instance Launched

Day 1 – Application Tasks [laptop]$ ssh -i ~/ec2.pem ec2-user@ec2-54-242-253-200.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 httpd mysql-server ruby19 git

[ec2-user@ip-10-40-203-29 ~]$ sudo service mysqld start

[ec2-user@ip-10-40-203-29 ~]$ sudo /etc/init.d/httpd start

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 Web Console 4. Chose an AMI 5. Launched an EC2 instance 6. Setup application

• How can we capture our work efforts to make them repeatable or recover from failure?

• What options do we have for setting up a tiered architecture?

• How can we apply security to our instances?

Day 2 – Create a tiered architecture

Region

Availability Zone

Snapshot Amazon S3

Internet

User

HTTP (80)

Source Protocol Port

0.0.0.0/0 HTTP 80

148.20.57.0/24

SSH 22

Connection Type Details

EC2 Security Group

web-tier-sg

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

Day 2 – Create a snapshot of our AMI

Day 2 – New AMI

Day 2 – Launch RDS DB Instance

Day 2 – RDS DB Instance Details

Day 2 – RDS Management Options

Day 2 – Granting EC2 App Access to RDS

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>

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?

Day 3 – Monitor Environment

Region

Availability Zone

Internet User

Amazon CloudWatch

Users

Alarm

Administrator

Email Notification

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

Day 3 – Create Alarm

Day 3 – Create Alarm

Day 3 – Create Alarm

Day 3 – Create Alarm

Day 3 – Alarm Created

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?

Day 4 – Designing for High Availability

Region

Availability Zone

Internet

Amazon CloudWatch

Users

Alarm

Availability Zone

RDS DB Standby

Auto scaling Group

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)

Day 4 – Define Load Balancer

Day 4 – Configure Health Check

Day 4 – Add EC2 Instance(s)

Day 4 – Elastic Load Balancer is Active

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

Day 4 – Find That AMI We Created

Day 4 – Set Up Auto Scaling

[laptop]$ as-create-launch-configuration webcfg \

--image-id ami-08dc4461 --instance-type m1.small \

--region us-east-1

[laptop]$ as-create-auto-scaling-group webscg \

--launch-configuration-name webcfg \

--availability-zones us-east-1a us-east-1c \

--min-size 2 --max-size 10 --load-balancer-names frontlb

Day 5 – Setup Auto Scaling continued

[laptop]$ as-put-scaling-policy WebScaleUpPolicy \

--auto-scaling group webscg \

--adjustment=1 --type ChangeInCapacity --cooldown 300

[laptop]$ mon-put-metric-alarm WebHighCPUAlarm \

--comparison-operator Greater ThanThreshold \

--evaluation-periods 1 --metric-name CPUUtilization \

--namespace "AWS/EC2" --period 600 \

--statistic Average --threshold 80 \

--alarm-actions POLICY-ARN_from_previous_step \

--dimensions "AutoScalingGroup Name=webscg"

Day 4 – Check on Our Instances

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. :)

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?

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

Template Stack

images.example.com

Day 5 – Route 53 (DNS)

Day 5 – Identity & Access Management

Day 5 – Deployment Automation

First Week on Amazon EC2

• Evolution from Day 1 Day 5

– Single AMI Tiered Monitored 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

…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

• VPC, 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/

Your First Week on Amazon Elastic Compute Cloud A hands on approach to understanding Amazon EC2