Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

FinOps as Code: DoiT Cloud Intelligence mit Terraform steuern

By Hannes HayashiJun 25, 202611 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Sie versionieren Ihre Infrastruktur. Sie reviewen Pull Requests für Anwendungscode. Aber was ist mit Ihrer FinOps-Konfiguration – Ihren Budgets, Kostenallokationen, Alerts und Analytics-Reports?

In den meisten Teams liegt all das in einer UI. Jemand klickt sich durch einen Wizard, setzt einen Schwellenwert, wählt einen Filter und hofft, dass die nächste Person, die etwas ändern muss, die ursprüngliche Absicht nachvollziehen kann. Keine Historie, kein Peer Review, keine Möglichkeit, das Setup über Umgebungen hinweg zu replizieren. Wenn Ihre FinOps-Praktiken genauso geschäftskritisch sind wie Ihre Infrastruktur, verdienen sie auch dieselbe Sorgfalt.

Genau dafür haben wir den DoiT Terraform Provider entwickelt. Er bringt Ihre DoiT Cloud Intelligence Konfiguration in denselben Infrastructure-as-Code-Workflow, den Sie ohnehin für Ihre Cloud-Ressourcen nutzen – mit 17 Managed Resources und 61 Data Sources, die alles abdecken: von Budgets und Reports über Abfragen an den AI-Assistenten bis hin zu Cloud-Infrastruktur-Diagrammen.

Erste Schritte

Für den Einstieg reichen ein Provider-Block und ein API-Key:

terraform {
required_providers {
doit = {
source = "doitintl/doit"
version = "~> 1.0"
}
}
}
provider "doit" {}

Setzen Sie DOIT_API_TOKEN in Ihrer Umgebung (API-Keys erstellen Sie in der DoiT Console) – und schon kann es losgehen. Mehr Konfiguration ist nicht nötig.

Der zentrale FinOps-Workflow

Schauen wir uns die Resources an, zu denen die meisten Teams als Erstes greifen: Allocations, Budgets, Alerts und Reports. Zusammen bilden sie eine vollständige FinOps-Pipeline – und wer sie als Code verwaltet, kann das gesamte Setup versionieren, reviewen und replizieren.

Cost Allocations

Mit Allocations schneiden Sie Ihre Cloud-Ausgaben in sinnvolle Kategorien. Der Provider unterstützt eine boolesche Formel-Engine zum Kombinieren von Filterkriterien, Group Allocations, die Kosten in benannte Buckets aufteilen, und sogar verschachtelte Allocations, die per ID auf andere Allocations verweisen.

Hier ein Beispiel für eine Group Allocation, die Kosten nach Region aufteilt – inklusive Sammelkategorie für alles, was nicht passt:

resource "doit_allocation" "by_region" {
name = "By Region"
description = "Group costs by geographic region"
unallocated_costs = "Other Regions"
rules = [
{
action = "create"
name = "US"
formula = "A"
components = [{
key = "country", mode = "is", type = "fixed", values = ["US"]
}]
},
{
action = "create"
name = "Europe"
formula = "A"
components = [{
key = "country", mode = "is", type = "fixed", values = ["DE", "FR", "GB", "NL"]
}]
}
]
}

Brauchen Sie eine feinere Granularität? Mit type = "allocation_rule" in einer Komponente verweisen Sie auf eine bestehende Allocation – so lassen sich Allocations aus anderen Allocations zusammensetzen, bis zu 3 Ebenen tief. Statt Dimensionswerte wie "US" oder "DE" fest zu verdrahten, können Sie die Data Source doit_dimension nutzen, um gültige Werte dynamisch über die API zu ermitteln.

Budgets

Budgets sind die Leitplanken. Der Provider erlaubt es Ihnen, Alerts mit mehreren Schwellenwerten zu definieren, Budgets auf bestimmte Allocations oder Dimensionen einzugrenzen und – ein besonders nützliches Muster – Collaborators nach Jobfunktion zu filtern, statt jeden Nutzer der Organisation einzeln hinzuzufügen:

data "doit_users" "all" {}
locals {
engineers = [
for u in data.doit_users.all.users : u
if u.job_title == "Software / Ops Engineer"
]
}
resource "doit_budget" "eng_budget" {
name = "Engineering Budget"
currency = "USD"
type = "recurring"
amount = 10000
time_interval = "month"
start_period = provider::time::rfc3339_parse("2026-01-01T00:00:00Z") * 1000
alerts = [
{ percentage = 50 },
{ percentage = 80 },
{ percentage = 100 }
]
collaborators = concat(
[{ email = data.doit_current_user.me.email, role = "owner" }],
[for u in local.engineers : { email = u.email, role = "viewer" }]
)
recipients = [for u in local.engineers : u.email]
scopes = [{
type = "allocation_rule"
id = "allocation_rule"
mode = "is"
values = [doit_allocation.by_region.id]
}]
}

