Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service

Reduce Your Blast Radius by
Using Multiple AWS Accounts

Per Region and Service
SEC304
Bryan Miller
Solutions Builder, Amazon Web Services
November 29, 2016
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
What to expect from the session
• How AWS manages multiple accounts and how

customers can leverage multiple AWS accounts to
manage security and reduce the blast radius by
deploying a single application into one account per
region
• Some insight into AWS account and security practices
• How to deploy the cross-account manager solution to
assist in managing role-based access to these accounts
Production application deployment diagram
AWS backbone
Corporate data center AWS Direct Connect Security account
Application accounts
Master (billing) account

Production application deployment on AWS
• Two accounts: One for the application and one for

security isolation
• The main account is owned by the application team and is
deployed in a single VPC
• The second account is owned by the security team and is
used to audit and control access to the first account and
control network connectivity between the first account and the
on-premises data center
• The accounts are connected using VPC peering and access
is managed by a federated role-based service
How did we arrive at this conclusion?
• Only applies to production, business critical applications,

or logical application groups
• A trade off between one large account and many small
accounts – what is the proper balance?
• Managing multiple accounts simplified with role-based
user federation solution – cross-account manager
solution
Cross-account manager solution
Using AWS
CloudFormation
templates to
create and
manage roles for
a master
account and sub
accounts
How AWS thinks about AWS
• Apply the right levels of control and change

management at the right time
• Automating the creation and management of resources
provides better traceability
• Verification and audit of configuration and access is
critical for production business-critical applications
How AWS thinks about security
• Simple, easily understood security invariants vs. subtle

and complex reasoning
• Historically have been overindexing on prevention
• Bias towards simpler policies and few objects to manage
• Shift to detection and response
• Turn on all logging and visibility features as possible in
the production application account Prevention Detection
Analysis Response
How AWS manages identity and access
• AWS uses an internal tool to manage employee access

to accounts
• Users authenticate to corporate directory
• Uses IAM roles to control access to resources in each
account using AWS STS AssumeRole
• Accounts are flagged as production/nonproduction or
contain customer data – three tiers with progressively
higher levels of control and auditing
How AWS manages usage
• Review application use case and in some cases,

disallow the use of a specific service for sensitive data
• The use of our internal tool does allow us to allow some
sensitive data to be delivered to logs since we are
comfortable that access to the account is controlled
• Use of programmatic tools to quickly determine policy
changes and remediate quickly using those tools
How AWS thinks about VPCs and accounts
• Use separate VPCs or accounts for things that are

clearly separate
• For this case, we chose to use two separate accounts,
one for the business owner and one for a security
gateway
• This doesn’t mean that we would hold hard and fast to
only one account per application but would make that
decision based on similarity of policies, groups, and
routing tables required to protect a group of applications
How AWS thinks about decision making
• Two-way doors vs. one-way doors – policies can be

changed, security groups can be modified, and instance
sizes and counts can be adjusted
• Often it’s better to deploy quickly and adjust rather than
get stuck trying to analyze for the ideal case for too long
How AWS thinks about system design
• “Modality is evil” – a system that works one way when

things are normal and switches to another mode when
there’s a problem
• Example: A system that provisions administrator access
on failure – when it’s more likely that the failure might
keep this from occurring – rather one should provision
admin access all of the time and use other mechanisms
to make sure it’s being used correctly
Flashback to re:Invent 2015
• SEC315 – AWS Directory Service Deep Dive

Fast forward – Cross-account manager solution
• Look familiar?
• Using AWS
CloudFormation
templates to create
and manage roles
for a master
account and sub
accounts.
CloudFormation components
Account onboarding
Role onboarding
Simple HTML access links
Demo
Live demo of solution here

Get started today!
Visit our website -

https://aws.amazon.com/answers/
Launch the solution -

https://aws.amazon.com/answers/account-
management/cross-account-manager
AWS Organizations
• New management capability for centrally managing multiple AWS accounts

- Simplified billing
- Programmatic creation of new AWS accounts
- Logically group AWS accounts for management convenience
- Apply organization control policies (OCP)
• A Consolidated Billing (CB) family automatically migrated to an organization
• All organization management activity is logged in AWS CloudTrail
• An AWS account can be a member of only one organization
• V1 OCP – Control which AWS service APIs accessible in AWS account(s)
• Console, SDK, and CLI support for all management tasks
Available in limited public preview: http://aws.amazon.com/organizations/preview

Related sessions
ARC314 – Enabling Enterprise Migrations: Creating an AWS Landing Zone

ENT203 – Enterprise Fundamentals: Design Your Account and VPC
Architecture for Enterprise Operating Models
SAC319 – Architecting Security and Governance Across a Multi-Account
Strategy
SAC320 – Deep Dive: Implementing Security and Governance Across a
Multi-Account Strategy
SAC323 - Centrally Manage Multiple AWS Accounts with AWS
Organizations
SEC304 – Reduce Your Blast Radius by Using Multiple AWS Accounts Per
Region and Service
Thank you!
Remember to complete
your evaluations!

Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service

Uploaded by

Copyright:

Available Formats

Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service

Uploaded by

Copyright:

Available Formats

Reduce Your Blast Radius by

Using Multiple AWS Accounts

• How AWS manages multiple accounts and how

Master (billing) account

• Two accounts: One for the application and one for

• Only applies to production, business critical applications,

• Apply the right levels of control and change

• Simple, easily understood security invariants vs. subtle

• AWS uses an internal tool to manage employee access

• Review application use case and in some cases,

• Use separate VPCs or accounts for things that are

• Two-way doors vs. one-way doors – policies can be

• “Modality is evil” – a system that works one way when

• SEC315 – AWS Directory Service Deep Dive

Live demo of solution here

Visit our website -

Launch the solution -

• New management capability for centrally managing multiple AWS accounts

Available in limited public preview: http://aws.amazon.com/organizations/preview

ARC314 – Enabling Enterprise Migrations: Creating an AWS Landing Zone

You might also like