Skip to content

AWS Organizations

Overview

This repository contains all Terraform configuration files used to create binbash Leverage Reference AWS Organizations Multi-Account baseline layout.

Why AWS Organizations?

This approach allows it to have a hierarchical structure of AWS accounts, providing additional security isolation and the ability to separate resources into Organizational Units with it associated Service Control Policies (SCP).

Considering that a current AWS account/s was/were already active (Client AWS Legacy Account), this one will then be invited to be a “member account” of the AWS Organization architecture. In the future, once all Client’s Legacy dev, stage, prod and other resources for the Project applications are running in the new accounts architecture, meaning a full AWS Organizations approach, all the already migrated assets from the ‘Legacy’ account should be decommissioned. This account will remain with the necessary services, such as DNS, among others.

AWS Organization Accounts Layout

The following block provides a brief explanation of the chosen AWS Organization Accounts layout:

MyExample project file structure 
    +📂 management/      (resources for the management account)
    ...
    +📂 security/        (resources for the security + users account)
    ...
    +📂 shared/          (resources for the shared account)
    ...
    +📂 network/         (resources for the centralized network account)
    ...
    +📂 apps-devstg/     (resources for apps dev & stg account)
    ...
    +📂 apps-prd/        (resources for apps prod account)
    ...

leverage-aws-org

Figure: AWS Organization multi-account architecture diagram (just as reference). (Source: binbash Leverage, "Leverage Reference Architecture components", binbash Leverage Doc, accessed August 4th 2021).

Benefits of AWS Organizations

  • Billing: Consolidated billing for all your accounts within organization, enhanced per account cost filtering and RI usage
  • Security I: Extra security layer: You get fully isolated infrastructure for different organizations units in your projects, eg: Dev, Prod, Shared Resources, Security, Users, BI, etc.
  • Security II: Using AWS Organization you may use Service Control Policies (SCPs) to control which AWS services are available within different accounts.
  • Networking: Connectivity and access will be securely setup via VPC peering + NACLS + Sec Groups everything with private endpoints only accessible vía Pritunl VPN significantly reducing the surface of attack.
  • User Mgmt: You can manage all your IAM resources (users/groups/roles) and policies in one place (usually, security/users account) and use AssumeRole to works with org accounts.
  • Operations: Will reduce the blast radius to the maximum possible.
  • Compatibility: Legacy accounts can (probably should) be invited as a member of the new Organization and afterwards even imported into your terraform code.
  • Migration: After having your baseline AWS Org reference cloud solutions architecture deployed (IAM, VPC, NACLS, VPC-Peering, DNS Cross-Org, CloudTrail, etc) you're ready to start progressively orchestrating new resources in order to segregate different Environment and Services per account. This approach will allow you to start a 1 by 1 Blue/Green (Red/Black) migration without affecting any of your services at all. You would like to take advantage of an Active-Active DNS switchover approach (nice as DR exercise too).
    • EXAMPLE: Jenkins CI Server Migration steps:
      1. Let's say you have your EC2_A (jenkins.aws.domain.com) in Account_A (Legacy), so you could deploy a brand new EC2_B Jenkins Instance in Account_B (Shared Resources).
      2. Temporally associated with jenkins2.aws.domain.com
      3. Sync it's current data (/var/lib/jenkins)
      4. Test and fully validate every job and pipeline works as expected.
      5. In case you haven't finished your validations we highly recommend to declare everything as code and fully automated so as to destroy and re-create your under development env on demand to save costs.
      6. Finally switch jenkins2.aws.domain.com -> to -> jenkins.aws.domain.com
      7. Stop your old EC2_A.
      8. If everything looks fine after after 2/4 weeks you could terminate your EC2_A (hope everything is as code and just terraform destroy)
      9. Considering the previously detailed steps plan your roadmap to move forward with every other component to be migrated.

Read more

AWS reference links

Consider the following AWS official links as reference: