Masterclass Webinar: Amazon EC2

Masterclass
Elastic Compute Cloud
Ryan Shuttleworth – Technical Evangelist
@ryanAWS

Masterclass

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

Amazon EC2

On-demand compute to run application workloads
Easy come easy go – disposable resource
We provide the infrastructure, you decide what you run

Complete control

Elastic capacity Flexible

What is EC2?
Reliable Secure

Inexpensive

Elastic capacity
Customer 1 Customer 2
… Customer n

Hypervisor
Securely
Virtual Interfaces
segregated
Customer 1
Security
Customer 2
Security … Customer n
Security
Shared Groups Groups Groups

Firewall
environment
Physical Interfaces

AMI

Amazon Machine
Image

Instance

AMI

Amazon Machine Running or
Image Stopped machine

EC2

Instance
VPC
AMI


EC2

Instance
VPC
AMI

AZ

Region

EC2 EC2

Instance
VPC VPC
AMI

AZ Availability Zone

Region

EC2 EC2

Instance
VPC VPC
AMI
EBS EBS EBS EBS EBS EBS


Region

EC2 EC2

Instance
VPC VPC
AMI
EBS EBS EBS EBS EBS EBS

EBS
S3 Buckets
Snapshots
S3

Region

Unit of control

Instance Unit of scale

Unit of resilience

Unit of control

Your stack Instance Unit of scale

Unit of resilience

Instance
Unit of control

Scale out Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance
Unit of control

Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance
Unit of control

Instance

Unit of scale

Unit of resilience
Instance

Instance types
Choose the right unit for your workload

High I/O 4XL 60.5 GB High Storage 8XL 117 GB Hi-Mem Cluster Compute 8XL
35 EC2 Compute Units 35 EC2 Compute Units, 244 GB
16 virtual cores 24 * 2 TB ephemeral drives 88 EC2 Compute Units
2*1024 GB SSD-based local instance storage
256 10 GB Ethernet 16 virtual cores
240 GB SSD

Hi-Mem 4XL 68.4 GB
26 EC2 Compute Units

128 8 virtual cores
10 GB
Hi-Mem 2XL 34.2 GB
13 EC2 Compute Units Inter-Instance Cluster Compute 8XL 60.5 GB
88 EC2 Compute Units
64 4 virtual cores

Hi-Mem XL 17.1 GB
Network Cluster Compute 4XL 23 GB
6.5 EC2 Compute Units 33.5 EC2 Compute Units

32 2 virtual cores
Memory (GB)

Cluster GPU 4XL 22 GB
33.5 EC2 Compute Units,
Extra Large 15 GB
2 x NVIDIA Tesla “Fermi”
16 8 EC2 Compute Units
4 virtual cores M3 XL 15 GB M3 2XL 30 GB
M2050 GPUs

13 EC2 Compute Units 26 EC2 Compute Units
4 virtual cores 8 virtual cores
Medium 3.7 GB, EBS storage only EBS storage only
8 2 EC2 Compute Units
1 virtual core
Large 7.5 GB
4 EC2 Compute Units High-CPU XL 7 GB

4 2 virtual cores 20 EC2 Compute Units
8 virtual cores
Small 1.7 GB, High-CPU Med 1.7 GB
1 EC2 Compute Unit 5 EC2 Compute Units
1 virtual core
2 Micro 613 MB
2 virtual cores

Up to 2 ECUs (for
short bursts)

1
1 2 4 8 16 32 64 128 256
EC2 Compute Units

AMIs

Amazon Community Your machine
maintained maintained images

Set of Linux and Windows Images published by other AMIs you have created from
images AWS users EC2 instances
Kept up to date by Amazon Managed and maintained by Can be kept private or shared
in each region Marketplace partners with other accounts

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

AMIs

Linux Enterprise Linux Windows

Small instance from Small instance from Small instance from
$0.060 per hour $0.120 per hour $0.115 per hour

Small instance from
$0.090 per hour

Instance types

On-demand instances

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

Instance types

On-demand instances Reserved instances

Unix/Linux instances start at 1- or 3-year terms
$0.02/hour
Pay low up-front fee, receive significant hourly
Pay as you go for compute power discount

Low cost and flexibility Low Cost / Predictability

Pay only for what you use, no up-front Helps ensure compute capacity is available
commitments or long-term contracts when needed

Use Cases:
Use Cases:
unpredictable workloads; Applications with steady state or predictable
usage
Applications that require reserved capacity,
including disaster recovery

Instance types Heavy utilization RI

> 80% utilization
Lower costs up to 58%
On-demand instances Reserved instances Use Cases: Databases, Large Scale HPC,
Always-on infrastructure, Baseline

$0.02/hour
Pay low up-front fee, receive significant hourly

Low cost and flexibility Low Cost / Predictability


