Imagine: at a fast-moving startup, you're a DevOps engineer responsible for managing cloud infrastructure. The team is focused on speed, deploying workloads across AWS without rigid controls. Anyone can spin up instances, create databases, and provision storage buckets as needed, but without clear governance, things can quickly spiral out of control.

On one security audit, a scan flags a publicly accessible RDS database containing sensitive customer data like phone numbers, emails, and passwords. This happened because the database was deployed without disabling the public accessibility flag, and no inbound rules were added to restrict who could connect. As a result, the database was open to the internet on port 5432, allowing anyone to attempt a connection. 

Even though VPC logs or CloudTrail could technically help trace who created it, logging wasn’t properly enabled, so there was no clear record of which engineer spun it up or why it was left exposed. Meanwhile, the finance team notices a huge spike in cloud costs, but figuring out where the money is going is nearly impossible because nothing is tagged properly. Engineers rush to fix the mess, but without governance —no tagging, no ownership mapping, no cleanup policies— they can’t tell which resources are actually powering production and which ones are just forgotten test instances draining money in the background.

This is what happens when cloud governance is missing from an organization. Misconfigured resources expose customer data, compliance violations build up, and infrastructure becomes difficult to track and secure. Instead of a well-organized cloud environment, teams end up with uncontrolled deployments, unknown ownership, and security blind spots. Cloud governance isn’t about adding bureaucracy — it’s about keeping cloud environments secure, cost-efficient, and easy to control from the start.

Preventing Resource Sprawl and Misconfigurations

Without proper governance, cloud environments become chaotic. Engineers spin up resources for development and testing but often forget to clean them up from the infra. Over time, the cloud account fills up with unused Elastic IPs, forgotten EBS snapshots, and orphaned Lambda functions that are still active - all silently driving up cloud costs and increasing your cloud’s security risk at the same time.

Misconfigurations make things even worse. A small oversight, like leaving a Lambda function with excessive permissions (iam:PassRole to any role) or forgetting to restrict access on a DynamoDB table, can leave critical internal operations exposed. Without proper governance, these misconfigurations remain unnoticed until a security review or, worse, an incident.

With governance in place, every resource is properly tracked and secured, making sure that only authorized, necessary, and well-configured resources exist in the environment.

Enforcing Consistent Security Policies Across Teams

Now, when multiple teams share the same cloud environment, security gaps are bound to happen. One team might enforce least-privilege IAM roles, restricting access to only what’s necessary, while another grants full admin rights to entire groups, exposing the entire infrastructure. Some engineers might configure private subnets with strict firewall rules, while others deploy resources with open security groups, making them accessible from anywhere. These inconsistencies create attack vectors and introduce compliance risks.

A strong governance framework enforces IAM policies, encryption, and network security rules uniformly across all teams. It also makes sure that every resource follows a standardized tagging strategy, so ownership is clear, costs are trackable, and security policies remain enforceable. Instead of relying on ad-hoc security checks, governance automates policy enforcement, ensuring that every deployment is secure by design.

Automating Policy Enforcement

Governance fails when security policies are enforced through ticket-based approvals, periodic audits, and reactive fixes after deployment. Engineers may accidentally leave default security groups open, misconfigure IAM roles with wildcard permissions, or forget to enable encryption for sensitive data. Security teams, overwhelmed with hundreds of daily deployments, simply can't review every configuration change in real-time. These misconfigurations go undetected until an audit or a security breach exposes them. The only way to enforce governance effectively at scale is through automation.

With tools like Terraform, AWS Organizations, AWS Config, Azure Policy, Google Cloud Organization Policies, and Open Policy Agent (OPA), governance policies can - and should, by default - be enforced before resources are even deployed to the cloud. These policies can:

• Block overly permissive IAM roles before they get created.
• Enforce encryption by default, ensuring S3 buckets, RDS databases, Azure Managed Disks, and Google Cloud Storage are protected with customer-managed keys.
• Prevent public exposure by blocking public IP assignments for EC2, RDS, Azure VMs, and Google Cloud SQL.

