AWS Account and VPC

Strategies
Chris Johnson, Solutions Architect
October 31, 2016

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Session Overview

AWS Accounts primer

VPC Basics
When to adopt a multi VPC strategies
Account and VPC segmentation reasons
Segmentation viewpoints
 What is an AWS Account?
Administrative Boundary

• All access and rights in

an account are
governed by the
permissioned created
and managed within the
account
• Including those for
users, groups,
applications and other
externally federated
access methods.
• Access is initially
managed by the root
account
 What is an AWS Account?
Administrative Boundary Resource Containment

• All access and rights in • Resources created

an account are within an account are
governed by the limited to that specific
permissioned created account, they cannot
and managed within the span multiple accounts,
account e.g. VPC, IAM
• Including those for • Resources cannot
users, groups, dynamically migrate
applications and other from one account to
externally federated another
access methods. • AWS resources are
• Access is initially constrained hard and
managed by the root soft limits by account;
account and can affect each
other, e.g. API throttling
 What is an AWS Account?
Administrative Boundary Resource Containment Billing Entity

• All access and rights in • Resources created • Billing and Financial

an account are within an account are detail, including
governed by the limited to that specific currency billing country
permissioned created account, they cannot are defined and
and managed within the span multiple accounts, controlled at an account
account e.g. VPC level
• Including those for • Resources cannot • Reserved Instances
users, groups, dynamically migrate and volume discounts
applications and other from one account to are calculated at an
externally federated another account level
access methods. • AWS resources are • Trusted Advisor
• Access is initially constrained hard and analysis at an account
managed by the root soft limits by account; level
account and can affect each
other, API throttling
Segmentation Reasons
There are multiple reasons for segmenting by accounts or VPCs, these generally
include:
Environmental

Separation
between
development, test
and production for
security,
governance or
regulatory reason,
e.g. PCI Workload
Segmentation Reasons
There are multiple reasons for segmenting by accounts or VPCs, these generally
include:
Environmental Financial

Separation Provide cost

between visibility,
development, test accountability or
and production for control on a per
security, account basis; this
governance or may also be
regulatory reason, related to a line of
e.g. PCI Workload business
Segmentation Reasons
There are multiple reasons for segmenting by accounts or VPCs, these generally
include:
Environmental Financial Business

Separation Provide cost Delegated control

between visibility, to particular
development, test accountability or business unit to be
and production for control on a per able leverage AWS
security, account basis; this platform within pre-
governance or may also be defined
regulatory reason, related to a line of governance
e.g. PCI Workload business framework
Segmentation Reasons
There are multiple reasons for segmenting by accounts or VPCs, these generally
include:
Environmental Financial Business Workload

Separation Provide cost Delegated control Segregation of

between visibility, to particular public or private
development, test accountability or business unit to be facing services,
and production for control on a per able leverage AWS differing risk
security, account basis; this platform within pre- profiles, data
governance or may also be defined classification,
regulatory reason, related to a line of governance consumer of
e.g. PCI Workload business framework service, etc.
Walkthrough: Setting up an
Internet-connected VPC
Creating an Internet-connected VPC: Steps

Choosing an Setting up subnets Creating a route to Authorizing traffic

address range in Availability Zones the Internet to/from the VPC
Choose address ranges
Choosing IP address ranges for your VPC

172.31.0.0/16
Recommended:
Recommended:
/16
RFC1918 range
(64K addresses)
Set up subnets
Choosing IP address ranges for your subnets

172.31.0.0/16

eu-west-1a eu-west-1b eu-west-1c

172.31.0.0/24 172.31.1.0/24 172.31.2.0/24

VPC subnet VPC subnet VPC subnet

Availability Zone Availability Zone Availability Zone
Auto-assign Public IP:
All instances will get an automatically assigned public IP
More on subnets

• Recommended for most customers:

• /16 VPC (64K addresses)
• /24 subnets (251 addresses)
• One subnet per Availability Zone
Create a route to the Internet
Routing in your VPC

• Route tables contain rules for which

packets go where
• Your VPC has a default route table
• … but you can assign different route
tables to different subnets
Traffic destined for my VPC
stays in my VPC
Internet gateway

Send packets here if you want

them to reach the Internet
Everything that isn’t destined for the VPC:
Send to the Internet
Authorizing traffic:
Network ACLs
security groups
Network ACLs = stateless firewall rules
Can be applied on a subnet basis

English translation: Allow all traffic in

Security groups follow the structure of
your application

“MyWebServers” Security Group

Allow only “MyWebServers”

“MyBackends” Security Group

Security groups = stateful firewall

In English: Hosts in this group are reachable

from the Internet on port 80 (HTTP)
Security groups = stateful firewall

In English: Only instances in the MyWebServers

Security Group can reach instances in this
Security Group
Layered Control

lock down on instance level

isolate concerns

lock down on network level

route restrictively
Flows
Security groups in VPCs: Additional notes

• VPC allows creation of egress as well as ingress

security group rules
• Best practice: Whenever possible, specify allowed traffic
by reference (other security groups)
• Many application architectures lend themselves to a 1:1
relationship between security groups (who can reach
me) and AWS Identity and Access Management (IAM)
roles (what I can do).
VPC Flow Logs: See all your traffic

• Visibility into effects of

security group rules
• Troubleshooting network
connectivity
• Ability to analyze traffic
Amazon VPC endpoints: Amazon S3
without an Internet gateway
When to adopt a multi-VPC strategy
When first deploying VPC it seems analogous to a traditional data center, however
there are good reasons to consider a multi-VPC strategy, for example

Security • Provide security configurations appropriate to workload, improving security posture

• Implement appropriate ingress and egress network access, e.g. create isolated
VPCs
 When to adopt a multi-VPC strategy
When first deploying VPC it seems analogous to a traditional data center, however
there are good reasons to consider a multi-VPC strategy, for example

Security • Provide security configurations appropriate to workload, improving security posture

• Implement appropriate ingress and egress network access, e.g. create isolated
VPCs
Supportability • VPC specific configurations, rather than multiple configurations within a single VPC
• De-risk changes by minimizing the “blast-radius”, accelerate deployment of
changes
 When to adopt a multi-VPC strategy
When first deploying VPC it seems analogous to a traditional data center, however
there are good reasons to consider a multi-VPC strategy, for example

Security • Provide security configurations appropriate to workload, improving security posture

• Implement appropriate ingress and egress network access, e.g. create isolated VPCs

Supportability • VPC specific configurations, rather than multiple configurations within a single VPC
• De-risk changes by minimizing the “blast-radius”, accelerate deployment of changes

Network • Provides granular network control and integration, only connect to relevant networks
• Leverage multiple VPC constructs effectively, route tables, subnets, NACLs, Peering,
DNS
 When to adopt a multi-VPC strategy
When first deploying VPC it seems analogous to a traditional data center, however
there are good reasons to consider a multi-VPC strategy, for example

Security • Provide security configurations appropriate to workload, improving security posture

• Implement appropriate ingress and egress network access, e.g. create isolated VPCs

Supportability • VPC specific configurations, rather than multiple configurations within a single VPC
• De-risk changes by minimizing the “blast-radius”, accelerate deployment of changes

Network • Provides granular network control and integration, only connect to relevant networks
• Leverage multiple VPC constructs effectively, route tables, subnets, NACLs, Peering,
DNS
Automation • Supports automated deployment of resources into segregated VPCs
• VPC can become part of the automation fabric, removing data center mindset
 When to adopt a multi-VPC strategy
When first deploying VPC it seems analogous to a traditional data center, however
there are good reasons to consider a multi-VPC strategy, for example

Security • Provide security configurations appropriate to workload, improving security posture

• Implement appropriate ingress and egress network access, e.g. create isolated VPCs

Supportability • VPC specific configurations, rather than multiple configurations within a single VPC
• De-risk changes by minimizing the “blast-radius”, accelerate deployment of changes

Network • Provides granular network control and integration, only connect to relevant networks
• Leverage multiple VPC constructs effectively, route tables, subnets, NACLs, Peering,
DNS
Automation • Supports automated deployment of resources into segregated VPCs
• VPC can become part of the automation fabric, removing data center mindset

