In a recent r/devops thread, engineers shared what’s really breaking modern infrastructure workflows. Teams are struggling with too many disconnected tools, IaC that doesn’t reflect what’s actually deployed, manual fixes outside of Git, and policy engines that only see part of the picture. Beyond the usual complaints, such as inconsistent provisioning and fragmented pipelines, governance emerged as the most fundamental failure.

At the center of all this is a governance problem, as most policy engines only evaluate resources that are defined in Infrastructure-as-Code, like Terraform, Pulumi, or CloudFormation. But a big chunk of your environment is created outside those systems: via the AWS console, CLI commands, or vendor UIs. These resources never hit Git, never enter your CI/CD, and aren’t part of any plan file.

If it’s not in your IaC or version-controlled pipelines, your policy tools can’t see it. That means no OPA checks, no Sentinel policies, no tagging enforcement, no cost controls.

This blog breaks down why cloud governance fails when you don’t have visibility into unmanaged resources, the parts of your infrastructure that never made it into code. We’ll look at what unmanaged really means, why it creates blind spots in security and compliance, and how Firefly helps make that happen without disrupting your existing setup.

Before diving deeper, let’s get clear on what “unmanaged” really means and why it’s more common in dev environments.

What “Unmanaged” Really Means in IaC

When DevOps engineers call a resource “unmanaged,” they don’t mean it’s broken; they mean it’s not declared in Infrastructure-as-Code. If it’s not in your Terraform, Pulumi, or CloudFormation definitions, it’s outside your version control, CI/CD workflows, and IaC state file. 

That means:

• No pull request reviewed the change
  
• No pipeline applied it
  
• No policy engine evaluated it

The dangerous assumption most teams make is that their IaC repo reflects reality. But we cannot guarantee that something isn’t in Git; it doesn’t mean it isn’t running, and that’s where visibility breaks down.

Common Examples of Unmanaged Resources in Infrastructure

These aren’t edge cases; they happen very often in every environment:

• EC2 instances are spun up manually in the AWS Console during testing, load troubleshooting, or outages
  
• S3 buckets and EBS volumes created by one-off scripts or for ad-hoc test data, and never cleaned up.
  
• DNS records were manually added in Route 53, meant to be temporary, but never migrated into Terraform
  
• IAM roles created mid-incident, bypassing CI/CD during rush hours, and forgotten afterward
  
• Resources provisioned by vendor tools or internal scripts that don’t commit changes back to your main IaC repo

These assets are live in your environment. They incur cost, hold IAM permissions, and often expose services to the public network via open security groups, public S3 buckets, unused ELBs, or untracked DNS entries. But because they aren’t defined in code, your policy engines,  whether OPA (via Rego), Sentinel, or AWS Config, have no input data to evaluate. They simply don’t exist in the evaluation context.

No tag enforcement. No security baselines. No cost attribution.

From your governance tooling’s perspective, they don’t exist. Before moving further, it’s important to distinguish between the different types of resources you’ll encounter in cloud environments, especially when working with Infrastructure-as-Code.

Drifted vs Unmanaged vs Deleted

It’s important to be precise with these terms. They aren’t the same:

• Drifted: The resource is defined in your Infrastructure-as-Code, for example, declared in a .tf file and applied via terraform apply. But its current state in the cloud has changed outside that workflow. A typical case: someone updates an EC2 tag or security group manually in the AWS Console after deployment. The resource still exists in the Terraform state file, but the actual configuration has diverged from what's in the code.
  
• Unmanaged: The resource was never defined in IaC; it doesn’t exist in any Terraform, Pulumi, or CloudFormation config, nor in the state backend. It was created manually (e.g., using CI or via console), and your tooling has no record of it. Terraform doesn’t track it, CI/CD doesn’t validate it, and your policy engines can’t evaluate it. Unless you’re doing external scans, it’s invisible by default.
  
• Deleted: The resource has been removed from your cloud account, but it still exists in the state file. Terraform believes it’s still active and will attempt to recreate it on the next terraform apply. You’ll need to either redeploy the resource or remove it manually using terraform state rm.

Governance tooling that hooks while terraform plan or terraform apply (e.g., OPA with Sentinel or CI gates) can detect drift, but unmanaged resources aren’t even part of the evaluation input. They’re never passed to the policy engine. No scan, no alert, no violation.

Where Unmanaged Resources Typically Hide

Unmanaged resources don’t show up in Git diffs or PR reviews. But they absolutely show up in your AWS bill and security audit. Common hotspots:

• Legacy accounts nobody’s touched in months, but are still running resources.
  
• Quick manual fixes applied in production during an incident and never rolled back or codified.
  
• ClickOps deployments and resources are created via cloud consoles.

Unless you're continuously comparing live cloud state against your IaC configuration, these resources stay hidden, untagged, untracked, and entirely outside governance.

Here's how the diagram below shows that unmanaged resources, like manually created EC2 instances, bypass your policy engines, creating gaps in security, compliance, and cost management:

This is the visibility gap that breaks enforcement. Governance doesn’t start with policy; it starts with your resource inventory. If you can’t see it, you can’t secure it, control costs, or prove compliance.

Why Unmanaged Assets Are a Direct Threat to Governance

Unmanaged infrastructure isn’t just messy, it’s a blind spot that breaks every part of your governance model.

Your policy engine, security scanners, and cost monitoring tools rely on inputs from codified infrastructure, usually from your IaC definitions, Terraform state files, and CI/CD workflows. If a resource was created outside of Terraform and never onboarded into your infrastructure pipeline, it’s not going to be evaluated by tools like OPA, Sentinel, or tagging policies  because it doesn’t exist in their input scope.

Now, yes, services like AWS CloudTrail do log the event when a resource is created, even if it’s done manually. But CloudTrail isn’t a compliance engine; it’s a log stream. It records that something happened, but unless you’ve built a system to process those logs and compare them with IaC state, that resource remains unmanaged from a governance perspective. It won’t be subject to drift detection, policy checks, or cost tagging enforcement, because your tooling doesn’t know to include it in those evaluations.

That’s where the gap lies: CloudTrail sees the creation, but your governance layer doesn’t ingest it, track it, or enforce policy on it.

Here’s how unmanaged resources compromise each layer of governance:

1. Security

Unmanaged resources don’t pass through your IaC security controls. That means:

• IAM roles created manually may have wildcard permissions (‘*’) or lack least-privilege boundaries.
  
• Security groups might expose services publicly and allow ingress on port 22.
  
• S3 buckets could be publicly readable or missing encryption at rest.
  
• Lambda functions or EC2s might be deployed with old AMIs or vulnerable dependencies.

Worse, these assets don’t exist in Git. You have no commit history, no PR review, no audit trail. OPA policies or Sentinel rules applied during the terraform plan never evaluate these resources because they were never part of the input.

End result: you're running production infrastructure that completely bypasses your security policy framework.

2. Cost

Every unmanaged resource burns budget, but no one is responsible for it.

You’ll typically find:

• Unattached EBS volumes costing $0.10/GB/month, indefinitely.
  
• Idle EC2 instances from a load test that someone forgot to shut down.
  
• RDS snapshots are retained “just in case” from a deleted database.
  
• Elastic IPs are still reserved and billed, not attached to anything.
  
• Orphaned dev clusters are still consuming compute and storage daily.
  
  

Because these aren’t declared in Terraform or tagged with cost-center or environment, they don’t show up in your budget dashboards or cost attribution tools. You’ll only notice them when someone runs a manual audit or your AWS bill spikes unexpectedly.

3. Compliance

From a compliance standpoint, if it’s not tracked, it’s non-compliant.

For frameworks like SOC 2, ISO 27001, HIPAA, or PCI, you need to show:

• A complete inventory of infrastructure
  
• Ownership attribution (Owner, Team, Service)
  
• Tagging for purpose and environment
  
• Applied controls for encryption, backup, and logging
  
• Evidence of change control and audibility

If your auditor pulls a resource from AWS Config or GCP Asset Inventory and it’s not in your IaC system, you’ve already failed that control.

4. Operational Risk

The biggest risk comes when your infrastructure-as-code doesn’t match reality.

Your Terraform state says everything’s green. terraform plan shows no changes. CI/CD passes.

But:

• A developer manually spun up a critical EC2 instance during an outage, which is now in the hot path, but it’s invisible to Terraform.
  
• A DNS record used for production was created via the console there’s no record of it in Git.
  
• A shared security group was manually modified to allow extra access. Next time, terraform apply runs, it gets wiped out, breaking access in prod.
  
• A console-deleted resource (say, an ALB or S3 bucket) still exists in Terraform. The next deploy fails or, worse, silently recreates it with unintended settings.
  
  

These are real-world failure modes that stem from IaC-state drift caused by unmanaged resources. They create operational risk that your observability and governance tooling can’t see until it becomes a production incident.

Why Firefly Isn’t Just Another IaC Tool

Firefly isn’t another Terraform wrapper or CI plugin; it’s a fully context-aware governance control plane built around what actually exists in your cloud, not just what your IaC knows about.

Here's what Firefly does differently and why it matters.

1. Live Inventory with IaC Awareness

Firefly continuously builds a live inventory of all your resources across AWS, Azure, GCP, Kubernetes, and even SaaS. It doesn’t just list them, it tracks their management state:

• Codified: Resource exists in your IaC and matches your state file.
  
• Drifted: Exists in code but has config differences.
  
• Ghost: Defined in IaC, but no longer exists in the cloud.
  
• Unmanaged: Exists in the cloud, but isn’t defined anywhere in your code.
  
  

These are clearly marked in the Inventory table under “IaC Status”. You can filter based on these flags, along with tags, cloud region, and IaC type (e.g., Terraform) as shown in the snapshot below:

This is not a static scan. This is a real-time map of cloud reality compared to your IaC intent.

2. Codify, Import, or Clean Up in One Click

Once Firefly shows you unmanaged resources, you can act on them without bouncing through Terraform CLI gymnastics:

• Codify: Generate Terraform or Pulumi code blocks directly from the Inventory. No need to reverse-engineer cloud JSON.
  
• Import Blocks: Auto-generate terraform import stanzas.
  
• Provider Blocks: Set up your provider config if needed.
  
• Safe Delete: Select unmanaged assets, and Firefly gives you exact CLI commands to delete them cleanly. Nothing runs automatically; keep control.

No retooling. No breaking your workflows. Just the context and commands you need to clean up, codify, or ignore intentionally. 

Here’s a snapshot of a GCP Service Account detected as Unmanaged in Firefly:

You can use Thinkerbell AI Assistant to codify its Infrastructure as Code definition in seconds, as shown in the snapshot below:

3. Policy + Lifecycle Governance, Not Just Static Linting

Governance isn’t just about whether your .tf passes OPA policies. Firefly enforces governance across all resources, including those outside code, by layering KICS (OPA Rego-based) policy evaluation over your entire inventory as shown in the governance dashboard below:

You get:

• Built-in checks across encryption, network exposure, tagging, IAM, backup, etc.
  
• Custom Rego policies with support for complex expressions and filtered scoping.
  
• Drift cost impact: See the $$ difference between desired and actual infrastructure.

Without Firefly, you'd be stitching this together yourself: writing Python or Bash scripts to call AWS/GCP/Azure APIs, feeding raw JSON into custom Rego policies, running those checks on a schedule (probably via Jenkins or a cron job), and keeping separate logic to calculate things like drifted resource cost.

4. Unified View of Your Entire Cloud Infrastructure

The Firefly Realtime Dashboard provides a powerful, top-down overview of the governance posture of your entire cloud environment. It surfaces critical metrics and compliance indicators at a glance, across multiple data sources including AWS, GCP, Kubernetes, and SaaS integrations.

With a real-time sync to live cloud environments, it reflects both what exists and what's missing from your infrastructure-as-code. Here’s the dashboard view of your entire infrastructure:

Dashboard Insights Include:

• % Codified / Unmanaged / Drifted / Ghosted
  
  
  • Understand how much of your infrastructure is governed by IaC.
    
  • Identify unmanaged or ghosted resources and take action.

Without Firefly: You’d have to diff terraform state vs. live cloud APIs and write custom logic to label assets accordingly.

• Policy violations by severity
  
  
  • Gain instant visibility into security and compliance risks.

Without Firefly: Manually run OPA policies on IaC files and separately scan cloud resources, then correlate the two.

• ClickOps Detection
  
  
  • Track manual changes made outside the code to reduce configuration drift.

Without Firefly: Sift through CloudTrail or audit logs, write custom rules to catch unauthorized mutations, and tie them back to state files.

• Cloud Waste & Lifecycle View
  
  
  • Identify potential savings and detect outdated or idle assets.

Without Firefly: Build scripts to calculate usage metrics, tag age, and billing data, and then manually review each asset.

• Per-stack and Per-provider Views
  
  
  • Breakdown compliance posture by team, region, or cloud type.

Without Firefly: Maintain your own asset metadata (likely in spreadsheets or CMDB) to group and analyze resources.

This dashboard is not static or dependent on scan intervals. It reflects your actual, current cloud infrastructure, tightly linked to policy engines and codification tools, offering end-to-end visibility and actionability.

Governance Flow With and Without Firefly

Let’s be real, most teams have some governance, but it’s duct-taped together with scripts, spreadsheets, and tribal knowledge. This section breaks down how typical governance flows work today, and how Firefly simplifies or automates each step without locking you into its tooling.

Here’s a side-by-side comparison:

‍

This isn’t just about saving time; it’s about having governance that can keep up with cloud velocity. When IaC coverage is partial (which it is in every real-world org), most tools either ignore the problem or require huge manual effort to plug the gaps.

Firefly closes that gap without forcing you to change your stack.

FAQs

What are the five disciplines of cloud governance?

These typically break down into:

1. Cost Management – Track what’s running, what’s orphaned, and who’s spending what. Without proper tagging or IaC coverage, you’re flying blind.
   
2. Security – Control access (IAM, firewall rules), manage secrets properly, and make sure nothing is open to the world unless it’s meant to be.
   
3. Compliance – Implement frameworks like SOC2, NIST, or HIPAA through actual policy enforcement, not just checklists. Requires visibility into both managed and unmanaged assets.
   
4. Operations Management – Monitor, alert, and respond to drift, outages, or misconfigurations. This includes rollback and recovery tied to IaC, where possible.
   
5. Resource Consistency – Standardize provisioning via IaC and detect deviations. This includes enforcing org-wide baselines via policies.

What’s the difference between IT governance and cloud governance?

IT governance is broader it includes all tech, including on-prem hardware, data centers, laptops, and even help desk policies.

Cloud governance is more specific. It’s about what’s running in your cloud accounts and making sure every piece of infrastructure is secure, cost-efficient, compliant, and ideally defined as code. Traditional IT governance tools can’t handle the dynamic nature of the cloud.

What is cloud governance as code?

This means writing governance policies in a codified, version-controlled way, usually in Rego (OPA’s policy language). Instead of saying “all resources should be encrypted,” you write a rule that enforces it and attach it to every IaC plan or live cloud resource.

The real value comes when you apply those rules not just to code, but to live infrastructure, including unmanaged assets. That’s where most setups fall short.

What’s the difference between cloud management and cloud governance?

Cloud management is about day-to-day ops  provisioning, monitoring, scaling, and deploying. Think dashboards, alerts, and cost reports.

Cloud governance is about control and accountability. It answers:

• Who owns this resource?
• Is it compliant?
• Was it created through code?
• If not, should it be codified or deleted?
• Can we audit its lifecycle?

Management runs the cloud. Governance makes sure it’s being run the way it should be.

‍