1. AWS Secure Environment Accelerator PBMM Architecture(link)

1.1. Overview(link)

The AWS Secure Environment PBMM Architecture is a comprehensive, multi-account AWS cloud architecture, initially designed for use within the Government of Canada for PBMM workloads. The AWS Secure Environment PBMM Architecture has been designed to address central identity and access management, governance, data security, comprehensive logging, and network design/segmentation per Canadian Centre for Cyber Security ITSG-33 specifications (a NIST 800-53 variant).

This document specifically does NOT talk about the tooling or mechanisms that can be used to deploy the architecture. While the AWS Secure Environment Accelerator (SEA) is one tool capable of deploying this architecture (along with many other architectures), customers can use whatever mechanism they deem appropriate to deploy it. This document does not discuss the AWS SEA tooling or architecture and is strictly focused on the resulting deployed solution created by using the provided sample PBMM Accelerator configuration file. This architecture document should stand on its own in depicting the deployed architecture. Users looking for information on the SEA tooling itself, should refer to the other SEA documents.

It is anticipated we will offer multiple sample architectures with the AWS SEA solution, each having its own architecture document like this. As the SEA can produce hundreds of solutions, it does not make sense to repeat that content in this document.

1.2. Introduction(link)

The AWS Secure Environment Architecture has been built with the following design principles:

Maximize agility, scalability, and availability
Enable the full capability of the AWS cloud
Be adaptable to evolving technological capabilities in the underlying platform being used in the AWS Secure Environment Architecture
Allow for seamless auto-scaling and provide unbounded bandwidth as bandwidth requirements increase (or decrease) based on actual customer load (a key aspect of the value proposition of cloud computing)
Design for high availability: the design stretches across two physical AWS Availability Zones (AZ), such that the loss of any one AZ does not impact application availability. The design can be easily extended to a third availability zone.
Operate as least privilege: all principals in the accounts are intended to operate with the lowest-feasible permission set.

1.2.1. Purpose of Document(link)

This document is intended to outline the technical measures that are delivered by the AWS Secure Environment Architecture that make it suitable for PBMM workloads. An explicit non-goal of this document is to explain the delivery architecture of the AWS Secure Environment Accelerator tool itself, an open-source software project built by AWS.

While the central purpose of the AWS Secure Environment Accelerator is to establish an AWS Secure Environment Architecture into an AWS account footprint, this amounts to an implementation detail as far as the AWS Secure Environment Architecture is concerned. The AWS Secure Environment Architecture is a standalone design, irrespective of how it was delivered into a customer AWS environment. It is nonetheless anticipated that most customers will choose to realize their AWS Secure Environment Architecture via the delivery mechanism of the AWS Secure Environment Accelerator tool.

Comprehensive details on the tool itself are available elsewhere:

Except where absolutely necessary, this document will refrain from referencing the AWS Secure Environment Accelerator tool further.

1.2.2. Overview(link)

The central features of the AWS Secure Environment Architecture are as follows:

AWS Organization with multiple-accounts: An AWS Organization is a grouping construct for a number of separate AWS accounts that are controlled by a single customer entity. This provides consolidated billing, organizational units, and facilitates the deployment of pan-Organizational guardrails such as CloudTrail logs and Service Control Policies. The separate accounts provide strong control-plane and data-plane isolation between workloads and/or environments.
Encryption: AWS KMS with customer-managed CMKs is used extensively for any data stored at rest, in S3 buckets, EBS volumes, RDS encryption.
Service Control Policies: SCPs provide a guardrail mechanism principally used to deny entire categories of API operations at an AWS account, OU, or Organization level. These can be used to ensure workloads are deployed only in prescribed regions, ensure only whitelisted services are used, or prevent the disablement of detective/preventative controls. Prescriptive SCPs are provided.
Centralized, Isolated Networking: Virtual Private Clouds (VPCs) are used to create data-plane isolation between workloads, centralized in a shared-network account. Connectivity to on-prem environments, internet egress, shared resources and AWS APIs are mediated at a central point of ingress/egress via the use of Transit Gateway, Site-to-Site VPN, Next-Gen Firewalls, and AWS Direct Connect (where applicable).
Centralized DNS Management: Amazon Route 53 is used to provide unified public and private hosted zones across the cloud environment. Inbound and Outbound Route 53 Resolvers extend this unified view of DNS to on-premises networks.
Comprehensive Logging: CloudTrail logs are enabled Organization-wide to provide auditability across the cloud environment. CloudWatch Logs, for applications, as well as VPC flow logs, are centralized and deletion is prevented via SCPs.
Detective Security Controls: Potential security threats are surfaced across the cloud environment via automatic deployment of detective security controls such as GuardDuty, AWS Config, and Security Hub.
Single-Sign-On: AWS SSO is used to provide AD-authenticated IAM role assumption into accounts across the Organization for authorized principals.

1.2.3. Document Convention(link)

Several conventions are used throughout this document to aid understanding.

1.2.3.1. AWS Account Numbers(link)

AWS account numbers are decimal-digit pseudorandom identifiers with 12 digits (e.g. 651278770121). This document will use the convention that an AWS Organization Management (root) account has the account ID 123456789012, and child accounts are given by 111111111111, 222222222222, etc.

For example the following ARN would refer to a VPC subnet in the ca-central-1 region in the Organization Management (root) account:

arn:aws:ec2:ca-central-1:123456789012:subnet/subnet-024759b61fc305ea3

1.2.3.2. JSON Annotation(link)

Throughout the document, JSON snippets may be annotated with comments (starting with //). The JSON language itself does not define comments as part of the specification; these must be removed prior to use in most situations, including the AWS Console and APIs.

For example:

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root" // Trust the Organization Management (root) account.
    },
    "Action": "sts:AssumeRole"
}

The above is not valid JSON without first removing the comment on the fourth line.

1.2.3.3. IP Addresses(link)

The design makes use of RFC1918 addresses (e.g. 10.1.0.0/16) and RFC6598 (e.g. 100.96.250.0/23) for various networks; these will be labeled accordingly. Any specific range or IP shown is purely for illustration purposes only.

1.2.4. Department Naming(link)

This document will make no reference to specific Government of Canada departments. Where naming is required (e.g. in domain names), this document will use a placeholder name as needed; e.g. dept.gc.ca.

1.2.5. Relationship to AWS Landing Zone(link)

AWS Landing Zone is an AWS Solution designed to deploy multi-account cloud architectures for customers. The AWS Secure Environment Architecture draws on design patterns from Landing Zone, and re-uses several concepts and nomenclature, but it is not directly derived from it. An earlier internal release of the AWS Secure Environment Architecture presupposed the existence of an AWS Landing Zone in the Organization; this requirement has since been removed as of release v1.1.0.