The Challenge
Cloud Platforms runs a suite of scans across a 160+ account AWS estate at Geoscience Australia - EC2, VPCs, security groups, S3, DNS, IAM and more - built up over time as an internal Streamlit toolset. Each scan did its job well, but the output only ever went one place: back into the tool, visible only to whoever had access to run it.
Account owners had no way to see the state of their own account without asking the platform team to look it up for them, and the platform team had no easy way to hand that data over without also handing over account IDs, VPC IDs and instance IDs that had no business leaving the tool. So results stayed put, misconfigurations stayed known only to whoever last ran the scan, and every "can you check X" request became a manual, one-off lookup.
What I Found
The gap wasn't the scanning logic - that already worked, resource by resource. The gap was everything downstream of it. Every scan produced its own shape of output, so there was no single, consistent way to browse results across EC2, VPCs, S3 and the rest. Nothing was published anywhere account owners could reach on their own, so visibility depended entirely on someone in Cloud Platforms being asked and being available. And whatever raw data did get shared carried identifiers - VPC IDs, instance IDs, full account numbers - that were fine internally but not something to hand around freely.
There was a second, more specific gap sitting inside the VPC scan data: provisioning a new VPC meant manually cross-referencing a proposed CIDR range against whatever the most recent export of assigned ranges happened to be, across 160+ accounts and every region. That process was slow, easy to get wrong, and entirely dependent on the export being current.
How I Approached It
I built a shared reporting pipeline that every scan feeds into, rather than a one-off export for each. Each scan module writes its results against a defined field list, strips or redacts identifying detail - VPC IDs and EC2 instance IDs are truncated, for example - and merges the result into a common HTML report template with sortable, filterable columns out of the box. That merge step and publishing happen automatically as part of the scan itself, so a fresh report is published the moment a scan completes, with no separate publishing step for anyone to remember.
Those reports land in a Cloud Centralised reporting CDN, with a shared intuitive template, so account owners can go straight to their account's data, search, filter and sort it, and leave with an answer instead of a ticket number to follow up.
On top of the Assigned CIDR Blocks report, I built a CIDR Block Generator that runs entirely client-side in the browser. It fetches that same live report at request time, evaluates a proposed parent range against every currently assigned CIDR block across the whole estate, and returns a randomly selected block guaranteed not to overlap with anything already in use - already split into three public and three private subnets, ready for design and approval review.
What Changed
Account owners can now see their own account's state - EC2, VPCs, security groups and more - without tool access and without asking anyone, using data that's never more than one scan old. Because sensitive identifiers are redacted as part of publishing rather than as an afterthought, those reports can be shared and looked at in the open, which is what turns a scan result into a transparency measure rather than an internal artefact.
Provisioning a new VPC no longer starts with a manual cross-check against a stale export - it starts with a generated CIDR range that has already been checked against every range currently assigned across the estate. And because the report pipeline is one system feeding many report types rather than one script per dataset, adding the next scan to the platform is a data-shape decision, not a new publishing mechanism to build.
Lessons for Enterprise Cloud Platform Management
Redaction belongs in the pipeline, not in someone's memory. Sensitive identifiers get stripped automatically as part of publishing, not as a manual step before a report goes out. A control that depends on someone remembering to apply it is a control that will eventually be skipped.
One report template beats one script per dataset. Driving every report from a shared, field-list-defined template means a new scan output is a data-shape decision, not new publishing code - and it's what let VPC, EC2 and every other report share one consistent, sortable, filterable experience from day one.
Decision-support tools are only trustworthy if they read live data. The CIDR generator is only useful because it checks a proposed range against the report as it stands right now, not against an export someone downloaded last month. Tooling built on stale data creates false confidence, which is worse than no tooling at all.
Visibility that requires asking doesn't stay current. Publishing automatically after every scan, rather than on request, is what keeps the data trustworthy enough for owners to rely on directly - and it's what actually closes the gap between an issue existing and someone noticing it.