January - December 2023 - AWS Control Tower

January - December 2023

In 2023, AWS Control Tower released the following updates:

Transition to new AWS Service Catalog External product type (phase 3)

December 14, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower no longer supports Terraform Open Source as a product type (blueprint) when creating new AWS accounts. For more information and for instructions about updating your account blueprints, review Transition to the AWS Service Catalog External product type.

If you do not update your account blueprints to use the External product type, you can only update or terminate accounts that you provisioned using Terraform Open Source blueprints.

AWS Control Tower landing zone version 3.3

December 14, 2023

(Update required for AWS Control Tower landing zone to version 3.3. For information, see Update your landing zone).

Updates to S3 bucket policy in the AWS Control Tower Audit account

We have modified the Amazon S3 Audit bucket policy that AWS Control Tower deploys in accounts, so that an aws:SourceOrgID condition must be met for any write permissions. With this release, AWS services have access to your resources only when the request originates from your organization or organizational unit (OU).

You can use the aws:SourceOrgID condition key and set the value to your organization ID in the condition element of your S3 bucket policy. This condition ensures that CloudTrail only can write logs on behalf of accounts within your organization to your S3 bucket; it prevents CloudTrail logs outside your organization from writing to your AWS Control Tower S3 bucket.

We made this change to remediate a potential security vulnerability, without affecting the functionality of your existing workloads. To view the updated policy, see Amazon S3 bucket policy in the audit account.

For more information about the new condition key, see the IAM documentation and the IAM blog post entitled "Use scalable controls for AWS services accessing your resources."

Updates to the policy in the AWS Config SNS topic

We added the new aws:SourceOrgID condition key to the policy for the AWS Config SNS topic.To view the updated policy, see The AWS Config SNS topic policy.

Updates to the landing zone Region Deny control
  • Removed discovery-marketplace:. This action is covered by the aws-marketplace:* exemption.

  • Added quicksight:DescribeAccountSubscription

Updated AWS CloudFormation template

We updated the AWS CloudFormation template for the stack named BASELINE-CLOUDTRAIL-MASTER so that is does not show drift when AWS KMS encryption is not used.

Transition to new AWS Service Catalog External product type (phase 2)

December 7, 2023

(No update required for AWS Control Tower landing zone.)

HashiCorp updated their Terraform licensing. As a result, AWS Service Catalog changed support for Terraform Open Source products and provisioned products to a new product type, called External.

To avoid disruption to existing workloads and AWS resources in your accounts, follow the AWS Control Tower transition steps in Transition to the AWS Service Catalog External product type by December 14, 2023.

AWS Control Tower announces controls to assist digital sovereignty

November 27, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower announces 65 new AWS-managed controls, to help you meet your digital sovereignty requirements. With this release, you can discover these controls under a new digital sovereignty group in the AWS Control Tower console. You can use these controls to help prevent actions and detect resource changes regarding data residency, granular access restriction, encryption, and resiliency capabilities. These controls are designed to make it simpler for you to address requirements at scale. For more information about digital sovereignty controls, see Controls that enhance digital sovereignty protection.

For example, you can choose to enable controls that help enforce your encryption and resiliency strategies, such as Require an AWS AppSync API cache to have encryption in transit enabled or Require an AWS Network Firewall to be deployed across multiple Availability Zones. You can also customize the AWS Control Tower Region deny control to apply regional restrictions that best fit your unique business needs.

This release brings well-enhanced AWS Control Tower Region deny capabilities. You can apply a new, parameterized Region deny control at the OU level, for increased granularity of governance, while maintaining additional Region governance at the landing zone level. This customizable Region deny control helps you to apply regional restrictions that best fit your unique business needs. For more information about the new, configurable Region deny control, see Region deny control applied to the OU.

As a new tool to the new Region deny enhancement, this release includes a new API, UpdateEnabledControl, which allows you to reset your enabled controls to the default settings. This API is especially helpful in use cases where you need to resolve drift quickly, or to guarantee programmatically that a control is not in a state of drift. For more information about the new API, see the AWS Control Tower API Reference