Use Cases:
Use Cases:
usage


> 80% utilization

$0.02/hour
Pay low up-front fee, receive significant hourly Medium utilization RI

Low cost and flexibility Low Cost / Predictability 41-79% utilization
Pay only for what you use, no up-front Helps ensure compute capacity is available Use Cases: Web applications, many heavy
commitments or long-term contracts when needed processing tasks, running much of the time

Use Cases:
Use Cases:
usage


> 80% utilization

$0.02/hour
Pay low up-front fee, receive significant hourly Medium utilization RI

Low cost and flexibility Low Cost / Predictability 41-79% utilization
Pay only for what you use, no up-front Helps ensure compute capacity is available Use Cases: Web applications, many heavy
commitments or long-term contracts when needed processing tasks, running much of the time

Use Cases:
Use Cases:
Applications with short term, spiky, or Light utilization RI
usage
Application development or testing 15-40% utilization
Applications that require reserved capacity, Lower costs up to 34%
Use Cases: Disaster Recovery, Weekly /
Monthly reporting, Elastic Map Reduce

Instance types

On-demand instances Reserved instances Spot instances

Unix/Linux instances start at 1- or 3-year terms Bid on unused EC2 capacity
$0.02/hour
Pay low up-front fee, receive significant hourly Spot Price based on supply/demand,
Pay as you go for compute power discount determined automatically

Low cost and flexibility Low Cost / Predictability Cost / Large Scale, dynamic workload handling

Use Cases:
Use Cases:
Use Cases: Applications with flexible start and end times
unpredictable workloads; Applications with steady state or predictable Applications only feasible at very low compute
usage prices

Launch an instance
Commands, keypairs & security groups

Region
Instance size
AMI
Key pair
Security group

Public Key
Inserted by Amazon into
each EC2 instance that
you launch

EC2
Instance
Comms secured
with private key

Private Key
Downloaded and stored
by you

Keypairs & Secrets

Keypairs Credentials x.509

Used to authenticate Access key and secret key Used to authenticate
when accessing and used to authenticate against some APIs
instance against APIs

security groups
instance firewalling

Port 22 Name
Security Group
(SSH) Description
Port 80 Protocol
(HTTP) Port range
IP Address, range, or
another security group

instance

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 "Statement": [
{
1. Up and running with CLI tools in a couple "Effect": "Allow",
"NotAction": "iam:*",
of minutes – just SSH on and use
"Resource": "*"
}
2. Terminate/stop instance when you are ]
done }

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?

Bootstrapping

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 vs Configure dynamically

Start an instance Launch an instance
Configure the instance Use metadata service
and cloud-init to
Create an AMI from
perform actions on
your instance
instance when it
Start new ones from launches
the AMI

Bootstrapping

Bake an AMI + Configure dynamically

Build your base images Use bootstrapping to
and setup custom pass custom
initialisation scripts information in and
perform post launch
Maintain your ‘golden’
tasks like pulling code
base
from SVN

Bootstrapping

Bake an AMI Configure dynamically

Time consuming
configuration (startup time)
Static configurations (less
change management)

Bootstrapping

Bake an AMI Configure dynamically

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 User
request data

Instance User Meta-data
request data service

Instance User Meta-data
request data service

Instance

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

#!/bin/sh
yum -y install httpd php mysql php-mysql
chkconfig httpd on
/etc/init.d/httpd start

Amazon Windows EC2Config Service executes user-
data on launch:
<script>dir > c:test.log</script>

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

AWS Powershell Tools (use IAM roles as before…)
<powershell>
Read-S3Object -BucketName myS3Bucket
-Key myFolder/myFile.zip
-File c:destinationFile.zip
</powershell>

63

Automation
Less fingers, less mistakes

Security Availability
Instances locked
Drive higher
down by default
availability with self-
healing

Why do this?
Flexible Efficiency
Shell, Powershell, Audit and manage
CloudFormation, your estate with less
Chef, Puppet, Scale time & effort
OpsWorks Manage large scale
deployments and drive
autoscaling

Some does and don’ts

Do

Use IAM roles
Go keyless if you can
Strike a balance between
AMI and dynamic
bootstrapping

Some does and don’ts

Do Don’t

Use IAM roles Put your API access keys
into code (and then publish
Go keyless if you can
to GIT) or bake into AMIs
Strike a balance between (and share)
AMI and dynamic
bootstrapping 

Block storage
Understanding instance storage vs EBS

Instance Storage
Local ‘on host’ disk
volumes
Data dependent upon
instance lifecycle

Instance Storage VS Elastic Block Storage
Local ‘on host’ disk Network attached optimised
volumes block storage
Data dependent upon Data independent of
instance lifecycle instance lifecycle

Instance A
Instance Storage Instance D

Instance B
volumes Instance E
Instance C
Data dependent upon Instance F
instance lifecycle Instance Store Instance Store

eph0 eph1 eph2 eph3 eph0 eph1 eph2 eph3

Host 1 Host 2

If an instance reboots (intentionally or
Instance Storage unintentionally), data in the instance store
persists
volumes
Data on instance store volumes is lost under
Data dependent upon the following circumstances:
instance lifecycle
• Failure of an underlying drive
• Stopping an Amazon EBS-backed instance
• Terminating an instance

Options
Differing types of
instance storage

One or more ephemeral
(temporary) drives
(instance storage)
One or more EBS
(persistent) drives
EBS snapshots
(backup images)
Elastic Block Storage
Network attached optimised
Workspace block storage
Network
Data independent of
EBS
snapshot
instance lifecycle
Hypervisor

EC2 EBS S3

Boot cycle Elastic Block Storage
block storage
Data independent of
EBS
snapshot
instance lifecycle
Hypervisor

EC2 EBS S3

Data independent of
EBS
snapshot
instance lifecycle
Hypervisor

EC2 EBS S3

Network
Data independent of
instance lifecycle
Hypervisor

EC2 EBS S3

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

Elastic Load Balancer

Instance Instance Instance Instance Instance Instance

Availability Zone Availability Zone Availability Zone

Region

Elastic Load Balancing

Spread Offload Health check
Go small and wide SSL processing on ELB Choose the right healthcheck
Balance resources across Remove load from EC2 point
AZs instances Check whole layers

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

Launch Configuration Auto-Scaling Group Auto-Scaling Policy

Describes what Auto Scaling Auto Scaling managed Parameters for performing an
will create when adding grouping of EC2 instances Auto Scaling action
Instances
Automatic health check to Scale Up/Down and by how much
AMI
maintain pool size
Instance Type ChangeInCapacity (+/- #)
Security Group ExactCapacity (#)
Automatically scale the number of
Instance Key Pair ChangeInPercent (+/- %)
instances by policy – Min, Max,
Desired
Only one active launch Cool Down (seconds)
configuration at a time
Automatic Integration with ELB
Policy can be triggered by
Auto Scaling will terminate CloudWatch events
Automatic distribution & balancing
instances with old launch
across AZs
configuration first
rolling update

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:

as-create-launch-config
--image-id ami-54cf5c3d
--instance-type m1.small The usual
--key mykey suspects
--group webservers
--launch-config 101-launch-config

Create an auto scaling group:

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


--max-size 5
--min-size 1 What’s going to launch


--max-size 5
--min-size 1
Integrate with an ELB?

Create an auto-scaling policy (scale up):

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

Period before another action will take place
(Damper)

Create an auto-scaling policy (scale down):

as-put-scaling-policy 101ScaleDownPolicy
"--adjustment=-1"
--cooldown 300

CloudWatch
Know what is going on

Cloud Watch Alarm: Takes action:

CPU >= 50% for 5 mins Scale up policy

CPU < 30% for 10 mins Scale down policy


CPU >= 50% for 5 mins Scale up policy


CPU >= 50% for 5 mins Deliver message to Q

SNS Topic Post to endpoint
CPU < 30% for 10 mins

Send Email


CPU >= 50% for 5 mins
SNS Topic

Comprehensive
Billing, technical, aggregate &
custom metrics

SNS Alarms
Integration Set custom alarms
Push alarms to and thresholds
SNS topics

CloudWatch
HTTP Email
Poke HTTP integration
endpoints for Send alarm
custom alarm Custom Metrics notifications to
actions Write your own metrics in via emails
SDKs

Other topics…

Resource tagging Route 53 Rolling deployments
Tag resources like EC2 Front EC2 and ELBs with Use Route 53 and ELBs to do
and have it appear on Route 53 for control over rolling deployments, A/B
billing reports DNS testing

Other topics…

Beanstalk OpsWorks CloudFormation
Manage an entire Manage stacks as layers Template everything from
autoscaling stack for and implement Chef configuration of CloudWatch
popular containers such recipes to automate EC2 alarms, SNS topics, EC2
as ruby, python etc configuration instances

Stop doing these:
Provisioning and fixing servers
Treating compute as physical things
Thinking of compute as a finite commitment

Elasticity
Stateless autoscaling Automation
Security applications Create instances when
Build systems secure by
you need them, drop
default
them when not

and start doing these

Replace not fix Be cost aware
Build from scratch, don’t Unconstrained Tag resources, play with
fix something instance types
Say goodbye to
traditional capacity
planning

Watch a demo here:
http://youtu.be/kMExnVKhmYc

Masterclass Webinar: Amazon EC2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Masterclass Webinar: Amazon EC2

Similar to Masterclass Webinar: Amazon EC2 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Recently uploaded

Recently uploaded (20)

Masterclass Webinar: Amazon EC2