Trusted Access | AWS CDK Landing Zone

src/config/trusted-access.ts declares which AWS services get trusted access to your AWS Organization. Trusted access lets an AWS service read your organization structure and operate across member accounts on your behalf, and it is the prerequisite for org-wide features like the organization trail, GuardDuty, Security Hub, and StackSets. The organization phase (LandingZoneOrganizationStack) reads this file and enables trusted access for each listed service before anything that depends on it runs.

The file exports a single trustedAccess object. Keep the list limited to the services the landing zone actually configures. Enabling trusted access for a service you do not use adds a service-linked integration you then have to remember to clean up.

Options

trustedAccess is a TrustedAccessProps. In the starter it sets enabled and an explicit services list, but the type also supports adjusting the built-in defaults without copying them.

Field	Type	Required	Description
`enabled`	`boolean`	No	Whether the landing zone manages trusted service access at all. Default `true`. Set `false` to stop managing it entirely.
`services`	`string[]`	No	Exact list of service principals to enable. When set, it is the complete list. Omit it to start from the built-in defaults.
`additionalServices`	`string[]`	No	Service principals to add on top of the default list. Use this instead of copying the defaults when you only need to add one.
`excludeServices`	`string[]`	No	Service principals to remove from the resolved list.

Use the TrustedAccessAwsService constants for the principal values so they stay typo-resistant and autocomplete-friendly (for example TrustedAccessAwsService.SECURITY_HUB instead of the raw securityhub.amazonaws.com). The constants track the services in the AWS Organizations integrated-services table that support trusted access.

Example

The starter ships an explicit services list so what is enabled is visible at a glance rather than hidden behind a default:

export const trustedAccess = {
  enabled: true,
  services: [
    TrustedAccessAwsService.ACCOUNT,
    TrustedAccessAwsService.BACKUP,
    TrustedAccessAwsService.BILLING_COST_MANAGEMENT,
    TrustedAccessAwsService.CLOUDTRAIL,
    TrustedAccessAwsService.CONFIG_MULTI_ACCOUNT_SETUP,
    TrustedAccessAwsService.CONFIG,
    TrustedAccessAwsService.COST_OPTIMIZATION_HUB,
    TrustedAccessAwsService.GUARDDUTY,
    TrustedAccessAwsService.HEALTH,
    TrustedAccessAwsService.IAM,
    TrustedAccessAwsService.INSPECTOR,
    TrustedAccessAwsService.MACIE,
    TrustedAccessAwsService.GUARDDUTY_MALWARE_PROTECTION,
    TrustedAccessAwsService.CLOUDFORMATION_STACKSETS_MEMBER,
    TrustedAccessAwsService.USER_NOTIFICATIONS,
    TrustedAccessAwsService.RAM,
    TrustedAccessAwsService.TRUSTED_ADVISOR,
    TrustedAccessAwsService.RESOURCE_EXPLORER,
    TrustedAccessAwsService.SECURITY_HUB,
    TrustedAccessAwsService.SERVICE_QUOTAS,
    TrustedAccessAwsService.SSM,
    TrustedAccessAwsService.TAG_POLICIES,
  ],
} satisfies TrustedAccessProps;

To add a service without restating the whole list, drop the explicit services array and use additionalServices:

export const trustedAccess = {
  enabled: true,
  additionalServices: [TrustedAccessAwsService.FIREWALL_MANAGER],
} satisfies TrustedAccessProps;

How it's used

LandingZoneOrganizationStack passes trustedAccess into OrganizationConstruct, which enables trusted service access for each principal at the organization root. Because it runs in the organization phase, trusted access is in place before the landing-zone phase deploys any StackSet or before delegated-admins.ts registers a delegated administrator: AWS requires a service's trusted access to be enabled before you can delegate its administration.

Keep this file aligned with delegated-admins.ts. Every service you delegate needs matching trusted access here. The default config enables IAM trusted access and delegates IAM to the security account so it can manage centralized root access after the Provision Management StackSet enables it from the management account.

Things to know

AWS IAM Identity Center (TrustedAccessAwsService.SSO) is intentionally left out of the default list. If Identity Center was enabled outside this landing zone, keeping it out means a stack deletion never disables its trusted access and takes your SSO setup down with it. Add it only if you want the landing zone to own that integration.
Removing a service disables its trusted access on the next deploy. Disabling trusted access for a security service has org-wide side effects, so treat removals the same way you treat removing a delegated administrator: confirm nothing still depends on the integration first.
Keep the list to what you use. The comment in the file spells out every service enabled by default; add to it only when you adopt a new AWS Organizations integration.