SlideShare a Scribd company logo
AWS Auto Scaling
presented by BlueChipTek
web: bluechiptek.com
twitter: @bluechiptek
phone: 408-731-7700
Copyright 2015 Blue Chip Tek
Who am I?
 DevOps Engineer and occasional Programmer
What experience do I have?
 Lyft: ride-sharing startup in San Francisco
 NetShelter: multi-region ad-network
Certified?
 AWS Certified Solutions Architect, number 2564
 AWS Certified SysOps, number 224
Projects?
 Contributed some cool features to SaltStack project
Intro: Colin Johnson
Copyright 2015 Blue Chip Tek
 Understand use cases for Auto Scaling
 Understand benefits and drawbacks of Auto Scaling
 Determine if and where Auto Scaling a fit for existing
Infrastructure
 Implement Auto Scaling!
Objectives
Copyright 2015 Blue Chip Tek
A Quick AWS Introduction
(as is relevant to Auto Scaling)
Copyright 2015 Blue Chip Tek
 Regions:
 9 Available Regions (as of April, 2015)
 Costs are Different in Each Region (~50% difference between
lowest/most expensive EC2 instance)
 Use Regions to Meet Availability, Compliance or Performance
Requirements
 Availability Zones:
 Each Availability Zone is Isolated, typically 3-4 AZs per-region
 Meet Availability or Scalability Requirements
Regions and Availability Zones
Copyright 2015 Blue Chip Tek
AWS: Global Regions
Copyright 2015 Blue Chip Tek
Example: Multi-AZ Architecture
us-west-2
us-west-2bus-west-2a
Internet
Load Balancer
Multi-AZ
Auto Scaling Group
Multi-AZ
Database
Multi-AZ
wwwlb-prod01 www-prod01
www-prod01wwwlb-prod01 db-prod01
db-prod01
Mobile Client
Client
Copyright 2015 Blue Chip Tek
Example: Multi-AZ
Architecture during Failure
Copyright 2015 Blue Chip Tek
 March, 2006 – S3 Launched
 August, 2006 – EC2 Beta Launched
 October, 2007 – EC2 “Large and Extra Large” Instances
 March, 2008 – Availability Zones
 October, 2008 – EC2 Officially Released
 May, 2009 – AWS Console Launched
 May, 2009 – Auto Scaling Released
 December, 2013 – Auto Scaling added to AWS Console
AWS and Auto Scaling: Timeline
Copyright 2015 Blue Chip Tek
 Provides Elasticity and Scalability
 Respond to changes in demand by scaling in/out EC2 servers.
 Scale manually, automatically or on schedule
 Automatic scaling based on CloudWatch Metrics
 Provides Availability
 Spreads Instances across Availability Zones
 Eliminate outages as result of changes in demand
 Terminate and rebuild failed nodes automatically
 Cost: “pay for what you need” or utilize “Spot” instances
Auto Scaling: Benefits
Copyright 2015 Blue Chip Tek
 Dynamic infrastructure creates challenges:
 Monitoring Tools
 Log File Collection and Analysis
 Changing IP Addresses/Ranges
 Applications saving “State” on Terminated Servers
 Applications may require modification to work with
Auto Scaling
Auto Scaling: Challenges
Copyright 2015 Blue Chip Tek
AWS Auto Scaling
(the Details)
Copyright 2015 Blue Chip Tek
An Auto Scaling Group has the following attributes:
 Min Size
 Max Size
 Desired Capacity
 Health Check Type (EC2 or ELB)
 Associated Load Balancers
 LaunchConfiguration
 Provides Instance Type, AMI ID, User Data
Auto Scaling: Attributes
Copyright 2015 Blue Chip Tek
A Launch Configuration tells an Auto Scaling Group
About the Instance to Launch. Example attributes:
 ImageID (aka AMI)
 InstanceType
 KeyName
 SecurityGroups
 Spot Price
 User-Data
Auto Scaling: Launch Configuration
Copyright 2015 Blue Chip Tek
 Tags applied on an “Auto Scaling Group” are also
applied to instances
 Tag with “Application”, “Environment”, “Owner” to
enable reporting and easier AWS Administration
 Tags are “Eventually Consistent” for Instances
 Create an instance as part of “web-prod01” and the
instance may not get that tag immediately
Auto Scaling: Tags
Copyright 2015 Blue Chip Tek
 Auto Scaling is designed to be used with other AWS
