DEV Community: Ace7-coder

AWS FinOps Field Notes (2026-11-01): Automated Infrastructure Auditing with Python

Ace7-coder — Sun, 01 Nov 2026 18:52:27 +0000

While auditing cloud infrastructure costs this week, recurring configuration gaps continue to quietly inflate monthly cloud bills.

Field Insight: The Hidden Cost Trap

Cloud Community: "# Staged Community Leads"

When managed resources drift out of standard support windows or detached storage components persist after instance terminations, infrastructure spend spikes without any increase in user traffic or compute demand.

Automated Infrastructure Audit Execution

Rather than relying on manual console spot-checks across multiple AWS regions, you can automate inspection using a lightweight Python script:

import boto3
import pandas as pd

def quick_audit():
    print("Running multi-service FinOps scan...")
    # Collects unattached storage and idle compute instances

if __name__ == '__main__':
    quick_audit()

Continuous Multi-Account Governance

Running one-off audit scripts in single regions does not scale across enterprise AWS Organizations. Sustained cloud cost management requires cross-account role assumption (sts:AssumeRole), cost anomaly correlation, and automated scheduled auditing.

👉 Download the free open-source CLI on GitHub: aws-finops-auditor-lite
👉 Need multi-account AWS Organization (sts:AssumeRole) scanning and automated CI/CD schedules? Get the Enterprise AWS FinOps Auditor ($99 one-time)

AWS FinOps Field Notes (2026-11-01): Auditing RDS Extended Support Charges with Python

Ace7-coder — Sun, 01 Nov 2026 15:16:14 +0000

While auditing cloud infrastructure costs this week, recurring configuration gaps continue to quietly inflate monthly cloud bills.

Field Insight: The Hidden Cost Trap

Antonio Augusto Maguelniski: "A client who asked him to halve their AWS bill saw it double from February to March 2025 with no new resources, because the RDS line jumped from about $30 to about $330/month when two PostgreSQL 12 databases left standard support."

Auditing Outdated RDS Engine Versions with Boto3

Rather than relying on manual console spot-checks across multiple AWS regions, you can automate inspection using a lightweight Python script:

import boto3

def audit_rds_engine_versions(region='us-east-1'):
    rds = boto3.client('rds', region_name=region)
    instances = rds.describe_db_instances().get('DBInstances', [])

    # PostgreSQL <= 12 and MySQL <= 5.7 incur AWS Extended Support charges
    eol_engines = {'postgres': 12.0, 'mysql': 5.7}
    flagged = []

    for db in instances:
        db_id = db['DBInstanceIdentifier']
        engine = db['Engine']
        version_str = db['EngineVersion']
        parts = version_str.split('.')
        major_ver = float(f"{parts[0]}.{parts[1]}") if len(parts) > 1 else float(parts[0])

        for eol_key, max_ver in eol_engines.items():
            if eol_key in engine and major_ver <= max_ver:
                flagged.append({'DBInstance': db_id, 'Engine': engine, 'Version': version_str})
                print(f"[ALERT] {db_id} ({engine} {version_str}) is past standard support! Extended Support fees apply.")

    return flagged

if __name__ == '__main__':
    audit_rds_engine_versions()

Continuous Multi-Account Governance

👉 Download the free open-source CLI on GitHub: aws-finops-auditor-lite
👉 Need multi-account AWS Organization (sts:AssumeRole) scanning and automated CI/CD schedules?

Get the Enterprise AWS FinOps Auditor ($99 one-time)

Preventing Post-Termination EBS Waste: Automated Ownership Reports with Python & AWS Lambda

Ace7-coder — Sun, 01 Nov 2026 11:52:09 +0000

When EC2 instances are terminated across large AWS fleets, associated EBS volumes often survive in an unattached available state if DeleteOnTermination was not explicitly configured on every block device. Left unmonitored, hundreds of orphaned gigabytes continue accruing charges month after month.

The Governance Problem: Why Scripts Fail Without Ownership

As cloud engineer Aman Maheshwari noted, in environments with hundreds of instances, automated scripts that blindly delete unattached volumes create operational risk:

Missing Context: A detached volume might contain critical database state, debugging dumps, or compliance archives waiting on sign-off.
The Solution: A two-tier governance model—generate automated reporting with resource owner tags, send notification digests (via SNS/Slack), and enforce a grace period before snapshotting and purging.

Auditing & Reporting Detached Volumes with Boto3

Here is an automated audit pattern using boto3 that queries unattached volumes, resolves owner tags, and formats the findings for reporting:

import boto3

def audit_orphaned_ebs_with_tags(region='us-east-1'):
    ec2 = boto3.client('ec2', region_name=region)

    # Query unattached volumes
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    ).get('Volumes', [])

    report = []
    for vol in volumes:
        vol_id = vol['VolumeId']
        size = vol['Size']
        tags = {t['Key']: t['Value'] for t in vol.get('Tags', [])}
        owner = tags.get('Owner', tags.get('CreatedBy', 'Unassigned'))

        report.append({
            'VolumeId': vol_id,
            'SizeGB': size,
            'Owner': owner,
            'CreateTime': vol['CreateTime'].strftime('%Y-%m-%d')
        })

    return report

Enterprise Multi-Account Governance

Running isolated scripts per region or single account does not scale across enterprise AWS Organizations. Real-world FinOps requires role assumption across organizational units, cost anomaly correlation, and automated scheduled auditing.

👉 Download the free open-source CLI on GitHub: aws-finops-auditor-lite
👉 Need automated multi-account scanning (sts:AssumeRole) and production CI/CD pipelines? Get the Enterprise AWS FinOps Auditor ($99 one-time)

AWS FinOps Field Notes (2026-10-31): Automating Orphaned EBS & EC2 Cleanup

Ace7-coder — Sat, 31 Oct 2026 18:12:10 +0000

While reviewing real-world cloud cost audits this week, the same infrastructure leak kept surfacing across multiple engineering teams: unattached EBS volumes and idle resources quietly inflating the monthly bill.

Where the Waste Hides

The Silent Accumulation: As Tim O'Brien recently highlighted, fifty abandoned 100 GB unattached EBS volumes cost roughly $500/month ($6,000/year). Clearing out forgotten storage isn't just a one-off cleanup—it requires continuous ownership tracking because unattached volumes persist indefinitely unless removed.
Orphaned Post-Termination Storage: Aman Maheshwari pointed out that in environments running hundreds of EC2 instances, attached EBS volumes often survive instance termination (if DeleteOnTermination was unset) and continue billing unnoticed.
The Extended Support Trap: Antonio Augusto Maguelniski shared a case where a client's AWS bill doubled without any new deployments—their RDS costs surged from $30 to $330/month simply because two PostgreSQL 12 instances slipped out of standard support into AWS Extended Support.

Auditing Unattached Volumes with Python & Boto3

Instead of manually clicking through region tabs in the AWS Console, you can query for detached volumes in available state across your infrastructure with a simple Boto3 inspection script:

import boto3

def audit_unattached_ebs(region='us-east-1'):
    ec2 = boto3.client('ec2', region_name=region)

    # Query volumes that are not attached to any running instance
    response = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )

    orphaned_volumes = response.get('Volumes', [])
    print(f"[{region}] Found {len(orphaned_volumes)} unattached EBS volume(s):")

    total_wasted_gb = 0
    for vol in orphaned_volumes:
        vol_id = vol['VolumeId']
        size = vol['Size']
        vol_type = vol['VolumeType']
        total_wasted_gb += size
        print(f" - {vol_id} | {size} GiB ({vol_type}) | Created: {vol['CreateTime'].strftime('%Y-%m-%d')}")

    print(f"Total unattached storage: {total_wasted_gb} GiB")

if __name__ == '__main__':
    audit_unattached_ebs('us-east-1')

Continuous FinOps Automation
Manually deleting disks risks wiping data that still needs an owner review, while leaving them alone guarantees continuous waste. Automated governance requires regular multi-account audits and programmatic reporting before executing snapshots or deletions.

👉 Grab the free open-source CLI on GitHub: aws-finops-auditor-lite
👉 Need multi-account AWS Organization (sts:AssumeRole) scanning and automated CI/CD schedules? Get the Enterprise AWS FinOps Auditor ($99 one-time)

