4. EC2 Basics
Virtual Servers in the Cloud
• One instance to thousands of instances
• In any public AWS region
• Create, start, stop, configure, monitor as desired
• Install any software: web, business, client/server,
batch processing
• Pay only for capacity you use
• Variety of cost models Amazon EC2
5. EC2 Basics: cost models
On-Demand Reserved Spot Dedicated
Pay upfront in exchange for hourly
prices that are 50-75% lower than
On-Demand
Pay for compute capacity by
the hour. No long-term
commitments
Bid for unused Amazon EC2
capacity
Launch instances in VPC on
dedicated customer hardware
Customers can combine multiple purchase types to optimize pricing based on current and forecast capacity needs.
Spiky workloads Committed utilization Time-insensitive workloads Highly sensitive workloads
7. Provisioning and Lifecycle
• Create -> Start -> Stop -> Terminate
• Manually in console
• Automate via API (or other tools)
• Automatically based on demand
(demand curve)
17. Custom script on AMI
(script_runner.py) fetches userdata,
parses it, and configures EC2 Instance
on boot
Bootstrapping: metadata and userdata
18. • CloudInit executes UserData on first boot if UserData begins with:
• #! (Linux)
• <script> (Windows; technically, EC2Config, not CloudInit, does this)
• CloudInit is installed on Amazon Linux, Ubuntu, and RHEL AMIs
• EC2Config is installed on Windows Server AMIs
• Both may be installed on other distributions via a package repo or
source
Bootstrapping: UserData and CloudInit
23. Bootstrapping: AMI bake
Fully-functional AMI is pre-build and
ready to launch from the AMI inventory
Inventory of AMIs
Linux
JEE
Your Code
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Amazon EC2
Linux
JEE
Your Code
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Linux
JEE
Your Code
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Linux
JEE
Your Code
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Linux
JEE
Your Code
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Java AMI
24. Bootstrapping: Configure dynamically
Base OS AMI
An AMI with minimal components (OS,
J2EE, and Chef/Puppet) is launched.
All configuration occurs via
Chef/Puppet after instance launch
Inventory of AMIs
Amazon EC2
OS AMI
Fetch on boot
Linux
JEE
Your Code
S3
Hibernate
Tomcat
Log4J
Spring
Struts
Apache
Linux
JEE
Linux
JEE
Chef/Puppet
Chef/Puppet
scripts
25. Bootstrapping: Sweet spot
Partially-configured AMI
A “Golden Image” is launched, with
scripts fetching/installing app code
and other supporting components on
boot
Inventory of AMIs
Amazon EC2
Java AMI
Your Code
S3
Log4J
Spring
Struts
Linux
JEE
Hibernate
Tomcat
Apache
Fetch on boot
Fetch on boot
Linu
x
JEE
Hibe
rnat
e
Tom
cat
Apac
he
Linu
x
JEE
Hibe
rnat
e
Tom
cat
Apac
he
Linu
x
JEE
Hibe
rnat
e
Tom
cat
Apac
he
Linu
x
JEE
Hibe
rnat
e
Tom
cat
Apac
he
51. • Tools Used:
• CloudFormation script –
• Create a multi-AZ, load balanced and Auto Scaled sample web site running on an Apache
Web Server (m1.small). The application is configured to span all Availability Zones in the
region and is Auto-Scaled based on the CPU utilization of the web servers.
• Bees with Machine Guns – Performance testing tool
• A cloudformation script that spins up a distibuted performance testing tool based on
apache eb tool. This tool will hit the ELB with 1000’s of concurrent requests for a total of
100’s of thousands of request, thus loading the web server behind the ELB.
• Expected result
• The Apache web server will scale to serve traffic without any customer impact.
Autoscaling: DEMO
52. • CloudFormation script (Auto scaling apache web server)
• Auto-scaling group configuration:
• Min: 1
• Max: 3
• Cooldown: 300
• Scaling Policies:
• Scaling Up:
• CPU Utilization > 20% for 1 consecutive period of 60 seconds
• Action: Add 1 instance
• Then wait: 60 seconds before next operation
• Scaling Down:
• CPU Utilization < 10% for 2 consecutive periods of 60 seconds
• Action: Remove 1 instance
• Then wait: 60 seconds before next operation
• Bees with Machine guns(NASTY)
Demo Information
53. Autoscaling isn’t one size fits all
• Choose the right metrics
• CPU Usage
• Queue Depth
• Number of concurrent users
• Scale too aggressively
• Overprovisioning: increases costs
• Bounciness: Add more than you need and have to partially scale back shortly after
scaling up, increasing costs.
• Scale too timidly
• Poor performance
• Outages due to lack of capacity
• Scale out early / Scale in slowly