By using AWS re:Post, you agree to the Terms of Use
/Effect Of Service Control Policy on Delegated Administrator Account/

Effect Of Service Control Policy on Delegated Administrator Account


Hi Everyone,

I would like to know about the Effect of Service Control Policies created in AWS Master Account's organization.

I have enabled Amazon GuardDuty in the Master account and added one of our member accounts as "Delegated Administrator Account" to manage GuardDuty Findings from all the member accounts.

The question is what would happen to the Delegated Administrator Account (for GuardDuty) when I create and apply a Service control policy in the AWS master account's organizations?

Since SCP's will take effect on all the member accounts of the master account, "Delegated Administrator Account (for GuardDuty)" is also a member account of the AWS master account.

Will access get denied when making modifying the GuardDuty configuration from the Delegated admin account (for GuardDuty) as well?

Ref Link:

Thanks, Swapnil Pawar

5 Answers
Accepted Answer

If you want to exclude a specified account, you can use condition like below. Account number in this condition should be the delegated admin account number.

"Condition": { "StringNotEquals": { "aws:PrincipalAccount": [ "0123456789012" ] } }


answered 6 months ago

Hi! Good question. Service Control Policies will apply to member accounts, but will not affect users or roles in the management account. With your "Delegated Admin," that will count as a member account. If the policy is attached to the "root", this will be inherited by all the member accounts.

For more about SCP inheritance, check out this AWS Guide:

If you are using a deny structure, keep in mind that explicit denies will override any explicit allows. Thus, if you have an explicit deny on GuardDuty, that will get inherited, it could block the ability of your delegated admin account to administer GuardDuty.

A couple options:

  • Conditions - You can use conditions to exclude the account to be able to manage GuardDuty. This can be done with aws:PrincipalAccount Principal and NotPrincipal are not supported in SCPs.

  • Re-structure the Organization so that the delegated admin account is not affected by the broad Deny/SCP. This could be useful if you plan on using the delegated admin account for other purposes or solely as a management or security account.

  • Using an allowlist structure for IAM. By using an Allowlist, you can have more granularity on child accounts/OUs. However, this would require not having an Allow * * at the root level. This may require a restructuring of your SCPs as well.

answered 6 months ago
  • Thank you, jsonc for your detailed information. Appreciate it. :)


If you attach the SCP to all account including the Delegated Admin Account, the Delegated Admin Account will access get denied when making a change on GuardDuty because you explicitly deny the action in the policy. Delegating administrator account for GuardDuty does NOT mean that the delegated admin account will have permission of "*" action in GuardDuty regardless of SCP but just mean that the delegated admin account can collect GuardDuty findings from member account and propagate configuration to member accounts. In order for the delegated admin account to manage GuardDuty configuration in your organization, you must exclude the delegated admin account.



answered 6 months ago

That's correct, Eunsu. I understand that I have to exclude that "Delegated Admin Account" when creating SCP from AWS master account in AWS organizations. I have checked the AWS documentation but I didn't find any global condition context key to add it to the condition in SCP policy in order to exclude that account.

Here is the doc link:

Let me know If you have any idea.

answered 6 months ago

SCPs are effective against Member Accounts (AWS Accounts) within an AWS Org, and not the Administrative/Root AWS Account (previously referred to as the 'Master Account'). So with this in-mind, if you have a flat AWS Org structure (no drill-down levels of OUs), then applying an SCP at the Root-level of the AWS Org will mean that the restrictive statements of the SCP will be applied to your AWS GuardDuty delegated admin account.

Now, how to get around this? You could go down the route of adding in Condition blocks within your SCP, but you're missing out on a perfect opportunity to organise your AWS Org structure, and to really get the most out of your SCPs. You should look into crafting an OU structure within AWS Organizations which enables you to apply your SCPs to Member accounts, but not have any detrimental effect on more 'sensitive' accounts, such as the delegate admin account for AWS GuardDuty within your AWS Org.

If you're looking for examples of OU structure, there's always that of the AWS Landing Zone solution, here.

answered 6 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions