Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
To remediate “AWS Organizations Should Be Used” for an account where you’re using Route 53, you essentially need to:
Once the account is part of an AWS Organization, most security/compliance checks for “AWS Organizations should be used” related to Route 53 will pass, assuming the account is correctly recognized as a member of an Organization.
- put the account into an AWS Organization, and
- (optionally) centralize Route 53 management using that Organization.
1. Create or join an AWS Organization
A. If you don’t have an Organization yet
- Sign in to the AWS Management Console using the account that will be the management (formerly “master”) account, with
rootor equivalent admin permissions. - Go to AWS Organizations:
Services → type “Organizations” → AWS Organizations. - On the Get started page, choose Create an organization.
- Select Enable all features (recommended for SCPs and advanced controls) and confirm.
B. If you already have an Organization and this is a standalone account
You must invite the standalone account into the existing Organization:- Sign in to the management account.
- Open AWS Organizations → Accounts → Add an AWS account → Invite an existing AWS account.
- Enter the Account ID and email of the standalone account; send the invitation.
- Sign into the invited account, open AWS Organizations, and under Invitations, Accept the invitation.
2. Ensure sharing within the Organization (for central Route 53 use)
This step helps centralize Route 53 (for example, sharing private hosted zones or related resources across accounts).A. Enable AWS Resource Access Manager (RAM) sharing with AWS Organizations
- In the management account, go to AWS RAM console.
- In the left menu, choose Settings.
- Under Resource sharing settings, enable Enable sharing with AWS Organizations.
- Save changes.
3. (Optional) Centralize Route 53 DNS using the Organization
If your intent is to manage DNS centrally in one “DNS account” for all Org accounts:- Choose/assign a central DNS account in the Organization.
- In that DNS account, create the necessary hosted zones in Route 53:
- Go to Route 53 → Hosted zones → Create hosted zone.
- To share private hosted zones with other Org accounts:
- Go to Route 53 → Hosted zones → select the private hosted zone.
- Choose Share hosted zone (this opens AWS RAM).
- In AWS RAM, choose Principals type: AWS Organization (or specific OUs/accounts).
- Complete and Create resource share.
Once the account is part of an AWS Organization, most security/compliance checks for “AWS Organizations should be used” related to Route 53 will pass, assuming the account is correctly recognized as a member of an Organization.
Using CLI
Using CLI
This finding isn’t actually specific to Route 53.
“AWS Organizations Should Be Used” is an account/organization-level requirement, not a Route 53 configuration. You remediate it by enabling and configuring AWS Organizations for the account that owns your Route 53 resources.Below are the step‑by‑step AWS CLI instructions.
Note the Capture the
The target account must accept the invitation.
Find the Now that account is in your organization.
Find the Note the current
Once your account is part of an AWS Organization (with
“AWS Organizations Should Be Used” is an account/organization-level requirement, not a Route 53 configuration. You remediate it by enabling and configuring AWS Organizations for the account that owns your Route 53 resources.Below are the step‑by‑step AWS CLI instructions.
1. Check if AWS Organizations is already in use
- If this returns details (with an
Idlikeo-xxxxxxx), your account is already in an organization. - If you get
AWSOrganizationsNotInUseException, you must create an organization.
2. Create an organization (if not already in one)
Run this from the account you want as the management (root) account:ALLenables full features (recommended for governance, SCPs, etc.).
3. (Optional) Create Organizational Units (OUs)
If you want to logically group accounts (e.g., prod / dev):- Get the Root ID:
"Id" (e.g., r-abcd).- Create an OU under that root:
"Id" of the new OU from the response if you plan to move accounts into it.4. Invite existing standalone accounts to the organization
From the management account, invite accounts that own Route 53 resources (or any others):5. Accept the invitation from the target account
Log in (or configure AWS CLI credentials) as the target/member account and list invitations:"Id" of the pending invitation (e.g., h-abc123xyz), then:6. (Optional) Move the member account into an OU
From the management account:- Get the account’s Org ID:
"Id" (e.g., 123456789012) of the account to move.- Get current parent and destination OU:
"Id" as SOURCE_PARENT_ID (often the root id).Set destination OU id:- Move:
7. (Optional) Attach Service Control Policies (SCPs)
To enforce governance that might be related to Route 53 usage (e.g., restricting changes to specific accounts):- Create an SCP document
scp-route53-guardrails.json:
- Create the policy:
- Attach the SCP to an OU or account:
Once your account is part of an AWS Organization (with
feature-set set to ALL), the “AWS Organizations Should Be Used” requirement is satisfied for that account and all services it hosts, including Route 53. There is no separate Route 53–specific switch for this control.Using Python
Using Python
Below are concise, step‑by‑step instructions to remediate the “AWS Organizations Should Be Used” finding using Python (boto3), with Route 53 in mind.Goal
Ensure the AWS account(s) using Route 53 are members of an AWS Organization (ideally a central Org) so that Route 53 and other services are governed centrally (SCPs, tagging policies, consolidated billing, etc.).
Result:
You now have an AWS Organization and a management account. All Route 53 configuration in this account is now under an Organization.
The invite is sent to the target account. The invitation must be accepted from the target account (via console or API).Result:
All your Route 53–using accounts are now member accounts in the Organization.
Now you can target Route 53 accounts with specific Service Control Policies.
Ensure the AWS account(s) using Route 53 are members of an AWS Organization (ideally a central Org) so that Route 53 and other services are governed centrally (SCPs, tagging policies, consolidated billing, etc.).
1. Prerequisites
- Use an account that will be the management account (formerly master) for the Organization.
- Configure credentials for that account (e.g., via
aws configureor environment variables). - Install boto3:
2. Check if an Organization Already Exists
You now have an AWS Organization and a management account. All Route 53 configuration in this account is now under an Organization.
3. Invite Existing Route 53 Accounts into the Organization
If you have other standalone AWS accounts that host Route 53 hosted zones or records, invite them into this Organization.3.1 Send Invitations
3.2 Accept Invitations from Member Accounts (Python Script Per Account)
From each invited account, configure credentials for that account and run:All your Route 53–using accounts are now member accounts in the Organization.
4. (Optional but Recommended) Put Route 53 Accounts into an OU
Organizational Units (OUs) let you group Route 53 accounts to apply consistent policies.5. (Optional) Apply Service Control Policies (SCPs) for Route 53 Governance
Examples:- Enforce Route 53 is only used in allowed regions (where applicable).
- Restrict changes to public hosted zones to designated admin roles.
5.1 Create an SCP
5.2 Attach SCP to OU or Accounts
6. Validate Remediation
- Confirm Organization exists and shows your Route 53 accounts as members:
- In each Route 53 account, try actions that should be restricted by SCP (e.g., delete hosted zone) and confirm they are denied if not using the approved role.
- Ensure billing and policy management is centrally visible in the management account.
Using Terraform
Using Terraform
terraform plan should show something like:Plan: 1 to add, 0 to change, 0 to destroy.