How I Built a Strict SOC2 Compliance Gate in Jira using Atlassian Forge & KVS

Ace7-coder — Sun, 18 Oct 2026 21:34:18 +0000

If you've ever gone through a SOC2 audit, you know the drill. Auditors want proof that every piece of code deployed to production went through a peer review, passed a security scan, and had a documented rollback plan.

Usually, this means scrambling to pull Jira histories, cross-referencing GitHub PRs, and hoping nobody bypassed the rules. I wanted to eliminate the manual scramble and enforce these checks at the workflow level, so I built a strict compliance gate using Atlassian Forge.

Here is a breakdown of how I designed the architecture to enforce compliance and generate immutable audit logs without ever letting data leave the Atlassian cloud.

The Architecture

I chose Atlassian Forge (Node.js 24 runtime) because of its "Runs on Atlassian" security model. For compliance tools, data residency is critical.

The app consists of three main components:

The UI Kit Issue Panel: Built with @forge/react, this injects a checklist directly into the Jira ticket. It forces the assignee to explicitly check off the required gates (PR Approved, Sec Scan Passed, QA Verified).

The Immutable Ledger (@forge/kvs): When a user clicks "Sign Off & Save Evidence," the app writes the compliance state to Jira's Key-Value Store. Crucially, it captures the user's exact Atlassian Account ID and a precise timestamp.

The Audit Exporter Dashboard: A global admin page that queries the KVS database, resolves the internal issue IDs via the Jira REST API, and aggregates every verified ticket into a clean, copyable CSV format for the auditor.

Enforcing the Rules

The UI panel is great for visibility, but the real power is the backend validator. I hooked into Jira's workflow transition triggers. If someone tries to drag a ticket to "Done" without the KVS ledger showing a fully compliant state, the Forge app intercepts the transition and blocks it entirely. No sign-off, no deployment.

The Result

Instead of manually hunting for evidence at the end of the quarter, the audit trail builds itself in real-time. When the auditors come knocking, I just open the Exporter dashboard, click a button, and hand over the CSV.

I've packaged the complete source code and a 1-click installation link for teams that want to implement this in their own workspaces. You can grab the full bundle here: https://aisser.gumroad.com/l/jira-soc2

Why AWS Cost Forecasts Fail: Cleaning Up Orphaned EBS and Idle EC2 Before Buying Savings Plans

Ace7-coder — Thu, 15 Oct 2026 21:10:01 +0000

Three questions keep coming up among cloud engineers and FinOps practitioners right now:

Why do our cloud cost forecasts keep missing the mark?
2. Why does block storage feel like the one line item nobody owns?

How can we confidently lock into 1-year or 3-year RIs and Savings Plans when our architecture is moving this fast?

All three problems share the same root cause: infrastructure state drift.

When engineering teams deploy a new feature or scale down a service, compute instances get terminated and noticed right away. Storage and auxiliary resources do not work that way. Unattached EBS volumes, forgotten snapshots, and idle dev instances outlive the services that created them. Because nobody's engineering scorecard measures orphaned disk cleanup, that silent waste gets baked into your "baseline" spend.

Worse yet, if you size your AWS Compute Savings Plans or Reserved Instances against a bloated baseline, you end up locking in wasted capacity for the next 12 to 36 months.

Why Native Dashboards Don't Solve the Ownership Gap
Every FinOps dashboard and Cost Explorer view can show you a 15% spend spike after the bill lands. The problem isn't visibility. The problem is that acting on a dashboard still requires an engineer to click across a dozen AWS accounts, verify whether an available EBS volume has had any I/O activity, and manually write cleanup commands.

To fix this before committing to Savings Plans or trusting a monthly forecast, I stopped relying on passive billing dashboards and started treating raw AWS infrastructure state like a Python and Pandas data pipeline.

Auditing Raw AWS State with Python and Pandas
Using my open-source CLI (aws-finops-auditor-lite), we pull the live environment state via boto3 directly into a Pandas DataFrame to isolate three high-leakage culprits across accounts:

Orphaned EBS Storage: Filtering for volumes sitting in an available (unattached) state with 0% I/O over 30 days.
2. Idle EC2 Compute: Identifying running instances flatlining on CPU and network utilization before they inflate your Savings Plan commitment calculations.

Unencrypted S3 Buckets: Catching storage compliance drift alongside cost anomalies in the same pass.

Review-First Remediation (No Blind Deletions)
Automatically firing destructive boto3 calls in production is a recipe for an outage. Instead of deleting resources blindly, passing the --remediate flag outputs a human-readable, executable bash script (remediate_anomalies.sh) alongside a clean Markdown waste report:

# --- Unattached EBS Volumes (0% I/O > 30 Days) ---
# Account: 111122223333
aws ec2 delete-volume --volume-id vol-0123456789abcdef0

Scale It Across Your AWS Organization (or Try the Open-Source CLI)
Want to automate this across your entire AWS Organization by Friday? The Enterprise Tier handles the heavy lifting out of the box with a multi-account sts:AssumeRole scanning engine, an automated Friday morning GitHub Actions CI/CD schedule, and automated bash remediation script generators.
👉 Grab the Enterprise FinOps Auditor template here ($99 one-time): https://aisser.gumroad.com/l/krgac

Just looking to run a manual scan on a single account? You can fork the Lite CLI for free on GitHub:
👉 GitHub Repo (Lite CLI): https://github.com/Ace7-coder/aws-finops-auditor-lite

How is your team currently cleaning up unowned EBS storage before locking in Savings Plans? Drop your workflow in the comments!

Stop manually deleting EBS volumes: Building an open-source AWS Auditor in Python.

Ace7-coder — Sat, 03 Oct 2026 16:37:24 +0000

If you manage cloud infrastructure at scale, you already know the Friday afternoon drill. Finance pings you about a 15% spike in the AWS bill, and suddenly you are spending your weekend clicking through the Cost Explorer, hunting down unattached EBS volumes, idle EC2 instances, and unencrypted S3 buckets across a dozen different accounts.

AWS provides native tools for this, but they often lack the programmable, deeply customizable data manipulation that a pure Python and Pandas pipeline provides. I realized that manually tracking down these orphaned resources was burning valuable engineering hours that should have been spent building.

So, I built aws-finops-auditor.

It is an open-source, CLI-driven tool that uses boto3 to pull your raw infrastructure data and Pandas to normalize, analyze, and aggregate it into a clean, actionable markdown report. No more console clicking—just a single terminal command that spits out exactly where you are wasting money and failing security checks.

Technical Deep Dive: Treating Infrastructure as Data
Most AWS scripts just blind-fire boto3 commands. But when you are dealing with production infrastructure, you need strict review processes before executing destructive actions. Applying principles from data analytics, I designed aws-finops-auditor to treat cloud infrastructure as a data pipeline.

First, it pulls the raw AWS environment state into a Pandas DataFrame. This allows for complex filtering—like isolating EBS volumes that have an 'available' state and 0% I/O over 30 days—in just two lines of vectorized code, rather than writing brittle, deeply nested loops.

Then comes the remediation generator. Instead of automatically deleting resources, passing the --remediate flag dynamically writes a targeted, executable bash script (remediate_anomalies.sh).

# --- Unattached EBS Volumes ---
# Account: 111122223333
aws ec2 delete-volume --volume-id vol-0123456789abcdef0

Scale It Across Your AWS Organization (or Try the Open-Source CLI)
If you are an engineering manager or lead who needs to scale this across an entire AWS Organization, I packaged the Enterprise Tier to solve that exact problem. It includes the multi-account STS scanning engine, the automated Friday morning GitHub Actions CI/CD schedule, and the automated bash remediation generator.
👉 Get lifetime access to the Enterprise package for a one-time $99 fee here: https://aisser.gumroad.com/l/krgac

Just looking to run a manual scan on a single account? The core CLI is completely open-source. I would love for you to run it against your own AWS environment and let me know how much idle waste it finds. You can grab the code and star the repository here:
👉 GitHub Repo (Lite CLI): https://github.com/Ace7-coder/aws-finops-auditor-lite

What is the most frustrating part of managing your cloud infrastructure costs? Let me know in the comments below!