2013 AWS Worldwide Public Sector Summit Washington, D.C.

AWS Best Practices

Tim Bixler

Sr. Manager, Federal Solutions Architecture

Choose your use

case well

1

Dev & Test

Spin environments up and

down on demand

Decouple development and

test environments from

operations constraints

Explore elasticity in a

sandboxed environment

Backup & DR

Take part of your data or

business applications step-

by-step into non-production

DR use

Understand cloud dynamics

and test during controlled

failovers

Greenfield

Project

Embody best practice of cloud

computing in unconstrained

greenfield projects

Self contained web projects,

document archiving etc

Low hanging fruit can be easiest to pick

Pain point

Move specific service aspects

causing undue cost or

management burden

Workflows, search indexing,

media streaming, document

archiving, constrained

databases

Choose appropriate use cases

PoC Production Automation

Understand services

Test performance

Architect for scale

Build cross functional team

capabilities

Implement monitoring

Change control and management

Security management

Scalability

Automate corrective measures

Auto-scaling

Zero downtime deployments

System backup and recovery Exam

ple

s

Plan evolution & set goals

PoC Production Automation

Understand services

Test performance

Architect for scale

Build cross functional team

capabilities

Implement monitoring

Change control and management

Security management

Scalability

Automate corrective measures

Auto-scaling

Zero downtime deployments

System backup and recovery Exam

ple

s

Plan evolution & set goals

Amazon

Beanstalk

Amazon Beanstalk

Amazon OpsWorks

Amazon Cloud Formation

Amazon Cloud Watch

Amazon IAM

APIs

CLI

Amazon Auto Scaling

Govern deployments

2

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

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

Control access to billing

information

Use Amazon IAM users to keep

billing information in the master

account

Consolidate billing into a

single account

Let one account pick up the bill

for multiple ‘sub accounts’

Setup billing alerts and

automated bill reporting

Get Amazon CloudWatch

notifications when billing reaches

a point and output csv reports to

Amazon S3 for analysis

Accounts Billing

Govern deployments

Enable CSV &

Programmatic Access

Billing

Preferences

Billing settings

Dev 1

Dev 2

Test Master Account

Consolidated Billing

Data labeled by

source in Amazon S3

Production

Internal Systems

Billing Alerts Bill reached $x

Cost accounting in

favorite package

Billing settings

Dev 1

Dev 2

Test Master Account

Production

Internal Systems

Dev 1 reached $100

Dev 2 reached $250

Test reached $1,000

Prod reached $1,200

Internal reached $400

Billing settings

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

Decide upon a key

management strategy

Control access to Amazon EC2

instances via SSH and

embedded public key:

e.g. Amazon EC2 Key Pair per

group of instances, Amazon EC2

Key Pair per account

Consider SSH key rotation

& automation

Limit exposure to private key

compromise by rotating keys and

replacing authorized_keys listings

on running instances

Consider bootstrap automation to

grant developer access with

developer unique keypairs

Accounts Billing Access Keys

Govern deployments

Control access to billing

information

Use Amazon IAM users to keep

billing information in the master

account

Consolidate billing into a

single account

Let one account pick up the bill

for multiple ‘sub accounts’

Setup billing alerts and

automated bill reporting

Get Amazon CloudWatch

notifications when billing reaches

a point and output csv reports to

Amazon S3 for analysis

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

Accounts Billing Access Keys

Use Amazon IAM Groups to

manage console users and

API access

Provide developers with Amazon

IAM user login and unique API

access credentials

Control & restrict what Amazon IAM

users can do by placing them in

groups with policies

Assign Amazon EC2

Instances Amazon IAM Roles

Let AWS manage API access

credentials on running instances by

assigning a system entitlement to an

instance

e.g. instance can only read Amazon

S3 bucket

Groups & Roles

Govern deployments

Control access to billing

information

Use Amazon IAM users to keep

billing information in the master

account

Consolidate billing into a

single account

Let one account pick up the bill

for multiple ‘sub accounts’

Setup billing alerts and

automated bill reporting

Get Amazon CloudWatch

notifications when billing reaches

a point and output csv reports to

Amazon S3 for analysis

Decide upon a key

management strategy

Control access to Amazon EC2

instances via SSH and

embedded public key:

e.g. Amazon EC2 Key Pair per

group of instances, Amazon EC2

Key Pair per account

Consider SSH key rotation

& automation

Limit exposure to private key

compromise by rotating keys and

replacing authorized_keys listings

on running instances

Consider bootstrap automation to

grant developer access with

developer unique keypairs

Account

Administrators Developers Applications

Bob

Kevin

Tomcat

Jim Brad

Mark

Susan

Reporting

Console

Identity & access management

Account

Administrators Developers Applications

Bob

Kevin

Tomcat

Jim Brad

Mark

Susan

Reporting

Console

Multi-factor authentication

Groups

Identity & access management

AWS system entitlements

Roles Account

Administrators Developers Applications

Bob

Kevin

Tomcat

Jim Brad

Mark

Susan

Reporting

Console

Multi-factor authentication

Groups

Identity & access management

IAM policies

{

"Statement": [

{

"Effect": "Allow",

"Action": [

"elasticbeanstalk:*",

"ec2:*",

"elasticloadbalancing:*",

"autoscaling:*",

"cloudwatch:*",

"s3:*",

"sns:*"

],

"Resource": "*"

}

]

}

Policy driven

Declarative definition of rights for

groups

Policies control access to AWS APIs

3 Ensure security

Foundation Services

Compute Storage Database Networking

AWS Global

Infrastructure Regions

Availability Zones

Edge Locations

Client-side Data Encryption & Data

Integrity Authentication

Server-side Encryption

(File System and/or Data) Network Traffic Protection

(Encryption/Integrity/Identity)

Platform, Applications, Identity & Access Management

Operating System, Network & Firewall Configuration

Customer Data

Am

azo

n

Cu

sto

mer

• SOC 1/SSAE 16/ISAE 3402

• SOC 2

• ISO 27001/ 2 Certification

• Payment Card Industry (PCI)

• Data Security Standard (DSS)

• NIST Compliant Controls

• DoD Compliant Controls

• FedRAMP

• HIPAA and ITAR Compliant

• Customers implement their

own set of controls

• Multiple customers with FISMA

Low and Moderate ATOs

Shared responsibility

Engage with security assessors early in adoption cycle

Leverage shared security model

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

Engage with security assessors early in adoption cycle

Use comprehensive materials and certifications provided by AWS

Leverage shared security model

http://aws.amazon.com/security/

Risk and compliance paper

AWS security processes paper

CSA consensus assessments

initiative questionnaire

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

Leverage shared security model

Build upon AWS features

Amazon IAM

Control users and allow AWS to

manage credentials in running

instances for service access

(allocation, rotation)

APIs vs. Instance

Provide developer API credentials

and control access to SSH keys

Temporary Credentials

Provide developer API credentials

and control access to SSH keys

Instance firewalls

Firewall control on instances via

Security Groups

CLIs and APIs

Instantly audit your entire AWS

infrastructure from scriptable

APIs – generate an on-demand IT

inventory enabled by

programmatic nature of AWS

Subnet control

Create low level networking

constraints for resource access,

such as public and private

subnets, internet gateways and

NATs

Bastion hosts

Only allow access for

management of production

resources from a bastion host.

Turn off when not needed

Tiered Access Security Groups Amazon VPC

Build upon AWS features

Store your cryptographic

keys

Use your most sensitive and

regulated data on Amazon EC2

without giving applications direct

access to your data's encryption

keys.

Migrate cryptographic

applications Use AWS CloudHSM in

conjunction with your compatible

on-premise HSMs to replicate

keys among on-premise HSMs

and CloudHSMs.

Amazon CloudHSM

Private connections to

Amazon VPC

Secured access to resources in

AWS over software or hardware

VPN and dedicated network links

Amazon Direct Connect &

VPN

Architect to use

cloud strengths

4

Architect to use cloud strengths

e.g. Application performance improvement by migration of static content to Amazon S3/CloudFront

Review application architectures early – assess fit for cloud

Can cloud benefits be leveraged with minimum effort outlay?

e.g. variable capacity requirements, ‘standard’ technology stacks, reference architectures*

*http://aws.amazon.com/architecture

?

?

?

?

e.g. Faster development cycles for dev/test, reduced cap-ex for application environments

Will cloud yield cost savings & agility improvements?

e.g. fully scripted deployments, Amazon IAM & EC2 instance roles, rolling deployments

Can automation lead to a more agile & secure service?

Architect to use cloud strengths

Design systems that can suffer

instance loss

Dispose of compute when it is not

required

Disposable compute

✓

✓ ✓

✓

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

✓

✓ ✓

✓

✓

✓

Architect to use cloud strengths

Utilize 99.999999999% durability of

objects in S3

Scale databases with RDS and use

DynamoDB for high throughput NoSQL

Disposable compute

Flexible capacity

Cost effective & reliable storage

✓

✓ ✓

✓

✓

✓

Architect to use cloud strengths

Disposable compute

Flexible capacity

Cost effective storage

Automation and control

Automate everything from scaling to

instance recovery from failure ✓ ✓ ✓

1 Create instance of your OS choice

2 Configure environment

3 Install software

4 Create Amazon Machine Image (AMI) from instance

5 Launch fully configured instances from AMI

Bootstrapping – custom AMIs

AMI

Custom machine image

Instance

Auto-scaling Manual deployments

Programmatic deployments

ami-id

ami-launch-index

ami-manifest-path

block-device-mapping

hostname

instance-action

instance-id

Instance-type

kernel-id

local-hostname

local-ipv4

mac

network

placement

profile

public-hostname

public-ipv4

public-keys

reservation-id

http://169.254.169.254/latest/meta-data

Metadata service contains wealth of information about an instance

Bootstrapping – metadata service

AMI

Custom or standard machine image

Instance

Metadata

Service

Receive custom data to drive

bootstrapping

+ user data Scripts in user-data field of metadata will be executed on launch

e.g.

http://169.254.169.254/latest/meta-data

Metadata service contains wealth of information about an instance

#!/bin/sh

yum -y install httpd

chkconfig httpd on

/etc/init.d/httpd start

<powershell>

…

</powershell>

Or:

AMI

Custom or standard machine image

Instance

Metadata

Service

Receive custom data to drive

bootstrapping

Bootstrapping – metadata service

+ user data Scripts in user-data field of metadata will be executed on launch

http://169.254.169.254/latest/meta-data

Metadata service contains wealth of information about an instance AMI

Custom or standard machine image

Instance

Metadata

Service

Receive custom data to drive

bootstrapping

Bootstrapping – metadata service

Install software e.g. web server, app server, proxy

Pull data and application packages from Amazon 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

1. Use Multiple

Availability Zones

2. Use Amazon RDS with

Replicas and Standby

3. Use Amazon Auto

Scaling groups

4. Use Amazon Elastic

Load Balancing

5. Use Amazon Route53

to host DNS zones

Three Services: Better Together

Amazon CloudWatch

Amazon Elastic Load

Balancer

Amazon Auto Scaling

Use at regional level

Combined with Amazon Auto

Scaling Amazon ELB will balance

requests and resource capacity

across Availability Zones

Within Amazon VPC

Use to loadbalance between

application tiers within an

Availability Zone

Instance migrations

Easily move instances from dev

environments to test

environments by moving between

Amazon ELBs

Leverage SLA

Improve application reliability with

Amazon Route 53’s SLA on

requests served

Weighted routing

Perform A/B analysis, and staged

application roll-outs by moving a

portion of traffic to new

infrastructure

Health checks

DNS health checks and

health-based failover

Latency Based Routing

Route end users to lowest-

latency endpoints

Scale databases without

admin overhead

Choose instance size for

databases and scale up over time

Add high availability from

management console

Create Multi-AZ deployments and

Read-Replicas. AWS takes care

of the failover and recreation of a

new standby in event of master

DB loss

Amazon Elastic Load

Balancing Amazon Route 53 Amazon RDS

Dynamically scale

resources & control costs

Only provision the resources that

are required with scale up and

cool down policies that match

demand

Amazon Auto Scaling

Architect to use cloud strengths

Be elastic and cost

optimized

5

PRICING (Amazon EC2)

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 Amazon 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

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

On

On-demand

Reserved capacity

100%

Capacity Over Time

AWS Spot Market Achieving economies of scale

Spot

0%

COST OPTIMIZE (ELASTIC CAPACITY)

Manually

Send an API call or use CLI to

launch/terminate instances –

Only need to specify capacity

change (+/-)

By Schedule

Scale up/down based on date

and time

By Policy

Scale in response to changing

conditions, based on user

configured real-time monitoring

and alerts

Auto-Rebalance

Instances are automatically

launched/terminated to ensure

the application is balanced

across multiple AZs

Amazon Auto Scaling policies

2013 AWS Worldwide Public Sector Summit

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

On Demand

Light Utilization RI

Medium Utilization RI

Heavy utilization RI

Hours

Ins

tan

ce

s

Optimizing Costs With RIs

COST OPTIMIZE (INSTANCE TYPES)

Start

Choose instance that

meets your basic

requirements best

Match memory &

virtual cores

Instance types

Start

Choose instance that

meets your basic

requirements best

Match memory &

virtual cores

Tune

Change instance size

up or down based

upon monitoring

Use trusted advisor to

assess

Instance types

Start

Choose instance that

meets your basic

requirements best

Match memory &

virtual cores

Tune

Change instance size

up or down based

upon monitoring

Use trusted advisor to

assess

Scale

Run instances across

multiple availability

zones

Smaller sizes equals

greater granularity

Purchase RIs after the

application has been

tuned and utilization

patterns are established

Instance types

COST OPTIMIZE (SOFWARE vs. SERVICES)

Leverage Scalable, On-demand Services

Software vs. Services

Amazon EC2 can run almost anything but there are cases where

there are more cost effective options AWS offers many scalable and

cost-effective options for common application needs:

• Amazon ELB instead of a software load balancer on Amazon EC2

• Amazon SQS instead of a queue on Amazon EC2

Software vs. Services – Amazon ELB

Web Servers

$0.06 per hour

(small instance)

Availability Zone

$0.025 per hour

Web Servers

Availability Zone

Amazon EC2 instance

+ software LB

Amazon

ELB DNS

DNS

vs.

vs.

Producer

Amazon SQS queue

Consumers

Consumers

Producer

Amazon EC2 instance

+ software queue

$0.50 per

1,000,000

Requests ($0.0000005 per

Request)

$0.06 per hour

(small instance)

Software vs. Services – Amazon SQS

Software vs. Services

Software on Amazon EC2

Pros:

Use custom features

Cons:

Requires an instance

SPOF

Limited to one AZ

DIY administration

AWS Services

Amazon ELB, Amazon SNS, Amazon

SQS, Amazon SES, Amazon SWF,

Amazon DynamoDB etc.

Pros:

Pay as you go

Scalability

Availability

High performance

SUPPORT

Basic Developer Business Enterprise

Included $49/month Greater of $100

- or -

10% of monthly AWS usage

for the first $0-$10K

7% of monthly AWS usage

from $10K-$80K

5% of monthly AWS usage

from $80K-$250K

3% of monthly AWS usage

from $250K+

Greater of $15,000

- or -

10% of monthly AWS

usage for the first $0-

$150K

7% of monthly AWS

usage from $150K-

$500K

5% of monthly AWS

usage from $500K-

$1M

3% of monthly AWS

usage from $1M+

Support

http://aws.amazon.com/premiumsupport/

BOTTOM LINE

Your Mission

70%

On-Premise Infrastructure

30%

Managing All of the “Undifferentiated Heavy Lifting”

Cloud computing bottom line

AWS Cloud-Based

Infrastructure

Your Mission

More Time to Focus on Your Mission

Configuring Your Cloud Assets

70%

30% 70%

On-Premise Infrastructure

30%

Managing All of the “Undifferentiated Heavy Lifting”

Cloud computing bottom line

AWS Best Practices

Thank you!