Multi-Cloud Infrastructure Intelligence
Terracarta discovers what's actually running across AWS, Azure, and GCP, understands how it's wired together, and generates import-ready Terraform from it — closing the gap between the wiki that's out of date, the console that shows what exists, and the bill that shows what it costs.
Live discovery — read-only credentials
terracarta discover --provider aws --region us-east-1
terracarta graph -i resources.json
14 nodes · 19 edges
Topological order resolved — VPC → Security Group → RDS → EC2
3 clouds discovered $0 spent guessing
The Problem
The wiki says what infrastructure should exist. The console shows what actually exists. The bill shows what it costs. None of the three agree, and reconciling them by hand doesn't scale past a handful of accounts.
The wiki
Out of date the week after it's written. Documents intent, not reality — and nobody updates it when a resource is provisioned by hand.
The console
Shows what exists right now, one account and one region at a time, with no dependency context and nothing to hand to Terraform.
The bill
Shows what everything costs, but flattened by service — disconnected from which system it belongs to or whether it's actually needed.
Terracarta discovers, graphs, and prices real infrastructure directly — so cost, dependency, and configuration live in one artifact instead of three, and stay in sync every time discovery re-runs.
How It Works
Scan every account
Boto3, Azure SDK, and Google Cloud SDK crawl your accounts across one or many regions in a single pass, normalizing everything into a cloud-agnostic model.
Persist with provenance
Every resource upserts into Postgres with full config, raw API payload, and tags. Re-discovery moves resources through new → in_sync → drifted.
Map dependencies
A NetworkX-directed graph captures attached_to, member_of, routes_to, depends_on, and uses relationships, then resolves a topological build order.
Emit Terraform & diagrams
Jinja2 templates produce modular, import-ready HCL per resource, in dependency order — with a Mermaid architecture diagram generated alongside it.
Resource Coverage
Every provider maps into the same cloud-agnostic type before it enters the graph, the database, or the generator — so the rest of the system never has to know which cloud a resource came from.
| Cloud-Agnostic Type | AWS | Azure | GCP |
|---|---|---|---|
| compute_instance | EC2 | Virtual Machines | Compute Engine VMs |
| database_instance | RDS | PostgreSQL Flexible Server | Cloud SQL |
| object_storage | S3 | Storage Accounts | Cloud Storage |
| virtual_network | VPC | Virtual Networks | VPC Networks |
| identity_role | IAM Roles | Role Assignments | IAM Bindings |
| firewall_rule | Security Groups | Network Security Groups | Firewall Rules |
Generated Output
Output structure mirrors what terraform import expects — modular, dependency-ordered, and paired with an architecture diagram generated in the same pass. Pass --no-diagram to skip it.
FinOps Module
A CUR 2.0 ingestor amortizes Reserved Instance and Savings Plan costs correctly using Decimal arithmetic throughout, then rolls spend up through the dependency graph — so a shared NAT Gateway's cost is attributed across every EC2 instance behind it.
Unmanaged Spend
18.4%
Waste %
11.2%
Tag Coverage
76%
Commitment Utilization
92%
Built to Extend
Cloud-agnostic core
An abstract BaseProvider interface means a new cloud provider adds zero changes to the database, graph, or generator.
Template-driven generation
A new resource type needs a Jinja2 template and a normalizer function — nothing else in the pipeline changes.
Pluggable cost allocation
Shared-dependency cost rollup runs through a pluggable AllocationStrategy, defaulting to an even split across dependents.
Read-only by design
The FinOps IAM policy is scoped to Cost Explorer, CloudWatch, the Pricing API, and the CUR bucket — nothing that can modify infrastructure.
CLI
REST API
Get in touch
If your cloud footprint has outgrown the wiki and the console disagrees with the bill, that's exactly the gap Terracarta closes.