AWS Landing Zone Accelerator - Part 3: Configuring Global Settings for Your Organization

2025-02-05 13 min read Walkthroughs Adam Divall

Welcome back to my deep dive into the AWS Landing Zone Accelerator (LZA)!

We’ve made some good progress so far. In Part 1, we introduced the LZA and explained how it can help you build a well-managed AWS environment. In Part 2, we got hands-on and learned how to set up your AWS Organization and create new accounts.

Now, in Part 3, we’re going to take a broader perspective and explore the global settings that the LZA provides. These settings let you establish standardised configurations across your entire AWS organization, ensuring consistency and simplifying management.

Configuring AWS Control Tower Settings

AWS Control Tower is a service that simplifies the setup and governance of a multi-account AWS environment. It helps organizations establish a well-architected, secure, and compliant AWS environment by automating the creation of a “landing zone” – a pre-configured, multi-account setup based on AWS best practices.

Automated Landing Zone Setup: Control Tower automates the creation of essential AWS accounts (management, log archive, audit) and configures them with foundational services like AWS Organizations, AWS Config, and AWS CloudTrail. This provides a solid starting point for your AWS environment.
Controls: It implements pre-configured “controls” – preventive and detective controls that help enforce security, compliance, and operational best practices. These controls can restrict certain actions (preventive) or alert you to non-compliant configurations (detective).
Account Factory: Control Tower provides an “Account Factory” that allows you to easily provision new AWS accounts with consistent configurations and pre-applied guardrails. This ensures that all accounts within your organization adhere to your established standards.
Centralised Governance: It offers a centralised dashboard that provides visibility into the compliance status of your accounts and resources, making it easier to manage and govern your AWS environment.

Update the LZA configuration:

Open the global-config.yaml file in your local copy of the aws-accelerator-config repository.
Find the controlTower section and make sure it looks something like this:

controlTower:
  enable: true  # Confirms you're using Control Tower
  landingZone:
    version: '3.3'  # Specify your Control Tower version
    logging:
      loggingBucketRetentionDays: 365  # How long to keep logs (in days)
      accessLoggingBucketRetentionDays: 365  # How long to keep access logs (in days)
      organizationTrail: true  # Turns on CloudTrail logging
    security:
      enableIdentityCenterAccess: true  # Enables IAM Identity Center
  controls:
    controlTowerControls:
      - identifier: AWS-GR_ROOT_ACCOUNT_MFA_ENABLED  # Example Control Tower control
        enable: true   # Enable the control
        deploymentTargets:
          organizationalUnits:
            - Root   # Apply the control to the whole organization
homeRegion: eu-west-1   # Your main AWS region
enabledRegions:            # All the AWS regions you want to use
  - eu-west-1
managementAccountAccessRole: AWSControlTowerExecution  # Name of the management account role

enable: Confirms that you’re using AWS Control Tower.
version: Specifies the version of Control Tower you’re using.
loggingBucketRetentionDays: How long to keep logs (in days).
accessLoggingBucketRetentionDays: How long to keep access logs (in days).
organizationTrail: Turns on CloudTrail logging, which keeps a record of activity in your AWS account.
enableIdentityCenterAccess: Enables IAM Identity Center, which helps you manage who has access to your AWS resources.
controls: Control Tower offers a set of guardrails (preventive, detective and proactive) to enforce security and compliance best practices. You can customise which guardrails are active in your Landing Zone. I’ve enabled AWS-GR_ROOT_ACCOUNT_MFA_ENABLED to require MFA for the root user, but you can explore and enable other relevant guardrails based on your needs.
homeRegion: Your primary AWS region (e.g., eu-west-1 for Ireland).
enabledRegions: A list of all the AWS regions you want to be able to use.
managementAccountAccessRole: The name of the IAM role used to access the management account.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the Control Tower Configuration"
git push

Logging

Logging is the process of recording events and actions that occur within a system, application, or network. Think of it as a detailed diary of what’s happening behind the scenes. These logs contain valuable information, such as timestamps, user actions, errors, warnings, and system events.

Logging is absolutely essential for a multitude of reasons:

Troubleshooting: When something goes wrong, logs are your best friend. They provide a trail of events leading up to the issue, helping you pinpoint the root cause and fix it quickly.
Debugging: During development, logs help developers understand the flow of their code and identify bugs. They can track variable values, function calls, and other relevant information.
Monitoring: Logs can be used to monitor the performance and health of systems and applications. By analyzing log data, you can identify performance bottlenecks, detect anomalies, and proactively address potential problems.
Security: Logs play a crucial role in security. They record user activity, login attempts, and other security-related events, which can be used to detect and investigate security breaches.
Auditing: Many regulations require organizations to maintain audit trails of system activity. Logs provide this audit trail, demonstrating compliance and accountability.
Analysis: Logs can be analyzed to gain insights into user behavior, system usage patterns, and other valuable information that can be used to improve pe

Update the LZA configuration:

Open the global-config.yaml file in your local copy of the aws-accelerator-config repository.
Find the logging section and make sure it looks something like this:

logging:
  account: LogArchive
  centralizedLoggingRegion: eu-west-1
  cloudtrail:
    enable: false
    organizationTrail: false
  centralLogBucket:
    applyAcceleratorManagedPolicy: true
    lifecycleRules:
      - enabled: true
        abortIncompleteMultipartUpload: 7
        expiration: 365
        expiredObjectDeleteMarker: false
        noncurrentVersionExpiration: 365
  accessLogBucket:
    enable: true
    deploymentTargets:
      organizationalUnits:
        - Root
    applyAcceleratorManagedPolicy: true
    lifecycleRules:
      - enabled: true
        abortIncompleteMultipartUpload: 7
        expiration: 365
        expiredObjectDeleteMarker: false
        noncurrentVersionExpiration: 365
  cloudwatchLogs:
    enable: true
    encryption:
      useCMK: true
      deploymentTargets:
        organizationalUnits:
          - Root
    dataProtection:
      managedDataIdentifiers:
        categories:
          - Credentials
      deploymentTargets:
        organizationalUnits:
          - Root
    dynamicPartitioning: dynamic-partitioning/log-filters.json
  elbLogBucket:
    applyAcceleratorManagedPolicy: true
    lifecycleRules:
      - enabled: true
        abortIncompleteMultipartUpload: 7
        expiration: 365
        expiredObjectDeleteMarker: false
        noncurrentVersionExpiration: 365
  sessionManager:
    sendToCloudWatchLogs: true
    sendToS3: true
    lifecycleRules:
      - enabled: true
        abortIncompleteMultipartUpload: 7
        expiration: 365
        expiredObjectDeleteMarker: false
        noncurrentVersionExpiration: 365
    attachPolicyToIamRoles:
      - EC2-Default-SSM-AD-Role

account: The name of the account where your logs will be stored.
centralizedLoggingRegion: The AWS region where your central logging account is located.
cloudtrail: We don’t need to configure this here because we’re using Control Tower, which handles CloudTrail for us.
centralLogBucket: Settings for your central log bucket, including a lifecycle policy to manage log retention.
accessLogBucket: Settings for the bucket that stores access logs.
cloudwatchLogs: Settings for CloudWatch Logs, including encryption and data protection features.
elbLogBucket: Settings for the bucket that stores logs from Elastic Load Balancers (ELBs).
sessionManager: Settings for AWS Session Manager logs, which allow you to connect to your EC2 instances securely.

For instance, the above configuration centralises logs in the Log Archive account in eu-west-1, using lifecycle policies for log retention in S3 buckets, enabling CloudWatch Logs encryption with data protection to mask credentials, and setting up dynamic partitioning for CloudWatch Logs. It also manages access logs, ELB logs, and Session Manager logs ensuring comprehensive logging across the AWS organization.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the Logging Configuration"
git push

Configuring S3 Global Settings

The LZA allows you to configure S3 encryption settings across your organization. This is crucial for protecting sensitive data at rest and meeting compliance requirements.

Update the LZA configuration:

Open the global-config.yaml file in your local copy of the aws-accelerator-config repository.
Configure the encryption section under s3 to enable encryption:

encryption:
   createCMK: true
   deploymentTargets:
     organizationalUnits:
       - Root

This configuration creates a customer-managed KMS key (CMK) that will be used to encrypt S3 buckets across your organization. This enhances the security of your data stored in S3.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the Encryption Configuration"
git push

Notifications

In the context of the AWS Landing Zone Accelerator (LZA), notifications refer to automated alerts sent to administrators or other stakeholders about events related to the LZA’s operation and the AWS environment it manages. These notifications are typically delivered via email, but other notification channels can be integrated.

Deployment Status: Notifications about the progress and completion (or failure) of the LZA deployment itself. This keeps administrators informed about the status of the landing zone setup.
Account Creation/Modification: Alerts about the creation of new AWS accounts through the LZA’s Account Factory or modifications to existing accounts. This provides visibility into account management activities.
Control Violations: Notifications triggered when resources or configurations deviate from the controls defined by the LZA. For example, if someone attempts to create an S3 bucket without encryption, a notification could be sent.
Security Events: Alerts about potential security issues, such as unauthorized access attempts, suspicious activity, or security group changes. This helps in quick incident response.
Compliance Events: Notifications related to compliance checks and audits. For example, alerts about resources that are not compliant with tagging policies or other compliance requirements.
Operational Events: Notifications about operational events, such as changes to network configurations, updates to critical systems, or resource usage thresholds being reached. This helps with proactive management.

Update the LZA configuration:

Open the global-config.yaml file.
Configure the snsTopics section under sns to define your SNS topics:

snsTopics:
  deploymentTargets:
    organizationalUnits:
      - Root
  topics:
    - name: Security
      emailAddresses:
        - infosec@example.com

This example creates an SNS topic called “Security” that sends notifications to the email address infosec@example.com. You can customise this with your own topic names and email addresses.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the SNS Configuration"
git push

Configuring CloudWatch Log Group Retention

CloudWatch Log Group Retention Periods define how long CloudWatch Logs retains log events. You can configure a retention period for each log group, specifying how many days, weeks, months, or years you want to keep the logs. Once the retention period expires, the log events are automatically deleted.

They are crucial for several reasons, particularly within an LZA environment:

Cost Management: Storing logs indefinitely can become expensive. Retention periods allow you to control log storage costs by automatically deleting older logs that are no longer needed. This is especially important in an LZA, where you might have many accounts generating a large volume of logs.
Compliance: Certain compliance regulations may require you to retain logs for a specific period (e.g., for auditing purposes). Retention periods help you meet these regulatory requirements by ensuring that logs are kept for the necessary duration. Conversely, some regulations might limit how long you can keep certain types of data. Retention policies help with this as well.
Performance: Having excessively large log groups can impact the performance of log queries. By setting appropriate retention periods, you can keep log groups at a manageable size, improving query performance.
Security: Retention policies can help manage the risk associated with storing sensitive data in logs. By deleting logs after a certain period, you can reduce the potential impact of a data breach.
Log Lifecycle Management: In an LZA, where you’re dealing with multiple accounts and diverse workloads, log lifecycle management is essential. Retention periods provide a consistent way to manage the lifecycle of logs across the entire environment. Different log groups can have different retention requirements based on the type of data they contain. For example, security logs might need to be kept longer than application debug logs.

Update the LZA configuration:

Open the global-config.yaml file in your local copy of the aws-accelerator-config repository.
Configure the cloudwatchLogRetention section under logging to define your log group retention settings:

cloudwatchLogRetentionInDays: 30

This configuration will configure all CloudWatch Log Group to 30 days in all AWS accounts under the management of the LZA. By setting up these global settings, you create consistent configurations for logging retention across your AWS organization. This makes managing your environment easier and helps improve security and compliance.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the CloudWatch Logs Retention"
git push

