Amazon EC2 forms the backbone compute platform for hundreds of thousands of AWS customers, but how do you go beyond starting an instance and manually configuring it? This webinar takes you on a journey starting with the basics of key creation and security groups and ending with an Auto Scaling application driven by dynamic policies. It will explain the tools you need to create an Auto Scaling configuration and show you how to bootstrap an instance.
Reasons to attend:
- Understand how to use Amazon EC2 beyond a simple single instance use case including bootstrap & AMIs.
- Learn how to create Auto Scaling configurations and the tools you need to drive Auto Scaling policies.
- Learn how to use Amazon CloudWatch alarms to trigger actions with Auto Scaling.
4. v
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
Customers can combine multiple purchase types to optimize pricing based on current and forecast capacity needs.
v
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
Spiky workloads Committed utilization Time-insensitive workloads Highly sensitive workloads
7. Provisioning and Lifecycle
v
• Create -> Start -> Stop -> Terminate
• Manually in console
• Automate via API (or other tools)
• Automatically based on demand
(demand curve)
16. Amazon Machine Images
v
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
19. v
Bootstrapping
Bake an AMI
Start an instance
Configure the instance
Create an AMI from your
instance
Start new ones from the AMI
20. v
Bootstrapping
Bake an AMI
Start an instance
Configure the instance
Create an AMI from your
instance
Start new ones from the AMI
Configure dynamically
Launch an instance
Use metadata service and
cloud-init to perform actions on
instance when it launches
vs
21. v
Bootstrapping
Bake an AMI Configure dynamically
Build your base images and
setup custom initialisation
scripts
Maintain your ‘golden’ base
Use bootstrapping to pass
custom information in and
perform post launch tasks like
pulling code from SVN
+
22. v
Bootstrapping
Bake an AMI Configure dynamically
Time consuming configuration
(startup time)
Static configurations (less change
management)
23. v
Bootstrapping
Bake an AMI Configure dynamically
Continuous deployment (latest code)
Environment specific (dev-test-prod)
24. Bootstrapping: some examples
v
• Install latest software
• Copy data from S3
• Register with DNS
• Start services
• Update packages
• Reboot
• Open port 80
• Register with load balancer
• Mount devices
25. v
Bootstrapping: tools
• Scripts on instance
• Config Management Tools; puppet, chef, others.
• Amazon OpsWorks
26. Bootstrapping: metadata and userdata
• Every EC2 Instance has access to local instance
v
metadata and userdata service
Instance
request
User
data
Meta-data
service
Instance
27. Bootstrapping: metadata and userdata
• Metadata: immutable information about the instance
v
• Accessible from within the instance via HTTP at
http://169.254.169.254/latest/meta-data/
• Script(s) on instance may retrieve useful information about the instance, such as:
• Host name
• AMI ID
• Instance ID
• Public/Private DNS
• Availability Zone
• An Example: Using Metadata to retrieve the hostname:
# curl http://169.254.169.254/latest/meta-data/hostname
ip-172-31-10-12.ap-southeast-2.compute.internal
28. Bootstrapping: metadata and userdata
• User Data: pass up to 16KB of text v
to an instance on launch
• Accessible from within the instance via HTTP at
http://169.254.169.254/latest/user-data/
• Text can be parsed by script on instance and used to configure the
machine
29. Bootstrapping: metadata and userdata
v
Custom script on AMI
(script_runner.py) fetches userdata,
parses it, and configures EC2 Instance
on boot
30. Bootstrapping: UserData and CloudInit
v • 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
31. Bootstrapping: UserData and CloudInit
v • UserData to install Apache and MySQL on boot, and attach an EIP:
#!/bin/bash
# Install Apache, PHP, and MySQL
yum install –y httpd mysql-server
# Attach an Elastic IP to this instance
ec2-associate-address
23.34.45.56
-i $(curl http://169.254.169.254/latest/meta-data/instance-id)
32. Bootstrapping: AMIs
v • Fully-Functional
• Partially Configured
• Base OS, Config with Code
33. v
Bootstrapping: AMIs
Apache
Tomcat
Struts
Your Code
Log4J
Spring
Hibernate
JEE
Linux
Java App Stack
Example full stack required to run your
application.
Let’s use the 3 AMI/bootstrapping
techniques
34. v
Bootstrapping: AMIs
Fully-functional AMI is pre-build and
ready to launch from the AMI inventory
Apache
Tomcat
Struts
Your Code
Hibernate
Apache
Tomcat
Struts
Your Code
Log4J
Spring
Hibernate
JEE
Linux
Apache
Tomcat
Struts
Your Code
Log4J
Spring
Hibernate
JEE
Linux
Apache
Tomcat
Struts
Your Code
Log4J
Spring
Hibernate
JEE
Linux
Inventory of AMIs
Log4J
Spring
JEE
Linux
Apache
Tomcat
Struts
Your Code
Log4J
Spring
Hibernate
JEE
Linux
Amazon EC2
Java AMI
35. v
Bootstrapping: AMIs
Partially-configured AMI
A “Golden Image” is launched, with
scripts fetching/installing app code
and other supporting components on
boot
Fetch on boot
Apac
he
Tom
cat
Hibe
rnat
e
JEE
Apac
he
Tom
cat
Hibe
rnat
e
JEE
Apac
he
Tom
cat
Hibe
rnat
e
JEE
Apac
he
Tom
cat
Hibe
rnat
e
JEE
Amazon EC2
Your Code
Struts
Log4J
S3
Spring
Apache
Tomcat
Hibernate
JEE
Java AMI
Inventory of AMIs
Linux
Fetch on boot
Linu
x
Linu
x
Linu
x
Linu
x
36. v
Bootstrapping: AMIs
Base OS AMI
An AMI with minimal components (OS,
J2EE, and Chef/Puppet) is launched.
All configuration occurs via
Chef/Puppet after instance launch
Fetch on boot
JEE
scripts
JEE
Amazon EC2
Your Code
Apache
Struts
Log4J
Hibernate
Spring
S3
JEE
Tomcat
OS AMI
Inventory of AMIs
Linux
Linux
Linux
Chef/Puppet
Chef/Puppet
37. Automation
Less fingers, less mistakes
Why do this?
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
38. Some dos and don’ts
Do Don’t
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)
42. v
Autoscaling
• Auto Scaling
• Scale your Amazon EC2 capacity up or down automatically
according to conditions you define
• Ensure that the number of Amazon EC2 instances you’re
using increases seamlessly during demand spikes to
maintain performance, and decreases automatically
during demand lulls to minimize costs
43. Launch Configuration Auto-Scaling Group Auto-Scaling Policy
Describes what Auto Scaling
will create when adding
Instances - Similar to ec2-run-instances
API command
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
54. Autoscaling: ELB + CloudWatch
v
Latency
ELB
Auto scaling Group
Auto Scaling CloudWatch
55. v
Autoscaling: DEMO
• Tools Used:
• CloudFormation script –
• Create a multi-AZ, load balanced and Auto Scaled sample web site running on an Apache
Web Server. 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.
• CPU script –
• Logging on to an m3.medium instance to generate CPU load (simulating heavy CPU
usage) to see the autoscaling working:
• while true; do echo; done
56. Stop doing these:
Provisioning and fixing servers
Treating compute as physical things
Thinking of compute as a finite commitment
57. Security
Build systems secure by
default
Elasticity
Stateless autoscaling
applications
Automation
Create instances when
you need them, drop
them when not
and start doing these
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
58. Online Labs | Training
Gain confidence and hands-on
experience with AWS. Watch free
Instructional Videos and explore Self-
Paced Labs
Instructor Led Classes
Learn how to design, deploy and operate
highly available, cost-effective and secure
applications on AWS in courses led by
qualified AWS instructors
AWS Certification
Validate your technical expertise
with AWS and use practice exams
to help you prepare for AWS
Certification
http://aws.amazon.com/training
63. v
Demo Information
• CloudFormation script
• Auto-scaling group configuration:
• Min: 1
• Max: 3
• Cooldown: 300
• Scaling Policies:
• Scaling Up:
• CPU Utilization > 80% for 2 consecutive periods of 60 seconds
• Action: Add 1 instance
• Then wait: 60 seconds before next operation
• Scaling Down:
• CPU Utilization < 15% for 2 consecutive periods of 60 seconds
• Action: Remove 1 instance
• Then wait: 60 seconds before next operation
• 100% CPU Script (NASTY): while true; do echo; done
Notes de l'éditeur
The AWS Core Benefit – Cost Savings
Pricing Models
There are a number of types of pricing models available that give companies of all sizes flexibility. Here are 3 pricing models.
On-Demand Instances let you pay for compute capacity by the hour with no long-term commitments. This frees you from the costs and complexities of planning, purchasing, and maintaining hardware and transforms what are commonly large fixed costs into much smaller variable costs.
Reserved Instances give you the option to make a low, one-time payment for each instance you want to reserve and in turn receive a significant discount on the hourly charge for that instance. This is good for those with steady-state workloads who want to pay upfront in exchange for hourly prices that are 50-75% lower than what you get for on-demand instances.
Spot Instances enable you to bid for unused Amazon EC2 capacity. Instances are charged the Spot Price, which is set by Amazon EC2 and fluctuates periodically depending on the supply of and demand for Spot Instance capacity. This is good for customers who have opportunistic workloads that can afford to be interrupted and want the lowest possible price.
Dedicated Instances
Dedicated Instances are Amazon EC2 instances launched within your VPC that run hardware dedicated to a single customer. Dedicated Instances let you take full advantage of the benefits of Amazon VPC and the AWS cloud – on-demand elastic provisioning, pay only for what you use, and a private, isolated virtual network, all while ensuring that your Amazon EC2 compute instances will be isolated at the hardware level.
Some of the larger customers run reserved instances for their steady-state workloads to maximize their savings on an per-hourly basis. They then fill in the rest of their workloads with either on-demand or spot instances depending on whether or not their applications can afford to be utilized over a period of time or be interrupted.
The following illustration represents the transitions between instance states. Notice that you can't stop and start an instance store-backed instance. For more information about instance store-backed instances, see Storage for the Root Device.
This scenario may occur throughout the day as well
This scenario may occur throughout the day as well
This scenario may occur throughout the day as well
This scenario may occur throughout the day as well
This scenario may occur throughout the day as well
Broad Set of Compute Instance Types
A good example of the breadth of features and of AWS’ approach, is in the instance types available on EC2. After eight years, AWS has built out a collection of instance types which move beyond just general purpose utility computing, into application-optimized instances.
AWS has spent a lot of time in the past year adding what it considers to be the next generation of instance families to EC2, for both general purpose workloads, and application specific optimized instances.
Today, these instance families have been extended further.
Bootstrapping actions can be almost anything. Here are some examples.
Bootstrapping actions can be almost anything. Here are some examples.
Bootstrapping actions can be almost anything. Here are some examples.
You can specify UserData in a couple of ways. The Management Console, for example, provides you with the option of including UserData when you spin up a new EC2 instance.
I said that most EC2 instances use CloudInit (or EC2Config). Let’s get more specific:
CloudInit is available on Amazon Linux, Ubuntu, and RHEL Amazon Machine Images (AMIs).
EC2Config is on all Windows Server AMIs.
Either one may be available on other distributions, however.
Here’s an example of UserData that:
Installs Apache
Installs MySQL
Attaches an Amazon Elastic IP address (EIP)
With Auto Scaling, you can scale your EC2 instances up and down automatically.
You can also ensure that EC2 instances increase and decrease seamlessly.
You can configure Auto Scaling through the EC2 dashboard, as shown here.
Creating a launch configuration is almost identical to launching an EC2 instance. You specify options for the AMI, storage, tags, and so on.
Auto Scaling configurations can also take bootstrapping scripts and configuration instructions, just like EC2 instances.
Notice also that you need to give every launch configuration that you create a name.
Again, you can create an Auto Scaling group using the AWS Management Console. With an auto scaling group, you define:
The name of the group
The launch configuration you want to use
The size of the auto scaling group
Whether to launch the Auto Scaling group within a VPC or not
How to load balance between auto scaling group instances
How to monitor the health of instances in an auto scaling group
In addition, you can also establish auto scaling policies, which dynamic increase or decrease EC2 instances based on CloudWatch alarms.
Note that it's always a good idea to ensure that your auto scaling group handles both scaling UP (adding instances) and scaling DOWN (removing instances). This is one way you can help maximize your IT budget—by adding and removing instances when needed.
Here’s what this Auto Scaling group looks like. Notice that we have four instances (as we specified in the desired-capacity parameter) running across two Availability Zones, all registered with one ELB.
If one instance goes down…
The Auto Scaling group spins up a new one.
If the instances in one Availability Zone aren’t accessible…
New instances are started in the other Availability Zone.
All of these service work well individually, but together the become more powerful and increase the control and flexibility our customers demand.
All of these service work well individually, but together the become more powerful and increase the control and flexibility our customers demand.
All of these service work well individually, but together the become more powerful and increase the control and flexibility our customers demand.