New FinOps Capabilities Kion Strengthens Multicloud Capabilities with New Support for FOCUS and Oracle Cloud Infrastructure Read the press release

Blog Continuous Compliance Financial Management Release News

New in Release 2.23: AWS SCPs, Permissions Boundaries, and More!

6 min read

Shields and shapes background pattern

Last updated on February 21st, 2023 at 5:40pm

We just released version 2.23 of our cloud governance software, and it's hard to fit all of the new features into a blog post! This month we focused on more granular and easier permissions control, better visibility into your compliance status, new savings opportunities, and more.

Here's what you'll find in release 2.23 of

For AWS users: SCPs and permissions boundaries

Our two newest additions for AWS are service control policies (SCPs) and permissions boundaries. These AWS objects let you better control your users' effective permissions, but when you leverage the power of, you can enforce them in more places, even faster.

What is an AWS service control policy?

A service control policy is a method to allow or deny certain actions in an AWS account. They don't actually grant any permissions, they just allow you to set the limits for what permissions can be given by IAM policies. Service control policies allow you to apply enforcements at a higher level than IAM policies that will apply to all users (even the AWS account's root user). With IAM policies, you could potentially get around restrictions by creating a new user in the AWS console to which the IAM policy does not apply. An SCP would apply account-wide, so there is no risk of that.

Why can creating and applying SCPs in the AWS console be challenging?

  1. You need highly privileged access to the root of your organization (i.e., your master payer account) to enforce them.
  2. Applying them across more than one account can be a cumbersome manual process.
  3. You can't apply them across multiple master payer accounts. now helps to create, manage, and apply SCPs to AWS accounts, including multiple management accounts. Users can apply SCPs to accounts by attaching cloud rules to a project or organizational unit. SCPs differ from IAM policies in that they apply account-wide and allow higher-level enforcements that apply to all users, while IAM policies offer granular control over individual users. However, if an IAM policy needs to be extended to the entire account, it can be cloned and converted to an SCP using the “Add an AWS Service Control Policy" feature.

Together with our other new offering (AWS permissions boundaries), SCPs also create a way to gain more control over a user's effective permissions.

AWS permissions boundaries and control over effective permissions

We are excited to announce that now you can also create, edit, and apply AWS permissions boundaries. What is a permission boundary? A permissions boundary allows you to set the maximum permissions for your AWS accounts by controlling effective permissions. It's also an effective way to allow users to create their own roles by requiring them to attach an IAM policy to a user or role during creation to ensure they can't elevate their own access. This is ideal for those that need to create their own roles for EC2 or Lambda.

Policies in AWS often overlap. Your AWS IAM policies, AWS SCPs, and permissions boundaries all control an entity's (i.e., a user, user group, or role) effective permissions, or what they can actually do in the cloud. An AWS permissions boundary helps define the limit on an entity's permission as the intersection of policy types. Denial of an action in either of these policies overrides allowance in the other.

AWS IAM policy vs permissions boundary

Developers often need to create new IAM roles and policies for their applications to interact with AWS resources. For example: an IAM role for an AWS Lambda function to perform actions on the data loaded to Amazon S3 or for an EC2 instance to report logs and metrics to Amazon CloudWatch.Prior to the launch of IAM permissions boundaries, a central admin team was responsible for creating and managing all IAM roles and policies, creating a bottleneck that doesn't scale. To address this issue, AWS introduced IAM permissions boundaries to empower developers to safely create and manage IAM roles and policies while having security guardrails in place to set maximum permissions. By setting up permissions boundaries, developers can focus on tasks that add value to the business, while freeing up the centralized security and IAM teams to work on other critical tasks.

In, you can create, view, edit, and delete an AWS permissions boundary the same way you would any other AWS IAM policy. That means you can use AWS permissions boundaries with's Cloud Rules and Cloud Access Roles. Thus giving you more granular control over your permissions and allowing you to apply them to entire projects or organizational units in a single click.

When you add SCPs to the mix too, you get even more control. If an identity-based policy, a permissions boundary, and an organization's SCP are all applied to the same entity, the request is only allowed if all 3 policy types allow it. Together these 3 policies create a rock-solid permission system, and you can add, apply, and change them more broadly and more easily with

For everyone: better compliance visibility, expanded savings opportunities, and more

The new compliance overview

We enhanced the compliance overview in this release, reorganizing things so that you see the most relevant compliance data at a glance. We also added a "findings by severity" section, so you know which findings you should prioritize. The end result is the ultimate control panel for tracking and addressing compliance issues.

visual of how to identify compliance findings by severity

A new page for compliance diagnostics

Speaking of compliance, you can now keep track of compliance scans that are pending or running. Our new compliance scan diagnostic list gives you even greater insight into your compliance by showing you what's currently running or pending, the scheduled date/time, when the scan started, and how long it's been running.

how to run cloud compliance scan diagnostics

Even more savings opportunities

Release 2.22's savings opportunities feature was a smash hit, so we made sure to add new opportunities in 2.23. You can now terminate additional resources with decommissioning opportunities, including Elastic IPs, EFS volumes, ElastiCache, AMQ, Workspaces, EBS snapshots, RDS DB snapshots, or Azure PostgreSQL databases. Plus, we now recommend Azure Virtual Machine rightsizing opportunities.

Check out the screenshot below to see just how many savings opportunity checks we offer. No wonder our customers are reporting 30% off their cloud bills with this feature!

decommissioning opportunities to help reduce cloud bill

New settings to customize your experience

We get that different organizations have different needs, so we strive to offer customizable settings within Our newest setting lets you disable or enable custom permission schemes on the General UI Settings page. This allows admins to turn off custom permission schemes if you don't need them, making things less confusing and clutter-free.

visual of how to disable or enable custom permission schemes

Plus, savings opportunities calculations now use a 3-month average instead of “current” monthly cost for comparisons. This gives a more accurate picture of your overall spending and how much you'll save.

We could go on!

We know this blog article is getting long, but we made even more changes and enhancements! Make sure you check out the Support Center if you’re an existing customer to see everything we packed into release 2.23!

If you're new to, you can request a demo to learn more about our comprehensive cloud management software.

Start your cloud operations journey.

Request a demo today,