Delegated Administrators

src/config/delegated-admins.ts declares which member accounts act as delegated administrators for AWS Organizations integrated services. Delegation moves day-to-day service management out of the management account: the security account owns CloudTrail, IAM, IAM Access Analyzer, Config, GuardDuty, Security Hub, Inspector, and Macie, and the landing zone account owns CloudFormation StackSets. The organization phase (LandingZoneOrganizationStack) reads this file and performs the registrations after each account exists and its trusted access is enabled.

A service can only be delegated once its trusted access is enabled in trusted-access.ts, so keep the two files aligned: every account you list here needs matching trusted access for the same service principal.

organizationDelegatedAdministrators

The file exports a single list. Each entry is a DelegatedAdministratorProps that maps one account key to the service principals it administers.

You list only the service principals. The foundation owns the registration mechanics: each principal is registered through whichever mechanism its own AWS service requires — a service-specific admin API for the services that need one (such as GuardDuty, Security Hub, Inspector, Macie, and CloudTrail), or the generic AWS Organizations RegisterDelegatedAdministrator API for everything else — and any service-linked role a service needs in the management account before it can be delegated is provisioned automatically as part of the registration. You do not encode any of that here.

The starter delegates the security account as administrator for the security and audit services, and the landing zone account for CloudFormation StackSets:

export const organizationDelegatedAdministrators: DelegatedAdministratorProps[] = [
  {
    accountKey: 'SecurityAccount',
    servicePrincipals: [
      'access-analyzer.amazonaws.com',
      'cloudtrail.amazonaws.com',
      'config.amazonaws.com',
      'config-multiaccountsetup.amazonaws.com',
      'guardduty.amazonaws.com',
      'iam.amazonaws.com',
      'inspector2.amazonaws.com',
      'macie.amazonaws.com',
      'securityhub.amazonaws.com',
    ],
  },
  {
    accountKey: 'LandingZoneAccount',
    servicePrincipals: ['member.org.stacksets.cloudformation.amazonaws.com'],
  },
];

To delegate another service, add its principal to the account's servicePrincipals list. Confirm the service supports delegated administration in the AWS Organizations integrated services table first, and add matching trusted access in trusted-access.ts. Keep the list limited to the services the landing zone configures rather than delegating every service that supports it.

How it's used

LandingZoneOrganizationStack passes this list into OrganizationConstruct, which registers each account as the delegated administrator for its service principals. The construct validates the configuration at synth time and fails the build if you delegate the same service principal to two different accounts, or repeat a principal. REGIONAL services (GuardDuty, Inspector, and Macie register per Region) are registered in the primary Region and every secondaryRegions entry from your settings; the rest register once.

Because delegation is owned by the organization phase, it completes before any landing-zone StackSet that relies on a delegated account runs, which is why the Security Hub V2 StackSet and Organization Security StackSet can assume the security account is already the delegated administrator. IAM is delegated so the Organization Security StackSet can manage centralized root access across member accounts, and IAM Access Analyzer so it can create the organization external access analyzer, both from the security account.

Things to know

• Verify the service before adding it. Confirm the service supports delegated administrators in the integrated services table, then add its principal here and its trusted access in trusted-access.ts. The foundation already knows how to register the delegated-administrator-capable services; a service it does not recognize natively can still be delegated through the generic Organizations API by listing it here.
• accountKey must exist in your organization structure. The key is resolved to a real account ID at deploy time, so a typo or a renamed account key fails the build rather than silently skipping registration.
• Removing an entry deregisters the administrator on the next deploy. Deregistering a security service's delegated admin has service-level side effects (for example, it can disrupt org-wide GuardDuty or Security Hub), so treat removals with the same care as the Security Hub V2 StackSet teardown.