AWS re:Invent 2016: NEW SERVICE: Centrally Manage Multiple AWS Accounts with AWS Organizations (SAC323)

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

Anders Samuelsson

12/1/2016

NEW SERVICE: Centrally Manage

Multiple AWS Accounts with AWS

Organizations

What to Expect from the Session

• Overview

• Best practices

• Demo

AWS Organizations

Available in limited public preview

http://aws.amazon.com/organizations/

Service Overview

• New management capability for centrally managing multiple

AWS accounts

- Simplified creation of new AWS accounts

- Logically group AWS accounts for management convenience

- Apply organizational control policies (OCP)

- Simplified billing

• An AWS account can be a member of only one organization

• Console, SDK, and CLI support for all management tasks

Key concepts

Organization• Consolidated set of all AWS accounts you can centrally control

AWS account• Resource container for AWS resources such as Amazon S3 buckets, Amazon EC2 instances

• Access to resources controlled by AWS Identity and Access Management (IAM) principals (users, roles)

• Smallest unit of management in AWS Organizations

Master account• Payer account for all other accounts in your organization

• Management “hub” for managing your organization

Organizational unit (OU)• Set of AWS accounts logically grouped within an organization

Administrative root• Starting point for hierarchy of OUs

Organization control policy (OCP)• Document describing controls to be applied to a selected set of accounts

• Different use cases have different types of OCPs

Let’s get to the details

Programmatic creation of new AWS accounts

• New AWS accounts can only be created from the master account

• As part of the creation process you can configure

- Email address (required)

- Account name (required)

- IAM role name (optional - default name is OrganizationAccountAccessRole)

o Trust policy configured for AssumeRole access from master account

o Permissions configured with FULL CONTROL

- IAM user access to billing (optional) Note! IAM users still need permissions

• New AWS account

- Is automatically part of your organization

- Cannot be removed from the organization

aws organizations create-account

--email [email protected]

--account-name "Production Account”

--role-name Role-to-access-anders-account

CLI sample – CreateAccount

Invite existing AWS accounts to an organization

• Invitation can only be initiated from master account

• Invited AWS account can accept or decline invitation

- Default action is DECLINE

- Can be controlled with IAM permissions

• When invitation is accepted

- AWS account becomes member of your organization

- Applicable OCPs automatically applied

• Invited AWS accounts can be removed from organization

Logically group AWS accounts

• Group AWS accounts into organizational units (OUs) for

management convenience

• AWS accounts and OUs can be member of an OU

• AWS account can be member of multiple OUs

Example

A6

Development Test Production

A8A1

A5A4A3

A2

A9

A7

Security

Apply Organizational Control Policies (OCP)

• Describes controls to be applied

• Different use cases have different types of OCPs

• OCPs can be attached to

- Organization

- OUs

- AWS account

• OCPs are inherited up the hierarchy (AWS account, OU, organization)

Example

A6

Development Test Production

A8A1

A5A4A3

A2

A9

A7

Security

OCP supported in V1: Service Control Policies (SCPs)

• Enables you to control which AWS service APIs are

accessible

- Define the list of APIs that are allowed – whitelisting

- Define the list of APIs that must be blocked – blacklisting

• Cannot be overridden by local administrator

• Resultant permission on IAM user/role is the intersection

between the SCP and assigned IAM permissions

• Necessary but not sufficient

• IAM policy simulator is SCP aware

{

"Version": "2012-10-17",

"Statement": [{

"Effect": "Allow",

"Action": "*",

"Resource": "*"

},

{

"Effect": "Deny",

"Action": "redshift:*",

"Resource": "*"

}

]

}

{

"Version": "2012-10-17",

"Statement": [{

"Effect": "Allow",

"Action": [

"ec2:RunInstances",

"ec2:DescribeInstances",

"ec2:DescribeImages",

"ec2:DescribeKeyPairs",

"ec2:DescribeVpcs",

"ec2:DescribeSubnets",

"ec2:DescribeSecurityGroups"

],

"Resource": "*"

}

]

}

Blacklisting example Whitelisting example

SCPs are necessary but not sufficient

Allow: EC2:*Allow: S3:* Allow: SQS:*Allow: EC2:*Allow: EC2:*

SCP IAMPermissions

Simplified billing

• Single payer for all AWS accounts

• All AWS usage across AWS accounts in your

organization rolled up for volume pricing and billing

• All existing Consolidated Billing families will be migrated

to an organization in billing mode

Different management levels

You select the management level when creating a new organization

Billing mode

• Backward-compatible with current Consolidated Billing (CB)

• Organization created from Consolidated Billing family automatically in

Billing mode

Full-control mode

• Everything included in Billing mode

• Enables management of ALL types of OCPs

• Changing from Billing mode to Full control mode requires consent from

all AWS accounts in your organization

Least privilege for managing your organization

• IAM permissions for all AWS Organizations actions

• You can also specify AWS Organizations resources

(organization, OU, AWS account) as resources in an

IAM policy

• You can delegate permissions to manage your

organization to an IAM user in another AWS account by

using IAM roles

• All organization management activity is logged in AWS

CloudTrail

Demo

AWS Organizations

Best practices

Best practices – AWS Organizations

1. Monitor activity in the master account using CloudTrail

2. Do not manage resources in the master account

3. Manage your organization using the principal of “Least privilege”

4. Use OUs to assign controls

5. Test controls on single AWS account first

6. Only assign controls to root of organization if necessary

7. Avoid mixing “whitelisting” and “blacklisting” SCPs in organization

8. Create new AWS accounts for the right reasons

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

SEC304 – Reduce Your Blast Radius by Using Multiple AWS Accounts Per

Region and Service

Remember to complete

your evaluations!

Thank you!