AWS Control Tower Landing Zone 4.0-க்கு மேம்படுத்துதல்

அறிமுகம்

நீங்கள் AWS Control Tower Landing Zone 3.x பயன்படுத்துகிறீர்கள் என்றால், உங்கள் AWS organization முழுவதும் governance controls பயன்படுத்தும் விதத்தில் அதிக flexibility பெற version 4.0-க்கு இப்போது மேம்படுத்தலாம். இந்த இடுகை முக்கிய கட்டமைப்பு மாற்றங்கள் வழியாக உங்களை வழிநடத்துகிறது, migration தாக்கத்தை புரிந்துகொள்ள உதவுகிறது, மற்றும் வெற்றிகரமான மேம்படுத்தலுக்கு படிப்படியான வழிகாட்டுதலை வழங்குகிறது.

AWS Control Tower-ன் முந்தைய பதிப்புகளில் (3.x மற்றும் அதற்கு முன்), landing zone-ஐ இயக்குவதற்கு கட்டாய service integrations-உடன் முன்வரையறுக்கப்பட்ட organizational structure-ஐ ஏற்றுக்கொள்ள வேண்டியிருந்தது. Landing Zone 4.0 இந்த கட்டுப்பாடுகளை நீக்குகிறது, பின்வருவனவற்றை அனுமதிக்கிறது:

• உங்கள் ஏற்கனவே உள்ள organization-ஐ மறுகட்டமைக்காமல் AWS Control Catalog-லிருந்து 1,200-க்கும் மேற்பட்ட controls-ஐ அணுகலாம்
• உங்கள் குறிப்பிட்ட தேவைகளின் அடிப்படையில் எந்த AWS சேவைகளை இயக்க வேண்டும் என்பதைத் தேர்வு செய்யும் சுதந்திரம். Service integrations இனி கட்டாயமில்லை, பின்வருவனவற்றை அனுமதிக்கிறது:
  • தேவைப்படும்போது மட்டும் detective controls-க்கு AWS Config இயக்கலாம்
  • ஏற்கனவே audit logging solutions இருந்தால் AWS CloudTrail-ஐ சுயமாக நிர்வகிக்கலாம்
  • உங்கள் identity management strategy-ன் அடிப்படையில் AWS IAM Identity Center-க்கு opt-in செய்யலாம்
  • உங்கள் backup தேவைகளின் படி AWS Backup integration-ஐ கட்டுப்படுத்தலாம்
• AWS Control Tower governance பயன்படுத்தும்போது உங்கள் சொந்த organizational unit (OU) hierarchy-ஐ வரையறுக்கலாம்
• Dedicated service integration accounts தேவையின்றி AWS Organizations integration மற்றும் controls மட்டுமே கொண்ட minimal landing zone டிப்ளாய் செய்யலாம்

இந்த controls-dedicated model ஏற்கனவே உள்ள landing zones கொண்ட enterprises-க்கு குறிப்பாக மதிப்புள்ளது, ஏனெனில் AWS Control Tower governance-ஐ படிப்படியாக ஏற்றுக்கொள்ள அனுமதிக்கிறது. முந்தைய பதிப்புகளில் தேவைப்பட்ட விரிவான மறுகட்டமைப்பு இல்லாமல் controls மற்றும் compliance monitoring பயன்படுத்தலாம்.

AWS Control Catalog-லிருந்து அதிகபட்ச மதிப்பைப் பெறுவதற்கான கூடுதல் வழிகாட்டுதலுக்கு, AWS ஆவணத்தைப் பார்க்கவும்: Search and discover governance controls with Control Catalog in AWS Control Tower.

நன்மைகள் மற்றும் கட்டமைப்பு மாற்றங்கள்

Landing Zone 4.0 அதிக flexibility மற்றும் operational efficiency வழங்கும் குறிப்பிடத்தக்க மேம்பாடுகளை அறிமுகப்படுத்துகிறது. பின்வரும் ஒப்பீடு version 3.x மற்றும் 4.0 இடையேயான முக்கிய வேறுபாடுகளை எடுத்துக்காட்டுகிறது:

Feature	Version 3.x	Version 4.0
Service integrations	Mandatory	Optional
AWS Config S3 bucket	Shared with AWS CloudTrail	Dedicated bucket
AWS Config aggregator	Organization + Account aggregators	Service-linked aggregator
Delegated administrator	None	Audit account for AWS Config
OU structure	Mandatory Security OU	Flexible, customer-defined
Manifest field	Required	Optional
Config baseline	Part of AWSControlTowerBaseline	Standalone ConfigBaseline
Drift notifications	Amazon SNS	Amazon EventBridge

முன்நிபந்தனைகள்

AWS Control Tower Landing Zone 4.0-க்கு மேம்படுத்துவதற்கு முன், பின்வரும் தேவைகளை பூர்த்தி செய்வதை உறுதிசெய்யவும்:

முக்கியம்: இந்த மேம்படுத்தல் மீள முடியாதது. AWS Control Tower முந்தைய landing zone version-க்கு downgrade செய்வதை ஆதரிக்காது. Landing Zone 4.0-க்கு மேம்படுத்தியவுடன், version 3.x-க்கு திரும்ப முடியாது. முதலில் non-production சூழலில் மேம்படுத்தலை சோதிக்கவும், தொடர்வதற்கு முன் விரிவான backups எடுக்கவும் வலுவாகப் பரிந்துரைக்கப்படுகிறது.

பொதுவான முன்நிபந்தனைகள்

1. Resolve organizational drift: It is strongly recommended to resolve all organizational drifts before upgrading to Landing Zone 4.0. You can check for drift in the AWS Control Tower console. Unresolved drift before the upgrade may persist after the upgrade and after OU re-registration, potentially requiring an AWS Support case to resolve.

2. Review AWS Control Tower prerequisites: Ensure your environment meets all standard AWS Control Tower prerequisites.

3. Review service integration dependencies: Understand the dependencies between baselines. If you plan to disable AWS Config integration in the future, you must also disable Security Roles, AWS IAM Identity Center, and AWS Backup integrations due to service dependencies.

4. Take comprehensive backups: Before upgrading, document and back up your current configuration:

   • Export organizational structure (OUs, accounts, account-to-OU mappings)
   • Screenshot or export current Landing Zone settings, Config aggregator views, and SNS topic configurations
   • Export Config rules and aggregator configurations
   • Export CloudFormation StackSet templates and parameters
   • Document current baseline versions per OU and control enablement status per OU
   • Save CfCT CloudFormation templates if applicable

# Export organizational units
aws organizations list-organizational-units-for-parent \
  --parent-id <ROOT_ID> > org_units_backup.json

# Export all accounts
aws organizations list-accounts > accounts_backup.json

# Export Config rules
aws configservice describe-config-rules > config_rules_backup.json

# Export Config aggregators
aws configservice describe-configuration-aggregators > aggregators_backup.json

# Export Control Tower IAM roles
aws iam get-role --role-name AWSControlTowerExecution > ct_exec_role_backup.json
aws iam get-role --role-name AWSControlTowerCloudTrailRole > ct_cloudtrail_role_backup.json

AWS CloudFormation StackSet prerequisites

Remove closed/suspended account stack instances

When AWS accounts are closed, their AWS CloudFormation stack instances in the management account's AWSControlTowerBP-* StackSets are not automatically removed. During the upgrade, AWS Control Tower attempts to update these StackSets and fails because it cannot assume AWSControlTowerExecution in closed accounts. This is a documented limitation.

In organizations that have closed accounts over time, this can cause the upgrade to stall while each StackSet operation times out sequentially. To prevent this, run the following pre-flight check and remediation before upgrading:

Pre-flight check:

# Identify closed/suspended accounts
CLOSED=$(aws organizations list-accounts \
  --query "Accounts[?Status!='ACTIVE'].Id" --output text)

# Check for orphaned stack instances in AWS Control Tower StackSets
for SS in $(aws cloudformation list-stack-sets --status ACTIVE \
  --query "Summaries[?starts_with(StackSetName,'AWSControlTowerBP-')].StackSetName" \
  --output text); do
  for ACCT in $CLOSED; do
    COUNT=$(aws cloudformation list-stack-instances --stack-set-name "$SS" \
      --query "length(Summaries[?Account=='${ACCT}'])" --output text)
    [ "$COUNT" -gt 0 ] && echo "BLOCKER: $SS has $COUNT instances for closed account $ACCT"
  done
done

Suggested Remediation:

# For each StackSet flagged as BLOCKER in the pre-flight check above,
# remove the orphaned instances for the closed account
aws cloudformation delete-stack-instances \
  --stack-set-name "<stackset-name>" \
  --accounts '["<closed-account-id>"]' \
  --regions '["us-east-1","us-west-2"]' \
  --retain-stacks \
  --no-cli-pager

Important: The --retain-stacks flag is required. Without it, AWS CloudFormation attempts to assume AWSControlTowerExecution in the closed account to delete the stack, which will fail.

Verify no termination protection on AWS Control Tower baseline stacks

The v4.0 upgrade deletes or replaces certain AWS CloudFormation stacks in member accounts (particularly AWS Config-related baselines). If those stacks have termination protection enabled, StackSet operations fail and the upgrade stalls.

AWS Control Tower does not enable termination protection on its baseline stacks — it uses SCPs (mandatory preventive controls) instead. However, termination protection may have been enabled outside AWS Control Tower, such as:

• AWS Security Hub CSPM auto-remediation — CloudFormation.3 recommends termination protection on all stacks. Auto-remediation enables it on every stack, including AWS Control Tower-managed ones.
• AWS Landing Zone Accelerator, which enables termination protection on its provisioned stacks by default.

Pre-flight check (run from management account):

# Assume role into a member account
CREDS=$(aws sts assume-role \
  --role-arn "arn:aws:iam::<member-account-id>:role/AWSControlTowerExecution" \
  --role-session-name "tp-check" --query Credentials --output json)

export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r .AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r .SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r .SessionToken)

# Check AWS Control Tower baseline stacks for termination protection
aws cloudformation describe-stacks --region <region> \
  --query "Stacks[?starts_with(StackName,'StackSet-AWSControlTowerBP-')].\
  [StackName,EnableTerminationProtection]" --output table

Suggested Remediation:

aws cloudformation update-termination-protection \
  --no-enable-termination-protection \
  --stack-name "<stack-name>" --region <region>

AWS CloudTrail prerequisites

If you are upgrading via API and have AWS CloudTrail integration enabled:

1. Update IAM role policy: Detach the existing inline policy from AWSControlTowerCloudTrailRole and attach the new managed policy AWSControlTowerCloudTrailRolePolicy.

# Detach inline policy
aws iam delete-role-policy \
  --role-name AWSControlTowerCloudTrailRole \
  --policy-name <inline-policy-name>

# Attach new managed policy
aws iam attach-role-policy \
  --role-name AWSControlTowerCloudTrailRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSControlTowerCloudTrailRolePolicy

2. Understand S3 replication configurations on S3 bucket: The mandatory SCP (CTS3PV8) to protect the Control Tower managed S3 bucket for CloudTrail now blocks the s3:PutReplicationConfiguration action. Since LZ 4.0 continues using the existing CloudTrail bucket, any current replication configurations will continue to function normally. However, you will be unable to modify or recreate replication rules after the upgrade. If you need to modify replication settings post-upgrade, the workaround is to assume the AWSControlTowerExecution role (which is exempted from the SCP) to update the replication rule, though this should be used cautiously as it bypasses Control Tower's protective guardrails.

AWS Config prerequisites

1. Understand data storage changes: Be aware that AWS Config data will be stored in a new dedicated S3 bucket after the upgrade. Historical data will remain in the original shared bucket and will not be migrated automatically. New Config data may take up to 24 hours to appear in the new bucket after the upgrade completes.

2. Identify dependent workflows: Document all workflows, scripts, and tools that access AWS Config data directly from S3 buckets, including:

   • Log aggregation tools (Splunk, Datadog, etc.)
   • SIEM integrations
   • Custom dashboards (tag compliance, patch compliance, etc.)
   • Automated compliance reporting tools

   Identify the owners of each dependency and coordinate cutover timing before upgrading.

3. Understand S3 replication configurations on S3 bucket: The mandatory SCP (CTS3PV7) to protect the Control Tower managed S3 bucket for Config now blocks the s3:PutReplicationConfiguration action. As a result, you will be unable to configure S3 replication on this bucket after the upgrade. If you require replication for the new Config bucket, the workaround is to assume the AWSControlTowerExecution role (which is exempted from the SCP) to create the replication rule, though this should be used cautiously as it bypasses Control Tower's protective guardrails.

4. Inventory custom AWS Config advanced queries: If you have custom AWS Config advanced queries created in the management account against the organization-level aggregator, these will need to be recreated in the audit account after the upgrade. The Config aggregator moves from the management account to the audit account, so cross-account queries from the management account will no longer work. Document all custom queries before upgrading.

5. Review SNS topic subscriptions: Review all subscriptions on AWS Control Tower SNS topics, especially HTTPS endpoints for third-party integrations (ServiceNow, PagerDuty, etc.). Verify these subscriptions will continue to receive notifications post-upgrade.

6. Identify accounts with pre-existing Config resources: If you have enrolled accounts with pre-existing AWS Config delivery channels not created by Control Tower, these delivery channels will not be automatically updated to point to the new Config S3 bucket. Identify these accounts before upgrading. See AWS documentation on Enroll accounts that have existing AWS Config resources.

Upgrade process

This section provides step-by-step guidance for upgrading your AWS Control Tower landing zone from version 3.x to version 4.0.

Step 1: Prepare for the upgrade

1. Access the AWS Control Tower console in your management account in your home region.

2. Review the landing zone version: Navigate to the Landing Zone settings page and verify your current version.

3. Check for drift: On the Landing Zone settings page, verify that your landing zone shows "No drift detected". If drift is detected, resolve it before proceeding. Accounts that are already in a drifted state before the upgrade may remain drifted after the upgrade and after OU re-registration, potentially requiring an AWS Support case to resolve.

4. Review enabled service integrations: Note which service integrations are currently enabled (AWS Config, AWS CloudTrail, AWS IAM Identity Center, AWS Backup).

Step 2: Initiate the upgrade

You can upgrade to Landing Zone 4.0 using either the AWS Control Tower console or the AWS CLI/API.

Upgrade via console

1. Navigate to Landing Zone settings in the AWS Control Tower console.

2. Select the Landing Zone version 4.0 and Click "Update" button to begin the upgrade process.

3. On the next page, confirm Landing zone version 4.0 is selected and optionally configure automatic account enrollment. Please note that after upgrade, it is not possible to go back to the previous version. Click Next.

4. Review your Governed Regions and Region deny control settings, then click Next

5. This is the page where you can update "Service Integrations", then click Next

5. Review the Landing Zone settings and then confirm the upgrade: Click "Update landing zone" to begin the upgrade process.

6. Monitor the upgrade progress: The upgrade process typically takes 30-60 minutes. You can monitor progress in the AWS Control Tower console.

Step 3: Verify the upgrade completion

1. Check landing zone status: In the AWS Control Tower console, verify that the landing zone status shows "Active" and the version shows "4.0".

   

2. Review service integrations: Confirm that all previously enabled service integrations remain enabled and functional.

3. Check for any upgrade errors: Review the AWS Control Tower console for any error messages or warnings.

Step 4: Verify new Config baseline

• New ConfigBaseline baseline: There is now a separate ConfigBaseline at the OU level for detective controls support without requiring the comprehensive AWSControlTowerBaseline. See list of baseline types at the OU level for more information. For existing customers that are using the default landing zone, all service integrations are now optional, with the caveat of dependency requirements outlined in Key changes.

Step 5: Verify AWS Config changes

After upgrading to Landing Zone 4.0, AWS Config undergoes significant architectural changes. Follow these verification steps:

Verify delegated administrator registration

Confirm that the Audit account is registered as the AWS Config delegated administrator:

# Check delegated administrator for AWS Config
aws organizations list-delegated-administrators \
  --service-principal config.amazonaws.com \
  --region <your-home-region>

Expected output should show your Audit account ID.

Verify Service-Linked Config Aggregator

Confirm that the Service-Linked Config Aggregator (SLCA) exists in your Audit account. The new aggregator is named aws-controltower-ConfigAggregatorForOrganizations and is deployed in the audit account (as opposed to the legacy aggregator of the same name which resided in the management account):

# Describe configuration aggregators in Audit account
aws configservice describe-configuration-aggregators \
  --region <your-home-region>

You should see the aggregator aws-controltower-ConfigAggregatorForOrganizations in the audit account. Note that while this shares the same name as the legacy aggregator that was in the management account, it is a different resource deployed in a different account.

Verify old aggregators are removed

Confirm that the legacy aggregators have been removed:

1. In the management account, verify that aws-controltower-ConfigAggregatorForOrganizations no longer exists
2. In the Audit account, verify that aws-controltower-GuardRailsComplianceAggregator no longer exists

# In the management account - check for old aggregator (should return empty or not found)
aws configservice describe-configuration-aggregators \
  --region <your-home-region>

Review custom Config aggregators If you have custom AWS Config aggregators outside AWS Control Tower naming conventions, verify they continue to function. AWS Control Tower only manages aggregators with specific naming patterns. Custom aggregators are not affected and can run in parallel with the new SLCA.

Verify custom Config query migration

If you had custom AWS Config advanced queries in the management account that ran against the old organization-level aggregator, these queries can now only run locally in the management account (not cross-account). To run cross-account queries, recreate them in the audit account where the new aws-controltower-ConfigAggregatorForOrganizations aggregator resides.

# In the Audit account - verify the new aggregator shows all member accounts
aws configservice describe-configuration-aggregator-sources-status \
  --configuration-aggregator-name aws-controltower-ConfigAggregatorForOrganizations \
  --region <your-home-region>

Verify new S3 bucket creation

Confirm that the new dedicated AWS Config S3 bucket exists in the Audit account:

# List S3 buckets in Audit account
aws s3 ls | grep aws-controltower-config-logs

Expected bucket naming pattern: aws-controltower-config-logs-<AUDIT_ACCOUNT>-<REGION_STRING>-<SUFFIX_STRING>

Note: Config data from member accounts may take up to 24 hours to appear in the new S3 bucket after the upgrade. Dashboards and compliance tools reading from S3 will show stale data during this window. For near-real-time data access, use the Config Aggregator API.

Verify CloudTrail bucket unchanged

Confirm that AWS CloudTrail continues using the existing bucket in the Log Archive account:

# List S3 buckets in Log Archive account
aws s3 ls | grep aws-controltower-logs

Expected bucket naming pattern: aws-controltower-logs-<LOGGING_ACCOUNT>-<HOME_REGION>

Test data flow by checking for recent timestamps:

# Check recent CloudTrail logs
aws s3 ls s3://aws-controltower-logs-<LOGGING_ACCOUNT>-<HOME_REGION>/ --recursive | tail -20

Verify Config delivery channels

Check that AWS Config delivery channels in all enrolled accounts point to the new S3 bucket:

# Describe delivery channels
aws configservice describe-delivery-channels \
  --region <your-home-region>

The s3BucketName should reference the new aws-controltower-config-logs-* bucket.

If you have enrolled accounts with pre-existing Config delivery channels not created by Control Tower, you must manually update them to point to the new bucket:

# Update pre-existing delivery channels to new bucket
aws configservice put-delivery-channel \
  --delivery-channel name=<CHANNEL_NAME>,s3BucketName=aws-controltower-config-logs-<AUDIT_ACCOUNT>-<REGION>-<SUFFIX>

Verify SLCA data aggregation

Allow 24-48 hours for full data aggregation after the upgrade completes. Then verify that the new Service-Linked Config Aggregator can aggregate data from all AWS Config recorders in the organization, including non-AWS Control Tower managed accounts:

# Get aggregated compliance summary
aws configservice get-aggregate-compliance-details-by-config-rule \
  --configuration-aggregator-name aws-controltower-ConfigAggregatorForOrganizations \
  --config-rule-name <any-config-rule-name> \
  --account-id <test-account-id> \
  --aws-region <region> \
  --region <your-home-region>

Verify downstream dashboards and tools

After Config data begins flowing to the new bucket (up to 24 hours), verify that all dependent dashboards and tools are receiving fresh data:

• Tag compliance dashboards
• Patch compliance dashboards
• SIEM integrations
• Any custom compliance reporting tools

Dashboards that still reference the old aws-controltower-logs-* bucket will show stale data from before the upgrade. Update them to point to the new aws-controltower-config-logs-* bucket, or preferably refactor them to use the Config Aggregator API.

Step 6: Verify AWS CloudTrail changes

AWS CloudTrail undergoes minimal changes in Landing Zone 4.0, but you should verify the following:

Verify IAM role policy update

If you upgraded via API, confirm that AWSControlTowerCloudTrailRole uses the new managed policy:

# List attached policies for CloudTrail role
aws iam list-attached-role-policies \
  --role-name AWSControlTowerCloudTrailRole

Expected output should include AWSControlTowerCloudTrailRolePolicy.

Verify CloudTrail logging continues

Confirm that the organization trail continues logging:

# Describe trails
aws cloudtrail describe-trails \
  --region <your-home-region>

Verify that the trail status is active and logging to the expected S3 bucket.

Step 7: Verify SNS topic changes

Landing Zone 4.0 introduces dedicated SNS topics for each service integration. Verify the SNS topics in the Audit account:

# List SNS topics in Audit account
aws sns list-topics --region <your-home-region>

Expected SNS topics in the Audit account:

• aws-controltower-AllConfigNotifications - Still receives AWS Config events
• aws-controltower-AggregateSecurityNotifications - Still exists but only for non-drift notifications
• aws-controltower-AggregateConfigurationNotifications - Continues to work for compliance notifications

For customers upgrading with AWSControlTowerBaseline enabled, the existing SNS topics and their subscriptions in the audit account are preserved and continue working unchanged. The primary change is for customers who later disable AWSControlTowerBaseline — in that case, drift notifications move from Amazon SNS to Amazon EventBridge in the management account.

Note: Some existing SNS topics (such as aws-controltower-AggregateSecurityNotifications) may have no active subscribers. This is expected and mirrors pre-upgrade behavior — these topics act as placeholders and do not indicate a problem.

Review all SNS topic subscriptions, especially HTTPS endpoints for third-party integrations (ServiceNow, PagerDuty, etc.), to confirm they continue to receive notifications post-upgrade.

Step 8: Verify control changes

With AWS Control Tower Landing Zone 4.0, there have been several changes to mandatory controls. To verify the changes follow the documentation Changes in Landing Zone 4.0 controls

Re-register organizational units

After upgrading to Landing Zone 4.0, you should re-register your OUs to apply the new baseline versions to member accounts. This is an incremental process that can be done in phases.

Understanding OU re-registration

When AWS Control Tower is updated to version 4.0, OU re-registration becomes necessary due to new baseline dependencies Structure. Please see the documentation on the [[compatibility of baselines with AWS Control Tower landing zone versions.]]

When you re-register an OU:

• AWS Control Tower updates all member accounts within that OU with the new baseline version
• Control Tower-managed SCPs are temporarily inactive while being refreshed (typically minutes)
• Custom SCPs remain enforced and are not impacted
• Workloads continue running without interruption
• You can process up to 1,000 accounts per OU in a single batch

Important: Re-registering a parent OU does not cascade to child OUs. Each OU in the hierarchy must be re-registered individually. Plan to re-register each child OU separately, starting from top-level OUs and working down. This can add significant time to the rollout if you have a deep OU hierarchy.

Phased rollout strategy

Recommended approach:

1. Hierarchical enablement: Start with top-level OUs before proceeding to child OUs. Remember that each child OU must be re-registered separately — it does not cascade.
2. Mixed baseline versions: Acceptable during transition periods (hybrid 3.x and 4.0)
3. Batch processing: Use "Re-register OU" to update all accounts within an OU (up to 1,000 accounts per batch)
4. Monitor each OU: Verify successful re-registration before proceeding to the next OU

Re-register an OU via console

1. Navigate to the OU page in the AWS Control Tower console
2. Select the OU you want to re-register
3. Click Re-register OU
4. Review the accounts that will be updated
5. Click Re-register OU to confirm
6. Monitor the re-registration progress in the console

Note: After migration, you may need to manually re-register certain OUs to deploy new baseline versions. This is expected behavior and ensures you have control over when baseline updates are applied.

Troubleshooting: If an account was already in a drifted state before the upgrade, it may remain drifted after re-registration. In this case, open a support case with AWS Support in the affected account to investigate and resolve the persistent drift.

Additional resources

• AWS Control Tower User Guide
• AWS Control Tower API Reference
• AWS Control Catalog
• AWS Config User Guide
• AWS CloudTrail User Guide
• AWS Organizations User Guide