Infrastructure Cost Monitoring: Tagging, Alerts, and FinOps Basics

The cloud bill is the line item every engineering organization complains about and few address structurally. Costs grow faster than revenue, surprise charges show up monthly, and the response is usually "we'll look at it next quarter" repeated until it becomes a board-level issue.

You do not need a FinOps platform to start. A tagging strategy, a few alerts, and a monthly review are most of the value. This post is the cost monitoring discipline that scales from "we noticed this is expensive" to a real ongoing practice.

What "Cost Monitoring" Means in Practice

Cost monitoring is not just looking at the bill. It is:

• Knowing where the money goes (per service, per team, per environment)
• Catching unusual spikes within hours, not weeks
• Setting budgets and getting alerted when they are exceeded
• Connecting cost data to engineering decisions

A bill that says "you spent $50,000 on AWS this month" is not actionable. A breakdown that says "Service X cost $12,000, up 40% month-over-month, because the new logging pipeline is duplicating traffic" is.

Step One: Tagging

Every cloud provider supports tags on resources. Tags become cost attribution. Without consistent tags, the bill is one big number.

A minimal tag schema:

Apply tags through:

• Terraform — every resource has tags by default
• Provider-level policies (AWS Organizations SCPs, GCP Org policies) that require certain tags
• CI pipelines that fail if tags are missing

The hardest part is the legacy resources without tags. A migration sprint to tag everything is real work but high-leverage. Untagged resources are unattributable cost.

Step Two: Cost Allocation Reports

Once tags exist, the cloud providers offer cost allocation reports:

• AWS Cost Explorer — group by tag, filter by service, export to CSV.
• GCP Billing reports — same idea, slightly different UI.
• Azure Cost Analysis — same idea, with broader subscription grouping.

The first report worth building: "spend by service tag, last 30 days, daily." Reveals which services dominate cost and how it trends.

-- BigQuery example for GCP billing export
SELECT
  labels.value AS service,
  DATE(usage_start_time) AS day,
  SUM(cost) AS daily_cost
FROM `your-project.cloud_billing.gcp_billing_export_v1_*`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'Service'
  AND usage_start_time >= '2026-10-01'
GROUP BY service, day
ORDER BY day, daily_cost DESC;

A Looker Studio or Metabase dashboard on top of this query becomes the team's cost view.

Step Three: Budgets and Alerts

Budgets prevent surprise bills. Both AWS Budgets and GCP Billing Budgets support:

• A monthly budget per project/tag/service
• Alerts at percentage thresholds (50%, 80%, 100%, 120%)
• Automated actions (notify, restrict access, shut down resources)

Set budgets that match expected spend with 20% headroom. When a budget alert fires, it is either expected growth (update the budget) or a real surprise (investigate before the month ends).

The action setting matters. A budget that just sends an email is one more email to ignore. A budget that posts to a specific Slack channel where the team monitors costs gets attention.

What to Look For

Common cost surprises and where they hide:

Idle resources. Forgotten EC2 instances, unused RDS instances, EBS volumes detached from anything. Cloud providers have dashboards for this; your dashboard should aggregate them.

Data egress. Cross-region traffic, S3 to internet, AWS-to-Azure interconnects. Usually a small line item until it is not.

Log volume. CloudWatch Logs, Stackdriver Logs, Datadog ingestion. The line item that grows quietly until you read the contract.

Unused reserved capacity. Bought reserved instances for a workload that scaled differently than planned. Sunk cost; check coverage reports.

Snapshot accumulation. EBS snapshots, RDS snapshots — they retain on the schedule you set, forever. Audit retention policies.

Misconfigured auto-scaling. Min replicas of 10 when 2 would do. Scales up correctly but never down to baseline.

Test environments. Staging at 80% of production cost. Spin up only when needed; tear down at night.

The Monthly Review

A standing 30-minute cost review per month, attended by the team(s) responsible, looks at:

• Total spend vs budget
• Top 5 services by spend
• Services with the largest month-over-month growth
• Outstanding cost-reduction items

The output is a list of actions. The review is not the action; the action is what someone does between reviews.

Tools

For most teams in 2026:

• Cloud-native tools first. AWS Cost Explorer, GCP Billing Reports, Azure Cost Analysis. Free, sufficient for the basics.
• Open source visualization. Metabase, Grafana with cloud cost data sources.
• Commercial FinOps platforms (Vantage, CloudHealth, Apptio, Densify) when the scale and complexity justify it. Usually $50K+ teams.
• OpenCost for Kubernetes-specific cost allocation by namespace, deployment, label.

Most teams should start with the cloud-native tools. Commercial FinOps platforms pay back only at meaningful scale — usually when cloud spend exceeds a few hundred thousand annually.

Allocating Shared Costs

Shared resources (network, shared databases, observability platforms) cost money but do not have a service tag. Two approaches:

Pro-rata allocation. Distribute shared cost across services in proportion to their direct cost. Imperfect but simple.

Usage-based allocation. Track which services use which shared resources. More accurate, much more work to set up.

For Kubernetes specifically, OpenCost allocates shared cluster costs to namespaces or workloads based on resource requests. The Kubernetes case is well-handled; other shared infrastructure is more manual.

What Engineering Teams Can Control

The biggest engineering levers on cost:

1. Right-sizing. Most workloads are over-provisioned. Adjust CPU, memory, replica counts to match actual usage.
2. Auto-scaling tuning. Scale-down delay too long, scale-up too aggressive. Burns money in the middle.
3. Spot/preemptible instances. Up to 70% cheaper than on-demand for fault-tolerant workloads.
4. Reserved/committed capacity. For predictable steady-state workloads, savings of 30-60%.
5. Storage class selection. Hot data on SSD, warm on standard, cold on infrequent-access. Most teams have everything on hot.
6. Log/metric retention. Three months of 10GB-per-day logs is 90GB; one year is 365GB. Pick durations deliberately.

Each of these is a real engineering project, not a tweak. Cost optimization is engineering work that produces engineering outcomes.

The Culture Side

Cost monitoring without culture change does not stick. The patterns that hold up:

• Cost is everyone's problem. Not just the platform team, not just leadership.
• Cost decisions are engineering decisions. Choosing instance types, retention policies, replica counts.
• Cost is reviewed at the team level. Not just at the company level.
• Wins are celebrated. "We cut our service's cost by 40%" should be as visible as "we shipped feature X."

Companies that treat cost as an afterthought watch it grow uncontrollably. Companies that treat it as ongoing engineering discipline keep it sustainable.

A Pragmatic Starting Point

For a team that has not been doing this:

1. Week 1: Tag every resource with Service, Environment, Team. Use Terraform if you have it; click-ops if not.
2. Week 2: Build a cost-by-service dashboard. AWS Cost Explorer or BigQuery + Metabase works.
3. Week 3: Set budgets per service. Alert to Slack at 80% and 100%.
4. Week 4: Identify the top three cost surprises. Decide which to address.
5. Monthly: Review costs with the team.

Four weeks of effort, then ongoing. The 5-10% cost reduction from just having visibility usually pays for the time spent.

Looking at a cloud bill that has grown faster than headcount and not sure where to start cutting? We help teams set up cost monitoring that turns vague concern into engineering work. scopeforged.com