Skip to content

[Governance] AWS Organizations & Multi-Accounts

🛬 [Landing Zones] Cloud-Foundation using AWS Organizations

Quickly and securely deploy your application workloads and solutions across a centrally governed multi-account environment

Cloud-Foundation using AWS Organizations

  • 1️⃣ Create an AWS account with the AWS Management Console. Use a planned naming convention for root user email and account alias. Secure root user account and configure billing and tax information.
  • 2️⃣ Create and configure AWS IAM Identity Center and standard management account roles for administrative management. Apply security configurations to IAM Identity Center settings.
  • 3️⃣ Activate AWS Cost Explorer and create and configure AWS Cost & Usage Reports.
  • 4️⃣ Plan and deploy your foundational Organization Unit (OU) structure and accounts from AWS Organizations.
  • 5️⃣ Set up AWS CloudTrail to deploy CloudTrail to all AWS member accounts to deliver logs to a Log Archive Amazon Simple Storage Service S3 bucket. Secure your log data using an AWS Key Management Service KMS customer managed key.
  • 6️⃣ Deploy AWS Config to all accounts within the organization. Configure delivery of resource changes to a Log Archive S3 Bucket. Secure the log storage using an AWS KMS customer managed key.
  • 7️⃣ Create and publish a Tagging dictionary and enable Cost Allocation Tags.
  • 8️⃣ Deploy additional foundational security hardening configurations to your environment, using services such as Amazon CloudWatch.

Identity Management using IAM Identity Center (AWS SSO) & Okta

Foundational Organizational Unit (OU) Structure and Accounts

Manage AWS Resources with Terraform: account folder will hold all the AWS accounts, management and non-management accounts.
  • Core-Root || management-account: [email protected] have a root with 5 children OUs.
  • Terraform-code: refer to Core-Root || Management-Account in DevOps/account/management/organization/main.tf
  • Each business domain generally has 3 top-level environments:
    • 📘 ou-sandbox: Sandboxes
    • 📘 ou-non-prod: Non-Prod (which may in turn contain VPCs for dev, test, etc as required)
    • 📗 ou-prod: Prod
  • Each environment has the structure
    • API: which is exposed externally and protected by WAF etc. Also the place for presentation layers. Transient storage only.
    • App: back end and persistent storage layer.
    • In addition: each environment has, but SHARES an authentication layer which implements common authentication using SAML2 & Cognito
  • Other notes:
    • No Landing Zone or Control Tower: May be consider in future
    • Guardrails SCP and AWS Config are coming
    • AWS config alternative: Dome9 scanning vulnerabilities

Foundational Organizational Unit Structure

  1. 🏠 Create Security OU (Foundational): ou-security
    • Log Archive Account: inbound-outbound-sec
    • Security Tooling (Audit) Account: aws-audit
  2. 📙 Create Infrastructure OU (Foundational): ou-shared-services
    • Backup Account: aws-backup
    • Shared Services Account: aws-shared-services
    • Identity, Monitoring, Network, Operational Tools: aws-centralized-ops
  3. 📚 Create Workloads OU (Application)
    • 📚 ou-prod
    • 📚 ou-non-prod (dev, test, sit, uat)
    • 📚 ou-sandbox
  4. 📂 Create Exceptions OU (Procedural)
  5. 📂 Create Sandbox OU (Experimental): ou-exceptions
  • Create [Security OU] Log Archive Account
  • Create IAM Identity Center Log Archive Administrator role
  • Create [Security OU] Security Tooling (Audit) Account
  • Create IAM Identity Center Security Tooling Administrator role

Service Control Policies (SCPs) & Permission Sets

Recommended SCP
  * [x] Deny_IAM_UserCreation: attached directly on all of the child OU, except `ou-exceptions`
  * [ ] DenyAllEC2Actions
  * [ ] DenyLaunchVeryLargeEc2InstanceTypes
  * [x] DenyLaunchVeryLargeEc2InstanceTypes_DenyGlueService: attached by ^^AttachDefaultSCPs^^ Lambda
  * [ ] DenyGlueService
  * [ ] DenyNetworkResourceCreation
  * [x] DenyNetworkResourceCreationExemptSRE: attached by ^^AttachDefaultSCPs^^ Lambda, for security and simplicity purpose - to prevent the creation of a `VPC` without an attached `TGW` (AWS Transit Gateway)
  * [x] DenyNonSydneyRegionalResources: attached by ^^AttachDefaultSCPs^^ Lambda, for billing purpose
  * [x] DenyLaunchInstanceWithoutMandatoryTags: attached by ^^AttachDefaultSCPs^^ Lambda, SRE patch-group for batching automation using `SSM`; also for Instance-Scheduler in [Cloud Custodian (c7n) open-source](https://github.com/cloud-custodian/cloud-custodian).
  * [ ] DenyAssumeRoleToManagementAccount
  * [ ] AI_opt-out_policy
  * [ ] Billing Tag Policy
  * [ ] FullAWSAccess
  • Runbooks: AttachDefaultSCPs.py Lambda
AccountCreationResultMonitor-tf EventBridge

  • EventBridge >> Environment variables:

    • Key: SCP_LIST
    • Value: DenyLaunchVeryLargeEc2InstanceTypes_DenyGlueService, DenyNetworkResourceCreationExemptSRE, DenyNonSydneyRegionalResources, DenyLaunchInstanceWithoutMandatoryTags

  • EventBridge >> Event pattern:

{
  "detail": {
    "eventName": ["CreateAccountResult"],
    "eventSource": ["organizations.amazonaws.com"]
  },
  "detail-type": ["AWS Service Event via CloudTrail"],
  "source": ["aws.organizations"]
}

Permission Sets

Layered approach to effective permissions

  • Our access to the cloud is exclusively through AWS SSO, which has been integrated with Okta.
  • So, a group should exist in Okta, the user should be a member of that group, and that group should be attached to the required permission set (with appropriate roles).
  • CloudOps-Admin: Only the Cloud Team should be granted this access AT ANY COST!
  • power-user: Can be granted to someone with the approval of the account owner.
  • admin-user: Can be granted to someone with the approval of the account owner.
  • ReadOnlyAccess: Can be granted to someone with the approval of the account owner.

Centralized EC2 Images

  ├───centralized-images
      ├───amzn-2
      ├───amzn-2023
      ├───rhel-8.10
      ├───rhel-9.2
      ├───ubuntu-20.04
      ├───win-2019
      └───win-2022

References: