Sam Aydlette

Many cloud vendors treat public sector compliance as an afterthought, resulting in half-baked solutions that turn their streamlined commercial offerings into Frankenstein monsters. OPA flips this model on its head by making compliance an impetus for building a world-class architecture.

The Business Model Everyone Misses

People often think compliance means higher costs and slower delivery. But that's simply not true. OPA enables a business model that offers lower costs with greater flexibility. Here's how it works:

Single Codebase, Multiple Deployments: Maintain one application codebase that deploys anywhere. OPA policies handle the regional differences. Your engineering team stops maintaining parallel codebases and starts shipping features. This dramatically reduces overhead costs and time to market for new services.

Rapid Sovereign Cloud Entry: New sovereign cloud region opens? Deploy your existing code with region-specific policies. What used to take months now takes days. You enter new markets while competitors scramble with compliance consultants.

Multi-Tenant Efficiency: Commercial customers share infrastructure. Government customers get dedicated, locked down single-tenants. Same code, different policies. You maximize resource utilization without compromising isolation requirements.

Compliance as a Service: Stop selling software; start selling compliant solutions. Embed compliance costs in your pricing model. Customers pay for outcomes, not audit reports.

The math works out and the profits start stacking up. Engineering costs drop because you maintain fewer codebases. Compliance costs drop because policies are reusable. Speed to market increases because deployment becomes configuration, not development. Revenue grows because you can serve any customer in any region without architectural changes. Forward thinking organizations are already adopting this model, while others are increasingly being left behind. The business landscape is changing quickly.

OPA in the Trenches: Real-World Use Cases

Consider a SaaS provider that wants to also offer sovereign cloud deployments across AWS, Azure, and Google Cloud. They need to enforce encryption at rest for all storage buckets and ensure compute instances meet specific hardening requirements.

With OPA, they write policies that check:

• S3 buckets have encryption enabled and use customer-managed keys
• Azure Blob containers enforce HTTPS-only access
• Google Cloud Storage buckets have uniform bucket-level access enabled
• EC2 instances use approved AMIs and have Systems Manager installed
• Azure VMs have disk encryption enabled and use managed identities
• Google Compute Engine instances have OS Login enabled and use custom service accounts

They also enforce tagging policies for cost allocation and data classification. Every resource must have CostCenter, DataClassification, and ComplianceScope tags. OPA rejects any Terraform plan, CloudFormation template, or ARM template that doesn't comply. No more orphaned resources bleeding money or storing sensitive data in unknown locations. No more discovering that your unmarked S3 bucket was actually storing customer PII when the auditors show up.

Runtime Enforcement: Steampipe + OPA

OPA is a policy engine, not a resource scanner. It evaluates rules but doesn't query your infrastructure. That's where Steampipe integration can take things to the next level with a single policy set to rule them all. Steampipe queries your cloud resources across AWS, Azure, and GCP, transforming them into SQL-queryable data. Here's how they work together:

Step 1: Steampipe Queries Resources

-- Find all unencrypted storage across clouds
SELECT
  resource_type,
  resource_id,
  region,
  encryption_status,
  tags
FROM
  all_storage_resources
WHERE
  encryption_status = 'none'

Step 2: Lambda Function Orchestrates

def lambda_handler(event, context):
    # Steampipe query results
    unencrypted_resources = steampipe.query(UNENCRYPTED_QUERY)
    
    # Pass to OPA for policy evaluation
    for resource in unencrypted_resources:
        decision = opa.evaluate('storage_encryption_policy', resource)
        
        if decision['remediate']:
            # Trigger remediation
            eventbridge.put_events(
                Source='compliance.opa',
                DetailType='RemediateStorage',
                Detail=json.dumps(resource)
            )

Step 3: OPA Evaluates Policies

package storage_encryption_policy

default remediate = false