New proactive controls
  • CT.APIGATEWAY.PR.6: Require an Amazon API Gateway REST domain to use a security policy that specifies a minimum TLS protocol version of TLSv1.2

  • CT.APPSYNC.PR.2: Require an AWS AppSync GraphQL API to be configured with private visibility

  • CT.APPSYNC.PR.3: Require that an AWS AppSync GraphQL API is not authenticated with API keys

  • CT.APPSYNC.PR.4: Require an AWS AppSync GraphQL API cache to have encryption in transit enabled.

  • CT.APPSYNC.PR.5: Require an AWS AppSync GraphQL API cache to have encryption at rest enabled.

  • CT.AUTOSCALING.PR.9: Require an Amazon EBS volume configured through an Amazon EC2 Auto Scaling launch configuration to encrypt data at rest

  • CT.AUTOSCALING.PR.10: Require an Amazon EC2 Auto Scaling group to use only AWS Nitro instance types when overriding a launch template

  • CT.AUTOSCALING.PR.11: Require only AWS Nitro instance types that support network traffic encryption between instances to be added to an Amazon EC2 Auto Scaling group, when overriding a launch template

  • CT.DAX.PR.3: Require an DynamoDB Accelerator cluster to encrypt data in transit with Transport Layer Security (TLS)

  • CT.DMS.PR.2: Require an AWS Database Migration Service (DMS) Endpoint to encrypt connections for source and target endpoints

  • CT.EC2.PR.15: Require an Amazon EC2 instance to use an AWS Nitro instance type when creating from the AWS::EC2::LaunchTemplate resource type

  • CT.EC2.PR.16: Require an Amazon EC2 instance to use an AWS Nitro instance type when created using the AWS::EC2::Instance resource type

  • CT.EC2.PR.17: Require an Amazon EC2 dedicated host to use an AWS Nitro instance type

  • CT.EC2.PR.18: Require an Amazon EC2 fleet to override only those launch templates with AWS Nitro instance types

  • CT.EC2.PR.19: Require an Amazon EC2 instance to use a nitro instance type that supports encryption in-transit between instances when created using the AWS::EC2::Instance resource type

  • CT.EC2.PR.20: Require an Amazon EC2 fleet to override only those launch templates with AWS Nitro instance types that support encryption in transit between instances

  • CT.ELASTICACHE.PR.8: Require an Amazon ElastiCache replication group of later Redis versions to have RBAC authentication activated

  • CT.MQ.PR.1: Require an Amazon MQ ActiveMQ broker to use use active/standby deployment mode for high availability

  • CT.MQ.PR.2: Require an Amazon MQ Rabbit MQ broker to use Multi-AZ cluster mode for high availability

  • CT.MSK.PR.1: Require an Amazon Managed Streaming for Apache Kafka (MSK) cluster to enforce encryption in transit between cluster broker nodes

  • CT.MSK.PR.2: Require an Amazon Managed Streaming for Apache Kafka (MSK) cluster to be configured with PublicAccess disabled

  • CT.NETWORK-FIREWALL.PR.5: Require an AWS Network Firewall firewall to be deployed across multiple Availability Zones

  • CT.RDS.PR.26: Require an Amazon RDS DB Proxy to require Transport Layer Security (TLS) connections

  • CT.RDS.PR.27: Require an Amazon RDS DB cluster parameter group to require Transport Layer Security (TLS) connections for supported engine types

  • CT.RDS.PR.28: Require an Amazon RDS DB parameter group to require Transport Layer Security (TLS) connections for supported engine types

  • CT.RDS.PR.29: Require an Amazon RDS cluster not be configured to be publicly accessible by means of the 'PubliclyAccessible' property

  • CT.RDS.PR.30: Require that an Amazon RDS database instance has encryption at rest configured to use a KMS key that you specify for supported engine types

  • CT.S3.PR.12: Require an Amazon S3 access point to have a Block Public Access (BPA) configuration with all options set to true

New preventive controls
  • CT.APPSYNC.PV.1 Require that an AWS AppSync GraphQL API is configured with private visibility

  • CT.EC2.PV.1 Require an Amazon EBS snapshot to be created from an encrypted EC2 volume

  • CT.EC2.PV.2 Require that an attached Amazon EBS volume is configured to encrypt data at rest

  • CT.EC2.PV.3 Require that an Amazon EBS snapshot cannot be publicly restorable

  • CT.EC2.PV.4 Require that Amazon EBS direct APIs are not called

  • CT.EC2.PV.5 Disallow the use of Amazon EC2 VM import and export

  • CT.EC2.PV.6 Disallow the use of deprecated Amazon EC2 RequestSpotFleet and RequestSpotInstances API actions

  • CT.KMS.PV.1 Require an AWS KMS key policy to have a statement that limits creation of AWS KMS grants to AWS services

  • CT.KMS.PV.2 Require that an AWS KMS asymmetric key with RSA key material used for encryption does not have a key length of 2048 bits

  • CT.KMS.PV.3 Require that an AWS KMS key is configured with the bypass policy lockout safety check enabled

  • CT.KMS.PV.4 Require that an AWS KMS customer-managed key (CMK) is configured with key material originating from AWS CloudHSM

  • CT.KMS.PV.5 Require that an AWS KMS customer-managed key (CMK) is configured with imported key material

  • CT.KMS.PV.6 Require that an AWS KMS customer-managed key (CMK) is configured with key material originating from an external key store (XKS)

  • CT.LAMBDA.PV.1 Require an AWS Lambda function URL to use AWS IAM-based authentication

  • CT.LAMBDA.PV.2 Require an AWS Lambda function URL to be configured for access only by principals within your AWS account

  • CT.MULTISERVICE.PV.1: Deny access to AWS based on the requested AWS Region for an organizational unit

The new detecive controls that enhance your digital sovereignty governance posture are part of the AWS Security Hub Service-Managed Standard AWS Control Tower.

New detective controls
  • SH.ACM.2: RSA certificates managed by ACM should use a key length of at least 2,048 bits

  • SH.AppSync.5: AWS AppSync GraphQL APIs should not be authenticated with API keys

  • SH.CloudTrail.6: Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible :

  • SH.DMS.9: DMS endpoints should use SSL

  • SH.DocumentDB.3: Amazon DocumentDB manual cluster snapshots should not be public

  • SH.DynamoDB.3: DynamoDB Accelerator (DAX) clusters should be encrypted at rest

  • SH.EC2.23: EC2 Transit Gateways should not automatically accept VPC attachment requests

  • SH.EKS.1: EKS cluster endpoints should not be publicly accessible

  • SH.ElastiCache.3: ElastiCache replication groups should have automatic failover enabled

  • SH.ElastiCache.4: ElastiCache replication groups should have encryption-at-rest enabled

  • SH.ElastiCache.5: ElastiCache replication groups should have encryption-in-transit enabled

  • SH.ElastiCache.6: ElastiCache replication groups of earlier Redis versions should have Redis AUTH enabled

  • SH.EventBridge.3: EventBridge custom event buses should have a resource-based policy attached

  • SH.KMS.4: AWS KMS key rotation should be enabled

  • SH.Lambda.3: Lambda functions should be in a VPC

  • SH.MQ.5: ActiveMQ brokers should use active/standby deployment mode

  • SH.MQ.6: RabbitMQ brokers should use cluster deployment mode

  • SH.MSK.1: MSK clusters should be encrypted in transit among broker nodes

  • SH.RDS.12: IAM authentication should be configured for RDS clusters

  • SH.RDS.15: RDS DB clusters should be configured for multiple Availability Zones

  • SH.S3.17: S3 buckets should be encrypted at rest with AWS KMS keys

For more information about controls added to the AWS Security Hub Service-Managed Standard AWS Control Tower see Controls that apply to Service-Managed Standard: AWS Control Tower in the AWS Security Hub documentation.

For a list of AWS Regions that do not support certain controls that are part of the AWS Security Hub Service-Managed Standard AWS Control Tower, see Unsupported Regions.

New configurable control for Region deny at the OU level

CT.MULTISERVICE.PV.1: This control accepts parameters to specify exempted Regions, IAM principals, and Actions that are allowed, at the OU level, rather than for the entire AWS Control Tower landing zone. It is a preventive control, implemented by Service control policy (SCP).

For more information, see Region deny control applied to the OU.

The UpdateEnabledControl API

This AWS Control Tower release adds the following API support for controls:

  • The updated EnableControl API can configure controls that are configurable.

  • The updated GetEnabledControl API shows the configured parameters on an enabled control.

  • The new UpdateEnabledControl API can change parameters on an enabled control.

For more information, see the AWS Control Tower API Reference.

AWS Control Tower supports landing zone APIs

November 26, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now supports landing zone configuration and launch using APIs. You can create, update, get, list, reset, and delete landing zones using APIs.

The following APIs enable you to set up and manage your landing zone programatically using AWS CloudFormation or the AWS CLI.

AWS Control Tower supports the following APIs for landing zones:

  • CreateLandingZone–This API call creates a landing zone using a landing zone version and manifest file.

  • GetLandingZoneOperation–This API call returns the status of a specified landing zone operation.

  • GetLandingZone–This API call returns details about the specified landing zone, including the version, manifest file, and status.

  • UpdateLandingZone–This API call updates the landing zone version or manifest file.

  • ListLandingZone–This API call returns one landing zone identifier (ARN) for a landing zone setup in the management account.

  • ResetLandingZone–This API call resets the landing zone to the parameters specified at the latest update, which can repair drift. If the landing zone has not been updated, this call resets the landing zone to the parameters specified at creation.

  • DeleteLandingZone–This API call decommissions the landing zone.

To get started with landing zone APIs, see the Get started with AWS Control Tower using APIs.

AWS Control Tower supports tagging for enabled controls

November 10, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now supports resource tagging for enabled controls, from the AWS Control Tower console or by means of APIs. You can add, remove, or list tags for enabled controls.

With the release of the following APIs, you can configure tags for the controls you enable in AWS Control Tower. Tags help you manage, identify, organize, search for, and filter resources. You can create tags to categorize resources by purpose, owner, environment, or other criteria.

AWS Control Tower supports the following APIs for control tagging:

  • TagResource–This API call adds tags to controls enabled in AWS Control Tower.

  • UntagResource–This API call removes tags from controls enabled in AWS Control Tower.

  • ListTagsForResource–This API call returns tags for controls enabled in AWS Control Tower.

AWS Control Tower control APIs are available in AWS Regions where AWS Control Tower is available. For a full list of AWS Regions in which AWS Control Tower is available, see the AWS Region Table. For a full list of AWS Control Tower APIs, see the API Reference.

AWS Control Tower available in Asia Pacific (Melbourne) Region

November 3, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower is available in Asia Pacific (Melbourne) Region.

If you are already using AWS Control Tower and you want to extend its governance features to this Region in your accounts, go to the Settings page in your AWS Control Tower dashboard, select the Region, and then update your landing zone. After a landing zone update, you must update all accounts that are governed by AWS Control Tower, to bring your accounts and OUs under governance in the new Region. For more information, see About Updates.

For a full list of Regions in which AWS Control Tower is available, see the AWS Region Table.

Transition to new AWS Service Catalog External product type (phase 1)

October 31, 2023

(No update required for AWS Control Tower landing zone.)

HashiCorp updated their Terraform licensing. As a result, AWS Service Catalog updated support for Terraform Open Source products and provisioned products to a new product type, called External.

AWS Control Tower does not support Account Factory customizations that rely on the AWS Service Catalog External product type. To avoid disruption to existing workloads and AWS resources in your accounts, follow the AWS Control Tower transition steps in this suggested order, by December 14, 2023:

  1. Upgrade your existing Terraform Reference Engine for AWS Service Catalog to include support for both External and Terraform Open Source product types. For instructions about updating your Terraform Reference Engine, review the AWS Service Catalog GitHub Repository.

  2. Go to AWS Service Catalog and duplicate any existing Terraform Open Source blueprints to use the new External product type. Do not terminate the existing Terraform Open Source blueprints.

  3. Continue to use your existing Terraform Open Source blueprints to create or update accounts in AWS Control Tower.

New control API available

October 14, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now supports an additional API that you can use to deploy and manage your AWS Control Tower controls, at scale. For more information about the AWS Control Tower control APIs, see the API Reference.

AWS Control Tower added a new control API.

  • GetEnabledControl—The API call provides details about an enabled control.

We also updated this API:

ListEnabledControls—This API call lists the controls enabled by AWS Control Tower on the specified organizational unit and the accounts it contains. It now returns additional information in an EnabledControlSummary object.

With these APIs, you can perform several common operations programmatically. For example:

  • Get a list of all the controls you've enabled from the AWS Control Tower controls library.

  • For any enabled control, you can get information about the Regions in which the control is supported, the control's identifier (ARN), the drift status of the control, and the control's status summary.

AWS Control Tower control APIs are available in AWS Regions where AWS Control Tower is available. For a full list of AWS Regions in which AWS Control Tower is available, see the AWS Region Table. For a full list of AWS Control Tower APIs, see the API Reference.

AWS Control Tower adds additional controls

October 5, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower announces new proactive and detective controls.

Proactive controls in AWS Control Tower are implemented by means of AWS CloudFormation Hooks, which identify and block non-compliant resources before AWS CloudFormation provisions them. Proactive controls complement existing preventive and detective control capabilities in AWS Control Tower.

New proactive controls
  • [CT.ATHENA.PR.1] Require an Amazon Athena workgroup to encrypt Athena query results at rest

  • [CT.ATHENA.PR.2] Require an Amazon Athena workgroup to encrypt Athena query results at rest with an AWS Key Management Service (KMS) key

  • [CT.CLOUDTRAIL.PR.4] Require an AWS CloudTrail Lake event data store to enable encryption at rest with an AWS KMS key

  • [CT.DAX.PR.2] Require an Amazon DAX cluster to deploy nodes to at least three Availability Zones

  • [CT.EC2.PR.14] Require an Amazon EBS volume configured through an Amazon EC2 launch template to encrypt data at rest

  • [CT.EKS.PR.2] Require an Amazon EKS cluster to be configured with secret encryption using AWS Key Management Service (KMS) keys

  • [CT.ELASTICLOADBALANCING.PR.14] Require a Network Load Balancer to have cross-zone load balancing activated

  • [CT.ELASTICLOADBALANCING.PR.15] Require that an Elastic Load Balancing v2 target group does not explicitly disable cross-zone load balancing

  • [CT.EMR.PR.1] Require that an Amazon EMR (EMR) security configuration is configured to encrypt data at rest in Amazon S3

  • [CT.EMR.PR.2] Require that an Amazon EMR (EMR) security configuration is configured to encrypt data at rest in Amazon S3 with an AWS KMS key

  • [CT.EMR.PR.3] Require that an Amazon EMR (EMR) security configuration is configured with EBS volume local disk encryption using an AWS KMS key

  • [CT.EMR.PR.4] Require that an Amazon EMR (EMR) security configuration is configured to encrypt data in transit

  • [CT.GLUE.PR.1] Require an AWS Glue job to have an associated security configuration

  • [CT.GLUE.PR.2] Require an AWS Glue security configuration to encrypt data in Amazon S3 targets using AWS KMS keys

  • [CT.KMS.PR.2] Require that an AWS KMS asymmetric key with RSA key material used for encryption has a key length greater than 2048 bits

  • [CT.KMS.PR.3] Require an AWS KMS key policy to have a statement that limits creation of AWS KMS grants to AWS services

  • [CT.LAMBDA.PR.4] Require an AWS Lambda layer permission to grant access to an AWS organization or specific AWS account

  • [CT.LAMBDA.PR.5] Require an AWS Lambda function URL to use AWS IAM-based authentication

  • [CT.LAMBDA.PR.6] Require an AWS Lambda function URL CORS policy to restrict access to specific origins

  • [CT.NEPTUNE.PR.4] Require an Amazon Neptune DB cluster to enable Amazon CloudWatch log export for audit logs

  • [CT.NEPTUNE.PR.5] Require an Amazon Neptune DB cluster to set a backup retention period greater than or equal to seven days

  • [CT.REDSHIFT.PR.9] Require that an Amazon Redshift cluster parameter group is configured to use Secure Sockets Layer (SSL) for encryption of data in transit

These new proactive controls are available in commercial AWS Regions where AWS Control Tower is available. For more details about these controls, see Proactive controls. For more details about where the controls are available, see Control limitations.

New detective controls

New controls were added to the Security Hub Service-Managed Standard: AWS Control Tower. These controls help you enhance your governance posture. They act as part of the Security Hub Service-Managed Standard: AWS Control Tower, after you enable them on any specific OU.

  • [SH.Athena.1] Athena workgroups should be encrypted at rest

  • [SH.Neptune.1] Neptune DB clusters should be encrypted at rest

  • [SH.Neptune.2] Neptune DB clusters should publish audit logs to CloudWatch Logs

  • [SH.Neptune.3] Neptune DB cluster snapshots should not be public

  • [SH.Neptune.4] Neptune DB clusters should have deletion protection enabled

  • [SH.Neptune.5] Neptune DB clusters should have automated backups enabled

  • [SH.Neptune.6] Neptune DB cluster snapshots should be encrypted at rest

  • [SH.Neptune.7] Neptune DB clusters should have IAM database authentication enabled

  • [SH.Neptune.8] Neptune DB clusters should be configured to copy tags to snapshots

  • [SH.RDS.27] RDS DB clusters should be encrypted at rest

The new AWS Security Hub detective controls are available in most AWS Regions where AWS Control Tower is available. For more details about these controls, see Controls that apply to Service-Managed Standard: AWS Control Tower. For more details about where the controls are available, see Control limitations.

New drift type reported: trusted access disabled

September 21, 2023

(No update required for AWS Control Tower landing zone.)

After you set up your AWS Control Tower landing zone, you can disable trusted access to AWS Control Tower in AWS Organizations. However, doing so causes drift.

With the trusted access disabled drift type, AWS Control Tower notifies you when this type of drift occurs, so you can repair your AWS Control Tower landing zone. For more information, see Types of governance drift.

Four additional AWS Regions

September 13, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower is now available in Asia Pacific (Hyderabad), Europe (Spain and Zurich), and Middle East (UAE).

If you are already using AWS Control Tower and you want to extend its governance features to this Region in your accounts, go to the Settings page in your AWS Control Tower dashboard, select the Region, and then update your landing zone. After a landing zone update, you must update all accounts that are governed by AWS Control Tower, to bring your accounts and OUs under governance in the new Region. For more information, see About Updates.

For a full list of Regions in which AWS Control Tower is available, see the AWS Region Table.

AWS Control Tower available in Tel Aviv Region

August 28, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower announces availability in the Israel (Tel Aviv) Region.

If you are already using AWS Control Tower and you want to extend its governance features to this Region in your accounts, go to the Settings page in your AWS Control Tower dashboard, select the Region, and then update your landing zone. After a landing zone update, you must update all accounts that are governed by AWS Control Tower, to bring your accounts and OUs under governance in the new Region. For more information, see About Updates.

For a full list of Regions in which AWS Control Tower is available, see the AWS Region Table.

AWS Control Tower launches 28 new proactive controls

July 24, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower is adding 28 new proactive controls, to assist you in managing your AWS environment.

Proactive controls enhance the governance capabilities of AWS Control Tower across your multi-account AWS environments, by blocking non-compliant resources before they are provisioned. These controls help manage AWS services such as Amazon CloudWatch, Amazon Neptune, Amazon ElastiCache, AWS Step Functions, and Amazon DocumentDB. The new controls help you meet control objectives such as establishing logging and monitoring, encrypting data at rest, or improving resiliency.

Here is a full list of the new controls:
  • [CT.APPSYNC.PR.1] Require an AWS AppSync GraphQL API to have logging enabled

  • [CT.CLOUDWATCH.PR.1] Require an Amazon CloudWatch alarm to have an action configured for the alarm state

  • [CT.CLOUDWATCH.PR.2] Require an Amazon CloudWatch log group to be retained for at least one year

  • [CT.CLOUDWATCH.PR.3] Require an Amazon CloudWatch log group to be encrypted at rest with an AWS KMS key

  • [CT.CLOUDWATCH.PR.4] Require an Amazon CloudWatch alarm action to be activated

  • [CT.DOCUMENTDB.PR.1] Require an Amazon DocumentDB cluster to be encrypted at rest

  • [CT.DOCUMENTDB.PR.2] Require an Amazon DocumentDB cluster to have automatic backups enabled

  • [CT.DYNAMODB.PR.2] Require an Amazon DynamoDB table to be encrypted at rest using AWS KMS keys

  • [CT.EC2.PR.13] Require an Amazon EC2 instance to have detailed monitoring enabled

  • [CT.EKS.PR.1] Require an Amazon EKS cluster to be configured with public access disabled to the cluster Kubernetes API server endpoint

  • [CT.ELASTICACHE.PR.1] Require an Amazon ElastiCache for Redis cluster to have automatic backups activated

  • [CT.ELASTICACHE.PR.2] Require an Amazon ElastiCache for Redis cluster to have automatic minor version upgrades activated

  • [CT.ELASTICACHE.PR.3] Require an Amazon ElastiCache for Redis replication group to have automatic failover activated

  • [CT.ELASTICACHE.PR.4] Require an Amazon ElastiCache replication group to have encryption at rest activated

  • [CT.ELASTICACHE.PR.5] Require an Amazon ElastiCache for Redis replication group to have encryption in transit activated

  • [CT.ELASTICACHE.PR.6] Require an Amazon ElastiCache cache cluster to use a custom subnet group

  • [CT.ELASTICACHE.PR.7] Require an Amazon ElastiCache replication group of earlier Redis versions to have Redis AUTH authentication

  • [CT.ELASTICBEANSTALK.PR.3] Require an AWS Elastic Beanstalk environment to have a logging configuration

  • [CT.LAMBDA.PR.3] Require an AWS Lambda function to be in a customer-managed Amazon Virtual Private Cloud (VPC)

  • [CT.NEPTUNE.PR.1] Require an Amazon Neptune DB cluster to have AWS Identity and Access Management (IAM) database authentication

  • [CT.NEPTUNE.PR.2] Require an Amazon Neptune DB cluster to have deletion protection enabled

  • [CT.NEPTUNE.PR.3] Require an Amazon Neptune DB cluster to have storage encryption enabled

  • [CT.REDSHIFT.PR.8] Require an Amazon Redshift cluster to be encrypted

  • [CT.S3.PR.9] Require that an Amazon S3 bucket has S3 Object Lock activated

  • [CT.S3.PR.10] Require an Amazon S3 bucket to have server-side encryption configured using AWS KMS keys

  • [CT.S3.PR.11] Require an Amazon S3 bucket to have versioning enabled

  • [CT.STEPFUNCTIONS.PR.1] Require an AWS Step Functions state machine to have logging activated

  • [CT.STEPFUNCTIONS.PR.2] Require an AWS Step Functions state machine to have AWS X-Ray tracing activated

Proactive controls in AWS Control Tower are implemented by means of AWS CloudFormation Hooks, which identify and block non-compliant resources before AWS CloudFormation provisions them. Proactive controls complement existing preventive and detective control capabilities in AWS Control Tower.

These new proactive controls are available in all AWS Regions where AWS Control Tower is available. For more details about these controls, see Proactive controls.

AWS Control Tower deprecates two controls

July 18, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower conducts regular reviews of its security controls to ensure that they are up to date and are still considered best practices. The following two controls have been deprecated, effective July 18, 2023, and they will be removed from the controls library, effective August 18, 2023. You can no longer enable these controls on any organizational units. You can choose to deactivate these controls before the removal date.

  • [SH.S3.4] S3 buckets should have server-side encryption enabled

  • [CT.S3.PR.7] Require an Amazon S3 bucket to have server-side encryption configured

Reason for deprecation

As of January ֿ2023, Amazon S3 configured default encryption on all new and existing unencrypted buckets to apply server-side encryption with S3 managed keys (SSE-S3) as the base level of encryption for new objects uploaded to these buckets. No changes have been made to the default encryption configuration for an existing bucket that already had SSE-S3 or server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS) configured.

AWS Control Tower landing zone version 3.2

June 16, 2023

(Update required for AWS Control Tower landing zone to version 3.2. For information, see Update your landing zone).

AWS Control Tower landing zone version 3.2 brings the controls that are part of the AWS Security Hub Service-Managed Standard: AWS Control Tower to general availability. It introduces the ability to view the drift status of controls that are part of this standard in the AWS Control Tower console.

This update includes a new service-linked role (SLR), called the AWSServiceRoleForAWSControlTower. This role assists AWS Control Tower by creating an EventBridge Managed Rule, called the AWSControlTowerManagedRule in each member account. This managed rule collects AWS Security Hub Finding events, from with AWS Control Tower can determine control drift.