Limits • Mitigates limits for very large VPCs, e.g. maximum practical security group and rule
limits
• Reduce risk of VPCs constraints, e.g. network, subnet size is fixed at creation time
So, what’s the right
strategy?
Sorry, there’s no one right answer 
Sorry, there’s no one right answer 

It’s often a balance of different

viewpoints
 Segmentation viewpoints

Financial Business Governance Operational

How resource Service provider How resources are Operational
utilisation and model, M&A secured, controlled management,
consumption is possibilities, and audited enterprise
measured, reported financial integration, network
and re-charged responsibility integration, AWS
model, autonomy limits
 Segmentation viewpoint considerations
Financial

Segmenting for financial visibility

+ Clear financial accountability by line of − Cross account reporting can be more complex,
business with discrete accounts requires access to billing reports per account
or consolidation between accounts for
+ Simplified billing and chargeback operations centralized reporting
across multiple cost centers or lines of
business − VPC doesn’t provide any financial separation
benefits

− May lose the benefit of AWS discounts without

consolidation and agreement on internal
recharge
 Segmentation viewpoint considerations
Financial Business

Segmenting based on business needs

+ Supports different lines of business having − Consideration needs to be given to duplication
different financial support structures of services across accounts, the shared
services paradigm
+ Allows lines of business to be easily devolved
from organization

+ Supports MSP model where individual

customers have dedicated account from
controls and billing perspective
 Segmentation viewpoint considerations
Financial Business Governance

Segmenting based on governance demands

+ Specialized workloads can be isolated in their − Requires common tagging and optimization
own account, where workload and policy to ensure cross account reporting and
environment specific controls can applied cost optimization is optimal

+ Allows separation by environment, allowing for − Governance review needs to be extended

clear delegation of duties across multiple accounts

+ Easier to implement least privilege principle by

account
 Segmentation viewpoint considerations
Financial Business Governance Operational

Segmenting based on operational needs

+ Minimize blast radius for changes and − Common operations functions, such as audit
simplifies risk assessment, e.g. development or security, require cross account access rights
changes cannot affect production environment
− Management of common policy across
+ Allow for per account AWS limits can be set for accounts required when deployed or updated
certain resources, e.g. can minimize risk of
cost overruns − Increases complexity of network connectivity
both between on-premises and AWS and also
cross account
AWS Account patterns
Account segmentation patterns
• Single across the enterprise Enterprise
Account
AWS Account patterns
Account segmentation patterns
• Multiple across the enterprise
Line Of Business
• Per line of business, whoever has
the corporate credit card
Line Of Business
AWS Account patterns
Account segmentation patterns
• Consolidated across the Enterprise
enterprise for billing purposes Account Master

• Based on environment with

consolidation, e.g. Prod, Non-Prod Production
Account

Non-Production
Account
AWS Account patterns
Account segmentation patterns
• Consolidated across the Enterprise
enterprise for billing purposes Account Master

• Based on environment with

consolidation, e.g. Prod, Non-Prod ERP
Internet
Applications

• Or, based on workload

Payment
Billing
Processing
AWS Account patterns
Account segmentation patterns
• Consolidated across the Enterprise
Security and Audit
enterprise for billing purposes Account Master

• Based on environment with

consolidation, e.g. Prod, Non-Prod Production
Internet
Applications

• Or, based on workload

• Considering governance and Non-Production Big Data

security needs
AWS Account patterns
Account segmentation patterns
• Consolidated across the Enterprise
Security and Audit
enterprise for billing purposes Account Master

• Based on environment with

consolidation, e.g. Prod, Non-Prod Production
Internet
Applications

• Or, based on workload

• Considering governance and Non-Production Big Data

security needs
VPC Patterns
VPC Patterns - Single Large VPC
Analogous to a traditional data center

Pros
Aligned with existing data center concept, allows
Enterprises to easily accept virtual DC concept
Allows for Rapid Deployment requiring minimal
incremental Involvement from Network group
WEB UAT
Single Direct Connect integration point

