Skip to content

org

Jump to bottom
Eric Odell edited this page Apr 21, 2021 · 22 revisions

AWS Organizations Service

How we use the AWS Organizations service to manage our AWS multi-account strategy

These are some of the benefits of aggregating AWS under a single organization:

  • Centralized management of all our AWS accounts
  • Consolidated billing for all member accounts
  • Grouping accounts into organizational units (OUs) with differentiated policies according to our OU tree.
  • Standardized tags across resources in our organization's accounts
  • Hierarchical grouping of our accounts to meet your budgetary, security, or compliance needs
  • Control over AWS services and API actions that each account can access via Service Control Policies (SCP)
  • Integration and support for AWS Identity and Access Management (IAM) which provides granular control over users and roles in individual accounts.
  • Integration with other AWS services
  • Eventually consistent data replication to evaluate and track our security baselines.

Will we run all major work loads in a single primary organization with Education Discount Program (EDP)?

Yes. to save %11 on our bill!

Who manages our EDP Organization?

The Cloud Services Team

What services do the Cloud Services Teams Provide to manage our EDP organization?

Core Services in support of Development and Product accounts:

Will we run a secondary low cost "test" organization to test out organization features, scp, etc, in isolation from our primary EDP org?

TBD

Will we use Organizational Units (OU) to separate tiers of account ?

Yes

We probably want to differentiate and roll out changes according to a dev/test/prod paradigm

Question how do we promote changes to an OU?

dev/test/prod paradigm?

However there are other OU strategies. Consider aligning OU to a billing strategy

Have your OU and eat it. A Hybrid OU strategy

  • Two Organizations: org master account with EDP, optional low spend test org master account
  • EDP org Level 1 business OU tier: biz1, biz2, etc
  • EDP org Level 2 team OU tier: teamA, teamB, etc
  • EDP org Level 3 environment OU tier dev/test/prod

Test org OU tree may be undefined as we use it to experiment with OU structure and governance.

NOTE: We will start with a single tier 1 business OU under our master EDP but structure it so we can host future business under our primary EDP master that may have different OU needs from the initial business tier.

How will we organize customer accounts and OU order?

TL;DR accounts fit into three OUs:

  • [dev] where product teams develop their products
  • [test] where product teams test their products
  • [prod] where product teams deploy their products

See below for details of where different account types hang on our OU tree. As an example let's pretend we support two teams in our primary EDP org:

  • The most awesome development team who own products eeny and meeny.

  • The business application development team who own products miny and moe.

The awesome and business teams request "mad" and "bad" as their respective team names. These teams would each have 5 accounts supporting their teams and products.

team env OU

How do accounts fit into our OU mapping?

Dev OU

Dev accounts are in Dev OU

Test OU

Test accounts in a Test OU

Prod OU
  • Product
  • Core
  • Build [ ] * Do we prefer to have build accounts in Test OU? HINT: think of test OU as dry run before promoting to Prod. Test accounts are preproduction environments that simulate production.

Will we have a coherent approach to services using ServiceControlPolicies?

Yes. As guard rails to focus our efforts on what we need to do. Eg dev accounts could be in an OU that prevents security group ingress from outside our on prem CIDR. Deployment of scp shall follow our OU structure, first in our test org, then in our EDP Org following a dev, test, prod sequence.

What are the scp?

We have a plan for that here.

How do we decide if/how/what to modify scp?

Cloud services and product teams will collaborate to define spec and seek approval from the Cloud Committee or future CCOE.

How do we promote scp?

Deployment of scps follows a dev/test/prod pattern with Change Management required for Prod.

Which Organization integrated services will we use?

These are the services that integrate with the AWS organization service.

These are the services we should implement at the organization level

  • Enable governance, compliance, and operational and risk auditing of our AWS accounts with AWS Cloud Trail and Organizations Service
  • sharing CloudWatch Events across all accounts in our organization
  • Organization-wide view of our compliance status with AWS config Service
  • Enforce compliance regulations on all of our AWS accounts with AWS Control Tower Service
  • Single sign-on services for all of our accounts and cloud applications with AWS SSO
  • Visibility and control of our virtual machine resources with AWS Systems Manager
  • Standardize tags across resources in your organization's accounts with Tag Policies
  • Integrate AWS Directory Service with AWS Organizations for seamless directory sharing across multiple accounts and any VPC in a Region with AWS Directory Service
  • Centrally configure and manage AWS WAF rules across accounts in our organization with AWS Firewall Manager
Clone this wiki locally