Services:
 Elastic Load Balancing for routing Inbound requests
 SQS for dispatching messages/work to ephemeral EC2
Servers
 CloudWatch for controlling scale/up events
Auto Scaling: Typical Design
Copyright 2015 Blue Chip Tek
Auto Scaling and ELB
Copyright 2015 Blue Chip Tek
Auto Scaling and SQS
Copyright 2015 Blue Chip Tek
 Use CloudFormation to provision Auto Scaling Groups
 Auto Scaling Groups are challenging to build manually
 Auto Scaling Groups don’t support easy “Launch
Configuration” modifications*
 Auto Scaling is Integrated with or Used By:
 CodeDeploy (for getting code onto instances)
 Elastic Load Balancers? Sure seems like it…
 Elastic Beanstalk
 EC2 Container Service (optional, but recommended)
Integration with other AWS Services
Copyright 2015 Blue Chip Tek
AWS Auto Scaling
(Live Demo)
Copyright 2015 Blue Chip Tek
 Use all Availability Zones
 AWS may “deny” the ability to launch an instance in an AZ if
over capacity
 Ship all data off instances as quickly as possible
 Avoid use of Lifecycle Hooks if Possible
 Create groups of 1 Instance
 If errors arise, terminate instance and rebuild
 Over-provision by 1 node until Scaling policy well
understood
 Keep Auto Scaling Rules Simple
Auto Scaling: Best Practices
Copyright 2015 Blue Chip Tek

More Related Content

Aws Autoscaling

  • 1. AWS Auto Scaling presented by BlueChipTek web: bluechiptek.com twitter: @bluechiptek phone: 408-731-7700 Copyright 2015 Blue Chip Tek
  • 2. Who am I?  DevOps Engineer and occasional Programmer What experience do I have?  Lyft: ride-sharing startup in San Francisco  NetShelter: multi-region ad-network Certified?  AWS Certified Solutions Architect, number 2564  AWS Certified SysOps, number 224 Projects?  Contributed some cool features to SaltStack project Intro: Colin Johnson Copyright 2015 Blue Chip Tek
  • 3.  Understand use cases for Auto Scaling  Understand benefits and drawbacks of Auto Scaling  Determine if and where Auto Scaling a fit for existing Infrastructure  Implement Auto Scaling! Objectives Copyright 2015 Blue Chip Tek
  • 4. A Quick AWS Introduction (as is relevant to Auto Scaling) Copyright 2015 Blue Chip Tek
  • 5.  Regions:  9 Available Regions (as of April, 2015)  Costs are Different in Each Region (~50% difference between lowest/most expensive EC2 instance)  Use Regions to Meet Availability, Compliance or Performance Requirements  Availability Zones:  Each Availability Zone is Isolated, typically 3-4 AZs per-region  Meet Availability or Scalability Requirements Regions and Availability Zones Copyright 2015 Blue Chip Tek
  • 6. AWS: Global Regions Copyright 2015 Blue Chip Tek
  • 7. Example: Multi-AZ Architecture us-west-2 us-west-2bus-west-2a Internet Load Balancer Multi-AZ Auto Scaling Group Multi-AZ Database Multi-AZ wwwlb-prod01 www-prod01 www-prod01wwwlb-prod01 db-prod01 db-prod01 Mobile Client Client Copyright 2015 Blue Chip Tek
  • 8. Example: Multi-AZ Architecture during Failure Copyright 2015 Blue Chip Tek
  • 9.  March, 2006 – S3 Launched  August, 2006 – EC2 Beta Launched  October, 2007 – EC2 “Large and Extra Large” Instances  March, 2008 – Availability Zones  October, 2008 – EC2 Officially Released  May, 2009 – AWS Console Launched  May, 2009 – Auto Scaling Released  December, 2013 – Auto Scaling added to AWS Console AWS and Auto Scaling: Timeline Copyright 2015 Blue Chip Tek
  • 10.  Provides Elasticity and Scalability  Respond to changes in demand by scaling in/out EC2 servers.  Scale manually, automatically or on schedule  Automatic scaling based on CloudWatch Metrics  Provides Availability  Spreads Instances across Availability Zones  Eliminate outages as result of changes in demand  Terminate and rebuild failed nodes automatically  Cost: “pay for what you need” or utilize “Spot” instances Auto Scaling: Benefits Copyright 2015 Blue Chip Tek
  • 11.  Dynamic infrastructure creates challenges:  Monitoring Tools  Log File Collection and Analysis  Changing IP Addresses/Ranges  Applications saving “State” on Terminated Servers  Applications may require modification to work with Auto Scaling Auto Scaling: Challenges Copyright 2015 Blue Chip Tek
  • 12. AWS Auto Scaling (the Details) Copyright 2015 Blue Chip Tek
  • 13. An Auto Scaling Group has the following attributes:  Min Size  Max Size  Desired Capacity  Health Check Type (EC2 or ELB)  Associated Load Balancers  LaunchConfiguration  Provides Instance Type, AMI ID, User Data Auto Scaling: Attributes Copyright 2015 Blue Chip Tek
  • 14. A Launch Configuration tells an Auto Scaling Group About the Instance to Launch. Example attributes:  ImageID (aka AMI)  InstanceType  KeyName  SecurityGroups  Spot Price  User-Data Auto Scaling: Launch Configuration Copyright 2015 Blue Chip Tek
  • 15.  Tags applied on an “Auto Scaling Group” are also applied to instances  Tag with “Application”, “Environment”, “Owner” to enable reporting and easier AWS Administration  Tags are “Eventually Consistent” for Instances  Create an instance as part of “web-prod01” and the instance may not get that tag immediately Auto Scaling: Tags Copyright 2015 Blue Chip Tek
  • 16.  Auto Scaling is designed to be used with other AWS Services:  Elastic Load Balancing for routing Inbound requests  SQS for dispatching messages/work to ephemeral EC2 Servers  CloudWatch for controlling scale/up events Auto Scaling: Typical Design Copyright 2015 Blue Chip Tek
  • 17. Auto Scaling and ELB Copyright 2015 Blue Chip Tek
  • 18. Auto Scaling and SQS Copyright 2015 Blue Chip Tek
  • 19.  Use CloudFormation to provision Auto Scaling Groups  Auto Scaling Groups are challenging to build manually  Auto Scaling Groups don’t support easy “Launch Configuration” modifications*  Auto Scaling is Integrated with or Used By:  CodeDeploy (for getting code onto instances)  Elastic Load Balancers? Sure seems like it…  Elastic Beanstalk  EC2 Container Service (optional, but recommended) Integration with other AWS Services Copyright 2015 Blue Chip Tek
  • 20. AWS Auto Scaling (Live Demo) Copyright 2015 Blue Chip Tek
  • 21.  Use all Availability Zones  AWS may “deny” the ability to launch an instance in an AZ if over capacity  Ship all data off instances as quickly as possible  Avoid use of Lifecycle Hooks if Possible  Create groups of 1 Instance  If errors arise, terminate instance and rebuild  Over-provision by 1 node until Scaling policy well understood  Keep Auto Scaling Rules Simple Auto Scaling: Best Practices Copyright 2015 Blue Chip Tek

Editor's Notes

  1. Regions: Costs: as of April 2015, difference between us-west-2 and sa-east-1 not all Services Available in All Regions: http://aws.amazon.com/about-aws/global-infrastructure/regional-product-services Availability Zones: Availability Zones aid in meeting availability requirements: A majority of AWS failures occur only in one AZ Availability Zones are Isolated from one another (http://aws.amazon.com/ec2/faqs/ - How isolated are Availability Zones from one another?)
  2. Slide is a representation of a highly available, multi-AZ architecture. The Load Balancer is run in both the us-west-2a and us-west-2b Availability Zones The Auto Scaling Group is also run in both the us-west-2a and us-west-2b Availability Zones. The Multi-AZ RDS Database runs in both us-west-2a and us-west-2b
  3. Slide is a representation of the result of a us-west-2a Failure: The ELB will most likely stop making the IP address(es) of the instances in the us-east-2a availability zone available, at which point clients will begin sending to alternative IP addresses (there are exceptions) The Auto Scaling Group will notice that the capacity of the Auto Scaling Group has dropped from 2 EC2 instances to 1 EC2 instance, and will respond by increasing the number of instances in the us-east-2b availability zone. The RDS instance will failover to the standby node in the us-west-2b availability zone.
  4. Reference: http://aws.amazon.com/autoscaling/
  5. Reference: http://aws.amazon.com/autoscaling/
  6. As far as I know, I built the first tool to do this.