APP SIT Direct

Connect
Locations Cons
• Complex operational management where multiple
teams are delegated access to VPC
DB DEV
• Complex security management, IAM Policies, Security
Groups and NACLs are common
• Higher chance of reaching VPC limits more quickly
• Security blast radius, common security and network
CORE SERVICES
controls
• Need to plan capacity requirements, “get it right first
time”
VPC Patterns - Multiple VPCs by Classification
Segregated based on information classification level

Pros
Clear boundaries of security control are established based
on data classification
Security assessment policies can be adapted based on
classification
CONFIDENTIAL

Direct
Connect
Locations Cons
UNRESTRICTED
• Complex operational management where multiple
teams are delegated access to VPC
• Complex security management, IAM Policies are
common
• Large blast-radius for incremental changes
• No segregation between environments, development
INTERNAL
and production co-exist
VPC Patterns - Multiple VPCs by Workload
Segregated based on application or workload
Pros
Able to scale by adding VPCs for new workloads
Delegate VPC configuration to different LOB
Security policies can be adapted based on application
Easier separation of applications, thus highly limiting the
ECOMMERCE PAYMENT GW
blast radius of changes
Support for common core services across applications
Supports highly automated and streamlined process within
each LOB
Direct
Connect
Locations Cons
INTRANET
• Accountability and responsibility needs to be enforced
when setting up inter-VPC peering
• Increased network routing complexity across peered
VPCs
• Multiple Direct Connect virtual interfaces required to
corporate data centers
COMMON SERVICES
VPC Patterns - Multiple VPCs by Environment
Segregated based on environment type
Pros
Delegate access control and VPC configuration to different
teams based on environment
Easier separation of environments, thus limiting the blast
radius of changes
PRODUCTION
Separation of security controls across environments
Security assessment policies can be based on
environment
Supports strong segregation of duties by environment
Direct
Connect
Locations Cons
SIT UAT
• Complex operational management where multiple
teams are delegated access to VPC
• Complex security management, IAM policies are
common
• Complex tagging processes required for billing
• Limited expansion space, “get it right first time” or add
DEVELOPMENT
multiple environment VPCs
VPC Patterns - Multiple VPCs and Accounts
Segregated based on environment type, across multiple AWS accounts
Pros
Delegate access control and VPC configuration to different
teams based on environment
Easier separation of environments, thus limiting the blast
radius of changes
PRODUCTION
Separation of security controls across accounts and
environments
Security assessment policies can be based on
environment
Direct
Connect
Supports strong segregation of duties by environment
Locations

Cons
SIT UAT • Limited expansion space, “get it right first time” or add
multiple environment VPCs

DEVELOPMENT
Advanced Enterprise Pattern

PRODUCTION SERVICES SENSITIVE BIG DATA

Direct
Connect
Locations

SIT UAT ECOMMERCE PAYMENT GW

An advanced enterprise will leverage multiple

patterns to accommodate different
DEVELOPMENT requirements
Where to start
1. Develop and enforce common tagging practices, which meet
minimum requirements for billing and chargeback needs
2. Implement consolidated single master which provides billing Enterprise
Account Master
consolidation and reporting across all lines of business
3. Define centralised security and audit account with strict access
controls to centralise logging and manage organisational Security and Audit

encryption keys
4. Define sub account creation policy based on actual needs for
isolation or delegation as per governance and security Production

requirements; segregate based on environment, production vs

non-production
5. Consider additional VPCs as boundaries for workloads that Non-Production
require specialised controls or resources
Where to start

But, there is still a lot of complexity to consider

Governance and Security across accounts Enterprise
Account Master
• Permitted Services
• Common IAM policies
Security and Audit
Billing
• Allocation of RI benefit in consolidated accounts
Production
• Internal re-charge processes
• Maximising AWS volume discounts
Non-Production
Finally…

1. There’s no silver bullet…

2. Understand your requirements across a range of different
viewpoints
3. Keep an eye on the future when designing accounts and VPCs,
new features will appear which will change the art of the
possible
4. Keep it simple at the start, needs will change as they mature
Thank you!