Instead of reacting to security misconfigurations after deployment, governance makes sure that they never make it into production in the first place. For example, if you have a policy defined with Open Policy Agent or a pre-commit hook that runs checks after terraform plan but before terraform apply, you can catch overly permissive IAM roles or untagged resources early - before they ever reach your cloud environment. This allows teams to move fast without compromising security. Security and compliance become part of the DevOps workflow - not a last-minute cleanup task.

This allows teams to move fast without compromising security. Compliance governance becomes a built-in part of infrastructure deployment, not a retroactive fix.

Now, let’s take a look at some of the best practices for enforcing governance and compliance in the cloud.

Enforce Tagging Policies for Resource Ownership and Cost Governance

The first one on the list is enforcing tagging policies for resource ownership and cost governance. This best practice falls under cloud governance, helping teams control resource sprawl, establish ownership, and manage cloud costs more effectively.

Your cloud environment can quickly become unmanageable without a proper strategy for tracking your resource ownership and cost allocation. Teams create resources for development, testing, and production, but without structured tagging policies, it becomes difficult to figure out who owns a resource, why it exists, and how much it costs. Sure, you could try to trace some of this through CloudTrail or activity logs, but at scale, that information often gets buried - making it nearly impossible to connect resources to their owners in real time.

A well-defined tagging policy ensures that every resource is properly labeled at creation, making cost tracking, access control, and automation much easier. It helps:

• Identify resource owners to avoid orphaned infrastructure.
• Allocate costs efficiently by associating resources with specific teams or projects.
• Enforce security policies by automating compliance checks.

Now, let’s move to the hands-on part, where we will implement mandatory tagging enforcement using Terraform, AWS Organizations SCPs, and AWS Config.

The first step in enforcing tagging policies is to make sure that every resource created through Terraform includes mandatory tags by default. This prevents engineers from accidentally deploying untagged resources and helps in tracking ownership and cost allocation from the start.

To implement this, we define a set of mandatory tags and ensure they are automatically applied to every Terraform-managed resource.

Now, every EC2 instance (or any other AWS resource using this module) will automatically inherit these required tags.

To apply the configuration, run:

This makes sure that all Terraform-managed resources will always be properly tagged.

To verify that the tags were applied successfully, run:

The output should show:

At this stage, Terraform makes sure that every deployed resource includes the required tags. However, this doesn’t stop engineers from creating untagged resources manually. To prevent this, we enforce tagging policies at the AWS Organization level.

Now, even with Terraform enforcing tags, engineers might manually deploy untagged resources via the AWS CLI or console. To prevent this, we use AWS Organizations Service Control Policies (SCPs) to deny resource creation if mandatory tags are missing.

Now, if an engineer tries to launch an untagged EC2 instance:

AWS blocks the request with:

Now, untagged resources cannot be created within the organization.

Even with Terraform and SCPs, existing resources may still lack the required tags. AWS Config detects and reports these non-compliant resources.

Run:

Check for untagged resources:

If untagged resources exist, AWS Config flags them:

Now, non-compliant resources are detected, flagged, and can be remediated accordingly.

With this in place, organizations can:

• Track resource ownership efficiently.
• Prevent untagged, unmanaged cloud spending.
• Ensure compliance across all AWS environments.

By automating tagging policies, cloud governance becomes simple, scalable, and fully enforced - without any kind of intervention from your team’s end.

Enforce Least-Privilege Access Control for IAM Security

Now moving to the next important aspect of cloud governance - enforcing least-privilege access control. While often seen as a governance concern, this practice also plays a crucial role in meeting compliance requirements like SOC 2, ISO 27001, and CIS benchmarks. In many organisations, IAM policies tend to become overly permissive over time. Engineers, in a rush to get things working, often request admin-level access to services they barely use. Over time, these excessive permissions create security risks. A compromised developer account with wildcard IAM permissions ("Action": "*") can lead to full control over your infrastructure.

Let’s say an engineer, working in the DevOps team, needing access to an S3 bucket for a data migration task. Instead of granting access to just that bucket, someone assigns John the AmazonS3FullAccess policy. Months later, his credentials are leaked in a public GitHub repository. Attackers now have unrestricted access to all S3 buckets in the AWS account.

This is why enforcing least-privilege IAM policies is crucial. Every IAM user, role, and group should have only the exact permissions needed to perform their tasks - nothing more.

To enforce least-privilege IAM, we will:

• Restrict wildcard ("Action": "*") permissions.
• Enforce MFA for high-privilege roles.
• Detect and remove unused IAM users and roles.
• Prevent IAM roles from being assumed by unauthorized accounts.

Let’s move into the implementation of this.

Implementing Least-Privilege IAM Policies with Terraform

The first step is to make sure that IAM policies never use wildcards ("Action": "*") unless absolutely necessary. We'll create a Terraform module that enforces granular permissions by default.

Step 1: Define a Least-Privilege IAM Policy

Create a Terraform file (iam-policy.tf) with a strict IAM policy that only allows read access to S3.

Apply the Terraform configuration:

Now, any user assigned this policy will only have read access to the firefly-prod-data bucket.

Step 2: Enforce MFA for IAM Users with Admin Access

MFA should be mandatory for IAM users with high-privilege roles. We will enforce this using an IAM policy (mfa-policy.json) that denies access if MFA is not enabled.

Apply this policy using the AWS CLI:

Attach it to all admin users:

Now, if John tries to perform any action without MFA, he will get an Access Denied error.

Step 3: Detect and Remove Unused IAM Users

To clean up unused IAM users, we’ll run a simple AWS CLI command to list users who haven’t logged in for 90 days.

Expected output:

These users haven't logged in for over 90 days. To remove them:

Enforcing IAM Security with AWS Organizations SCP

Even with strict IAM policies, engineers may still attempt to create overly permissive roles. We’ll use AWS Organizations Service Control Policies (SCPs) to block IAM roles that grant "Action": "*" access.

Create an SCP file (scp-restrict-wildcard.json)

Apply it:

Attach it to an Organizational Unit (OU):

Now, if an engineer tries to create an IAM policy with "Action": "*", AWS will deny the request.

By implementing these least-privilege IAM policies:

• IAM users only get the permissions they need.
• Engineers cannot create overly permissive IAM roles.
• MFA is mandatory for high-privilege users.
• Unused IAM users are automatically detected and removed.

These measures help organizations enforce strong IAM security by default, reducing the risk of privilege escalation and account compromises.

Enforce Encryption for S3, RDS, and EBS Volumes

Now, moving to the next important aspect of cloud governance - enforcing encryption for S3, RDS, and EBS volumes. While it contributes to secure infrastructure governance, encryption is primarily a compliance-driven requirement. It’s important for protecting sensitive data from unauthorized access and meeting standards like PCI-DSS, HIPAA, and GDPR. Without encryption, any misconfigured access control or compromised credentials can expose confidential information. Many organizations assume AWS encrypts everything by default, but in reality, S3 buckets, RDS instances, and EBS volumes must be explicitly configured for encryption.

To make sure that all stored data remains secure, we’ll enforce encryption across AWS storage services using Terraform. Additionally, we’ll require AWS Key Management Service (KMS) customer-managed keys (CMK) instead of the default AWS-managed keys. Finally, AWS Config will be used to flag any unencrypted resources, preventing security gaps.

Enforcing Encryption for S3 Buckets

The first step is to ensure that all S3 buckets are encrypted with a KMS CMK instead of the default AES-256 encryption. This guarantees better access control and audit logging for encrypted data.

Here’s how we enforce encryption in Terraform:

Apply the configuration:

To verify encryption is enabled, run:

Expected output:

Now, all objects uploaded to this S3 bucket are encrypted using the specified KMS CMK.

Enforcing Encryption for RDS Instances

Next, we ensure that all Amazon RDS databases are encrypted at rest using a KMS CMK. RDS does not allow enabling encryption on an existing unencrypted database, so encryption must be enforced at the time of resource creation.

Here’s the Terraform configuration:

Verify encryption for the RDS instance:

With this setup, the database storage and automated backups will always be encrypted using KMS CMK.

Enforcing Encryption for EBS Volumes

For EC2 instances, we must ensure that all EBS volumes are encrypted. Terraform enforces encryption by default:

To check if the volume is encrypted, run:

Enforcing Encryption with AWS Config

Even with Terraform, there’s still a chance that someone might create unencrypted resources manually via the AWS console or CLI. To prevent this, we enforce AWS Config rules that detect and flag any unencrypted storage.