Dieses Budget ist auf die zuvor erstellte Region-Allocation begrenzt und benachrichtigt ausschließlich Nutzer mit dem Jobtitel "Software / Ops Engineer". Budgets unterstützen außerdem seasonal_amounts für Monate mit abweichenden Spend-Zielen, und berechnete Felder wie current_utilization und forecasted_utilization stehen als Read-only-Outputs zur Verfügung.

Alerts

Alerts lösen Benachrichtigungen aus, sobald Kosten oder Nutzung einen Schwellenwert überschreiten. Die eigentliche Stärke liegt im Scoping – Sie können einen Alert auf einen bestimmten Cloud-Provider, einen Service, eine Region oder jede beliebige Dimension einschränken. Das folgende Beispiel nutzt die Data Source doit_products, um die Service-ID von Compute Engine dynamisch nachzuschlagen, statt sie fest zu verdrahten:

data "doit_products" "gcp" {
platform = "google_cloud_platform"
}
resource "doit_alert" "compute_cost" {
name = "GCP Compute Cost Alert"
config = {
metric = { type = "basic", value = "cost" }
time_interval = "day"
value = 500
currency = "USD"
condition = "value"
operator = "gt"
scopes = [{
type = "fixed"
id = "service_description"
mode = "is"
values = [
for p in data.doit_products.gcp.products : p.id
if p.display_name == "Compute Engine"
]
}]
}
recipients = [data.doit_current_user.me.email]
}

Reports

Cloud-Analytics-Reports sind die funktionsreichste Resource im Provider. Sie können bis zu 4 Metriken konfigurieren, Year-over-Year-Vergleiche mit secondary_time_range ergänzen, Filter und Group-by-Dimensionen anwenden und Reports in Ordnern organisieren.

resource "doit_report" "monthly_costs" {
name = "Monthly Cost Report"
description = "Tracks monthly costs across cloud providers with YoY comparison"
config = {
metrics = [
{ type = "basic", value = "cost" },
{ type = "basic", value = "usage" }
]
aggregation = "total"
time_interval = "month"
data_source = "billing"
time_range = {
mode = "last"
amount = 3
include_current = true
unit = "month"
}
secondary_time_range = {
amount = 1, unit = "year", include_current = false
}
filters = [{
id = "cloud_provider", type = "fixed", mode = "is"
values = ["amazon-web-services", "google-cloud"]
}]
group = [{ id = "cloud_provider", type = "fixed" }]
layout = "table"
display_values = "actuals_only"
currency = "USD"
}
}

Wenn Sie gültige Dimension-IDs und -Typen für Filter und Gruppierungen ermitteln müssen, liefert die Data Source doit_dimensions einen vollständigen Katalog – Schluss mit Raten.

Mehr als nur FinOps

Die zentralen FinOps-Resources sind für die meisten Teams der Einstieg, aber der Provider deckt deutlich mehr von der DoiT-Plattform ab. Einige dieser Features kennen Sie vielleicht nicht einmal aus der Console – sie als Code zu verwalten, ist ein guter Weg, sie zu entdecken.

Ava direkt aus Terraform fragen

Ja, Sie können Ava – den AI-Assistenten von DoiT – direkt aus Ihrer Terraform-Konfiguration heraus abfragen. Besonders praktisch: Sie können im Prompt auf Report-IDs aus anderen Terraform-Resources verweisen:

data "doit_ava" "report_summary" {
question = "Can you summarize report ${doit_report.monthly_costs.id} for me?"
}
output "report_summary" {
value = data.doit_ava.report_summary.answer
}

Einen Report anlegen und ihn sich unmittelbar danach von Ava erklären lassen – alles im selben terraform apply. Genauso lassen sich schnelle Abfragen wie "Was sind meine Top-3-Cloud-Services nach Kosten in diesem Monat?" einbauen und die Antwort direkt in Terraform-Outputs leiten.

Ad-hoc-Analytics-Abfragen

Manchmal brauchen Sie keinen dauerhaften Report – Sie wollen einfach nur eine Frage beantworten. Die Data Source doit_report_query führt Cloud-Analytics-Abfragen on the fly aus und liefert strukturiertes JSON zurück, das Sie parsen, transformieren oder exportieren können:

data "doit_report_query" "cost_by_provider" {
config = {
metrics = [{ type = "basic", value = "cost" }]
aggregation = "total"
time_interval = "month"
currency = "USD"
time_range = {
mode = "last", amount = 3, include_current = true, unit = "month"
}
group = [{ id = "cloud_provider", type = "fixed" }]
}
}
locals {
result = jsondecode(data.doit_report_query.cost_by_provider.result_json)
columns = [for s in local.result.schema : s.name]
}
resource "local_file" "query_csv" {
filename = "cost_by_provider.csv"
content = join("\n", concat(
[join(",", local.columns)],
[for row in local.result.rows :
join(",", [for cell in row : cell == null ? "" : tostring(cell)])]
))
}

Besonders nützlich für Cost Gates in CI/CD – Abfrage in der Pipeline ausführen, prüfen, ob die Ausgaben einen Schwellenwert überschreiten, und den Build im Zweifel scheitern lassen. Mit doit_report_result rufen Sie zudem Ergebnisse aus bereits gespeicherten Reports ab.

Cloud Diagrams als Mermaid-Flowcharts

Der Provider enthält 12 Data Sources für das Feature Cloud Diagrams und deckt damit Suche, Export, Relationships, Snapshots und Statistiken ab. Ein kreativer Anwendungsfall: Mermaid-Flowcharts aus Ihrer Cloud-Infrastruktur-Topologie generieren und sie direkt in READMEs, Confluence-Seiten oder Incident-Reports einbetten.

data "doit_cloud_diagrams_search" "project" {
query = "my-gcp-project"
}
data "doit_cloud_diagrams_schemes" "diagram" {
layer_ids = [data.doit_cloud_diagrams_search.project.scheme[0].ss_id]
components = true
link = true
}
locals {
ss = data.doit_cloud_diagrams_schemes.diagram.statussheet[
data.doit_cloud_diagrams_search.project.scheme[0].ss_id
]
node_lines = [
for id, n in local.ss.node :
" ${id}[\"${replace(coalesce(n.name, id), "\"", "#quot;")}\"]"
]
edge_lines = [
for id, l in local.ss.link :
l.connection_type != null
? " ${l.origin._id} -->|${l.connection_type}| ${l.destination._id}"
: " ${l.origin._id} --> ${l.destination._id}"
]
mermaid = join("\n", concat(["flowchart LR"], local.node_lines, local.edge_lines))
}
output "mermaid" {
value = local.mermaid
}

Fügen Sie den Output in mermaid.live oder einen beliebigen Markdown-Renderer ein, und Sie erhalten eine visuelle Darstellung Ihrer Infrastruktur-Beziehungen – Topologie-Diffs im Zeitverlauf, Compliance-Snapshots oder einfach einen schnellen Überblick, was womit verbunden ist.

Sharing & Access Control

Wer Ihre FinOps-Resources sehen darf, wird gerne mal hinten angestellt – bis es dann doch wichtig wird. Die Resource doit_sharing erlaubt es Ihnen, Berechtigungen für Reports, Budgets, Alerts und Allocations zu definieren:

locals {
permissions = [
{ user = data.doit_current_user.me.email, role = "owner" },
{ user = "[email protected]", role = "editor" },
{ user = "[email protected]", role = "viewer" },
]
}
resource "doit_sharing" "report" {
resource_type = "reports"
resource_id = doit_report.monthly_costs.id
permissions = local.permissions
public = "viewer" # Grant org-wide read access
}

Definieren Sie Ihre Permission Sets einmal in locals und wenden Sie sie konsistent auf jede geteilte Resource an. Kombinieren Sie das mit doit_user, um neue Teammitglieder zu onboarden, und mit doit_roles, um verfügbare Rollen zu ermitteln – alles aus Ihrer Terraform-Konfiguration heraus.

Annotations & Labels

Haben Sie schon einmal einen Kostenpeak von vor sechs Monaten gesehen und sich gefragt, was damals eigentlich passiert ist? Mit Annotations dokumentieren Sie Cost Events – Deployments, Migrationen, Incidents – direkt an Ihren Kostendaten:

resource "doit_label" "infrastructure" {
name = "infrastructure"
color = "blue"
}
resource "doit_annotation" "black_friday" {
content = "AWS cost spike due to Black Friday traffic"
timestamp = "2024-11-29T00:00:00Z"
reports = [doit_report.monthly_costs.id]
labels = [doit_label.infrastructure.id]
}

Labels und Label-Zuweisungen ermöglichen ressourcenübergreifendes Tagging – kategorisieren Sie Reports, Alerts und Annotations nach Team, Projekt oder einer beliebigen Taxonomie, die für Ihre Organisation Sinn ergibt.

Skalierbar organisieren mit Folders

Wenn Ihre Terraform-gesteuerte FinOps-Konfiguration wächst, sorgen Folders für Ordnung. Sie lassen sich verschachteln und funktionieren sowohl mit Reports als auch mit Allocations:

resource "doit_folder" "analytics" {
name = "Analytics"
description = "Cloud Analytics reports and dashboards"
}
resource "doit_folder" "cost_reports" {
name = "Cost Reports"
description = "Monthly and quarterly cost breakdowns"
parent_folder_id = doit_folder.analytics.id
}
resource "doit_report" "monthly_costs" {
name = "Monthly Cost Overview"
folder_id = doit_folder.cost_reports.id
# ... report config ...
}

Mit Custom Themes können Sie Ihre Analytics zusätzlich im Corporate Design anpassen – definieren Sie Farbpaletten für Light und Dark Mode, die auf die Charts der Cloud-Analytics-Reports angewendet werden, und verleihen Sie Ihren Dashboards einen sauberen, markenkonformen Look.

AWS CloudConnect Onboarding

AWS-Accounts an DoiT anzubinden, ist in der Regel ein mehrstufiger Prozess: IAM-Rolle erstellen, S3-Bucket konfigurieren, Account registrieren. Wir haben dafür ein dediziertes Terraform-Modul veröffentlicht, das den gesamten Stack in einem einzigen terraform apply abwickelt:

module "doit_cloudconnect" {
source = "doitintl/doit-cloudconnect/aws"
version = "~> 1.0"
}

Das Modul legt IAM-Rolle, S3-Bucket und CloudConnect-Registrierung in einem Rutsch an. Wer im Enterprise-Umfeld Dutzende Accounts onboardet, kombiniert es mit for_each über eine Account-Liste. Wenn Sie mehr Kontrolle brauchen, steht die zugrunde liegende Resource doit_cloudconnect_aws_account auch direkt zur Verfügung.

Custom Insights

Wenn Sie eigene Optimierungs-Checks fahren – Scans auf ungenutzte Ressourcen, Identifikation von Right-Sizing-Potenzialen, Hinweise auf Sicherheitsprobleme – können Sie Findings direkt in die DoiT Console publizieren:

resource "doit_insight" "unused_instances" {
key = "unused-ec2-instances"
title = "Unused EC2 Instances"
short_description = "EC2 instances with consistently low CPU utilization"
cloud_provider = "aws"
categories = ["FinOps"]
}

Kombinieren Sie das mit doit_insight_resource_results, um Findings pro Ressource anzuhängen – und schon erscheinen die Ergebnisse Ihrer eigenen Optimierungs-Engine direkt neben den eingebauten Insights von DoiT.

Das Composability-Pattern

Durch all diese Beispiele zieht sich ein roter Faden: Data Sources sind der Klebstoff. Statt Dimension-IDs, Service-Namen oder E-Mail-Adressen fest zu verdrahten, ermitteln Sie sie zur Plan Time:

data "doit_dimensions" "all" {}
locals {
dimension_types = { for id, types in {
for d in data.doit_dimensions.all.dimensions : d.id => d.type...
} : id => types[0] }
}

Diese Dimensions-Lookup-Map lässt sich über Reports, Budgets, Alerts und Allocations hinweg wiederverwenden – einmal schreiben, überall mit local.dimension_types["region"] referenzieren. Genauso macht doit_current_user fest verdrahtete E-Mail-Adressen überflüssig, doit_products ermittelt gültige Service-Filterwerte und doit_platforms listet die Cloud-Provider, die Ihrer Organisation zur Verfügung stehen.

Aktiv weiterentwickelt und Open Source

Seit dem Launch von v1.0 im Februar 2026 gab es in vier Monaten 5 Minor Releases – jeweils mit neuen Resources und Data Sources. Zu den jüngsten Highlights zählen Cloud-Diagrams-Support, Custom Console Themes, Folder Management, Sharing & Access Control, AWS CloudConnect Onboarding und die Ava AI Data Source.

Wenn Sie noch auf einem v0.x-Release sind, ist jetzt ein guter Zeitpunkt zum Upgrade. Die v0.x-Versionen waren ein Technical Preview – v1.x ist die stabile, produktionsreife Linie mit automatischer State-Migration, die den Übergang reibungslos macht. Anleitungen zur Migration finden Sie im v1.0.0 Upgrade Guide.

Der Provider ist Open Source auf github.com/doitintl/terraform-provider-doit. Wir freuen uns über Issues, Feature Requests und Contributions. Jede Resource hat Acceptance Tests, die gegen die echte DoiT-API laufen, und das CloudConnect AWS Modul ist das erste einer Reihe geplanter High-Level-Module, die Provider-Resources zu sofort einsatzbereiten Patterns kombinieren.

Jetzt loslegen

  1. Installation über die Terraform Registry
  2. Einen API-Key erstellen
  3. Die vollständige Dokumentation für Schema-Details und weitere Beispiele durchstöbern
  4. Dem GitHub-Repo einen Stern geben und uns wissen lassen, was Sie als Nächstes sehen möchten

Ihre FinOps-Praktiken verdienen dieselbe Versionskontrolle, dasselbe Peer Review und dieselbe Reproduzierbarkeit wie Ihre Infrastruktur. Probieren Sie den Provider aus und bringen Sie Ihre Cloud Intelligence in Code.