3. Choose appropriate initial workloads
Web Dev & Test Backup & DR Big Data Pain point
A natural workload for Spin environments up Take part of your data or Cloud perfectly suited to Move specific service
the cloud and down on demand business applications batch processing, aspects causing undue
step- by-step into non- variable loads cost or management
Loads are often highly Decouple dev and test
production DR use burden
variable and environments from No waiting in queue:
unpredictable; perfect operations constraints Understand cloud each workgroup gets its Workflows, search
for elastic cloud dynamics and test during own cluster—”PC” = indexing, media
Explore elasticity in a
controlled failovers personal cluster streaming, document
Connect back to on- sandboxed environment
archiving, constrained
prem systems using VPC, Shut it all off when
Test systems at full databases
DMZ subnets, private you’re not using it
scale!
subnets and a VPN
Low hanging fruit can be easiest way to ‘cut teeth’
4. Plan evolution & set goals
PoC Production Automation
Understand services Implement monitoring Automate corrective measures
Examples
Test performance Change control and management Auto-scaling
Architect for scale Security management Zero downtime deployments
Build cross functional team capabilities Scalability System backup and recovery
5. Plan evolution & set goals
PoC Production Automation
Understand services Implement monitoring Automate corrective measures
Examples
Test performance Change control and management Auto-scaling
Architect for scale Security management Zero downtime deployments
Build cross functional team capabilities Scalability System backup and recovery
Beanstalk
APIs
Beanstalk Cloud Formation
CLI
Cloud Watch
Auto scaling
IAM
7. Govern deployments
Accounts
Create an account structure
that makes sense
Use accounts like environments
where you need separation and
control
e.g.
Dev Sandboxes
Test Environments
Business Units
Products & Services
8. Govern deployments
Accounts Billing
Create an account structure Control access to billing
that makes sense information
Use accounts like environments Use IAM users to keep billing
where you need separation and information in the master account
control
Consolidate billing into a
e.g. single account
Dev Sandboxes Let one account pick up the bill for
Test Environments multiple ‘sub accounts’
Business Units
Products & Services Setup billing alerts and
automated bill reporting
Get CloudWatch notifications when
billing reaches a point and output
csv reports to S3 for analysis
10. Billing settings
Cost accounting in
favorite package
Billing Alerts
Bill reached $x
Dev 1
Dev 2
Test Master Account
Production Data labeled by
source in S3
Consolidated Billing
Internal
Systems
11. Billing settings
Dev 1 Dev 1 reached $100
Dev 2 Dev 2 reached $250
Test Master Account Test reached $1,000
Production Prod reached $1,200
Internal
Internal reached $400
Systems
12. Govern deployments
Accounts Billing
Create an account structure Control access to billing
that makes sense information
Use accounts like environments Use IAM users to keep billing
where you need separation and information in the master account
control
Consolidate billing into a
e.g. single account
Dev Sandboxes Let one account pick up the bill for
Test Environments multiple ‘sub accounts’
Business Units
Products & Services Setup billing alerts and
automated bill reporting
Get CloudWatch notifications when
billing reaches a point and output
csv reports to S3 for analysis
13. Govern deployments
Accounts Billing Access Keys
Create an account structure Control access to billing Decide upon a key
that makes sense information management strategy
Use accounts like environments Use IAM users to keep billing Control access to EC2 instances via
where you need separation and information in the master account SSH and embedded public key:
control e.g. EC2 Key Pair per group of
Consolidate billing into a instances, EC2 Key Pair per account
e.g. single account
Dev Sandboxes Consider SSH key rotation &
Let one account pick up the bill for
Test Environments multiple ‘sub accounts’
automation
Business Units Limit exposure to private key
Products & Services Setup billing alerts and compromise by rotating keys and
replacing authorized_keys
automated bill reporting listings on running instances
Get CloudWatch notifications when Consider bootstrap automation to
billing reaches a point and output grant developer access with
csv reports to S3 for analysis developer unique keypairs
14. Govern deployments
Accounts Billing Access Keys Groups & Roles
Create an account structure Control access to billing Decide upon a key Use IAM Groups to manage
that makes sense information management strategy console users and API access
Use accounts like environments Use IAM users to keep billing Control access to EC2 instances via Provide developers with IAM user
where you need separation and information in the master account SSH and embedded public key: login and unique API access
control e.g. EC2 Key Pair per group of credentials
Consolidate billing into a instances, EC2 Key Pair per account Control & restrict what IAM users
e.g. single account can do by placing them in groups
Dev Sandboxes Consider SSH key rotation & with policies
Let one account pick up the bill for
Test Environments multiple ‘sub accounts’
automation
Business Units Limit exposure to private key
Assign EC2 Instances IAM
Products & Services compromise by rotating keys and roles
Setup billing alerts and
replacing authorized_keys Let AWS manage API access
automated bill reporting listings on running instances credentials on running instances by
Get CloudWatch notifications when Consider bootstrap automation to assigning a system entitlement to an
billing reaches a point and output grant developer access with instance
csv reports to S3 for analysis developer unique keypairs e.g. instance can only read S3 bucket
15. Identity & access management
Account
Administrators Developers Applications
Jim Brad Reporting
Bob Mark Console
Susan Tomcat
Kevin
16. Identity & access management
Groups Account
Administrators Developers Applications
Jim Brad Reporting
Bob Mark Console
Susan Tomcat
Kevin
Multi-factor authentication
17. Identity & access management
Groups Account Roles
Administrators Developers Applications
Jim Brad Reporting
Bob Mark Console
Susan Tomcat
Kevin
Multi-factor authentication AWS system entitlements
18. IAM policies
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticbeanstalk:*",
Policy driven "ec2:*",
Declarative definition of rights for principals "elasticloadbalancing:*",
"autoscaling:*",
Policies control access to AWS APIs "cloudwatch:*",
"s3:*",
"sns:*"
],
"Resource": "*"
}
]
}
19. Identity Federation Sample
• Use case:
– Enterprise employee signs with his normal
credentials
– Access S3 with enterprise application
• Setup
– IIS for enterprise authentication against
Active Directory
– Client application to access S3
– Read-only access to S3
21. Shared responsibility
Customer Data
Customer
• Customers implement their
Platform, Applications, Identity & Access Management own set of controls
• Multiple customers with
FISMA Low and Moderate
Operating System, Network & Firewall Configuration ATOs
Client-side Data Encryption & Data Server-side Encryption Network Traffic Protection
Integrity Authentication (File System and/or Data) (Encryption/Integrity/Identity)
Foundation Services
• SAS-70 Type II
Amazon
• ISO 27001/ 2 Certification
Compute Storage Database Networking • Payment Card Industry (PCI)
• Data Security Standard (DSS)
• NIST Compliant Controls
Availability Zones • DoD Compliant Controls
AWS Global • FedRAMP Compliant Controls
Edge Locations
Infrastructure • HIPAA and ITAR Compliant
Regions
23. Leverage shared security model
Understand your customer & form security stance
Engage with security assessors early in adoption cycle
Don’t fear assessment – AWS meets high standards (PCI, ISO27001, SOC1…)
As with any infrastructure provider, security assessments take time
Derive value from architecture reviews early in deployment cycle
24. Leverage shared security model
Understand your customer & form security stance
Engage with security assessors early in adoption cycle
Use comprehensive materials and certifications provided by AWS
http://aws.amazon.com/security/
Risk and compliance paper
AWS security processes paper
NEW! CSA consensus assessments
initiative questionnaire
25. Leverage shared security model
Understand your customer & form security stance
Engage with security assessors early in adoption cycle
Use comprehensive materials and certifications provided by AWS
Build upon features of AWS and implement a ‘security by design’ environment
26. Build upon AWS features
Tiered Access Security Groups VPC Direct Connect & VPN
IAM Instance firewalls Subnet control Private connections to VPC
Control users and allow AWS to Firewall control on instances via Create low level networking Secured access to resources in AWS
manage credentials in running Security Groups constraints for resource access, such over software or hardware VPN and
instances for service access as public and private subnets, dedicated network links
(allocation, rotation) CLIs and APIs internet gateways and NATs
Instantly audit your entire AWS
APIs vs. Instance infrastructure from scriptable APIs –
Bastion hosts
Provide developer API credentials generate an on-demand IT inventory Only allow access for management
and control access to SSH keys enabled by programmatic nature of of production resources from a
AWS bastion host. Turn off when not
Temporary Credentials needed
Provide developer API credentials
and control access to SSH keys
28. Architect to use cloud strengths
Review application architectures early – assess fit for cloud
? e.g. variable capacity requirements, ‘standard’ technology stacks, reference architectures*
Can cloud benefits be leveraged with minimum effort outlay?
? e.g. Application performance improvement by migration of static content to S3/CloudFront
Will cloud yield cost savings & agility improvements?
? e.g. Faster development cycles for dev/test, reduced cap-ex for application environments
Can automation lead to a more agile & secure service?
? e.g. fully scripted deployments, IAM & EC2 instance roles, rolling deployments
*http://aws.amazon.com/architecture
29. Architect to use cloud strengths
Disposable compute
✓✓ Design systems that can suffer
instance loss
Dispose of compute when it is not
✓ ✓ required
30. Architect to use cloud strengths
Disposable compute
Flexible capacity
✓ ✓ ✓ Design for systems that potentially scale
from zero instances to hundreds
Use Auto-scaling (events, schedules etc) to
✓ ✓ ✓ drive capacity availability
31. Architect to use cloud strengths
Disposable compute
Flexible capacity
✓ ✓ ✓ Utilize 11 9s durability of objects in S3
Scale databases with RDS and use
DynamoDB for high throughput NoSQL
Cost effective & reliable storage ✓ ✓✓
32. Architect to use cloud strengths
Disposable compute
Flexible capacity
✓ ✓ ✓ Automate everything from scaling to
instance recovery from failure
Cost effective storage
Automation and control
33. Bootstrapping – custom AMIs
Instance
AMI
Custom machine
1 Create instance of your OS choice image
2 Configure environment
Auto-scaling
Manual deployments
3 Install software Programmatic deployments
4 Create AMI from instance
5 Launch fully configured instances from AMI
34. Bootstrapping – metadata service
Instanc
e
Metadata service contains wealth of information about an instance AMI
http://169.254.169.254/latest/meta-data Custom or standard
machine image
ami-id local-hostname Receive custom
Metadata
data to drive
ami-launch-index local-ipv4 Service
bootstrapping
ami-manifest-path mac
block-device-mapping network
hostname placement
instance-action profile
instance-id public-hostname
Instance-type public-ipv4
kernel-id public-keys
reservation-id
35. Bootstrapping – metadata service
Instanc
e
Metadata service contains wealth of information about an instance AMI
http://169.254.169.254/latest/meta-data Custom or standard
machine image
+ user data Receive custom
data to drive
Metadata
Service
bootstrapping
Scripts in user-data field of metadata will be executed on launch
e.g.
#!/bin/sh
yum -y install httpd
chkconfig httpd on
/etc/init.d/httpd start
Or:
<powershell>
…
</powershell>
36. Bootstrapping – metadata service
Instanc
e
Metadata service contains wealth of information about an instance AMI
http://169.254.169.254/latest/meta-data Custom or standard
machine image
+ user data Receive custom
data to drive
Metadata
Service
bootstrapping
Scripts in user-data field of metadata will be executed on launch
Install software e.g. web server, app server, proxy
Pull data and application packages from S3
Publish metadata for instance to other systems e.g. monitoring systems
Setup security profile of instance based upon intended use e.g. pull latest config
42. Architect to use cloud strengths
Elastic Load Balancing Route 53 RDS Auto-scaling
Use at regional level Leverage SLA Scale databases without Dynamically scale resources &
Combined with autoscaling will Improve application reliability with admin overhead control costs
balance requests and resource Route 53’s SLA on requests served Choose instance size for databases Only provision the resources that
capacity across availability zones and scale up over time are required with scale up and cool
Weighted routing down policies that match demand
Within VPC Perform A/B analysis, and staged Add high availability from
Use to loadbalance between application roll-outs by moving a management console
application tiers within an portion of traffic to new Create master-slave configurations
availability zone infrastructure and read-replicas. AWS takes care of
the failover and recreation of a new
Instance migrations Control TTLs and updates slave in event of master DB loss
Easily move instances from dev Take absolute control of DNS
environments to test environments updates for more decisive system
by moving between ELBs updates
44. Be elastic and cost optimized
Elastic Load Balancing Auto-scaling policies
Scalability
Cost Optimization
Availability
Instance types and sizes
45. Auto-scaling policies
Manually By Schedule
Preemptive manual scaling
Send an API call or use CLI to Regular scaling up and down
Scale up/down based on date
of capacity
launch/terminate instances – ofand time
instances
Only need marketing event add 10
e.g. before a to specify capacity e.g. scale from 0 to 2 to process SQS
more instances messages every night or double
change (+/-) capacity on a Friday night
By Policy Auto-Rebalance
Scale in response to changing Instances are automatically
Dynamic scale based upon
conditions, based on user Maintain capacity across
launched/terminated to
configuredmetrics
custom real-time availability zones
ensure the application is
e.g. SQS queue depth, Average CPU e.g. Instance availability maintained in
monitoring and alerts
load, ELB latency
balanced across multiple Azs
event of AZ becoming unavailable
46. Instance types / Pricing models
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
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:
Use Cases: Applications with flexible start and end times
Applications with short term, spiky, or
unpredictable workloads; Applications with steady state or predictable Applications only feasible at very low compute
usage prices
Application development or testing
Applications that require reserved capacity,
including disaster recovery
47. Leverage all models
7000
6000 Spot
5000
4000 On Demand
3000
2000
Reserved Instances
1000
0
48. Cloud computing bottom line
30% 70%
On-Premise Your Managing All of the
Infrastructure Mission “Undifferentiated Heavy Lifting”
49. Cloud computing bottom line
30% 70%
On-Premise Your Managing All of IT’s
Infrastructure Mission “Undifferentiated Heavy Lifting”
AWS
More Time and Resources to Focus on Configuring Your
Cloud-Based
Your Mission Cloud Assets
Infrastructure
70% 30%
Our goal, and what our customers tell us they see, is that this ratio is inverted after moving to AWS. When you move your infrastructure to the cloud, this changes things drastically. Only 30% of your time should be spent architecting for the cloud and configuring your assets. This gives you 70% of your time to focus on your business. Project teams are free to add value to the business and it's customers, to innovate more quickly, and to deliver products to market quickly as well.
Our goal, and what our customers tell us they see, is that this ratio is inverted after moving to AWS. When you move your infrastructure to the cloud, this changes things drastically. Only 30% of your time should be spent architecting for the cloud and configuring your assets. This gives you 70% of your time to focus on your business. Project teams are free to add value to the business and it's customers, to innovate more quickly, and to deliver products to market quickly as well.
