Introduction- AWS Service Control Policies 

Service control policies (SCPs) are a type of organization policy that is used to manage permissions in an organization. Furthermore, AWS Service Control Policies offer central control over the maximum available permissions for all accounts in your organization. SCPs ensures that your accounts stay within the organization’s access control guidelines.

Additionally, Please note: There is no “audit” mode for SCPs or any other way to test if a SCP will break things.

SCPs cannot restrict the Master Account of the Organization. Moreover, this is the primary reason behind not using the Organization Master Account for anything except Organization Activities. This means that you should not put S3 buckets, EC2s, or any other resources in your Organization Master, because you cannot use SCPs to create guardrails around that.

Moreover, in this article we will talk about a few policies like:

Production Specific Policies which you could apply for Production Environment.

In addition, the test environment can have a set of different policies which can be used. For example, Sandbox Policies like:

1. Restrict user to create 10x size EC2 instance.
2. Allow only approved services rds
3. lambda ec2 iam
4. Restrict user for confidential services

Production specific AWS Control policies

Furthermore, read the code below that we implemented for production specific policy:

Block service usage in all regions except Sydney. Moreover, block service access for the root user and Deny Account’s ability to leave the Organization.

Prevent resource creation without specifying mandatory tags

Resource Size AWS Control policies

It requires Amazon EC2 instances to use a specific type. 

To Require a tag on Resource creation and resource’s Name

 Application environment platform cost center

Sandbox Specific Policy

• Furthermore, this policy requires Amazon Elastic Cloud Compute (EC2) instances to use a specific type.
• Then allow only approved services.
• GP inherited rules.
• Block service usage in all regions except Sydney.
• Then deny the Account’s ability to leave the Organization.

Limitations

Limitations: Furthermore, We could not get a few of the services to work with the service control policies. However, policies like EC2, EKS, ECS and Secrets Manager worked fine. Although, Lambda and S3 buckets do not work with the tag restrictions because they do not support tag based authorization in IAM policies. Further, we could not get RDS, Athena, or Amplify to work because although, they may support tag-based restrictions in IAM policies, the consoles of those services do not let you add tags upon resource creation. 

For example, you can tag a RDS instance during creation in the CLI, but the console does not let you do it during creation. Moreover, This means that if your users are in the console, there is no way to ask them to add tags upon RDS creation.

Additionally, To know more, read this link AWS services that work with IAM – Compute services – https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work- with-iam.html#compute_svcs

Unit Test Screenshots

Below are the screenshots of the resources showing error when not followed with the policy.

 When the policies are followed, it creates the workload as expected having the mandatory tags as enforced by the policy.

Conclusion- AWS Service Control Policies

In conclusion, it is important to use the right policy to create workload as expected. If you do not follow the policy, then you will not get the permission. Additionally, setting up AWS control policies is beneficial as it ensures your account stays within your organization’s access control guidelines.