This rule is the first managed rule to be created by AWS Control Tower. The rule is not deployed by a stack; it is deployed directly from the EventBridge APIs. You can view the rule in the EventBridge console, or by means of the EventBridge APIs. If the managed-by field is populated, it will show the AWS Control Tower service principal.

Previously, AWS Control Tower assumed the AWSControlTowerExecution role to perform operations in member accounts. This new role and rule are better aligned with the best practices principle of allowing least privilege when performing operations in a multi-account AWS environment. The new role provides scoped-down permissions that specifically allow: creating the managed rule in member accounts, maintaining the managed rule, publishing security notifications through SNS, and verifying drift. For more information, see AWSServiceRoleForAWSControlTower.

The landing zone 3.2 update also includes a new StackSet resource in the management account, BP_BASELINE_SERVICE_LINKED_ROLE, which initially deploys the service-linked role.

When reporting Security Hub control drift (in landing zone 3.2 and later), AWS Control Tower receives a daily status update from Security Hub. Although controls are active in every governed Region, AWS Control Tower sends the AWS Security Hub Finding events to the AWS Control Tower home Region only. For more information, see Security Hub control drift reporting.

Update to the Region Deny control

This landing zone version also includes an update to the Region Deny control.

Global services and APIs added
  • AWS Billing and Cost Management (billing:*)

  • AWS CloudTrail (cloudtrail:LookupEvents) to allow visibility of global events in member accounts.

  • AWS Consolidated Billing (consolidatedbilling:*)

  • AWS Management Console Mobile Application (consoleapp:*)

  • AWS Free Tier (freetier:*)

  • AWS Invoicing (invoicing:*)

  • AWS IQ (iq:*)

  • AWS User Notifications (notifications:*)

  • AWS User Notifications Contacts (notifications-contacts:*)

  • Amazon Payments (payments:*)

  • AWS Tax Settings (tax:*)

Global services and APIs removed
  • Removed s3:GetAccountPublic because it is not a valid action.

  • Removed s3:PutAccountPublic because it is not a valid action.

AWS Control Tower handles accounts based on ID

June 14, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now creates and manages accounts that you create in Account Factory by tracking the AWS account ID, rather than the account's email address.

When provisioning an account, the account requester always must have the CreateAccount and the DescribeCreateAccountStatus permissions. This permission set is part of the Admin role, and it is given automatically when a requester assumes the Admin role. If you delegate permission to provision accounts, you may need to add these permissions directly for the account requestors.

Additional Security Hub detective controls available in the AWS Control Tower controls library

June 12, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower has added ten new AWS Security Hub detective controls to the AWS Control Tower controls library. These new controls target services such as API Gateway, AWS CodeBuild, Amazon Elastic Compute Cloud (EC2), Amazon Elastic Load Balancer, Amazon Redshift, Amazon SageMaker, and AWS WAF. These new controls help you enhance your governance posture by meeting control objectives, such as Establish logging and monitoring, Limit network access, and Encrypt data at rest.