Configuring Vaults for AWS Backup

In AWS Backup, a Backup Vault is a container for storing your backups (called recovery points). Think of it like a secure, organszed storage location specifically for your backups. Each backup vault has its own set of access policies that control who can create, copy, restore, and delete the backups within it.

They are crucial for several reasons:

Organization and Isolation: Backup vaults provide a way to organize your backups. You can create different vaults for different types of backups (e.g., production data, development data), different applications, or different compliance requirements. This makes it easier to manage and find the backups you need. Vaults also provide logical isolation. You can control access to each vault independently, preventing unauthorized access to sensitive backups.
Access Control: Backup vaults allow you to implement granular access control. You can use IAM policies to define who has permission to perform specific actions on the backups within a vault. This ensures that only authorized users can create, restore, or delete backups. You can, for example, grant restore-only access to certain users.
Encryption: By default, backups stored in a vault are encrypted at rest using AWS KMS. This adds an extra layer of security to your backups, protecting them from unauthorized access even if the underlying storage is compromised. You can even use customer-managed KMS keys for more control.
Lifecycle Management: While not directly tied to the vault itself, you can combine Backup Vaults with lifecycle policies to automate the transition of backups to different storage tiers (like Glacier) or to delete backups after a certain period. This helps optimize storage costs and meet compliance requirements.
Disaster Recovery: Backup vaults can be replicated to other AWS regions. This allows you to create copies of your backups in a different location for disaster recovery purposes. If your primary region becomes unavailable, you can restore your backups from the replica vault in the other region.
Compliance: Backup vaults can help you meet various compliance requirements by providing a secure and auditable way to store and manage your backups. The access control and encryption features are particularly important for compliance.

Update the LZA configuration:

Open the global-config.yaml file in your local copy of the aws-accelerator-config repository.
Configure the vaults section under backup to define your backup vaults:

backup:
  vaults:
    - name: LocalBackUpVaultGold
      deploymentTargets:
        organizationalUnits:
          - Root
    - name: LocalBackUpVaultSilver
      deploymentTargets:
        organizationalUnits:
          - Root
    - name: LocalBackUpVaultBronze
      deploymentTargets:
        organizationalUnits:
          - Root
    - name: LocalBackUpVaultPlatinum
      deploymentTargets:
        organizationalUnits:
          - Root
    - name: CentralizedBackUpVaultGold
      deploymentTargets:
        accounts:
          - Backup
    - name: CentralizedBackUpVaultSilver
      deploymentTargets:
        accounts:
          - Backup
    - name: CentralizedBackUpVaultBronze
      deploymentTargets:
        accounts:
          - Backup
    - name: CentralizedBackUpVaultPlatinum
      deploymentTargets:
        accounts:
          - Backup

This configuration defines several backup vaults, categorized by data classification (“Gold”, “Silver”, “Bronze”, “Platinum”). It creates local vaults in each account within the organization and centralised vaults in a dedicated “Backup” account. This approach provides both local and centralised backup capabilities, allowing for flexible and secure data protection. These vaults link to the Backup Policies that we created in the previous post.

Save your changes:

Use these commands to save your changes and update the LZA configuration:

git add .
git commit -m "Updating the Backup Vaults Configuration"
git push

Wrapping up

That’s a wrap for this part of our LZA adventure! We’ve covered a lot, setting up global configurations for Control Tower, logging, S3 encryption, SNS notifications, and backup vaults. These are the building blocks for a well-organized, secure, and standardized AWS environment. By standardizing these settings, you can ensure consistent security, efficient log management, and reliable backups across your AWS accounts.

But we’re not done yet! There’s still much more to explore with the LZA. In the next post, we’ll dive into network configuration, setting up VPCs, subnets, and other networking components. After that, we’ll tackle identity and access management, security configurations, and even some customization options.

Stay tuned for more practical guides and insights on mastering the LZA!