masterclass webinar: amazon ec2

Masterclass

Elastic Compute Cloud

Ryan Shuttleworth – Technical Evangelist @ryanAWS

A technical deep dive beyond the basics Help educate you on how to get the best from AWS technologies

Show you how things work and how to get things done Broaden your knowledge in ~45 mins

Masterclass

On-demand compute to run application workloads Easy come easy go – disposable resource

We provide the infrastructure, you decide what you run

Amazon EC2

What is EC2?

Elastic capacity Flexible

Complete control

Reliable

Inexpensive

Secure

Securely segregated

Shared environment

Elastic capacity

Physical Interfaces

Customer 1

Hypervisor

Customer 2 Customer n …

… Virtual Interfaces

Firewall

Customer 1

Security

Groups

Customer 2

Security

Groups

Customer n

Security

Groups

AMI

Amazon Machine Image

AMI


Instance

Running or Stopped machine

AMI


Instance


VPC

EC2

AMI


Instance


VPC

EC2

AZ

Region

AMI


Instance


VPC

EC2

AZ Availability Zone

VPC

EC2

Region

AMI


Instance


VPC

EC2


EBS EBS EBS

VPC

EC2

EBS EBS EBS

Region

AMI


Instance


VPC

EC2


S3

EBS EBS EBS

VPC

EC2

EBS EBS EBS

EBS Snapshots

S3 Buckets

Region

Instance

Instance Unit of scale

Unit of resilience

Unit of control

Instance Unit of scale

Unit of resilience

Unit of control

Your stack

Instance

Instance

Instance

Instance

Unit of scale

Unit of resilience

Unit of control

Scal

e o

ut

Instance

Instance

Instance

Instance

Unit of scale

Unit of resilience

Unit of control

Instance

Instance

Instance

Unit of scale

Unit of resilience

Unit of control

Instance

Instance

Instance

Unit of scale

Unit of resilience

Unit of control

Instance

Instance types Choose the right unit for your workload

256

128

64

32

16

8

4

2

1

1 2 4 8 16 32 64 128 256

High I/O 4XL 60.5 GB 35 EC2 Compute Units 16 virtual cores 2*1024 GB SSD-based local instance storage

EC2 Compute Units

Me

mo

ry (

GB

)

Small 1.7 GB, 1 EC2 Compute Unit 1 virtual core

Micro 613 MB Up to 2 ECUs (for short bursts)

Large 7.5 GB 4 EC2 Compute Units 2 virtual cores

Hi-Mem XL 17.1 GB 6.5 EC2 Compute Units 2 virtual cores

Hi-Mem 2XL 34.2 GB 13 EC2 Compute Units 4 virtual cores

Hi-Mem 4XL 68.4 GB 26 EC2 Compute Units 8 virtual cores

High-CPU Med 1.7 GB 5 EC2 Compute Units 2 virtual cores

High-CPU XL 7 GB 20 EC2 Compute Units 8 virtual cores

Medium 3.7 GB, 2 EC2 Compute Units 1 virtual core

M3 XL 15 GB 13 EC2 Compute Units 4 virtual cores EBS storage only

M3 2XL 30 GB 26 EC2 Compute Units 8 virtual cores EBS storage only

Extra Large 15 GB 8 EC2 Compute Units 4 virtual cores

10 GB Inter-Instance

Network

Cluster GPU 4XL 22 GB 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs

Cluster Compute 4XL 23 GB 33.5 EC2 Compute Units

Cluster Compute 8XL 60.5 GB 88 EC2 Compute Units

High Storage 8XL 117 GB 35 EC2 Compute Units, 24 * 2 TB ephemeral drives 10 GB Ethernet

Hi-Mem Cluster Compute 8XL 244 GB 88 EC2 Compute Units 16 virtual cores 240 GB SSD

Start small Easy to up-size

AMIs

Your machine images

AMIs you have created from

EC2 instances

Can be kept private or shared with other accounts

Amazon maintained

Set of Linux and Windows

images

Kept up to date by Amazon in each region

Community maintained

Images published by other

AWS users

Managed and maintained by Marketplace partners

http://aws.amazon.com/amazon-linux-ami/

Windows Linux Enterprise Linux

Small instance from $0.060 per hour


AMIs



Unix/Linux instances start at $0.02/hour

Pay as you go for compute power

Low cost and flexibility

Pay only for what you use, no up-front commitments or long-term contracts

Use Cases:

Applications with short term, spiky, or

unpredictable workloads;

Application development or testing

On-demand instances

Instance types





Use Cases:




On-demand instances

1- or 3-year terms

Pay low up-front fee, receive significant hourly discount

Low Cost / Predictability

Helps ensure compute capacity is available

when needed

Use Cases:

Applications with steady state or predictable usage

Applications that require reserved capacity,

including disaster recovery

Reserved instances

Instance types





Use Cases:




On-demand instances

1- or 3-year terms




when needed

Use Cases:




Reserved instances

> 80% utilization Lower costs up to 58%

Use Cases: Databases, Large Scale HPC, Always-on infrastructure, Baseline

Heavy utilization RI Instance types





Use Cases:




On-demand instances

1- or 3-year terms




when needed

Use Cases:




Reserved instances



Heavy utilization RI

41-79% utilization Lower costs up to 49%

Use Cases: Web applications, many heavy processing tasks, running much of the time

Medium utilization RI

Instance types





Use Cases:




On-demand instances

1- or 3-year terms




when needed

Use Cases:




Reserved instances



Heavy utilization RI


Use Cases: Web applications, many heavy processing tasks, running much of the time

Medium utilization RI


Use Cases: Disaster Recovery, Weekly / Monthly reporting, Elastic Map Reduce

Light utilization RI

Instance types





Use Cases:




On-demand instances

1- or 3-year terms




when needed

Use Cases:




Reserved instances

Bid on unused EC2 capacity

Spot Price based on supply/demand, determined automatically

Cost / Large Scale, dynamic workload handling

Use Cases:

Applications with flexible start and end times

Applications only feasible at very low compute prices

Spot instances

Instance types

Launch an instance Commands, keypairs & security groups

Region

Instance size

AMI

Key pair

Security group

key pairs secure access

Public Key

Inserted by Amazon into each EC2 instance that

you launch

Private Key

Downloaded and stored by you

EC2 Instance

Comms secured with private key

x.509 Keypairs Credentials

Used to authenticate when accessing and

instance

Used to authenticate against some APIs

Keypairs & Secrets

Access key and secret key used to authenticate

against APIs

security groups instance firewalling

Security Group

instance

Port 80 (HTTP)

Port 22 (SSH)

Name Description Protocol Port range IP Address, range, or another security group

PS C:> New-EC2Instances

-ImageId ami-269dbb63

-KeyName mykey

-SecurityGroupId sg-9cf9e5d9

-InstanceType t1.micro

ec2-run-instances ami-54cf5c3d

--instance-count 2

--group webservers

--key mykey

--instance-type m1.small

$>

>>> import boto.ec2

>>> conn = boto.ec2.connect_to_region("us-east-1")

>>> conn.run_instances(

'ami-54cf5c3d',

key_name='mykey',

instance_type='m1.small',

security_groups=['webservers'])

Wait a minute I want to use those tools too…

IAM Roles and EC2 tools

1. Start an EC2 Linux instance

2. Assign an IAM role at launch time:

3. Sets up all the tools you need & manages API access credentials

1. Up and running with CLI tools in a couple

of minutes – just SSH on and use

2. Terminate/stop instance when you are done

{

"Statement": [

{

"Effect": "Allow",

"NotAction": "iam:*",

"Resource": "*"

}

]

}

Now you have tools Try this…


--instance-count 1

$>


--instance-count 1

--group webservers

--key mykey


$>

What about all this?


--instance-count 1

--group Default

--key NONE

--instance-type default(m1.small)

$>

Defaults


--instance-count 1

--group Default

--key NONE

--instance-type default(m1.small)

$>

Instances don’t need keypairs But how do you configure it if you can’t log

onto it?

Bake an AMI

Start an instance

Configure the instance

Create an AMI from your instance

Start new ones from the AMI

Bootstrapping

Bake an AMI Configure dynamically

Start an instance

Configure the instance

Create an AMI from your instance

Start new ones from the AMI

Bootstrapping

Launch an instance

Use metadata service and cloud-init to

perform actions on instance when it

launches

vs


Build your base images and setup custom

initialisation scripts

Maintain your ‘golden’ base

Bootstrapping

Use bootstrapping to pass custom

information in and perform post launch

tasks like pulling code from SVN

+


Bootstrapping

Time consuming configuration (startup time)

Static configurations (less change management)


Bootstrapping

Continuous deployment (latest code)

Environment specific (dev-test-prod)

Goal is bring an instance up in a useful state

The balance will vary depending upon your application

Instance

request

User data

Instance

request

User data

Meta-data service

Instance

request

User data

Instance

Meta-data service

#!/bin/sh

yum -y install httpd php mysql php-mysql

chkconfig httpd on

/etc/init.d/httpd start

Shell script in user-data will be executed on launch:

63

Amazon Windows EC2Config Service executes user-

data on launch:

<script>dir > c:\test.log</script>

<powershell>any command that you can run</powershell>

<powershell>

Read-S3Object -BucketName myS3Bucket

-Key myFolder/myFile.zip

-File c:\destinationFile.zip

</powershell>

AWS Powershell Tools (use IAM roles as before…)

Why do this?

Automation Less fingers, less mistakes

Availability Drive higher

availability with self-healing

Security Instances locked down by default

Flexible Shell, Powershell, CloudFormation,

Chef, Puppet, OpsWorks

Scale Manage large scale

deployments and drive autoscaling

Efficiency Audit and manage

your estate with less time & effort

Do

Some does and don’ts

Use IAM roles

Go keyless if you can

Strike a balance between AMI and dynamic

bootstrapping

Do Don’t

Some does and don’ts

Use IAM roles

Go keyless if you can

Strike a balance between AMI and dynamic

bootstrapping

Put your API access keys into code (and then publish

to GIT) or bake into AMIs (and share)

Block storage Understanding instance storage vs EBS

Instance Storage

Local ‘on host’ disk volumes

Data dependent upon instance lifecycle

Elastic Block Storage Instance Storage VS



Network attached optimised block storage

Data independent of instance lifecycle

Instance Storage



Host 1

eph0 eph1 eph2 eph3

Instance Store

Instance A

Instance B

Instance C

Host 2

eph0 eph1 eph2 eph3

Instance Store

Instance D

Instance E

Instance F

Instance Storage



If an instance reboots (intentionally or unintentionally), data in the instance store persists

Data on instance store volumes is lost under the following circumstances:

• Failure of an underlying drive

• Stopping an Amazon EBS-backed instance

• Terminating an instance

Options Differing types of instance storage

Elastic Block Storage



EBS EC2

Workspace

Hypervisor

S3

EBS snapshot

Network

One or more ephemeral (temporary) drives (instance storage)

One or more EBS (persistent) drives

EBS snapshots (backup images)




EBS EC2

Hypervisor

S3

EBS snapshot

Boot cycle




EBS EC2

Workspace

Hypervisor

S3

EBS snapshot

Boot cycle




EBS EC2

Workspace

Hypervisor

S3

Boot cycle

Network

EBS Persistence

EBS volume is off-instance storage You pay for the volume usage as long as the data persists 1. By default, EBS volumes that are attached to a running instance

automatically detach from the instance with their data intact when that instance is terminated

2. By default, EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated. You can modify this behavior by changing the value of the flag DeleteOnTermination to false when you launch the instance.

Elastic Load Balancer Spreading the load and fronting EC2

A regional service Load balance across availability zones

Availability Zone Availability Zone

Region

Availability Zone

Instance Instance Instance Instance Instance Instance

Elastic Load Balancer

Offload

SSL processing on ELB

Remove load from EC2 instances

Spread

Go small and wide

Balance resources across AZs

Health check

Choose the right healthcheck point

Check whole layers

Elastic Load Balancing

1. Persistent HTTP connections – enable them and ELB to Server will be optimized

2. Never address underlying IP – always DNS name • There’s a set behind an ELB and real clients spread

across them • They will change as the ELB scales to keep ahead

of demand

3. If you span ELB across AZs have an instance in all Azs

4. De-register instances from an ELB before terminating

AutoScaling Automate EC2 commissioning and decommisioning

Describes what Auto Scaling will create when adding

Instances

AMI Instance Type

Security Group Instance Key Pair

Only one active launch configuration at a time

Auto Scaling will terminate instances with old launch

configuration first rolling update

Auto Scaling managed grouping of EC2 instances

Automatic health check to

maintain pool size

Automatically scale the number of instances by policy – Min, Max,

Desired

Automatic Integration with ELB

Automatic distribution & balancing across AZs

Parameters for performing an Auto Scaling action

Scale Up/Down and by how much

ChangeInCapacity (+/- #) ExactCapacity (#)

ChangeInPercent (+/- %)

Cool Down (seconds)

Policy can be triggered by CloudWatch events

Launch Configuration Auto-Scaling Group Auto-Scaling Policy

as-create-launch-config

--image-id ami-54cf5c3d


--key mykey

--group webservers

--launch-config 101-launch-config

Create a launch configuration:

as-create-launch-config

--image-id ami-54cf5c3d


--key mykey

--group webservers

--launch-config 101-launch-config

Create a launch configuration:

The usual suspects

as-create-auto-scaling-group 101-as-group

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

--launch-configuration 101-launch-config

--load-balancers myELB

--max-size 5

--min-size 1

Create an auto scaling group:





--max-size 5

--min-size 1


What’s going to launch





--max-size 5

--min-size 1


Integrate with an ELB?

as-put-scaling-policy 101ScaleUpPolicy

--auto-scaling-group 101-as-group

--adjustment=1

--type ChangeInCapacity

--cooldown 300

Create an auto-scaling policy (scale up):

as-put-scaling-policy 101ScaleUpPolicy


--adjustment=1


--cooldown 300

Create an auto-scaling policy (scale up):

Period before another action will take place (Damper)

as-put-scaling-policy 101ScaleDownPolicy


"--adjustment=-1"


--cooldown 300

Create an auto-scaling policy (scale down):

CloudWatch Know what is going on

CPU >= 50% for 5 mins

Takes action: Cloud Watch Alarm:

Scale up policy

CPU < 30% for 10 mins Scale down policy



Scale up policy



SNS Topic CPU < 30% for 10 mins

Send Email

Post to endpoint

Deliver message to Q



SNS Topic

CloudWatch

Comprehensive Billing, technical, aggregate &

custom metrics

Alarms Set custom alarms

and thresholds

SNS Integration Push alarms to

SNS topics

HTTP Poke HTTP

endpoints for custom alarm

actions Custom Metrics

Write your own metrics in via SDKs

Email integration

Send alarm notifications to

emails

masterclass webinar: amazon ec2

Technology