These controls act as part of the Security Hub Service-Managed Standard: AWS Control Tower, after you enable them on any specific OU.

  • [SH.Account.1] Security contact information should be provided for an AWS account

  • [SH.APIGateway.8] API Gateway routes should specify an authorization type

  • [SH.APIGateway.9] Access logging should be configured for API Gateway V2 Stages

  • [SH.CodeBuild.3] CodeBuild S3 logs should be encrypted

  • [SH.EC2.25] EC2 launch templates should not assign public IPs to network interfaces

  • [SH.ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS

  • [SH.Redshift.10] Redshift clusters should be encrypted at rest

  • [SH.SageMaker.2] SageMaker notebook instances should be launched in a custom VPC

  • [SH.SageMaker.3] Users should not have root access to SageMaker notebook instances

  • [SH.WAF.10] A WAFV2 web ACL should have at least one rule or rule group

The new AWS Security Hub detective controls are available in all AWS Regions where AWS Control Tower is available. For more details about these controls, see Controls that apply to Service-Managed Standard: AWS Control Tower.

AWS Control Tower publishes control metadata tables

June 7, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now provides full tables of control metadata as part of the published documentation. When working with the control APIs, you can look up each control's API controlIdentifier, which is a unique ARN associated with each AWS Region. The tables include the frameworks and control objectives that each control covers. Previously, this information was available in the console only.

The tables also include the metadata for Security Hub controls that are part of the AWS Security Hub Service-Managed Standard:AWS Control Tower. For full details, see Tables of control metadata.

For an abbreviated list of control identifiers, and some usage examples, see Resource identifiers for APIs and controls.

Terraform support for Account Factory Customization

June 6, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower offers single-Region support for Terraform through Account Factory Customization (AFC). Starting with this release, you can use AWS Control Tower and Service Catalog together, to define AFC account blueprints, in Terraform open source. You can customize your new and existing AWS accounts, before you provision resources in AWS Control Tower. By default, this feature enables you to deploy and update accounts, with Terraform, in your AWS Control Tower home Region.

An account blueprint describes the specific resources and configurations that are required when an AWS account is provisioned. You can use the blueprint as a template to create multiple AWS accounts at scale.

To get started, use the Terraform Reference Engine on GitHub. The Reference Engine configures the code and infrastructure required for the Terraform open source engine to work with Service Catalog. This one-time setup process takes a few minutes. After that, you can define your custom account requirements in Terraform, and then deploy your accounts with the well-defined AWS Control Tower account factory workflow. Customers who prefer to work with Terraform can utilize AWS Control Tower account customization at scale with AFC, and gain immediate access to each account after it is provisioned.

To learn how to create these customizations, see Creating Products and Getting started with Terraform open source in the Service Catalog documentation. This feature is available in all AWS Regions where AWS Control Tower is available.

AWS IAM Identity Center self-management available for landing zone

June 6, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower now supports an optional choice of identity provider for an AWS Control Tower landing zone, which you can configure during setup or update. By default, the landing zone is opted-in to using AWS IAM Identity Center, in alignment with best-practices guidance defined in Organizing Your AWS Environment Using Multiple Accounts. You now have three alternatives:

  • You can accept the default and allow AWS Control Tower to set up and manage AWS IAM Identity Center for you.

  • You can choose to self-manage AWS IAM Identity Center, to reflect your specific business requirements.

  • You can optionally bring and self-manage a third-party identity provider, by connecting it through IAM Identity Center, if needed. You should use identity provider optionality if your regulatory environment requires you to use a specific provider, or if you operate in AWS Regions where AWS IAM Identity Center is not available.

For more information, see IAM Identity Center guidance.

Selection of identity providers at the account level is not supported. This feature applies only for the landing zone as a whole. AWS Control Tower identity provider optionality is available in all AWS Regions where AWS Control Tower is available.

AWS Control Tower addresses mixed governance for OUs

June 1, 2023

(No update required for AWS Control Tower landing zone.)

With this release, AWS Control Tower prevents controls from deploying to an organizational unit (OU), if that OU is in a state of mixed governance. Mixed governance occurs in an OU if accounts are not updated after AWS Control Tower extends governance to a new AWS Region, or removes governance. This release helps you keep the member accounts of that OU in uniform compliance. For more information, see Avoid mixed governance when configuring Regions.

Additional proactive controls available

May 19, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower is adding 28 new proactive controls to assist you in governing your multi-account environment and meeting specific control objectives, such as data encryption at rest, or limiting network access. Proactive controls are implemented with AWS CloudFormation hooks that check your resources before they are provisioned. The new controls can help govern AWS services such as Amazon OpenSearch Service, Amazon EC2 Auto Scaling, Amazon SageMaker, Amazon API Gateway, and Amazon Relational Database Service (RDS).

Proactive controls are supported in all commercial AWS Regions where AWS Control Tower is available.

Amazon OpenSearch Service
  • [CT.OPENSEARCH.PR.1] Require an Elasticsearch domain to encrypt data at rest

  • [CT.OPENSEARCH.PR.2] Require an Elasticsearch domain to be created in a user-specified Amazon VPC

  • [CT.OPENSEARCH.PR.3] Require an Elasticsearch domain to encrypt data sent between nodes

  • [CT.OPENSEARCH.PR.4] Require an Elasticsearch domain to send error logs to Amazon CloudWatch Logs

  • [CT.OPENSEARCH.PR.5] Require an Elasticsearch domain to send audit logs to Amazon CloudWatch Logs

  • [CT.OPENSEARCH.PR.6] Require an Elasticsearch domain to have zone awareness and at least three data nodes

  • [CT.OPENSEARCH.PR.7] Require an Elasticsearch domain to have at least three dedicated master nodes

  • [CT.OPENSEARCH.PR.8] Require an Elasticsearch Service domain to use TLSv1.2

  • [CT.OPENSEARCH.PR.9] Require an Amazon OpenSearch Service domain to encrypt data at rest

  • [CT.OPENSEARCH.PR.10] Require an Amazon OpenSearch Service domain to be created in a user-specified Amazon VPC

  • [CT.OPENSEARCH.PR.11] Require an Amazon OpenSearch Service domain to encrypt data sent between nodes

  • [CT.OPENSEARCH.PR.12] Require an Amazon OpenSearch Service domain to send error logs to Amazon CloudWatch Logs

  • [CT.OPENSEARCH.PR.13] Require an Amazon OpenSearch Service domain to send audit logs to Amazon CloudWatch Logs

  • [CT.OPENSEARCH.PR.14] Require an Amazon OpenSearch Service domain to have zone awareness and at least three data nodes

  • [CT.OPENSEARCH.PR.15] Require an Amazon OpenSearch Service domain to use fine-grained access control

  • [CT.OPENSEARCH.PR.16] Require an Amazon OpenSearch Service domain to use TLSv1.2

Amazon EC2 Auto Scaling
  • [CT.AUTOSCALING.PR.1] Require an Amazon EC2 Auto Scaling group to have multiple Availability Zones

  • [CT.AUTOSCALING.PR.2] Require an Amazon EC2 Auto Scaling group launch configuration to configure Amazon EC2 instances for IMDSv2

  • [CT.AUTOSCALING.PR.3] Require an Amazon EC2 Auto Scaling launch configuration to have a single-hop metadata response limit

  • [CT.AUTOSCALING.PR.4] Require an Amazon EC2 Auto Scaling group associated with an Amazon Elastic Load Balancing (ELB) to have ELB health checks activated

  • [CT.AUTOSCALING.PR.5] Require that an Amazon EC2 Auto Scaling group launch configuration does not have Amazon EC2 instances with public IP addresses

  • [CT.AUTOSCALING.PR.6] Require any Amazon EC2 Auto Scaling groups to use multiple instance types

  • [CT.AUTOSCALING.PR.8] Require an Amazon EC2 Auto Scaling group to have EC2 launch templates configured

Amazon SageMaker
  • [CT.SAGEMAKER.PR.1] Require an Amazon SageMaker notebook instance to prevent direct internet access

  • [CT.SAGEMAKER.PR.2] Require Amazon SageMaker notebook instances to be deployed within a custom Amazon VPC

  • [CT.SAGEMAKER.PR.3] Require Amazon SageMaker notebook instances to have root access disallowed

Amazon API Gateway
  • [CT.APIGATEWAY.PR.5] Require Amazon API Gateway V2 Websocket and HTTP routes to specify an authorization type

Amazon Relational Database Service (RDS)
  • [CT.RDS.PR.25] Require an Amazon RDS database cluster to have logging configured

For more information, see Proactive controls.

Updated Amazon EC2 proactive controls

May 2, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower has updated two proactive controls: CT.EC2.PR.3 and CT.EC2.PR.4.

For the updated CT.EC2.PR.3 control, any AWS CloudFormation deployment that references a prefix list for a security group resource is blocked from deployment, unless it is for port 80 or 443.

For the updated CT.EC2.PR.4 control, any AWS CloudFormation deployment that references a prefix list for a security group resource is blocked if the port is 3389, 20, 23, 110, 143, 3306, 8080, 1433, 9200, 9300, 25, 445, 135, 21, 1434, 4333, 5432, 5500, 5601, 22, 3000, 5000, 8088, 8888.

Seven additional AWS Regions available

April 19, 2023

(No update required for AWS Control Tower landing zone.)

AWS Control Tower is now available in seven additional AWS Regions: Northern California (San Francisco), Asia Pacific (Hong Kong, Jakarta, and Osaka), Europe (Milan), Middle East (Bahrain), and Africa (Cape Town). These additional Regions for AWS Control Tower, called opt-in Regions, are not active by default, except the US West (N. California) Region, which is active by default.

Some controls in AWS Control Tower do not operate in some of these additional AWS Regions where AWS Control Tower is available, because those Regions do not support the required underlying functionality. For details, see Control limitations.

Among these new Regions, CfCT is not available in Asia Pacific (Jakarta and Osaka). Availability in other AWS Regions is unchanged.

For more information about how AWS Control Tower manages the limitations of Regions and controls, see Considerations for activating AWS opt-in Regions.

The VPCe endpoints required by AFT are not available in the Middle East (Bahrain) Region. Customers deploying AFT in this Region are required to deploy with parameter aft_vpc_endpoints=false. For more information, see the parameter in the README file.

AWS Control Tower VPCs have two Availability Zones in the US West (N. California) Region, us-west-1, due to a limitation in Amazon EC2. In the US West (N. California), six subnets are divided across two Availability Zones. For more information, see Overview of AWS Control Tower and VPCs.

AWS Control Tower added new permissions to AWSControlTowerServiceRolePolicy that allow AWS Control Tower to make calls to the EnableRegion, ListRegions, and GetRegionOptStatus APIs implemented by the AWS Account Management service, to make these additional AWS Regions available for your shared accounts in the landing zone (Management account, Log archive account, Audit account) and your OU member accounts. For more information, see Managed policies for AWS Control Tower.

Account Factory for Terraform (AFT) account customization request tracing

February 16, 2023

AFT supports account customization request tracing. Every time you submit an account customization request, AFT generates a unique tracing token that passes through an AFT customization AWS Step Functions state machine, which logs the token as part of its execution. You can use Amazon CloudWatch Logs insights queries to search timestamp ranges and retrieve the request token. As a result, you can see payloads that accompany the token, so you can trace your account customization request throughout the entire AFT workflow. For more information about AFT, see Overview of AWS Control Tower Account Factory for Terraform. For information about CloudWatch Logs and Step Functions, see the following:

AWS Control Tower landing zone version 3.1

February 9, 2023

(Update required for AWS Control Tower landing zone to version 3.1. For information, see Update your landing zone)

AWS Control Tower landing zone version 3.1 includes the following updates:

  • With this release, AWS Control Tower deactivates unnecessary access logging for your access logging bucket, which is the Amazon S3 bucket where access logs are stored in the Log Archive account, while continuing to enable server access logging for S3 buckets. This release also includes updates to the Region Deny control that allow additional actions for global services, such as AWS Support Plans and AWS Artifact.

  • Deactivation of server access logging for the AWS Control Tower access logging bucket causes Security Hub to create a finding for the Log Archive account's access logging bucket, due to an AWS Security Hub rule, [S3.9] S3 bucket server access logging should be enabled. In alignment with Security Hub, we recommend that you suppress this particular finding, as stated in the Security Hub description of this rule. For additional information, see information about suppressed findings.

  • Access logging for the (regular) logging bucket in the Log Archive account is unchanged in version 3.1. In alignment with best practices, access events for that bucket are recorded as log entries in the access logging bucket. For more information about access logging, see Logging requests using server access logging in the Amazon S3 documentation.

  • We made an update of the Region Deny control. This update allows actions by more global services. For details of this SCP, see Deny access to AWS based on the requested AWS Region and Controls that enhance data residency protection.

    Global services added:

    • AWS Account Management (account:*)

    • AWS Activate (activate:*)

    • AWS Artifact (artifact:*)

    • AWS Billing Conductor (billingconductor:*)

    • AWS Compute Optimizer (compute-optimizer:*)

    • AWS Data Pipeline (datapipeline:GetAccountLimits)

    • AWS Device Farm(devicefarm:*)

    • AWS Marketplace (discovery-marketplace:*)

    • Amazon ECR (ecr-public:*)

    • AWS License Manager (license-manager:ListReceivedLicenses)

    • AWS Lightsail (lightsail:Get*)

    • AWS Resource Explorer (resource-explorer-2:*)

    • Amazon S3 (s3:CreateMultiRegionAccessPoint, s3:GetBucketPolicyStatus, s3:PutMultiRegionAccessPointPolicy)

    • AWS Savings Plans (savingsplans:*)

    • IAM Identity Center (sso:*)

    • AWS Support App (supportapp:*)

    • AWS Support Plans (supportplans:*)

    • AWS Sustainability (sustainability:*)

    • AWS Resource Groups Tagging API (tag:GetResources)

    • AWS Marketplace Vendor Insights (vendor-insights:ListEntitledSecurityProfiles)

Proactive controls generally available

January 24, 2023

(No update required for AWS Control Tower landing zone.)

Optional proactive controls, previously announced in preview status, are now generally available. These controls are referred to as proactive because they check your resources – before the resources are deployed – to determine whether the new resources comply with the controls that are activated in your environment. For more information, see Comprehensive controls assist in AWS resource provisioning and management.