Stax Policies are AWS Service Control Policies that can be attached to a Stax-managed AWS Organization or a specific Account Type. Stax allows you to create and attach Policies to your Organization and Account Types.
Stax attaches a default Policy to your Organization in order to protect Stax resources and maintain the integrity of the platform. This policy cannot be removed. In addition, Stax provides a number of predefined Policies that you can attach to your Organization or Account Types.

Why use Stax Policies?
Stax Policies allow you to utilize the AWS Organization Service Control Policy system to limit the maximum available permissions for accounts within your Stax Organization.
Policies attached at the Organization level will apply Policy permissions to all of your Stax-managed AWS accounts.
Policies attached at the Account Type level will apply Policy permissions to all Stax-managed AWS accounts within that specific Account Type.
Get Started with Policies
Limitations
- You can attach up to two policies to your Stax Organization
- You can attach up to three policies to an Account Type
- Stax applies default Policies for global protection. These Policies are in place to protect resources Stax creates within your AWS accounts
If you need to attach more policies to an Organization or Account Type, you should consider combining multiple policies where appropriate.
Considerations
While Stax Policies utilizes AWS's Service Control Policies framework, Stax introduces some guardrails to help ensure ensure the application of your policies align with best practice. One of these is to take a "100% Deny" approach to writing Policies. What this means, in practise, is that you can only use the Deny Effect when crafting your Policies. Any use of the Allow Effect will cause the Policy to fail to deploy.
Examples
Below are example Policies which can be adapted and deployed into Stax. Remember to validate the policies to ensure they meet your individual requirements before applying them to your organization.
Restrict AWS services a region
Using this policy, you can restrict AWS services to the ap-southeast-2 (Sydney) region.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideAU",
"Effect": "Deny",
"NotAction": [
"a4b:*",
"artifact:*",
"aws-portal:*",
"budgets:*",
"ce:*",
"chime:*",
"cloudfront:*",
"cur:*",
"datapipeline:GetAccountLimits",
"directconnect:",
"globalaccelerator:*",
"health:*",
"iam:*",
"importexport:*",
"mobileanalytics:*",
"organizations:*",
"resource-groups:*",
"route53:*",
"route53domains:*",
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"shield:*",
"sts:*",
"support:*",
"tag:*",
"trustedadvisor:*",
"waf:*",
"wellarchitected:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-southeast-2",
"us-east-1"
]
}
}
}
]
}
Enforce encryption for all S3 buckets
Using this policy, you can prevent users from creating S3 buckets that are not encrypted.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIncorrectEncryptionHeader",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
},
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": true
}
}
}
]
}
Further Information
You should familiarize yourself with Service Control Policies before beginning to write and apply your own. Test Policies against an Account Type with a limited scope before applying them broadly to your production Account Types or to your entire Organization. The incorrect application of a Service Control Policy could directly impact multiple AWS accounts and Stax Users.