# Critical data must be encrypted within 1 hour
remediate = true {
    input.tags.DataClassification == "Critical"
    time.now_ns() - input.created_timestamp > 3600000000000
}

# Non-prod gets 24 hours before remediation
remediate = true {
    input.tags.Environment != "Production"
    time.now_ns() - input.created_timestamp > 86400000000000
}

# Production requires manual approval
remediate = false {
    input.tags.Environment == "Production"
}

Step 4: EventBridge Routes Actions

• Critical resources: Auto-encrypt via Lambda
• Non-production: Send Slack notification, then auto-encrypt
• Production: Create Jira ticket for manual review

This pattern scales across hundreds of policies. Steampipe handles the "what's out there?" question, OPA answers "is it compliant?", and your automation layer handles "what do we do about it?" Each component does what it's best at. No need to find the holy grail tool that can do all in one.

To Engineers Reading This and Thinking "Give Me A Viable Migration Path or GTFO."

You're juggling seventeen priorities, program management keeps pinging you nonstop for status updates, and somewhere in your Slack notifications is a message about a critical production issue. The last thing you need is another "transformation initiative" promising to revolutionize your infrastructure.

Legacy systems still work. Sure, they're held together with bash scripts and prayers, but they generate revenue today. Now compliance wants quarterly attestations, sales promised enterprise customers features you haven't built yet, and the board is asking why you're not "AI-native" yet.

I get it. The idea of adding OPA to this chaos feels like a low priority. But OPA is different. Using OPA is how you reduce many of those other problems.

Immediate Value: The Blocking Audit Finding

Nothing motivates like a failed audit. If auditors flagged specific issues, write OPA policies that prevent these exact violations. Deploy them as admission controllers or pre-commit hooks.

Within one week, those audit findings become impossible to recreate. Your team literally cannot deploy the non-compliant resources that got you dinged. When auditors return, you don't scramble to prove compliance, you just show them the policies that make violations impossible. You've turned audit findings into automated preventions. Auditors love you, and you've got political cover for broader adoption.

The Money Conversation

Skip the philosophy. Here's what gets the budget approved: "We'll implement OPA incrementally with zero downtime. Phase 1 prevents the compliance violations that delayed our last launch by 3 months. Each phase is self-funding. ROI starts week one."

Add this kicker: "Some organizations are hiring expensive compliance consultants. Others are automating. Every policy written is permanent cost savings."

The Cultural Shift: From Gatekeepers to Enablers

For Developers: "OPA is spell-check for infrastructure. It catches mistakes before they cost money. Ship faster knowing you can't accidentally create compliance incidents."

For Security Teams: "Stop being the 'Department of No.' Write policies as code, not tickets. Define good patterns once, enforce them automatically forever."

For Program Managers: "Have real-time metrics on project blockers, responsible parties and actual costs the moment they are identified."

For Leadership: "Compliance becomes a competitive advantage. Enter new markets in days, not months. Turn audit prep from a fire drill into a dashboard review."

Some systems won't migrate easily. That legacy monolith with 10,000 hardcoded rules? Leave it alone until you're ready for a rewrite. OPA isn't magic and it can't fix technical debt. But it can ensure every new system is compliant by design while you gradually modernize the old ones. The migration will take time for meaningful adoption unless you have a very simple environment. But even with complex or legacy environments, you'll see value in the first week. Every policy you add is one less future audit finding or production incident. And as you build them, you can use the same policies pre-deployment as well as in production monitoring.

Your Next Monday Morning

Engineers, stop reading this blog post. Start doing this:

• 1. Download OPA locally
• 2. Write one policy for your biggest compliance pain point
• 3. Run it against your existing configurations
• 4. Count how many violations you find
• 5. Calculate the cost of those violations if they hit production

That number? That's your weekly ROI from adopting OPA. The migration path isn't an insurmountable mountain to climb. It's a series of profitable steps, each one making the next one easier. The question isn't "How do I migrate?" It's "How much money am I losing by not starting today?"