awslabs / landing-zone-accelerator-on-aws

Deploy a multi-account cloud foundation to support highly-regulated workloads and complex compliance requirements.

• Landing Zone Accelerator on AWS
  • Documentation
  • Package Structure
    • @aws-accelerator/accelerator
    • @aws-accelerator/config
    • @aws-accelerator/constructs
    • @aws-accelerator/installer
    • @aws-accelerator/ui (future)
    • @aws-accelerator/utils
    • @aws-cdk-extensions/cdk-extensions
    • @aws-cdk-extensions/tester

Landing Zone Accelerator on AWS

The Landing Zone Accelerator on AWS (LZA) is architected to align with AWS best practices and in conformance with multiple, global compliance frameworks. We recommend customers deploy AWS Control Tower as the foundational landing zone and enhance their landing zone capabilities with Landing Zone Accelerator. These complementary capabilities provides a comprehensive low-code solution across 35+ AWS services to manage and govern a multi-account environment built to support customers with highly-regulated workloads and complex compliance requirements. AWS Control Tower and Landing Zone Accelerator help you establish platform readiness with security, compliance, and operational capabilities.

Landing Zone Accelerator is provided as an open-source project that is built using the AWS Cloud Development Kit (CDK). You install directly into your environment to get full access to the infrastructure as code (IaC) solution. Through a simplified set of configuration files, you are able to configure additional functionality, controls and security services (eg. AWS Managed Config Rules, and AWS Security Hub), manage your foundational networking topology (eg. VPCs, Transit Gateways, and Network Firewall), and generate additional workload accounts using the AWS Control Tower Account Factory.

There are no additional charges or upfront commitments required to use Landing Zone Accelerator on AWS. You pay only for AWS services enabled in order to set up your platform and operate your controls. This solution can also support non-standard AWS partitions, including AWS GovCloud (US), and the US Secret and Top Secret regions.

For an overview and solution deployment guide, please visit Landing Zone Accelerator on AWS

---

IMPORTANT: This solution will not, by itself, make you compliant. It provides the foundational infrastructure from which additional complementary solutions can be integrated. The information contained in this solution implementation guide is not exhaustive. You must be review, evaluate, assess, and approve the solution in compliance with your organization’s particular security features, tools, and configurations. It is the sole responsibility of you and your organization to determine which regulatory requirements are applicable and to ensure that you comply with all requirements. Although this solution discusses both the technical and administrative requirements, this solution does not help you comply with the non-technical administrative requirements.

---

This solution collects anonymized operational metrics to help AWS improve the quality of features of the solution. For more information, including how to disable this capability, please see the implementation guide.

Documentation

Additional documentation for the solution is hosted on GitHub Pages. We strongly recommend reviewing this resource as well as the Implementation Guide for important details on deployment, customization, and maintenance of the solution and its included sample configuration files.

NOTE: The installation and configuration reference documentation that was previously hosted in this README has been migrated to the new GitHub Pages location.

Package Structure

@aws-accelerator/accelerator

A CDK Application. The core of the accelerator solution. Contains all the stack definitions and deployment pipeline for the accelerator. This also includes the CDK Toolkit orchestration.

@aws-accelerator/config

A pure typescript library containing modules to manage the accelerator config files.

@aws-accelerator/constructs

Contains L2/L3 constructs that have been built to support accelerator actions, such as creating an AWS Organizational Unit or VPC. These constructs are intended to be fully reusable, independent of the accelerator, and do not directly access the accelerator configuration files. Example: CentralLogsBucket, an S3 bucket that is configured with a CMK with the proper key and bucket policies to allow services and accounts in the organization to publish logs to the bucket.

@aws-accelerator/installer

Contains a CDK Application that defines the accelerator Installer stack.

@aws-accelerator/ui (future)

A web application that utilizes the aws-ui-components library to present a console to configure the accelerator

@aws-accelerator/utils

Contains common utilities and types that are needed by @aws-accelerator/* packages. For example, throttling and backoff for AWS SDK calls

@aws-cdk-extensions/cdk-extensions

Contains L2 constructs that extend the functionality of the CDK repo. The CDK repo is an actively developed project. As the accelerator team identifies missing features of the CDK, those features will be initially developed locally within this repo and submitted to the CDK project as a pull request.

@aws-cdk-extensions/tester

Accelerator tester CDK app. This package creates AWS Config custom rules for every test cases defined in test case manifest file.

---

Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

Licensed under the Apache License Version 2.0 (the "License"). You may not use this file except in compliance with the License. A copy of the License is located at

http://www.apache.org/licenses/

or in the "license" file accompanying this file. This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied. See the License for the specific language governing permissions and limitations under the License.

landing-zone-accelerator-on-aws's Issues

Cannot synthesize cloudformation template

when running
yarn cdk synth
from within source/packages/@aws-accelerator/installer using node v18.12.1 (current LTS) I receive the following error:

yarn run v1.22.19
$ cdk synth
/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:859
    return new TSError(diagnosticText, diagnosticCodes, diagnostics);
           ^
TSError: ⨯ Unable to compile TypeScript:
bin/installer.ts:16:22 - error TS2307: Cannot find module 'aws-cdk-lib' or its corresponding type declarations.

16 import * as cdk from 'aws-cdk-lib';
                        ~~~~~~~~~~~~~
bin/installer.ts:17:36 - error TS2307: Cannot find module 'cdk-nag' or its corresponding type declarations.

17 import { AwsSolutionsChecks } from 'cdk-nag';
                                      ~~~~~~~~~
bin/installer.ts:30:3 - error TS2584: Cannot find name 'console'. Do you need to change your target library? Try changing the 'lib' compiler option to include 'dom'.

30   console.log(`Invalid --management-cross-account-role-name ${managementCrossAccountRoleName}`);
     ~~~~~~~
bin/installer.ts:37:3 - error TS2345: Argument of type '{ description: string; synthesizer: any; useExternalPipelineAccount: boolean; enableTester: boolean; managementCrossAccountRoleName: any; }' is not assignable to parameter of type 'InstallerStackProps'.
  Object literal may only specify known properties, and 'description' does not exist in type 'InstallerStackProps'.

37   description: `(SO0199) Landing Zone Accelerator on AWS. Version ${version}.`,
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    at createTSError (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:859:12)
    at reportTSError (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:863:19)
    at getOutput (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:1077:36)
    at Object.compile (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:1433:41)
    at Module.m._compile (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:1617:30)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Object.require.extensions.<computed> [as .ts] (/Users/sbussetti/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/src/index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Function.Module._load (node:internal/modules/cjs/loader:878:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
  diagnosticCodes: [ 2307, 2307, 2584, 2345 ]
}

Subprocess exited with error 1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Failure during bootstrap phase when `s3PublicAccessBlock` is set to `true` in `us-east-1`

Describe the bug
After encountering a failure during bootstrap phase when attempting to configure a pure LZA deployment in us-east-1, I have narrowed the apparent cause down to the s3PublicAccessBlock setting in security-config.yaml.

To Reproduce

The solution deploys without issue with the following config:

centralSecurityServices:
  delegatedAdminAccount: Audit
  ebsDefaultVolumeEncryption:
    enable: true
    excludeRegions: []
  s3PublicAccessBlock:
    enable: false
    excludeAccounts: []
  snsSubscriptions: []
  macie:
    enable: false
    excludeRegions: []
    policyFindingsPublishingFrequency: FIFTEEN_MINUTES
    publishSensitiveDataFindings: true
  guardduty:
    enable: false
    excludeRegions: []
    s3Protection:
      enable: false
      excludeRegions: []
    exportConfiguration:
      enable: false
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES
  securityHub:
    enable: false
    regionAggregation: false
    excludeRegions: []
    standards: []
  ssmAutomation:
    excludeRegions: []
    documentSets: []
accessAnalyzer:
  enable: false
iamPasswordPolicy:
  allowUsersToChangePassword: true
  hardExpiry: false
  requireUppercaseCharacters: true
  requireLowercaseCharacters: true
  requireSymbols: true
  requireNumbers: true
  minimumPasswordLength: 14
  passwordReusePrevention: 24
  maxPasswordAge: 90
awsConfig:
  enableConfigurationRecorder: true
  enableDeliveryChannel: true
  ruleSets: []
cloudWatch:
  metricSets: []
  alarmSets: []

However, if security-config-yaml is updated so that s3PublicAccessBlock is true:

centralSecurityServices:
  delegatedAdminAccount: Audit
  ebsDefaultVolumeEncryption:
    enable: true
    excludeRegions: []
  s3PublicAccessBlock:
    enable: true
    excludeAccounts: []
  snsSubscriptions: []
  macie:
    enable: false
    excludeRegions: []
    policyFindingsPublishingFrequency: FIFTEEN_MINUTES
    publishSensitiveDataFindings: true
  guardduty:
    enable: false
    excludeRegions: []
    s3Protection:
      enable: false
      excludeRegions: []
    exportConfiguration:
      enable: false
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES
  securityHub:
    enable: false
    regionAggregation: false
    excludeRegions: []
    standards: []
  ssmAutomation:
    excludeRegions: []
    documentSets: []
accessAnalyzer:
  enable: false
iamPasswordPolicy:
  allowUsersToChangePassword: true
  hardExpiry: false
  requireUppercaseCharacters: true
  requireLowercaseCharacters: true
  requireSymbols: true
  requireNumbers: true
  minimumPasswordLength: 14
  passwordReusePrevention: 24
  maxPasswordAge: 90
awsConfig:
  enableConfigurationRecorder: true
  enableDeliveryChannel: true
  ruleSets: []
cloudWatch:
  metricSets: []
  alarmSets: []

The solution will then fail during the Bootstrap phase with the following error:

[2023-02-09 16:04:49] - info:       [security-audit-stack] Create SNS Topics and Subscriptions
[2023-02-09 16:04:49] - info:       [security-audit-stack] Completed stack synthesis
[2023-02-09 16:04:49] - info:       [accelerator-bootstrap] Creating bucket for region us-east-1 in account 111122223333
[2023-02-09 16:04:49] - debug:      [logging-stack] Logging stack started for account 111122223333 and region us-east-1
[2023-02-09 16:04:49] - debug:      [Logging-stack] Create S3 Key
[2023-02-09 16:04:49] - error:  undefined
[2023-02-09 16:04:49] - error:  undefined
Subprocess exited with error 1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
[Container] 2023/02/09 16:04:49 Command did not exit successfully if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi exit status 1
[Container] 2023/02/09 16:04:49 Phase complete: BUILD State: FAILED
[Container] 2023/02/09 16:04:49 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi. Reason: exit status 1

Expected behavior
I would prefer to be able to block public S3 access without breaking LZA 😃

Note that both configurations work without issue in us-gov-west-1. I have not tested in additional commercial regions as of yet.

Please complete the following information about the solution:

• Version: 1.3.0
• Region: us-east-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? Not applicable in this case
• Were there any errors in the CloudWatch Logs? CodeBuild errors are shown.

Additional context
Add any other context about the problem here.

Any changes to transit Gateway fail at bootstrap step

Describe the bug
I had been using landing accelerator and deployed a few VPCs/subnets/Routes and a transit gateway.

Lately (Starting Sept 23) any change to a transit gateway attachment causes the build to fail at the bootstrap step with "error: undefined". This problem coincided with v1.2.1

To Reproduce
Deploy a network with Transit Gateway and attachment on v1.2.0, make any to change to transit gateway attachment and deploy on v1.2.1

Expected behavior
boot strap would either emit an error from the build, or continue with CDK Synth

Please complete the following information about the solution:

• Version: [e.g. v1.1.0]
  v1.2.1

Mappings:
  SourceCode:
    General:
      S3Bucket: "solutions"
      KeyPrefix: "video-on-demand-on-aws/v5.0.0"

• Region: [e.g. us-east-1]:
  us-east-1
• Was the solution modified from the version published on this repository?
  no
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the services this solution uses?
• Were there any errors in the CloudWatch Logs?

[2022-10-31 20:00:20] - info: [network-vpc-stack] Adding Transit Gateway Attachment for Network-Main.TG
288 | [2022-10-31 20:00:20] - error: undefined
289 | Subprocess exited with error 1
290 | error Command failed with exit code 1.
291 | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
292 |  
293 | [Container] 2022/10/31 20:00:20 Command did not exit successfully if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi exit status 1
294 | [Container] 2022/10/31 20:00:20 Phase complete: BUILD State: FAILED
295 | [Container] 2022/10/31 20:00:20 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi. Reason: exit status 1
296 | [Container] 2022/10/31 20:00:20 Entering phase POST_BUILD
297 | [Container] 2022/10/31 20:00:20 Phase complete: POST_BUILD State: SUCCEEDED
298 | [Container] 2022/10/31 20:00:20 Phase context status code: Message:
299

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

AWS IAM Identity Center integration

Now that IAM Identity Center (previous AWS SSO) has a proper set of APIs (https://docs.aws.amazon.com/singlesignon/latest/APIReference/welcome.html) it would be great to be able to manage Permission sets, Groups and account associations through LZA config.

It might be integrated in iam-config.yaml file.

DefaultValue Support for CloudWatch Metric Filters

Describe the feature you'd like
Please add support to be set a Default value in security-config.yaml --> cloudWatch --> metricSets --> metrics

Additional context
Creating CW metric filters on a particular combination of events does not result in a metric being created (or visible) unless:

1. the event being filtered on actually occurs
2. there is a default value set on the filter

Being able to set the default value would help in checking / debugging / testing metricSets and related alarmSets.

Cannot deploy networking stack without vpcFlowLogs in NetworkConfig

Describe the bug
You cannot synthetize the network-vpc stage without vpcFlowLogs in network-config.yaml.

To Reproduce
Try deploying the solution without this option.

Expected behavior
The solution should not deploy the flow logs if the option is not configured.

Please complete the following information about the solution:

• Version: 1.3.0
• Region: N/A
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? Please see below:

[2023-02-03 16:19:05] - info:           [toolkit] Executing cdk synth network-vpc
[2023-02-03 16:19:55] - info:           [app] Begin Accelerator CDK App
[2023-02-03 16:19:55] - error:  undefined
[2023-02-03 16:19:55] - error:  undefined
Subprocess exited with error 1
error Command failed with exit code 1.

Screenshots
N/A

Additional context
N/A

Session Manager settings clobbers existing configuration

Describe the bug
When LZA is installed in existing accounts that already contain custom Session Manager settings, the custom resource (https://github.com/awslabs/landing-zone-accelerator-on-aws/blob/main/source/packages/%40aws-accelerator/constructs/lib/aws-ssm/session-manager-settings/index.ts) used to create the SSM-SessionManagerRunShell document doesn't fail if the document already exists; it instead adopts the document into management and clobbers the existing settings.

To avoid breaking existing workloads, this custom resource should ideally fail if the document already exists, rather than implicitly importing and replacing it (or potentially the built-in AWS::SSM::Document resource could be used instead?)

To Reproduce
Install LZA into existing accounts that have custom Session Manager settings.

Expected behavior

• Session Manager settings to be applied to accounts that don't already have custom settings
• CloudFormation stack to error when settings already exist, so that an informed decision can be made about whether to remove the existing settings

Please complete the following information about the solution:

• Version: 1.2.2
• Region: ap-southeast-2
• Was the solution modified from the version published on this repository? unknown
• If the answer to the previous question was yes, are the changes available on GitHub? n/a
• Have you checked your service quotas for the services this solution uses? n/a
• Were there any errors in the CloudWatch Logs? n/a

Screenshots
n/a

Additional context
n/a

Guard duty S3 protection doesnt honour manifest settings

Describe the bug
S3 protection gets enabled on guard duty for all account irrespective of settings are disabled on manifest

To Reproduce

1. Disable s3protection on guardduty on manifest
   

2. It is still comes up as enabled
   

Expected behavior
S3 protection should be disabled

Please complete the following information about the solution:

• [ x ] Version: [e.g. v1.1.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0021) - Video On Demand workflow with AWS Step Functions, MediaConvert, MediaPackage, S3, CloudFront and DynamoDB. Version v5.0.0". If the description does not contain the version information, you can look at the mappings section of the template:

guardduty:
    enable: true
    excludeRegions: []
    s3Protection:
      enable: false
      excludeRegions: []
    exportConfiguration:
      enable: true
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES

• Region: ap-south-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? No
• Have you checked your service quotas for the sevices this solution uses?
• Were there any errors in the CloudWatch Logs?

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

security-config.yaml ${ACCEL_LOOKUP... documentation

Is your feature request related to a problem? Please describe.
I am trying to create some custom Config rules that have auto remediation built in. I see line entries in the file that are leveraging the ${ACCEL_LOOKUP:: .....) but I can find no documentation on how to leverage it.

Describe the feature you'd like
I would like to have some documentation available that explains how I can leverage that function.

Additional context

Here is the block of code from best practices templates that I am trying to reverse engineer to figure out how the ${ACCEL_LOOKUP...) works:

    - name: accelerator-s3-bucket-server-side-encryption-enabled
      identifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      complianceResourceTypes:
        - AWS::S3::Bucket
      remediation:
        rolePolicyFile: custom-config-rules/bucket-sse-enabled-remediation-role.json
        automatic: true
        targetId: Put-S3-Encryption
        retryAttemptSeconds: 60
        maximumAutomaticAttempts: 5
        parameters:
          - name: BucketName
            value: RESOURCE_ID
            type: String
          - name: KMSMasterKey
            value: ${ACCEL_LOOKUP::KMS}
            type: StringList

In the above the vlue: ${ACCEL_LOOKUP::KMS} returns the S3 CMK value to encrypt with

Below is the code I created to solve another issue:

    - name: abc-sns-topic-encryption-enabled
      identifier: SNS_ENCRYPTED_KMS
      complianceResourceTypes:
        - AWS::SNS::Topic
      remediation:
        rolePolicyFile: custom-config-rules/abc-config-remediation-encrypt-sns-topic-role.json
        automatic: true
        targetId: abc-config-remediation-encrypt-sns-topic
        retryAttemptSeconds: 60
        maximumAutomaticAttempts: 5
        parameters:
          - name: TopicArn
            value: RESOURCE_ID
            type: String
          - name: KMSMasterKey
            value: ${ACCEL_LOOKUP::KMS}
            type: StringList

The above code works, but it encrypts with the S3 CMK... How do i get ${ACCEL_LOOKUP::KMS} to return the SNS CMK?

Account enrollment failed - Received response status [FAILED] from custom resource.

Describe the bug
at the prepare stage, the AWSAccelerator-PrepareStack failed, entering UPDATE_ROLLBACK_FAILED state with below error;

"The following resource(s) failed to update: [CreateCTAccounts3049A752]."

To Reproduce
Run LZA with 7 workload accounts?

Expected behavior
Enrollment for all accounts successful. Only one here has failed

Please complete the following information about the solution:

• Version: v1.3.0

• Region: [e.g. us-east-1]

• Was the solution modified from the version published on this repository?: no don't believe so

• If the answer to the previous question was yes, are the changes available on GitHub?

• Have you checked your service quotas for the sevices this solution uses?: yes

• Were there any errors in the CloudWatch Logs?: yes;

From: Lambda function logs /aws/lambda/AWSAccelerator-PrepareSta-CreateCTAccountsCreateCo-xxx

{
"errorType": "Error",
"errorMessage": "Account creation failed. Error: Accounts failed to enroll in Control Tower. Check Service Catalog Console",
"stack": [
"Error: Account creation failed. Error: Accounts failed to enroll in Control Tower. Check Service Catalog Console",
" at Runtime.kr [as handler] (/var/task/index.js:1:19159)",
" at processTicksAndRejections (internal/process/task_queues.js:95:5)"
]
}

From: CFN

Screenshots

Additional context
6 of the 7 workload accounts deployed just fine. This one is deployed in the same OU as 2 others, no apparent different configuration in accounts

CloudWatch Alarms does not have authorization to access the SNS topic encryption key

Describe the bug
LZA 1.2.2 creates the Config aggregator in the Management Account, and when I set the CloudWatch alarms deployment target to this account, the alarm default action will send the notifications to the SNS topics created in the Audit account.

I received the following error message when I created some events to trigger the alarm:
"CloudWatch Alarms does not have authorization to access the SNS topic encryption key."

To fix the issue, I have to update the key "accelerator/kms/sns/key" in the Audit account manually as following.

    {
        "Sid": "Allow_CloudWatch_for_CMK",
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudwatch.amazonaws.com"
        },
        "Action": [
            "kms:Decrypt",
            "kms:GenerateDataKey*"
        ],
        "Resource": "*"
    }

To Reproduce
Steps to reproduce the behavior.

Expected behavior
CloudWatch should have access to the SNS topic encryption key and the Alarm should be able to send the notifications via the topics created in the Audit account.

Please complete the following information about the solution:

• Version: [e.g. v1.1.0] v1.2.2
• Region: [e.g. us-east-1]
• Was the solution modified from the version published on this repository?
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses?
• Were there any errors in the CloudWatch Logs?

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Sending Guardduty findings to Log archive account

Describe issue
In manifest settings, there is no option to send Guardduty findings to S3 bucket in Log Archive account. When logging is enable for Guardduty, logs are sent to S3 bucket in Audit account.

Expected behavior
There should be an option to define account id to store logs in define account's S3 bucket.

Run a specific stage of the accelerator pipeline

Is your feature request related to a problem? Please describe.
In large environments, running the full pipeline takes hours. This discourage customers to use the native LZA configuration files. It would be nice to be able to run simple changes (e.g. adding a new role, adding a new permissionSet, a new assignment etc.) without having the run the full pipeline (or having to stop its execution once the required stage is finished).

Describe the feature you'd like
Being able to re-run a single stage of the pipeline (e.g. security or organization) once a configuration change has been made.

Additional context
It's also more environmental friendly and uses less resources ;)

feat(customizations): Add stack parameters

It would be great if we could specify parameters to customizations.cloudFormationStacks. Example:

Example:

customizations:
  cloudFormationStacks:
    - deploymentTargets:
        organizationalUnits:
          - SDLC
      description: Project A - Auto CDK bootstrap stack
      name: cdk-bootstrap-template
      regions:
        - us-east-1
      runOrder: 1
      template: cloudformation-templates/cdk-bootstrap-template.yaml
      terminationProtection: true
      parameters:
        - CDK_VERSION: 2.48.0
        - QUALIFIER: projectA

Landing Zone Accelerator Does Not Deploy Outside of US-EAST-1

Hi,

I'm trying to deploying the Landing Zone Accelerator in EU-WEST-1. During the CodePipeline Account stage it fails as it is looking for a CDK folder in US-EAST-1. There are only 4 regions listed in the GlobalRegionMap section of the template.

To Reproduce
Deploy in any region other than US-EAST-1, US-GOV-WEST-1, US-ISOB-EAST-1 or US-ISO-EAST-1 which are all listed.

Expected behavior
Expect LZA to deploy all resources in my EU-WEST-1 not split across EU-WEST-1 and US-EAST-1.

Please complete the following information about the solution:

• Version: [e.g. v1.2.0]
• Region: [e.g. eu-west-1]
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your [service quotas] yes (https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) for the sevices this solution uses?
• Were there any errors in the CloudWatch Logs? See screenshots

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Adding multiple OUs for TagPolicy bug

Describe the bug
Specifing multiple OUs for a TagPolicy in the organization-config.yaml causes the LZA pipeline to fail in the bootstrap stage with error: undefined.

To Reproduce
Steps to reproduce the behavior.
Add more than one OU for a TagPolicy
taggingPolicies:

• name: TagPolicy
  description: Organization Tagging Policy
  policy: tagging-policies/org-tag-policy.json
  deploymentTargets:
  organizationalUnits:
  - Infrastructure
  - PolicyStaging
  - Production
  - Sandbox

Expected behavior
A clear and concise description of what you expected to happen.
LZA Pipeline to succeed and create the Tagging Policy and attached to passed OUs

Please complete the following information about the solution:

• Version: 1.2.1
• Region: us-east-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? Not a service limit issue
• Were there any errors in the CloudWatch Logs? No

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.
Logs from CodeBuild
--partition aws
[2022-11-11 19:47:45] - info: [toolkit] Executing cdk synth
[2022-11-11 19:48:12] - info: [app] Begin Accelerator CDK App
[2022-11-11 19:48:13] - debug: [prepare-stack] homeRegion: us-east-1
[2022-11-11 19:48:13] - debug: [prepare-stack] CloudWatch Encryption Key
[2022-11-11 19:48:13] - debug: [prepare-stack] Lambda Encryption Key
[2022-11-11 19:48:13] - debug: [prepare-stack] Configuration assets creation
[2022-11-11 19:48:13] - info: [prepare-stack] Load Config Table
[2022-11-11 19:48:13] - info: [prepare-stack] Call create ou construct
[2022-11-11 19:48:13] - info: [prepare-stack] newOrgAccountsTable
[2022-11-11 19:48:13] - info: [prepare-stack] newControlTowerAccountsTable
[2022-11-11 19:48:13] - info: [prepare-stack] Validate Environment
[2022-11-11 19:48:13] - info: [prepare-stack] Create new organization accounts
[2022-11-11 19:48:13] - info: [prepare-stack] Get Portfolio Id
[2022-11-11 19:48:13] - info: [prepare-stack] Create new control tower accounts
[2022-11-11 19:48:13] - info: [prepare-stack] Completed stack synthesis
[2022-11-11 19:48:13] - debug: [finalize-stack] Region: us-east-1
[2022-11-11 19:48:13] - debug: [finalize-stack] Retrieving CloudWatch kms key
[2022-11-11 19:48:13] - info: [finalize-stack] Completed stack synthesis
[2022-11-11 19:48:13] - debug: [accounts-stack] Region: us-east-1
[2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for access-analyzer.amazonaws.com
[2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for guardduty.amazonaws.com
[2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for securityhub.amazonaws.com
[2022-11-11 19:48:13] - info: [accounts-stack] Completed stack synthesis
[2022-11-11 19:48:13] - debug: [organizations-stack] homeRegion: us-east-1
[2022-11-11 19:48:13] - debug: [organizations-stack] logging.cloudtrail.enable: false
[2022-11-11 19:48:13] - debug: [organizations-stack] logging.cloudtrail.organizationTrail: false
[2022-11-11 19:48:13] - debug: [organizations-stack] Enable Service Access for access-analyzer.amazonaws.com
[2022-11-11 19:48:13] - debug: [organizations-stack] Starts guardduty admin account delegation to the account with email xxxxx account in us-east-1 region
[2022-11-11 19:48:13] - debug: [organizations-stack] Guardduty Admin Account ID is xxxxxxx
[2022-11-11 19:48:13] - debug: [organizations-stack] Starts SecurityHub admin account delegation to the account with email xxxxxx account in us-east-1 region
[2022-11-11 19:48:13] - debug: [organizations-stack] SecurityHub Admin Account ID is xxxxxx
[2022-11-11 19:48:13] - info: [organizations-stack] Adding Tagging Policies
[2022-11-11 19:48:13] - error: undefined

v1.2.0 Deployment Error

Hey there! I am trying to deploy the landing zone accelerator to manage Commercial AWS accounts.

While deploying the stack set, CodeDeploy fails to generate a pipeline with the following build error.

Build failed to start
Build failed to start. The following error occurred: ArtifactsOverride must be set when using artifacts type CodePipelines

In the stackset, the resource GitHubPipeline7B79E906 failed to deploy with the error Internal Failure.

Pipeline Fails Due to a Previous Configuration Reference

Describe the bug
A previous accounts configuration contained a reference to an OU that was then removed from the configuration. The pipeline fails to build at the prepare stack step with the resulting CloudWatch message:

Provisioning failure error message: InvalidParametersException The parent organizational unit 'OUName (ou-afqi-xxx5xxx9)' is not enrolled in AWS Control Tower.

where 'OUName (ou-afqi-xxx5xxx9)' does not exist in any LZ Accelerator configuration file. All accounts to be created are under different existing OUs registered successfully in control tower.

To Reproduce
Add an OU to the organization config without creating the OU prior.
Add an account to the accounts config that references the OU that does not yet exist.
run the pipeline using this configuration
Add the OU manually using the console and register it in control tower
rerun the pipeline. It will fail with a log message that the parent OU is not registered in Control Tower (even though the OUID number is correct, and control tower shows no issues with the OU. The account is not created.
delete the configuration from the account and organization configs
rerun the pipeline. The same message occurs the the parent OU is not registered in Control Tower

Expected behavior
Expected behavior is that removing the references in the accounts and organization config should remove any artifacts from the pipeline. The pipeline should now run successfully and not try to deploy anything to the previous configuration.

Please complete the following information about the solution:

• Version: [e.g. v1.1.0]
  v1.1.0

• Region: [e.g. us-east-1]

• Was the solution modified from the version published on this repository?

• no

• If the answer to the previous question was yes, are the changes available on GitHub?

• Have you checked your service quotas for the sevices this solution uses?

• Were there any errors in the CloudWatch Logs?
  Full CloudWatch log message:

2022-08-18T22:01:10.162Z 913140eb-f4f7-455f-b024-683254d8af17 INFO {
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-1:1234567891011:function:AWSAccelerator-PrepareSta-CreateCTAccountsCreateCo-jrmzNQRYwAaI',
ResponseURL: 'https://cloudformation-custom-resource-response-useast1.s3.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%1234567891011%3Astack/AWSAccelerator-PrepareStack-1234567891011-us-east-1/c4f8e500-1f3f-11ed-8673-0a3a69fb2f09%7CCreateCTAccounts3049A752%7Ca9969771-bdaf-4ef7-9671-1ed7d0b05f66?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20220818T220108Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=AKIA6L7Q4OWTVPX5N4HK%2F20220818%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=7bdc2f2642c72e435def6cc5f00f642150aa2e2ef70550b63b6bfbacd729e718',
StackId: 'arn:aws:cloudformation:us-east-1:1234567891011:stack/AWSAccelerator-PrepareStack-1234567891011-us-east-1/c4f8e500-1f3f-11ed-8673-0a3a69fb2f09',
RequestId: 'a9969771-bdaf-4ef7-9671-1ed7d0b05f66',
LogicalResourceId: 'CreateCTAccounts3049A752',
PhysicalResourceId: '97fc9681-1857-4b29-b43e-dca64893d3b2',
ResourceType: 'Custom::CreateControlTowerAccounts',
ResourceProperties: {
ServiceToken: 'arn:aws:lambda:us-east-1:1234567891011:function:AWSAccelerator-PrepareSta-CreateCTAccountsCreateCo-jrmzNQRYwAaI',
uuid: 'da85c318-59b8-482b-b0fe-53555cad737f'
},
IsComplete: true
}
2022-08-18T22:01:10.524Z 913140eb-f4f7-455f-b024-683254d8af17 INFO getSingleAccount response {"Items":[],"Count":0,"ScannedCount":0}
2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Provisioning failure error message: InvalidParametersException The parent organizational unit 'Sandbox (ou-afqi-hatb5wy9)' is not enrolled in AWS Control Tower.
2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Control Tower account provisioning failed
2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Error: Accounts failed to enroll in Control Tower. Check Service Catalog Console at Runtime.Nr [as handler] (/var/task/index.js:1:17989) at processTicksAndRejections (internal/process/task_queues.js:95:5)
2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Create accounts failed. Deleting pending account creation records

"s3:GetEncryptionConfiguration" permission missing in central logging bucket policy

Describe the bug
When session manager s3 logging is enabled in the global-config.yaml (sessionManager.sendToS3), the session manager is configured to enforce S3 log encryption and checks if the s3 bucket has encryption enabled before connecting. The currently policy of the central logging bucket in the log archive account does not grant s3:GetEncryptionConfiguration permission for this check to complete.

To Reproduce

1. Deploy the LZA with sessionManager.sendToS3 set to true in the global-config.yaml
2. Launch an ec2 instance with the provided AWSAccelerator-SessionManagerEC2Role-<region> role in one of the workload accounts
3. Connect to the instance using session manager
4. Get error:

Your session has been terminated for the following reasons: Couldn't start the session
because we are unable to validate encryption on Amazon S3 bucket.
Error: AccessDenied: Access Denied status code: 403, request id: XXXXXX

Expected behavior
Enable session manager s3 logging and connect to ec2 instance using session manager without error.

Please complete the following information about the solution:

• Version: v1.2.0
• Region: ap-southeast-2
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses?
• Were there any errors in the CloudWatch Logs?

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
It appears that we need to include s3:ObjectOwnerOverrideToBucketOwner permission in central-logs-bucket.ts.

landing-zone-accelerator-on-aws/reference/sample-configurations/aws-best-practices/backup-policies/org-backup-policies.json file has a JSON error

Describe the bug
Line 173 and 176 of the landing-zone-accelerator-on-aws/reference/sample-configurations/aws-best-practices/backup-policies/org-backup-policies.json file has to switch since delete after days must be greater than move to cold storage after days.

To Reproduce
Edit the file.

Expected behavior
The policy is created but gives the rror when you open the console.

Please complete the following information about the solution:

• Version: [e.g. v1.1.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0021) - Video On Demand workflow with AWS Step Functions, MediaConvert, MediaPackage, S3, CloudFront and DynamoDB. Version v5.0.0". If the description does not contain the version information, you can look at the mappings section of the template:

Mappings:
  SourceCode:
    General:
      S3Bucket: "solutions"
      KeyPrefix: "video-on-demand-on-aws/v5.0.0"

• Region: [e.g. us-east-1]
• Was the solution modified from the version published on this repository?
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses?
• Were there any errors in the CloudWatch Logs?

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Check organization account limit against LZA config files and provide method to validate config files before commit.

LZA pipeline failed when it hit the account limit creating accounts. Being able to run this check and validate the configuration before starting the pipeline would be ideal. The configuration errors are helpful, but it would be better to validate the config before committing the code.

GuardDuty - Specify S3 Prefix for GuardDuty logs

Is your feature request related to a problem? Please describe.
Right now, GuardDuty logs are exported to the central logging bucket in the log archive account #14.

It is possible to store GuardDuty logs with a custom S3 Object Prefix as part of the destination ARN. In the current implementation of LZA, GuardDuty logs are not stored with a custom S3 Object prefix.

The LZA configuration bundles the GuardDuty logs with other AWSLogs such as Config Logs. The Logs are collectively stored under AWSLogs/{AWS::AccountId}. See this screenshot where GuardDuty and Config logs are stored under the Account ID.

This limits the capability to use S3 event notifications to send notifications when GuardDuty events are written to the S3 Bucket. We use S3 event notifications integration with SQS as part of a solution to do log processing and analytics on GuardDuty logs. S3 event notifications do not support wildcards in prefix filters, so we cannot set up a single S3 event notification filter for all GuardDuty Logs. Instead, we would have to create a new S3 event notification with a filter for every new Account ID in the landing zone, which adds additional complexity and has scaling issues.

Describe the feature you'd like
Allow the capability to specify S3 Prefix in the exportConfiguration for guardduty in security-config.yml.

guardduty:
    enable: true
    excludeRegions: []
    s3Protection:
      enable: true
      excludeRegions: []
    exportConfiguration:
      enable: true
      overrideExisting: true
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES

Cannot reference TGW peering attachments cross region in the same account

Describe the bug
You cannot reference TGW peering attachments in TGW route tables using attachment.transitGatewayPeeringName if using one Network account and multiple regions.

To Reproduce
Deploy the network-associations stack using a similar configuration for network-config.yaml as below :

transitGatewayPeering:
  - name: Network-Main-eu-west-1-Peering
    autoAccept: true
    requester:
      transitGatewayName: Network-Main
      account: Network
      region: *HOME_REGION
      routeTableAssociations: cross-tgw-egress
      tags:
        - key: Name
          value: Network-Main-eu-west-1-Peering
    accepter:
      transitGatewayName: Network-Main-eu-west-1
      account: Network
      region: eu-west-1
      routeTableAssociations: cross-tgw-egress
      autoAccept: true
      applyTags: true

transitGateways:
  - name: Network-Main
    account: Network
    region: *HOME_REGION
    shareTargets:
      organizationalUnits:
        - Development
        - Production
    asn: 65521
    dnsSupport: enable
    vpnEcmpSupport: enable
    defaultRouteTableAssociation: disable
    defaultRouteTablePropagation: disable
    autoAcceptSharingAttachments: enable
    routeTables:
      - name: east-west
        routes:
          - destinationCidrBlock: 0.0.0.0/0
            name: Inspection
            attachment:
              account: Network
              vpcName: Network-Inspection
      - name: ingress
        routes:
          - destinationCidrBlock: 0.0.0.0/0
            name: Inspection
            attachment:
              account: Network
              vpcName: Network-Inspection
      - name: inspection
        routes:
          - destinationCidrBlock: 0.0.0.0/0
            name: Outbound
            attachment:
              account: Network
              vpcName: Outbound
      - name: cross-tgw-egress
        routes:
          - destinationCidrBlock: 10.1.0.0/16
            name: eu-west-1
            attachment:
              transitGatewayPeeringName: Network-Main-eu-west-1-Peering
  - name: Network-Main-eu-west-1
    account: Network
    region: eu-west-1
    shareTargets:
      organizationalUnits:
        - Development
        - Production
    asn: 65522
    dnsSupport: enable
    vpnEcmpSupport: enable
    defaultRouteTableAssociation: disable
    defaultRouteTablePropagation: disable
    autoAcceptSharingAttachments: enable
    routeTables:
      - name: east-west
        routes:
          - destinationCidrBlock: 0.0.0.0/0
            name: Outbound-eu-west-1
            attachment:
              account: Network
              vpcName: Outbound-eu-west-1
      - name: cross-tgw-egress
        routes:
          - destinationCidrBlock: 10.0.0.0/16
            name: us-east-1
            attachment:
              transitGatewayPeeringName: Network-Main-eu-west-1-Peering

Expected behavior
The solution should reference the TransitGatewayAttachment using a lookup, not the SSM parameter that does not exist in the other region.

This may be related to the getTgwPeeringAttachmentId method of NetworkAssociationsStack:

[ landing-zone-accelerator-on-aws/source/packages/@aws-accelerator/accelerator/lib/stacks/network-associations-stack.ts between lines 2140-2188 ]

  private getTgwPeeringAttachmentId(transitGatewayPeeringName: string, tgwItem: TransitGatewayConfig): string {
    const requesterConfig = this.props.networkConfig.getTgwPeeringRequesterAccepterConfig(
      transitGatewayPeeringName,
      'requester',
    );
    const accepterConfig = this.props.networkConfig.getTgwPeeringRequesterAccepterConfig(
      transitGatewayPeeringName,
      'accepter',
    );

    if (!requesterConfig || !accepterConfig) {
      throw new Error(`Transit gateway peering ${transitGatewayPeeringName} not found !!!`);
    }

    // Get TGW attachment ID for requester
    if (this.props.accountsConfig.getAccountId(requesterConfig.account) === cdk.Stack.of(this).account) {
      return cdk.aws_ssm.StringParameter.valueForStringParameter(
        this,
        `/accelerator/network/transitGateways/${tgwItem.name}/peering/${transitGatewayPeeringName}/id`,
      );
    }

    // Get TGW attachment ID for accepter
    if (this.props.accountsConfig.getAccountId(accepterConfig.account) === cdk.Stack.of(this).account) {
      const transitGatewayId = this.transitGateways.get(accepterConfig.transitGatewayName);
      if (!transitGatewayId) {
        throw new Error(`Transit Gateway ${accepterConfig.transitGatewayName} not found`);
      }

      Logger.info(
        `[network-associations-stack] Looking up transit gateway peering attachment id of accepter account ${accepterConfig.account}`,
      );
      return TransitGatewayAttachment.fromLookup(
        this,
        pascalCase(`${accepterConfig.account}${transitGatewayPeeringName}TransitGatewayPeeringAttachment`),
        {
          name: transitGatewayPeeringName,
          owningAccountId: cdk.Stack.of(this).account,
          transitGatewayId,
          type: TransitGatewayAttachmentType.PEERING,
          kmsKey: this.cloudwatchKey,
          logRetentionInDays: this.logRetention,
        },
      ).transitGatewayAttachmentId;
    }

    throw new Error(`Transit Gateway attachment id not found for ${transitGatewayPeeringName}`);
  }

Please complete the following information about the solution:

• Version: [1.3.0]
• Region: [us-east-1, eu-west-1]
• Was the solution modified from the version published on this repository? no
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? Please see attached log file. AWSAccelerator-ToolkitProject-network-error.txt

Screenshots
N/A

Additional context
N/A

Enable application of Tag policy and backup policy at Account level

Based on the example configurations and source code, it looks like the deployment targets for Backup policies and Tagging policies can only be organization units and not accounts. AWS supports applying Backup policies and Tagging policies at both OU level and individual accounts level. Can this solution be updated to support application of these policies at account level? This solution seem to already support application of SCPs at account level. The same can be extended to these other policies.

Found Account not in configuration

Describe the bug
Prepare phase fails for existing accounts in existing Landing Zone when added to config.

498 | AWSAccelerator-PrepareStack-036499323218-us-east-1 | 4:44:51 PM | CREATE_FAILED | Custom::ValidateEnvironmentConfig | ValidateEnvironmentConfig/Resource/Default (ValidateEnvironmentConfigB40B464F) Received response status [FAILED] from custom resource. Message returned: Error: Found account with id xxxxx in OU Infrastructure that is not in the configuration.,Found account with id xxxxxx in OU Infrastructure that is not in the configuration.
Pipeline: AWSAccelerator-Pipeline
Phase: Prepare

To Reproduce
Existing landing Zone created in Control Tower. Installed Landing zone accelerator 1.2.2
Modified Config to add existing OU and Accounts (Matching Name and Email)

  enable: true
  organizationalUnits:
    - name: core
    - name: Security
    - name: Development
    - name: Infrastructure
    - name: Network
    - name: Production
    - name: Sandbox
  serviceControlPolicies: []
  taggingPolicies: []
  backupPolicies: []

accounts-config.yaml

  workloadAccounts:
    - name: caplz-security-services
      description: >-
        The security account
      email: xxxxx
      organizationalUnit: Infrastructure
    - name: caplz-shared-services
      description: >-
        The shared services account
      email: xxxxxx
      organizationalUnit: Infrastructure

Both Accounts are indeed in this OU and are registered.

ERROR:

Failed resources:

498 | AWSAccelerator-PrepareStack-036499323218-us-east-1 | 4:44:51 PM | CREATE_FAILED | Custom::ValidateEnvironmentConfig | ValidateEnvironmentConfig/Resource/Default (ValidateEnvironmentConfigB40B464F) Received response status [FAILED] from custom resource. Message returned: Error: Found account with id xxxxx3306 in OU Infrastructure that is not in the configuration.,Found account with id xxxxxx344 in OU Infrastructure that is not in the configuration.

Expected behavior
Recognize Account Config as Matching AWS Actual

Please complete the following information about the solution:

• [release/v1.2.2] Version: [e.g. v1.1.0]

• [ us-east-1] Region: [e.g. us-east-1]

• [no] Was the solution modified from the version published on this repository?

• [no] If the answer to the previous question was yes, are the changes available on GitHub?

• [yes] Have you checked your service quotas for the sevices this solution uses?

• [yes ] Were there any errors in the CloudWatch Logs?

Screenshots

Additional context
Add any other context about the problem here.

TSE-SE Sample Architecture SCP AWSAccelerator-Quarantine-New-Object update to solve timeout issue

I want to customize the build time, because some build need more time to deploy every resource.

Thanks in advance

Writeup on how to integrate with eks blueprint pattern

Is your feature request related to a problem? Please describe.
While Landing zone accelerator provides a robust framework on how to build 1 orchestrator for various accounts and network configurations, eks blueprint provide similar thoughts on orchestrating multiple eks cluster even across accounts and manage apps with gitops.
Its not very clear on how one should combine both the patterns to ensure an last mile delivery of secure containerised application.

Describe the feature you'd like
A writeup on how to extend landing zone to containers leveraging eke-blueprints

Additional context
https://github.com/aws-samples/cdk-eks-blueprints-patterns/blob/main/docs/patterns/pipeline-multi-env-gitops.md

Security Hub: CIS controls not disabled

Describe the bug
In the security config if you try to disable CIS controls using the syntax specified in the best practice files the control will not be disabled. The "AWS Security Best Practice" and "PCI-DSS" standards are unaffected and work as intended.

The format that does not work is using the CIS prefix, e.g:

    controlsToDisable:
      - CIS.1.17
      - CIS.1.16

A format that does work is passing a string of just the control number (as it appears in SH), e.g:

    controlsToDisable:
      - "1.17"
      - "1.16"

To Reproduce
Edit the security config and use the format as described as above. Run the LZA pipeline. Once complete review Security Hub, the control will still display "enabled".

Expected behavior
The control should be disabled in Security Hub.

Please complete the following information about the solution:

• Version: v1.3.0
• Region: eu-west-2
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? No. There are also no API calls made to "UpdateStandardsControl".

Not all v1.3.0 IamConfig class properties are listed in README

This is a documentation issue but couldn't figure out how to change the label.
There seem to have been a few changes in v1.3.0 to the IamConfig class that aren't represented in the README, namely the identityCenter and managedActiveDirectories properties which aren't listed in the IAM Configuration table.

Incorrect use of defaultVpcs in NetworkConfig / DefaultVpcsConfig example

I think the example use of defaultVpcs here has had an "s" appended in error as the definition here and NetworkConfig class property here don't have that "s" at the end.

bug(cicd): Change to config repo does not trigger the AWSAccelerator-Pipeline

Describe the bug
For any change to be deploy after a commit pushed to the aws-accelerator-config codecommit repo I have to click on "Release Change" in console for them to be applied.

To Reproduce
Push updates to the config repo. Nothing will happen in pipeline

Expected behavior
Automatic trigger of AWSAccelerator-Pipeline on aws-accelerator-config codecommit repo commits.

Please complete the following information about the solution:

• Version: v1.3.0

• Region: eu-west-1

• Was the solution modified from the version published on this repository? No

• If the answer to the previous question was yes, are the changes available on GitHub? -

• Have you checked your service quotas for the sevices this solution uses? Yes

• Were there any errors in the CloudWatch Logs? No

Does it not create an OU automatically?

Describe the bug
The accelerator pipeline not able to create infrastructure OU on first run.

To Reproduce
Pipeline runs the first time

Expected behavior
Infrastructure OU is automatically created.

Please complete the following information about the solution:

• [ x ] Version: [e.g. v1.0.1]
• [ x ] Region: ap-south-1
• [ x ] Was the solution modified from the version published on this repository? No
• [ x ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ x ] Have you checked your service quotas for the sevices this solution uses? yes
• [ x ] Were there any errors in the CloudWatch Logs? Nope

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Landing Zone Failure

Hello Team,

I hope you are doing well. I am testing AWS Landing Zone Accelerator and actually faced a lot of issues (Using AWS Organization instead of Control Tower) but I was able to fix it all. However, I am currently stuck with the Bootstrap Phase of CodePipeline. The build stage is returning:

Cannot assume role for 3600 seconds: AccessDenied: User: arn:aws:sts::ManagementAccountID:assumed-role/AWSAccelerator-PipelineSt-AdminCdkToolkitRole292E1-LNLW330962BO/AWSCodeBuild-afe03dcb-5634-43cf-852f-8d5e1e7fbf79 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::SecurityAccountID:role/AWSControlTowerExecution

Although I have disabled Control Tower in the global-config file, "controlTower: enable: false"
the Bootstrap is still assuming that the Control Tower IAM Role "AWSControlTowerExecution" is created but this is not the case for me.
The Landing Zone Accelerator documentation stated that if Control Tower is not enabled, the default Role "OrganizationAccountAccessRole" would do the job. This role is present in all my org accounts and the master account can assume these roles but still, the bootstrap is expecting the "AWSControlTowerExecution" role.

Apologies for any inconvenience and thank you so much for your support on this.

Thanks,

Duplicate emails error on validate-config

Describe the bug
i am getting an error when validaing my config doing yarn validate-config $CODEBUILD_SRC_DIR_Config

[config-validator] Error: accounts-config.yaml has 1 issues: Duplicate emails defined [[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]]. in accounts-config.yaml config file

i assume its becuase i am using plus emails i have added them to the yaml with and without single quotes and still getting error

is there a work around

• Version: 1.3.0

• name: Epic-Prod
  description: The Epic prod account
  email: '[email protected]'
  organizationalUnit: HIS/HIS-Prod

• name: Ohitdemo-Shared-SVC
  description: The Shared Service account
  email: '[email protected]'
  organizationalUnit: Infrastructure

Ignore OUs and or Accounts for Brownfield install

Trying to find documentation on integrating with a brown field ENV I have a few accounts and OU/s i want to keep out of this while we implement and even if i have them un managed in control tower i seem to keep getting errors on deploy unless i associate them

• Version: v1.3.0

Support CloudFormation templates with length greater than 51200 for customizations-config.yaml

Is your feature request related to a problem? Please describe.
When attempting to utilize customizations-config.yaml in version 1.3 to deploy our own CloudFormation stackSets, we are running into an error where the max template length supported appears to be 51200 bytes:

❌  AWSAccelerator-CustomizationsStack-246440944109-us-gov-west-1 failed: Error: The stack named AWSAccelerator-CustomizationsStack-246440944109-us-gov-west-1 failed to deploy: UPDATE_ROLLBACK_COMPLETE: Properties validation failed for resource AwsAcceleratorCustomAtomAwsAlerts with message:
--
#: #: only 1 subschema matches out of 2
#/TemplateBody: expected maxLength: 51200, actual: 94352, Resource handler returned message: "Operation 48a37db6-9c54-4555-be7a-efab2919886d on StackSet arn:aws-us-gov:cloudformation:us-gov-west-1:246440944109:stackset/ATOM-ThreatAlert-Scan-Role:8c356590-8c2f-4eb9-862c-8c91fa33996c is in progress (Service: CloudFormation, Status Code: 409, Request ID: d1db2c0b-511e-4f35-bc5f-68e9b0a17312)" (RequestToken: a79de482-54bd-9749-7e40-b7def9645bd6, HandlerErrorCode: GeneralServiceException)
at FullCloudFormationDeployment.monitorDeployment (/codebuild/output/src190/src/s3/00/source/node_modules/aws-cdk/lib/api/deploy-stack.ts:496:13)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async deployStack (/codebuild/output/src190/src/s3/00/source/node_modules/aws-cdk/lib/cdk-toolkit.ts:241:24)
at async /codebuild/output/src190/src/s3/00/source/node_modules/aws-cdk/lib/deploy.ts:39:11
at async run (/codebuild/output/src190/src/s3/00/source/node_modules/p-queue/dist/index.js:163:29)
 
❌ Deployment failed: Error: Stack Deployments Failed: Error: The stack named AWSAccelerator-CustomizationsStack-246440944109-us-gov-west-1 failed to deploy: UPDATE_ROLLBACK_COMPLETE: Properties validation failed for resource AwsAcceleratorCustomAtomAwsAlerts with message:
#: #: only 1 subschema matches out of 2
#/TemplateBody: expected maxLength: 51200, actual: 94352, Resource handler returned message: "Operation 48a37db6-9c54-4555-be7a-efab2919886d on StackSet arn:aws-us-gov:cloudformation:us-gov-west-1:246440944109:stackset/ATOM-ThreatAlert-Scan-Role:8c356590-8c2f-4eb9-862c-8c91fa33996c is in progress (Service: CloudFormation, Status Code: 409, Request ID: d1db2c0b-511e-4f35-bc5f-68e9b0a17312)" (RequestToken: a79de482-54bd-9749-7e40-b7def9645bd6, HandlerErrorCode: GeneralServiceException)
at Object.exports.deployStacks (/codebuild/output/src190/src/s3/00/source/node_modules/aws-cdk/lib/deploy.ts:61:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async CdkToolkit.deploy (/codebuild/output/src190/src/s3/00/source/node_modules/aws-cdk/lib/cdk-toolkit.ts:314:7)
at async Function.execute (/codebuild/output/src190/src/s3/00/source/packages/@aws-accelerator/accelerator/lib/toolkit.ts:281:9)
at async Promise.all (index 0)
at async Function.run (/codebuild/output/src190/src/s3/00/source/packages/@aws-accelerator/accelerator/lib/accelerator.ts:464:5)
Stack Deployments Failed: Error: The stack named AWSAccelerator-CustomizationsStack-246440944109-us-gov-west-1 failed to deploy: UPDATE_ROLLBACK_COMPLETE: Properties validation failed for resource AwsAcceleratorCustomAtomAwsAlerts with message:
#: #: only 1 subschema matches out of 2
#/TemplateBody: expected maxLength: 51200, actual: 94352, Resource handler returned message: "Operation 48a37db6-9c54-4555-be7a-efab2919886d on StackSet arn:aws-us-gov:cloudformation:us-gov-west-1:246440944109:stackset/ATOM-ThreatAlert-Scan-Role:8c356590-8c2f-4eb9-862c-8c91fa33996c is in progress (Service: CloudFormation, Status Code: 409, Request ID: d1db2c0b-511e-4f35-bc5f-68e9b0a17312)" (RequestToken: a79de482-54bd-9749-7e40-b7def9645bd6, HandlerErrorCode: GeneralServiceException)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
 
[Container] 2023/01/26 18:09:50 Command did not exit successfully yarn run ts-node --transpile-only cdk.ts --require-approval never $CDK_OPTIONS --config-dir $CODEBUILD_SRC_DIR_Config --partition aws-us-gov --app cdk.out exit status 1
[Container] 2023/01/26 18:09:50 Phase complete: BUILD State: FAILED
[Container] 2023/01/26 18:09:50 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: yarn run ts-node --transpile-only cdk.ts --require-approval never $CDK_OPTIONS --config-dir $CODEBUILD_SRC_DIR_Config --partition aws-us-gov --app cdk.out. Reason: exit status 1
[Container] 2023/01/26 18:09:51 Entering phase POST_BUILD
[Container] 2023/01/26 18:09:51 Phase complete: POST_BUILD State: SUCCEEDED
[Container] 2023/01/26 18:09:51 Phase context status code:  Message:

Describe the feature you'd like

While we can refactor our post-deployment stacks to be smaller than this limit, it would be helpful if the limitations were the same as the CloudFormation service itself, or if at the very least these limitations were explicitly documented in https://awslabs.github.io/landing-zone-accelerator-on-aws/classes/_aws_accelerator_config.CustomizationConfig.html

Additional context
Add any other context or screenshots about the feature request here.

feat(identity-center): Add support for identity store

Would be great to be able to manage groups and users through LZA leveraging identity store API the same way we can manage permission sets and assignments

Unable to create stateful firewall rule groups when using strict order

Describe the bug
Creating a stateful firewall rule group fails when using strict order.

To Reproduce
Add statefulRuleOptions: "STRICT_ORDER" to a stateful firewall rule group in network-config.yaml.

centralNetworkServices:
  networkFirewall:
    rules:
      - name: firewall-rule-group:
        regions:
          - *HOME_REGION
        capacity: 100
        type: STATEFUL
        ruleGroup:
          rulesSource:
            statefulRules:
              - action: PASS
                header:
                  destination: 10.0.0.0/24
                  destinationPort: '80'
                  direction: FORWARD
                  protocol: TCP
                  source: 10.50.0.0/20
                  sourcePort: Any
                ruleOptions:
                  - keyword: sid
                    settings: ['1']
          statefulRuleOptions: "STRICT_ORDER"

Expected behavior
Create a stateful firewall rule group with rule option strict order with no error.

Please complete the following information about the solution:

• Version: 1.2.2
• Region: us-gov-west-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? No

Additional context
Attached is the CodeBuild error log. I'm sure that I have the correct code because it failed earlier in the Build stage when, I believe, the solution goes through code verification. I changed the code to the snippet above to get past the error, but now it fails at the Network_Prepare stage of Deploy.

firewall-rule-error.txt

`customizations-config.yaml` does not appear to properly implement `runOrder` for `cloudFormationStackSets`

Describe the bug
As a result of #51 we have refactored some of our stackSets out into multiple templates. As there are now run order dependencies for these templates we attempted to enforce run order in the following way:

# Note that template files must be updated for each deployment, as there is currently no support in LZA for passing parameters
homeRegion: &HOME_REGION us-east-1
customizations:
  cloudFormationStackSets:
    - capabilities: [CAPABILITY_NAMED_IAM]
      deploymentTargets:
        organizationalUnits:
          - Root
      description: ATOM ThreatAlert Scan Role
      name: ATOM-ThreatAlert-Scan-Role
      regions: 
        - *HOME_REGION
      runOrder: 1
      template: cloudformation/atom-threatalert-scan-role.yaml
      terminationProtection: true
      # Customizations are limited to a max length of 51200 bytes, while the atom-aws-alerts clocks in at 94532 bytes.
      # ATOM AWS Alerts are chunked into three separate templates below
      # This limitation will be lifted in the future, and is being tracked in https://github.com/awslabs/landing-zone-accelerator-on-aws/issues/51
    - capabilities: [CAPABILITY_NAMED_IAM]
      deploymentTargets:
        organizationalUnits:
          - Root
      description: ATOM CloudWatch Alerting infrastructure and CIS alerts
      name: ATOM-AWS-Alerts-Infrastructure
      regions: 
        - *HOME_REGION
      runOrder: 1
      template: cloudformation/atom-aws-alerts-infrastructure.yaml
      terminationProtection: true
    - capabilities: [CAPABILITY_NAMED_IAM]
      deploymentTargets:
        organizationalUnits:
          - Root
      description: ATOM Splunk Cross Account Role
      name: ATOM-Splunk-Cross-Account-Role
      regions: 
        - *HOME_REGION
      runOrder: 1
      template: cloudformation/atom-splunk-cross-account-role.yml
    - capabilities: []
      deploymentTargets:
        organizationalUnits:
          - Root
      description: ATOM AWS Alerts
      name: ATOM-AWS-Alerts-1
      regions: 
        - *HOME_REGION
      runOrder: 2
      template: cloudformation/atom-aws-alerts-1.yaml
      terminationProtection: true
    - capabilities: []
      deploymentTargets:
        organizationalUnits:
          - Root
      description: ATOM AWS Alerts
      name: ATOM-AWS-Alerts-2
      regions: 
        - *HOME_REGION
      runOrder: 2
      template: cloudformation/atom-aws-alerts-2.yaml
      terminationProtection: true
      # FIPS requirements are not universally applicable. If FIPS is not applicable, comment out this stackset
    - capabilities: [CAPABILITY_NAMED_IAM]
      deploymentTargets:
        organizationalUnits:
          - Infrastructure
      description: SSM association for EC2 instances running Windows or Linux. Association checks FIPS status and publishes alerts if instances are not running in FIPS mode
      name: ATOM-SSM-CloudWatch-FIPS-Validator
      regions: 
        - *HOME_REGION
      runOrder: 2
      template: cloudformation/atom-ssm-cw-fips.yaml
      terminationProtection: true

However, when deploying this configuration, the following error was encountered:

❌  AWSAccelerator-CustomizationsStack-838035265473-us-east-1 failed: Error: The stack named AWSAccelerator-CustomizationsStack-838035265473-us-east-1 failed to deploy: UPDATE_ROLLBACK_COMPLETE (Update successful. One or more resources could not be deleted.): Resource handler returned message: "Resource of type 'Stack set operation [cd6f0cf4-6783-44c3-8352-84b20f5ab2f2] was unexpectedly stopped or failed. status reason(s): [Unable to fetch parameters [/atom/alerts/snsPrimaryTopic] from parameter store for this account.]' with identifier 'ATOM-SSM-CloudWatch-FIPS-Validator:ea9d5edd-4eff-420d-8963-7ee83e2a419f' did not stabilize." (RequestToken: f4a69153-9c73-0f3f-abaf-83f3c194293c, HandlerErrorCode: NotStabilized), Resource handler returned message: "Operation 9b7fb3c7-a217-4cdb-a3ac-2ac2df66b143 on StackSet arn:aws:cloudformation:us-east-1:838035265473:stackset/ATOM-ThreatAlert-Scan-Role:8583acf8-5221-40e4-aa0a-30dae216e351 is in progress (Service: CloudFormation, Status Code: 409, Request ID: f1e164c3-e9f4-4026-a1ca-bc9ccd55ced9)" (RequestToken: 61969314-d635-367c-b31b-09bdee53b5df, HandlerErrorCode: GeneralServiceException), Resource handler returned message: "Operation 561495e8-f5a0-4ae4-8ce5-dc4bc589c70e on StackSet arn:aws:cloudformation:us-east-1:838035265473:stackset/ATOM-Splunk-Cross-Account-Role:eef0d709-8ca9-4be2-8935-c4988aa3994d is in progress (Service: CloudFormation, Status Code: 409, Request ID: 8ca2e553-0189-4fbb-afcb-181443820e25)" (RequestToken: f816fa85-60b1-2f34-2fe4-3bd6a4e7f2d8, HandlerErrorCode: GeneralServiceException), Resource handler returned message: "Operation 70dc8db2-0ebf-4b46-928a-ada733705e28 on StackSet arn:aws:cloudformation:us-east-1:838035265473:stackset/ATOM-AWS-Alerts-Infrastructure:511f6cc5-2eac-4d23-b6f4-acb82791e3c6 is in progress (Service: CloudFormation, Status Code: 409, Request ID: e0d264fa-8e38-4b0d-8f93-1478698dcc76)" (RequestToken: 90183a28-859a-510c-8567-6325a6899a60, HandlerErrorCode: GeneralServiceException), Resource handler returned message: "Operation 70dc8db2-0ebf-4b46-928a-ada733705e28 on StackSet arn:aws:cloudformation:us-east-1:838035265473:stackset/ATOM-AWS-Alerts-Infrastructure:511f6cc5-2eac-4d23-b6f4-acb82791e3c6 is in progress (Service: CloudFormation, Status Code: 409, Request ID: 39310035-ad9b-42b1-a851-7b4345099d92)" (RequestToken: f2d8f689-726d-7bf7-680d-c6855a964c3c, HandlerErrorCode: GeneralServiceException)

This error should not occur if runOrder is working as expected, since cloudformation/atom-aws-alerts-infrastructure.yaml sets this parameter and has a runOrder of 1, while cloudformation/atom-ssm-cw-fips.yaml has a runOrder of 2.

Interrogating AWSAccelerator-CustomizationsStack- in the CloudFormation console indicates that all stackSet creations were initiated at the same time:

Expected behavior
I would expect for the Accelerator to respect runOrder arguments when deploying stackSets.

Please complete the following information about the solution:

• Version: 1.3.0
• Region: us-east-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? Not applicable
• Were there any errors in the CloudWatch Logs? Relevant errors are shown

Unable to add customer managed policies to IAM roles

Describe the bug
I appear unable to add customer managed policies to IAM roles.

To Reproduce
Try to add a customer managed policy to an IAM role within iam-config.yaml

Expected behavior
I am expecting to be able to add customer managed policies to IAM roles. Specifically, I am trying to add the LZA generated Session Manager roles to this specific role.

Please complete the following information about the solution:

• Version: v1.2.2
• Region: us-gov-west-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? No

Additional context

I am trying to create all IAM roles necessary to use EKS in the iam-config.yaml file. I can create multiple IAM roles with no problem. When I add the role with only AWS managed policies there are no problems. If I try the same action with only customer managed polices or with both customer managed polices and AWS managed policies, it fails with no apparent error (see attached CodeBuild logs). I have tried assigning customer managed policies with both arn and name, and both have the same results. I even tried to use the wrong customer managed policy name (as seen in the attached CodeBuild log), and I still have no error in the logs, but end up with a failure.

roleSets:
  # Roles for EKS
  - deploymentTargets:
      accounts:
        - NCCTDev
    roles:
      - name: eksRole
        assumedBy:
          - type: service
            principal: eks.amazonaws.com
        policies:
          awsManaged:
            - AmazonEKSClusterPolicy
      - name: eksNodeRole-temp
        assumedBy:
          - type: service
            principal: ec2.amazonaws.com
        policies:
          awsManaged:
            - AmazonEKSWorkerNodePolicy
            - AmazonEKS_CNI_Policy
            - AmazonS3FullAccess
            - AmazonEC2ContainerRegistryReadOnly
          customerManaged:
            - arn:aws-us-gov:iam::****:policy/AWSAccelerator-SessionManagerLogging-us-gov-west-1
            - arn:aws-us-gov:iam::****:policy/AWSAccelerator-SessionManagerUserKMS-us-gov-west-1

CodeBuild-Output.txt

AWS Config Conformance Packs

Describe the feature you'd like
It looks like you can create individual AWS Config rules, but the current limit is 250 rules per region. A lot of customers using AWS Conformance Packs to group rules together. Some customers have different compliance requirements for workloads. Implementing Conformance Packs would help to group rules together and keeping the config files not in the thousands of lines.

Deploying AWS Accelerator Installer Stack always fails at GitHubPipeline creation

Describe the bug
When trying to deploy the AWS Accelerator Installer Stack, i run into this error:

Looking into Cloud Trail shows me that the interactions with CodePipeline only ever calls get operations. I am wondering why there is no Create operation for the pipeline. Because the Get actually returns that an expected pipeline cannot be found:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::000000000000:assumed-role/AWSReservedSSO_AWSAdministratorAccess_abc/[email protected]",
       ...
        "invokedBy": "cloudformation.amazonaws.com"
    },
    "eventTime": "2022-09-29T10:07:26Z",
    "eventSource": "codepipeline.amazonaws.com",
    "eventName": "GetPipeline",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "AWS Internal",
    "userAgent": "AWS Internal",
    "errorCode": "ValidationException",
    "errorMessage": "Account '000000000000' does not have a pipeline with name 'AWSAccelerator-Installer'",
    "requestParameters": {
        "name": "AWSAccelerator-Installer"
    },
    "responseElements": null,
    "requestID": "b72c71a1-6847-4f1e-b764-c42a5108a03c",
    "eventID": "da118a2b-2954-4b99-98f3-0203ee552d37",
    "readOnly": true,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "eventCategory": "Management",
    "sessionCredentialFromConsole": "true"
}
``
`

**To Reproduce**
- go to https://aws.amazon.com/de/solutions/implementations/landing-zone-accelerator-on-aws/
- click "Launch in the AWS Console"
- enter the parameters (i used the account email addresses of already existing AWS Accounts that were created by AWS Control Tower)
- During deployment of the AWS Accelerator Installer Stack, the mentioned error occurs

**Expected behavior**
The AWS Accelerator Installer Stack deploys successfully without an error.
If an error occurs, i would expect a more detailed and helpful error message than only "Internal Failure".

**Please complete the following information about the solution:**

- [ x ] Version: 1.2.0
- [ x ] Region:  us-east-1, also tried eu-central-1 before and ran into the same issue
- [ x ] Was the solution modified from the version published on this repository? no
- [ ] If the answer to the previous question was yes, are the changes available on GitHub?
- [ x ] Have you checked your [service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) for the sevices this solution uses?  yes, haven't found something suspicious on the code pipeline quotas. All quotas should still be set to the defaults
- [ x ] Were there any errors in the CloudWatch Logs?  yes, during the GetPipeline as mentioned above

**Screenshots**
already added them above

**Additional context**
None

Code Pipeline fails using reference sample config

Describe the bug
Code Pipeline Prepare stage failed with error message

[Container] 2022/07/19 13:22:49 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi. Reason: exit status 1

To Reproduce
After initial deployment of landing-zone-accelerator I then utilised the reference sample configuration, replacing aws region and email addresses in the relevanlt configuration yaml files.
I then went to the codepipline and performed a release change

Expected behavior
Using the reference sample configuration I expected the codepipeline to deploy the relevant configuration

Please complete the following information about the solution:

• [Version: v1.0.1

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0021) - Video On Demand workflow with AWS Step Functions, MediaConvert, MediaPackage, S3, CloudFront and DynamoDB. Version v5.0.0". If the description does not contain the version information, you can look at the mappings section of the template:

Mappings:
  SourceCode:
    General:
      S3Bucket: "solutions"
      KeyPrefix: "video-on-demand-on-aws/v5.0.0"

• Region: sa-east-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? No.. Is there any particular service and I need to check
• Were there any errors in the CloudWatch Logs? No

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Prepare step fails with base configuration on new organization

Describe the bug
Installing the landing zone fails in CodePipeline prepare step when installing it in a new organization.

To Reproduce
We have created a new account to use as management account for a new landing zone setup.

Before we install the landing zone setup the following have been done in the account:

• Account created and billing have been setup
• Organization account limit have been increased to 200 through a support case
• New email domain have been purchased and moved out of sandbox mode
• AWS Control Tower and SSO have been enabled (Without KMS enabled)
  • Used emails logarchive@{DOMAIN} and audit@{DOMAIN}
  • Added Infrastructure as the additional OU
• KMS key created with CDK and AWS Control Tower have been updated to use KMS key
• GitHub token created in accelerator/github-token

The CodePipeline AWSAccelerator-Installer runs without errors and starts the AWSAccelerator-Pipeline that fails in the Prepare step.

Log from prepare step with undefined error in line 124 and 125:

1 	[Container] 2023/01/13 14:58:02 going inside waitForAgent
2	[Container] 2023/01/13 14:58:02 Waiting for agent ping
3	[Container] 2023/01/13 14:58:03 Waiting for DOWNLOAD_SOURCE
4	[Container] 2023/01/13 14:58:21 Phase is DOWNLOAD_SOURCE
5	[Container] 2023/01/13 14:58:21 finished waitForAgent
6	[Container] 2023/01/13 14:58:22 CODEBUILD_SRC_DIR=/codebuild/output/src644/src/s3/00
7	[Container] 2023/01/13 14:58:22 CODEBUILD_SRC_DIR_Config=/codebuild/output/src644/src/s3/01
8	[Container] 2023/01/13 14:58:22 YAML location is /codebuild/readonly/buildspec.yml
9	[Container] 2023/01/13 14:58:22 No commands found for phase name: install
10	[Container] 2023/01/13 14:58:22 Setting HTTP client timeout to higher timeout for S3 source
11	[Container] 2023/01/13 14:58:22 Processing environment variables
12	[Container] 2023/01/13 14:58:22 Selecting 'nodejs' runtime version '14' based on manual selections...
13	[Container] 2023/01/13 14:58:22 Running command echo "Installing Node.js version 14 ..."
14	Installing Node.js version 14 ...
15	
16	[Container] 2023/01/13 14:58:22 Running command n $NODE_14_VERSION
17	     copying : node/14.19.2
18	   installed : v14.19.2 (with npm 6.14.17)
19	
20	[Container] 2023/01/13 14:58:55 Moving to directory /codebuild/output/src644/src/s3/00
21	[Container] 2023/01/13 14:58:55 Configuring ssm agent with target id: codebuild:20da8443-dbe9-4fca-8c1e-791edd2cae53
22	[Container] 2023/01/13 14:58:55 Successfully updated ssm agent configuration
23	[Container] 2023/01/13 14:58:55 Registering with agent
24	[Container] 2023/01/13 14:58:55 Phases found in YAML: 2
25	[Container] 2023/01/13 14:58:55  BUILD: 6 commands
26	[Container] 2023/01/13 14:58:55  INSTALL: 0 commands
27	[Container] 2023/01/13 14:58:55 Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED
28	[Container] 2023/01/13 14:58:55 Phase context status code:  Message: 
29	[Container] 2023/01/13 14:58:55 Entering execCommands
30	[Container] 2023/01/13 14:58:55 Entering phase INSTALL
31	[Container] 2023/01/13 14:58:55 Phase complete: INSTALL State: SUCCEEDED
32	[Container] 2023/01/13 14:58:55 Phase context status code:  Message: 
33	[Container] 2023/01/13 14:58:55 Entering phase PRE_BUILD
34	[Container] 2023/01/13 14:58:55 Phase complete: PRE_BUILD State: SUCCEEDED
35	[Container] 2023/01/13 14:58:55 Phase context status code:  Message: 
36	[Container] 2023/01/13 14:58:55 Entering phase BUILD
37	[Container] 2023/01/13 14:58:55 Running command env
38	GOLANG_15_VERSION=1.15.15
39	MAVEN_OPTS=-Dmaven.wagon.httpconnectionManager.maxPerRoute=2
40	CODEBUILD_LAST_EXIT=0
41	CODEBUILD_START_TIME=1673621854123
42	GOLANG_16_VERSION=1.16.15
43	ACCELERATOR_QUALIFIER=aws-accelerator
44	CODEBUILD_BMR_URL=https://CODEBUILD_AGENT:3000
45	NODE_12_VERSION=12.22.12
46	JRE_8_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto/jre
47	CODEBUILD_SOURCE_VERSION=arn:aws:s3:::aws-accelerator-pipeline-111122223333-eu-west-1/AWSAccelerator-Pipel/Build/5GGH3Ie
48	CODEBUILD_AGENT_ENDPOINT=http://127.0.0.1:7831
49	HOSTNAME=9a3c9325dbae
50	CODEBUILD_BUILD_ID=AWSAccelerator-ToolkitProject:20da8443-dbe9-4fca-8c1e-791edd2cae53
51	CODEBUILD_KMS_KEY_ID=arn:aws:kms:eu-west-1:111122223333:key/97a2fa88-5ed0-47e2-997f-1a8829ebee3b
52	NODE_14_VERSION=14.19.2
53	JRE_11_HOME=/usr/lib/jvm/java-11-amazon-corretto
54	HOME=/root
55	OLDPWD=/codebuild/readonly
56	JRE_HOME=/usr/lib/jvm/java-11-amazon-corretto
57	CODEBUILD_GOPATH=/codebuild/output/src644
58	CODEBUILD_CI=true
59	GOENV_DISABLE_GOPATH=1
60	CODEBUILD_BUILD_NUMBER=1
61	CODEBUILD_BUILD_SUCCEEDING=1
62	NODE_OPTIONS=--max_old_space_size=8192
63	CODEBUILD_BUILD_ARN=arn:aws:codebuild:eu-west-1:111122223333:build/AWSAccelerator-ToolkitProject:20da8443-dbe9-4fca-8c1e-791edd2cae53
64	AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/v2/credentials/85af7e8c-d950-4fc1-ab68-10d839e3ee2f
65	LC_CTYPE=C.UTF-8
66	AWS_EXECUTION_ENV=AWS_ECS_EC2
67	ACCELERATOR_STAGE=prepare
68	RUBY_BUILD_SRC_DIR=/usr/local/rbenv/plugins/ruby-build
69	DOTNET_5_SDK_VERSION=5.0.408
70	CODEBUILD_INITIATOR=codepipeline/AWSAccelerator-Pipeline
71	CODEBUILD_SOURCE_REPO_URL_Config=arn:aws:s3:::aws-accelerator-pipeline-111122223333-eu-west-1/AWSAccelerator-Pipel/Config/NM1OP6M
72	AWS_DEFAULT_REGION=eu-west-1
73	PHP_80_VERSION=8.0.18
74	ECS_CONTAINER_METADATA_URI_V4=http://169.254.170.2/v4/c4de0f39-998b-4e6f-a211-07da9a1e3313
75	PHP_73_VERSION=7.3.33
76	ECS_CONTAINER_METADATA_URI=http://169.254.170.2/v3/c4de0f39-998b-4e6f-a211-07da9a1e3313
77	DOTNET_ROOT=/root/.dotnet
78	PHP_74_VERSION=7.4.29
79	CODEBUILD_SRC_DIR_Config=/codebuild/output/src644/src/s3/01
80	CODEBUILD_EXECUTION_ROLE_BUILD=
81	DOTNET_31_SDK_VERSION=3.1.419
82	PATH=/usr/local/bin/sbt/bin:/root/.phpenv/shims:/root/.phpenv/bin:/root/.goenv/shims:/root/.goenv/bin:/go/bin:/root/.phpenv/shims:/root/.phpenv/bin:/root/.pyenv/shims:/root/.pyenv/bin:/root/.rbenv/shims:/usr/local/rbenv/bin:/usr/local/rbenv/shims:/root/.dotnet/:/root/.dotnet/tools/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/tools:/codebuild/user/bin
83	RUBY_26_VERSION=2.6.10
84	CODEBUILD_LOG_PATH=20da8443-dbe9-4fca-8c1e-791edd2cae53
85	RUBY_27_VERSION=2.7.6
86	PYYAML_VERSION=5.4.1
87	CDK_OPTIONS=deploy --stage prepare
88	CODEBUILD_BUILD_IMAGE=aws/codebuild/standard:5.0
89	GOPATH=/go:/codebuild/output/src644
90	AWS_REGION=eu-west-1
91	CODEBUILD_BUILD_URL=https://eu-west-1.console.aws.amazon.com/codebuild/home?region=eu-west-1#/builds/AWSAccelerator-ToolkitProject:20da8443-dbe9-4fca-8c1e-791edd2cae53/view/new
92	JAVA_8_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto
93	CODEBUILD_SRC_DIR=/codebuild/output/src644/src/s3/00
94	CODEBUILD_PROJECT_UUID=c61ec112-5ca4-4ccf-88a1-5de1e1cd89b2
95	CDK_NEW_BOOTSTRAP=1
96	CODEBUILD_AUTH_TOKEN=5d067a1d-8051-4637-987c-77d96c618c5a
97	CODEBUILD_CONTAINER_NAME=default
98	JAVA_11_HOME=/usr/lib/jvm/java-11-amazon-corretto
99	CDK_METHOD=direct
100	JDK_8_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto
101	LOG4J_UNSAFE_VERSIONS=2.11.1 1.2.8
102	JAVA_HOME=/usr/lib/jvm/java-11-amazon-corretto
103	PWD=/codebuild/output/src644/src/s3/00
104	CODEBUILD_FE_REPORT_ENDPOINT=https://codebuild.eu-west-1.amazonaws.com/
105	PYTHON_37_VERSION=3.7.13
106	PYTHON_38_VERSION=3.8.13
107	PYTHON_39_VERSION=3.9.12
108	JDK_11_HOME=/usr/lib/jvm/java-11-amazon-corretto
109	CONFIG_COMMIT_ID=7e450a5a5dd5edd8820f35261f61e38daa358f72
110	NUGET_XMLDOC_MODE=skip
111	JDK_HOME=/usr/lib/jvm/java-11-amazon-corretto
112	
113	[Container] 2023/01/13 14:58:55 Running command cd source
114	
115	[Container] 2023/01/13 14:58:55 Running command cd packages/@aws-accelerator/accelerator
116	
117	[Container] 2023/01/13 14:58:55 Running command if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi
118	
119	[Container] 2023/01/13 14:58:55 Running command if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi
120	yarn run v1.22.19
121	$ /codebuild/output/src644/src/s3/00/source/packages/@aws-accelerator/accelerator/node_modules/.bin/ts-node --transpile-only cdk.ts synth --stage prepare --require-approval never --config-dir /codebuild/output/src644/src/s3/01 --partition aws
122	[2023-01-13 14:58:58] - info:       [toolkit] Executing cdk synth prepare
123	[2023-01-13 14:59:31] - info:       [app] Begin Accelerator CDK App
124	[2023-01-13 14:59:32] - error:  undefined
125	[2023-01-13 14:59:32] - error:  undefined
126	Subprocess exited with error 1
127	error Command failed with exit code 1.
128	info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
129	
130	[Container] 2023/01/13 14:59:32 Command did not exit successfully if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi exit status 1
131	[Container] 2023/01/13 14:59:32 Phase complete: BUILD State: FAILED
132	[Container] 2023/01/13 14:59:32 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi. Reason: exit status 1
133	[Container] 2023/01/13 14:59:32 Entering phase POST_BUILD
134	[Container] 2023/01/13 14:59:32 Phase complete: POST_BUILD State: SUCCEEDED
135	[Container] 2023/01/13 14:59:32 Phase context status code:  Message: 

Expected behavior
I expected that the minimal configuration was deployed to the account

Please complete the following information about the solution:

• Version: v1.3.0 - "Description": "(SO0199) Landing Zone Accelerator on AWS. Version 1.3.0."
• Region: Main region: eu-west-1, Additional regions: us-east-1, eu-central-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? Yes
• Were there any errors in the CloudWatch Logs?

/aws/codebuild/AWSAccelerator-ToolkitProject

| 1673621939425 | [Container] 2023/01/13 14:58:55 Running command cd source                                                                                                                                                                                                                                                                                                                               |
| 1673621939425 |                                                                                                                                                                                                                                                                                                                                                                                         |
| 1673621939425 | [Container] 2023/01/13 14:58:55 Running command cd packages/@aws-accelerator/accelerator                                                                                                                                                                                                                                                                                                |
| 1673621939425 |                                                                                                                                                                                                                                                                                                                                                                                         |
| 1673621939425 | [Container] 2023/01/13 14:58:55 Running command if [ -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi                                                                                                                                                               |
| 1673621939425 |                                                                                                                                                                                                                                                                                                                                                                                         |
| 1673621939425 | [Container] 2023/01/13 14:58:55 Running command if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi                                                                                                                                  |
| 1673621939425 | yarn run v1.22.19                                                                                                                                                                                                                                                                                                                                                                       |
| 1673621939425 | $ /codebuild/output/src644/src/s3/00/source/packages/@aws-accelerator/accelerator/node_modules/.bin/ts-node --transpile-only cdk.ts synth --stage prepare --require-approval never --config-dir /codebuild/output/src644/src/s3/01 --partition aws                                                                                                                                      |
| 1673621939425 | [2023-01-13 14:58:58] - �[32minfo�[39m:   [toolkit] Executing cdk synth prepare                                                                                                                                                                                                                                                                                                         |
| 1673621971487 | [2023-01-13 14:59:31] - �[32minfo�[39m:   [app] Begin Accelerator CDK App                                                                                                                                                                                                                                                                                                               |
| 1673621974327 | [2023-01-13 14:59:32] - �[31merror�[39m:  undefined                                                                                                                                                                                                                                                                                                                                     |
| 1673621974327 | [2023-01-13 14:59:32] - �[31merror�[39m:  undefined                                                                                                                                                                                                                                                                                                                                     |
| 1673621974327 | Subprocess exited with error 1                                                                                                                                                                                                                                                                                                                                                          |
| 1673621974327 | error Command failed with exit code 1.                                                                                                                                                                                                                                                                                                                                                  |
| 1673621974327 | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.                                                                                                                                                                                                                                                                                                    |
| 1673621974327 |                                                                                                                                                                                                                                                                                                                                                                                         |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Command did not exit successfully if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi exit status 1                                                                                                  |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Phase complete: BUILD State: FAILED                                                                                                                                                                                                                                                                                                                     |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ ! -z "${ACCELERATOR_STAGE}" ]; then yarn run ts-node --transpile-only cdk.ts synth --stage $ACCELERATOR_STAGE --require-approval never --config-dir $CODEBUILD_SRC_DIR_Config --partition aws; fi. Reason: exit status 1                                |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Entering phase POST_BUILD                                                                                                                                                                                                                                                                                                                               |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Phase complete: POST_BUILD State: SUCCEEDED                                                                                                                                                                                                                                                                                                             |
| 1673621974327 | [Container] 2023/01/13 14:59:32 Phase context status code:  Message:   

Screenshots

Additional context
No

LZA AWSAccelerator-PrepareStack-xxx cloudformation fails

Describe the bug
Running the code pipeline after changes to config repository results in the AWSAccelerator-PrepareStack cloudformation template

To Reproduce
Rerunning cloudformation results in failure always

Please complete the following information about the solution:

• [ 1.3.0] Version:
  (SO0199-prepare) Landing Zone Accelerator on AWS. Version 1.3.0.

• [us-west-2 ] Region: [e.g. us-east-1]

• [N] Was the solution modified from the version published on this repository?

• [Y] Were there any errors in the CloudWatch Logs?

Details

The following resource(s) failed to create: [LoadAcceleratorConfigTable8F9D29D6]. Rollback requested by user.
Received response status [FAILED] from custom resource. Message returned: AccessDeniedException: You don't have permissions to access this resource.

Code Pipeline fails in the Security Stage when adding a new account with configurations security-config enabled

Describe the bug

Code Pipeline fails in the Security Stage when adding a new account with configurations in security-config.yaml enabled. It fails only for the new account I do not see any error for already created account:

AWSAccelerator-SecurityStack-753133502924-us-east-1 | 15/25 | 6:58:48 PM | CREATE_FAILED | Custom::GuardDutyCreatePublishingDestinationCommand | GuardDutyPublishingDestination/Resource/Default (GuardDutyPublishingDestination52AE4412) Received response status [FAILED] from custom resource. Message returned: InvalidInputException: The request was rejected because you do not have the required iam:GetRole permission.

To Reproduce

1. Deploy AWSAccelerator Pipeline
2. After the deployment is successful add a new Account in the accounts-config.yaml
3. Enable the security-config.yaml with AWS Best practices
4. Deploy again

Expected behavior
The Pipeline should complete successfully with the new account setup and security-configs enabled.

Please complete the following information about the solution:

• Version: [v1.1.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0021) - Video On Demand workflow with AWS Step Functions, MediaConvert, MediaPackage, S3, CloudFront and DynamoDB. Version v5.0.0". If the description does not contain the version information, you can look at the mappings section of the template:

Mappings:
  SourceCode:
    General:
      S3Bucket: "solutions"
      KeyPrefix: "video-on-demand-on-aws/v5.0.0"

• Region: [us-east-1]
• Was the solution modified from the version published on this repository? Yes
• If the answer to the previous question was yes, are the changes available on GitHub? No, it's in my code commit repository
• Have you checked your service quotas for the sevices this solution uses? N/A
• Were there any errors in the CloudWatch Logs? Received response status [FAILED] from custom resource. Message returned: InvalidInputException: The request was rejected because you do not have the required iam:GetRole permission. at Object.extractError (/var/runtime/node_modules/aws-sdk/lib/protocol/json.js:52:27) at Request.extractError (/var/runtime/node_modules/aws-sdk/lib/protocol/rest_json.js:49:8) at Request.callListeners (/var/runtime/node_modules/aws-sdk/lib/sequential_executor.js:106:20) at Request.emit (/var/runtime/node_modules/aws-sdk/lib/sequential_executor.js:78:10) at Request.emit (/var/runtime/node_modules/aws-sdk/lib/request.js:686:14) at Request.transition (/var/runtime/node_modules/aws-sdk/lib/request.js:22:10) at AcceptorStateMachine.runTo (/var/runtime/node_modules/aws-sdk/lib/state_machine.js:14:12) at /var/runtime/node_modules/aws-sdk/lib/state_machine.js:26:10 at Request.<anonymous> (/var/runtime/node_modules/aws-sdk/lib/request.js:38:9) at Request.<anonymous> (/var/runtime/node_modules/aws-sdk/lib/request.js:688:12) (RequestId: 6cb560f3-e78b-40f8-b0b1-8aaee6f2613a)

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

Canadian Centre for Cyber Security (CCCS) Cloud Medium - readme.md - error in installation documentation

Describe the bug
Error in the installation documentation of LZA with the sample configuration for the Canadian Centre for Cyber Security (CCCS) Cloud Medium.
The readme.md must me corrected:
[https://gitlab.aws.dev/landing-zone-accelerator/landing-zone-accelerator-on-aws/-/blob/main/reference/sample-configurations/aws-best-practices-cccs-medium/readme.md]

To Reproduce
I discover this error when trying to deploy the landing zone (LZ 1.3.0) for the first time in January 2023. There is a missing step in the installation procedure. Anyone that will perform a fresh installation will be face with this problem.

Expected behavior
The following instruction are missing to copy the proper accelerator config files in AWS CodeCommit:

Step 3. Copy the configuration files

• Clone the aws-accelerator-config AWS CodeCommit repository.
• Clone the landing-zone-accelerator-on-aws repo
• Copy the contents from the aws-best-practice-cccs-medium folder under reference/sample-configurations to your local aws-accelerator-config repo. You may be prompted to over-write duplicate configs, such as accounts-config.yaml.

Please complete the following information about the solution:
LZA Version 1.3.0

Existing documentation:

Step 3. Update the configuration files

• Navigate to the aws-accelerator-config AWS CodeCommit repository.
• Update the configuration files to match the desired state of your environment, including the desired home region. Look for the #UPDATE EMAIL ADDRESS comments in all files for areas requiring updates.
• Release a change manually to the AWSAccelerator-Pipeline pipeline.
• After the Accounts stage completes, the Network account will be created. VPC service quotas need to be increased in the Network account before the Networking phase begins or the Pipeline will fail. This is approximately 20 minutes after the Accounts stage completes. (If it does, executing a Retry is the next action).
• Two service limits need to be increased in the Network AWS Account. Follow these steps:
  • Assume the OrganizationAccountAccessRole role into the Network account. (The AWS Account ID can be determined in AWS Organizations)
  • Navigate to Service Quotas → AWS Services
  • Search for VPC and select when found
  • Click on Interface VPC endpoints per VPC (Quota Code: L-29B6F2EB) and request a quota increase to 90
  • Click on VPCs per Region (Quota Code: L-F678F1CE) and request a quota increase to 8
  • (It takes approximately 15-30 minutes for the requested quota increase to apply)
• (optional) Retry the failed Pipeline Stage if the quota increase was not completed in time.
• Await successful completion of AWSAccelerator-Pipeline pipeline.

Propose change to existing documentation:

Step 3. Copy the configuration files

• Clone the aws-accelerator-config AWS CodeCommit repository.
• Clone the landing-zone-accelerator-on-aws repo
• Copy the contents from the aws-best-practice-cccs-medium folder under reference/sample-configurations to your local aws-accelerator-config repo. You may be prompted to over-write duplicate configs, such as accounts-config.yaml.

Step 4. Update the configuration files and release a change.

• Using the IDE of your choice, in your local aws-accelerator-config repo, update the variables at the top of each config, such as homeRegion, to match where you deployed the solution to.
• Update the configuration files to match the desired state of your environment. Look for the UPDATE comments for areas requiring updates, such as e-mail addresses in your accounts-config.yaml
• Review the contents in the Security Controls section below to understand if any changes need to be made to meet organizational requirements, such as applying SCPs to the various OUs.
• Commit and push all your change to the aws-accelerator-config AWS CodeCommit repository.
• Release a change manually to the AWSAccelerator-Pipeline pipeline.
• After the Accounts stage completes, the Network account will be created. VPC service quotas need to be increased in the Network account before the Networking phase begins or the Pipeline will fail. This is approximately 20 minutes after the Accounts stage completes. (If it does, executing a Retry is the next action).
• Two service limits need to be increased in the Network AWS Account. Follow these steps:
  • Assume the OrganizationAccountAccessRole role into the Network account. (The AWS Account ID can be determined in AWS Organizations)
  • Navigate to Service Quotas → AWS Services
  • Search for VPC and select when found
  • Click on Interface VPC endpoints per VPC (Quota Code: L-29B6F2EB) and request a quota increase to 90
  • Click on VPCs per Region (Quota Code: L-F678F1CE) and request a quota increase to 8
  • (It takes approximately 15-30 minutes for the requested quota increase to apply)
• (optional) Retry the failed Pipeline Stage if the quota increase was not completed in time.
• Await successful completion of AWSAccelerator-Pipeline pipeline.

AWS Config - Specify S3 Prefix for AWS Config logs

Is your feature request related to a problem? Please describe.
Right now, AWS Config logs are exported to the central logging bucket in the log archive account.

It is possible to store AWS Config logs with a custom S3 Object Prefix as part of the destination ARN. In the current implementation of LZA, AWS Config logs are not stored with a custom S3 Object prefix.

The LZA configuration bundles the AWS Config logs with other AWSLogs such as GuardDuty Logs. The Logs are collectively stored under AWSLogs/{AWS::AccountId}. See this screenshot where GuardDuty and Config logs are stored under the Account ID.

This limits the capability to use S3 event notifications to send notifications when AWS Config events are written to the S3 Bucket. We use S3 event notifications integration with SQS as part of a solution to do log processing and analytics on AWS Config logs. S3 event notifications do not support wildcards in prefix filters, so we cannot set up a single S3 event notification filter for all AWS Config Logs. Instead, we would have to create a new S3 event notification with a filter for every new Account ID in the landing zone, which adds additional complexity and has scaling issues.

Describe the feature you'd like
Allow the capability to specify S3 Prefix for awsConfig as part of the Delivery Channel settings in security-config.yml.

awsConfig:
  enableConfigurationRecorder: true
  enableDeliveryChannel: true

Suggestion: Tutorial implementation Landing Zone Accelerator

I would like to suggest a tutorial to the development of the Landing Zone Accelerator which enables the user to comprehend the architectonic decision made hands on by maybe even rebuilding the solution.

How would this contribute to the project?

• convey users security in administrating and adapting your work to companies needs while feeling save as one may understand the solution better if one rebuild it by oneself
• using the chance to teach AWS customers about applying AWS CDK in bigger project and how services integrate with each other.
• open up a bigger community of users and contributors on different skill levels

bug(doc): initial naming of extra OU created by Control Tower is called "Sandbox" while "Infrastructure" is expected

Describe the bug
When choosing Control Tower (CT) to initialise your environment it will propose to create an extra OU which by default is called "Sandbox". But the Installer is expecting it to be called "Infrastructure". It would be great to have it documented.

To Reproduce
Follow the LZA doc going the Control Tower way (which only mention "To set up AWS Control Tower, refer to Getting started with AWS Control Tower in the AWS Control Tower User Guide.").
Then deploy LZA Installer with CT enabled. It will fail with an error mentioning that "Infrastructure" OU does not exists and found "Sandbox" one instead.

Expected behavior
Properly documented setup for CT.

Please complete the following information about the solution:

• Version: v1.3.0