Check for non-compliant resources:

Expected output (if an unencrypted bucket exists):

Now, any unencrypted S3 buckets, RDS instances, or EBS volumes will be flagged as non-compliant, making sure that no security gaps exist in storage encryption.

Automate Security Group Audits and Restrict Inbound Traffic

Now, security groups act as virtual firewalls for your AWS resources, controlling inbound and outbound traffic. This is a key governance practice that also supports compliance by ensuring access controls are enforced consistently. Misconfigured security groups with open ports can expose your workloads to unnecessary risk, making them a common attack vector. Making sure that the security groups follow best practices is important to maintaining a secure cloud environment.

To prevent misconfigurations, we will automate security group audits and enforce restrictions using Terraform and AWS-native tools. This includes defining security group rules to allow only necessary traffic and implementing AWS Config Rules to detect open ports and flag misconfigurations.

Step 1: Defining Secure Security Group Rules with Terraform

Security groups should follow the principle of least privilege, allowing only necessary inbound traffic. Instead of manually reviewing rules, Terraform can enforce strict security group policies from the start.

The following Terraform configuration defines a security group that:

• Allows only SSH (port 22) from a specific IP
• Allows HTTP traffic (port 80) from the internet
• Blocks all other inbound traffic

By enforcing these rules, we make sure that SSH is limited to a trusted IP, and only HTTP is accessible to the public.

Step 2: Automating Security Group Audits with AWS Config

Even with strict Terraform policies, manual changes in the AWS console can introduce misconfigurations. AWS Config continuously monitors security groups and flags violations based on predefined compliance rules.

To detect and report open security groups, we’ll use an AWS Config managed rule that checks for unrestricted inbound access.

The Terraform configuration below sets up an AWS Config rule to identify security groups with open inbound ports:

This rule automatically flags security groups where SSH (port 22) is open to the public.

Step 3: Verifying Security Group Compliance

Once AWS Config is enabled, we can verify whether security groups are compliant.

To check compliance status, run:

If all security groups follow best practices, the output will be:

If any security groups allow unrestricted SSH access, the output will show NON_COMPLIANT:

Step 4: Enforcing Compliance and Remediating Misconfigurations

If AWS Config detects non-compliant security groups, take the following actions:

• Identify the violating security group using AWS Config findings.
• Update the security group rules to restrict inbound access.
• Reapply Terraform configuration to enforce best practices.

To check for open ports, run:

If a security group is found with an open SSH rule (0.0.0.0/0), update it using:

This removes the public SSH rule, ensuring compliance.

By defining security group rules in Terraform and continuously monitoring compliance with AWS Config, we eliminate the risk of open ports and enforce security best practices. This approach ensures that security groups remain hardened against unauthorized access, reducing the attack surface and enhancing cloud security.

Enable Centralized Logging for Security and Compliance

In any cloud environment, centralised logging is primarily a compliance-driven requirement. It forms the first line of defence for detecting security threats and proving that controls are working as expected. Without it, tracking down incidents across multiple services becomes nearly impossible. A well-structured logging system ensures that security events, API activity, and network traffic are recorded, stored securely, and made available for analysis.

To achieve this, we will enable AWS CloudTrail, set up VPC Flow Logs, and configure AWS Security Hub to aggregate security findings. This setup will help detect unauthorised access, monitor network activity, and ensure compliance with security best practices.

Step 1: Enabling AWS CloudTrail

AWS CloudTrail records all API activity within an AWS account. To ensure every action is logged, we enable CloudTrail and configure it to store logs in an S3 bucket.

Once applied, CloudTrail will capture all API calls and store them in the designated S3 bucket.

To verify that CloudTrail is running, use:

This should return details of the configured trail:

This confirms that all API calls are being logged and securely stored.

Step 2: Capturing Network Activity with VPC Flow Logs

To monitor traffic at the network level, we enable VPC Flow Logs. These logs capture inbound and outbound traffic for security analysis.

After applying this, all traffic data will be stored in S3. To check if logs are enabled, run:

This should return:

This confirms that all network traffic is now being recorded.

Step 3: Aggregating Security Findings with AWS Security Hub

AWS Security Hub collects findings from multiple security services and flags misconfigurations or threats. To enable it, we use:

If misconfigurations exist, the output might look like:

These are important security risks that require immediate attention.

Step 4: Investigating Security Events

Once logging is centralized, we can investigate specific events.

Checking if any unauthorized S3 bucket deletions occurred:

If an unauthorized deletion attempt was made, the output will show:

This indicates an unauthorized action was attempted, requiring further investigation.

Similarly, checking blocked network connections:

If suspicious traffic was blocked, it might look like this:

This suggests an unauthorized attempt to access an internal server via SSH, which could indicate a brute-force attack.

With CloudTrail, VPC Flow Logs, and Security Hub in place, we now have a complete logging setup that captures API activity, network traffic, and security findings. This ensures real-time security monitoring, incident detection, and compliance tracking across the AWS environment.

How Firefly Makes Cloud Governance and Compliance Much Simpler?

Ensuring cloud governance and compliance manually is an exhausting process. DevOps engineers are often forced to track misconfigurations, enforce security policies, and remediate compliance issues across multiple cloud environments. This means running dozens of AWS CLI commands just to audit configurations, sifting through endless outputs, and manually fixing security loopholes. Even with strict processes in place, human errors and overlooked misconfigurations are inevitable.

For example, consider a simple security audit in AWS. To check if any security groups have open access to the internet, a DevOps engineer needs to run:

This command returns raw JSON output, which then has to be carefully analyzed to find security groups exposing ports to 0.0.0.0/0. If an issue is found, the engineer must update the security group rules to restrict access.

A similar challenge exists when checking for unencrypted S3 buckets. To list all buckets and verify their encryption status, they must first retrieve all bucket names and then run an encryption check for each one:

If any bucket is unencrypted, the engineer must manually enable encryption, making sure to apply the correct policies to avoid service disruptions. The process is no easier when auditing IAM roles with excessive permissions. Running a command to list all policies:

only provides raw policy names and ARNs. To understand whether a policy is overly permissive, an engineer needs to dive into each policy document, analyze permissions, and compare them to security best practices.

This entire workflow is repetitive, time-consuming, and prone to misconfigurations, especially in large cloud environments with constantly changing cloud resources. That’s where Firefly steps in, eliminating this manual burden and automating governance and compliance enforcement.

Instead of running individual commands and manually interpreting results, Firefly continuously scans the cloud environment and detects governance issues. The platform provides an immediate visual overview of misconfigurations, highlighting risks such as overly permissive security groups, unencrypted storage, and excessive IAM permissions.

Whatever resources you have in your cloud - whether EC2 instances, S3 buckets, RDS databases, IAM roles, or EKS clusters - Firefly Governance tracks all of them and generates a governance report for each. 

Firefly identifies misconfigurations, security risks, and compliance violations across all cloud accounts and services, giving DevOps teams a centralized view of their infrastructure's health.

‍

Firefly also offers a powerful Analytics Dashboard that surfaces key insights about your governance and compliance posture.

With these analytics, teams can track whether governance is improving, pinpoint gaps, and stay on top of asset inventory and configuration drift. It also makes proving compliance during audits dramatically simpler.

Beyond just flagging issues, Firefly goes a step further with AI-powered remediation. When a misconfiguration is detected, Firefly automatically suggests the necessary fixes and gives the suggestions to solve them with minimal user intervention. If a security group is found to allow unrestricted access, Firefly can instantly generate a corrective policy, ensuring access is granted only to authorized sources. For unencrypted storage, it enforces encryption policies without disrupting existing workloads. When IAM roles have excessive permissions, Firefly recommends a least-privilege configuration, reducing the risk of privilege escalation attacks.

Firefly doesn’t just fix misconfigurations once - it enforces compliance continuously. The platform monitors infrastructure changes in real-time, identifying drifts from security best practices as they happen. This ensures that even as engineers modify resources or deploy new services, governance policies remain intact without requiring constant manual intervention.

Instead of relying on engineers to manually track and remediate issues, Firefly does the heavy lifting. It makes sure that security policies are consistently applied, compliance requirements are met, and misconfigurations are corrected before they lead to security incidents. By replacing lengthy command-line audits and manual fixes with automated governance, Firefly makes cloud security and compliance effortless.

‍