#13. Implementing Governance through Policy: Part Two - Cloud IAM Policies

n article #08 - Fix the root cause, not the symptoms: Cloud Governs vs Cost Optimizations, I discussed the importance of cloud governance through policy. There are multiple ways to implement such governance, which I'll explore in this two-part article series.

In the first article, I examined the best practice of implementing governance using IaC (Infrastructure as Code), with Terraform as an example. In this one, we will consider the second guardrail mechanism: setting cloud IAM roles, policies and user to govern cloud resources.

TL;DR

• Although governance through policy in IaC should be the primary measure, adding cloud policies as a second guardrail ensures that governance rules will still apply even when resources are deployed without IaC.
• Governance through IAM policies provides flexibility in assigning different policies to different roles

Is an Extra Layer of Governance Beyond IaC Necessary?

Even if your organization prohibits manual deployment of cloud resources (e.g., through cloud consoles or cloud terminals), implementing a second governance layer via cloud IAM policies is not redundant. Following recommended cloud security practices—assigning groups, users, roles, and policies—ensures well-regulated cloud usage.

These policies shouldn't be overly restrictive, as this could hamper productivity and creativity. Instead, view them as a way to grant privileges and foster accountability. For instance, while an architect or senior cloud engineer may deploy a multi-regional, high-performance database instance in production, a junior developer working in a sandbox environment should request permissions through a CI/CD pull request for this IaC.

How to implement Governance using Cloud IAM Policies

This sort of governance utilizes the cloud IAM (Identity and Access Management) services directly. The key is to assign specific policies that limit the use of certain resources when particular conditions are met.

For example, we can assign a policy restricting high-performing (and thus expensive) cloud resources when deployed to development or sandbox environments—after all, you don't need a premium hard drive for sandbox accounts.

You may also want to restrict resources to specific families, types, or sizes to ensure coverage of cloud commitment rates. For example, if you've purchased Reserved Instances (RIs) that cover certain VMs or EC2 instances, you might want to ensure that most deployed instances match these criteria to maximize savings—unless there's a specific business need for different instances.

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "AllowSpecificInstanceFamilies",
     "Effect": "Deny",
     "Action": "ec2:RunInstances",
     "Resource": [
       "arn:aws:ec2:*:*:instance/*"
     ],
     "Condition": {
       "StringNotLike": {
         "ec2:InstanceType": [
           "t3.*",
           "m5.*"
         ]
       }
     }
   }
 ]
}


Such policies (like the example above) can include conditions that align with the organization's business requirements. Once defined, they are typically assigned to users, groups, and accounts, ensuring that governance is enforced.

Summary

Adding an extra guardrail layer of governance through cloud IAM policies ensures that security best practices are followed. Assigning these policies to users, groups, and accounts establishes the appropriate level of governance.

Thanks for reading! Share if you found it helpful. Have questions or suggestions for future topics? We'd love to hear from you!

‍