Masterclass Elastic Compute Cloud Ryan Shuttleworth – Technical Evangelist @ryanAWS
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
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
Amazon Machine Image
Instance
Running or Stopped machine
AMI
Amazon Machine Image
Instance
Running or Stopped machine
VPC
EC2
AMI
Amazon Machine Image
Instance
Running or Stopped machine
VPC
EC2
AZ
Region
AMI
Amazon Machine Image
Instance
Running or Stopped machine
VPC
EC2
AZ Availability Zone
VPC
EC2
Region
AMI
Amazon Machine Image
Instance
Running or Stopped machine
VPC
EC2
AZ Availability Zone
EBS EBS EBS
VPC
EC2
EBS EBS EBS
Region
AMI
Amazon Machine Image
Instance
Running or Stopped machine
VPC
EC2
AZ Availability Zone
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
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
Small instance from $0.115 per hour
AMIs
Small instance from $0.120 per hour
Small instance from $0.090 per hour
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
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
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
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
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
> 80% utilization Lower costs up to 58%
Use Cases: Databases, Large Scale HPC, Always-on infrastructure, Baseline
Heavy utilization RI Instance types
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
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
> 80% utilization Lower costs up to 58%
Use Cases: Databases, Large Scale HPC, Always-on infrastructure, Baseline
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
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
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
> 80% utilization Lower costs up to 58%
Use Cases: Databases, Large Scale HPC, Always-on infrastructure, Baseline
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
15-40% utilization Lower costs up to 34%
Use Cases: Disaster Recovery, Weekly / Monthly reporting, Elastic Map Reduce
Light utilization RI
Instance types
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
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
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…
ec2-run-instances ami-54cf5c3d
--instance-count 1
$>
ec2-run-instances ami-54cf5c3d
--instance-count 1
--group webservers
--key mykey
--instance-type m1.small
$>
What about all this?
ec2-run-instances ami-54cf5c3d
--instance-count 1
--group Default
--key NONE
--instance-type default(m1.small)
$>
Defaults
ec2-run-instances ami-54cf5c3d
--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
Bake an AMI Configure dynamically
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
+
Bake an AMI Configure dynamically
Bootstrapping
Time consuming configuration (startup time)
Static configurations (less change management)
Bake an AMI Configure dynamically
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
Local ‘on host’ disk volumes
Data dependent upon instance lifecycle
Network attached optimised block storage
Data independent of instance lifecycle
Instance Storage
Local ‘on host’ disk volumes
Data dependent upon instance lifecycle
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
Local ‘on host’ disk volumes
Data dependent upon instance lifecycle
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
Options Differing types of instance storage
Elastic Block Storage
Network attached optimised block storage
Data independent of instance lifecycle
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)
Elastic Block Storage
Network attached optimised block storage
Data independent of instance lifecycle
EBS EC2
Hypervisor
S3
EBS snapshot
Boot cycle
Elastic Block Storage
Network attached optimised block storage
Data independent of instance lifecycle
EBS EC2
Workspace
Hypervisor
S3
EBS snapshot
Boot cycle
Elastic Block Storage
Network attached optimised block storage
Data independent of instance lifecycle
EBS EC2
Workspace
Hypervisor
S3
EBS snapshot
Boot cycle
Elastic Block Storage
Network attached optimised block storage
Data independent of instance lifecycle
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
--instance-type m1.small
--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
--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:
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:
What’s going to launch
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:
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
--auto-scaling-group 101-as-group
--adjustment=1
--type ChangeInCapacity
--cooldown 300
Create an auto-scaling policy (scale up):
Period before another action will take place (Damper)
as-put-scaling-policy 101ScaleDownPolicy
--auto-scaling-group 101-as-group
"--adjustment=-1"
--type ChangeInCapacity
--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
CPU >= 50% for 5 mins
Takes action: Cloud Watch Alarm:
Scale up policy
CPU >= 50% for 5 mins
Takes action: Cloud Watch Alarm:
SNS Topic CPU < 30% for 10 mins
Send Email
Post to endpoint
Deliver message to Q
CPU >= 50% for 5 mins
Takes action: Cloud Watch Alarm:
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
Other topics to look at:
Route 53
Front EC2 and ELBs with Route 53 for control over
DNS
Resource tagging
Tag resources like EC2 and have it appear on
billing reports
Rolling deployments
Use Route 53 and ELBs to do rolling deployments, A/B
testing
Other topics…
OpsWorks
Manage stacks as layers and implement Chef
recipes to automate EC2 configuration
Beanstalk
Manage an entire autoscaling stack for
popular containers such as ruby, python etc
CloudFormation
Template everything from configuration of CloudWatch
alarms, SNS topics, EC2 instances
Other topics…
Summary
Stop doing these: Provisioning and fixing servers
Treating compute as physical things Thinking of compute as a finite commitment
and start doing these
Security Build systems secure by
default
Elasticity Stateless autoscaling
applications
Replace not fix Build from scratch, don’t
fix something Unconstrained
Say goodbye to traditional capacity
planning
Be cost aware Tag resources, play with
instance types
Automation Create instances when you need them, drop
them when not
Watch a demo here: http://youtu.be/kMExnVKhmYc
aws.amazon.com