FinOps for Engineering Teams: Cloud Cost Attribution, Budget Alerts, and Automated Right-Sizing

Cloud bills arrive monthly. Engineers ship daily. The mismatch between those two rhythms is why most FinOps programs fail: they live in spreadsheets owned by finance, not in the CI pipelines and Slack channels where engineering decisions happen.

This article is not about FinOps as a discipline. It is about the specific, concrete things an engineering team can wire up themselves: tagging, alerting, right-sizing automation, and dashboards that survive contact with a real on-call rotation. The examples use AWS and Cloudflare because that is where the patterns are most battle-tested, but the underlying mechanics apply to any major cloud.

---

The Attribution Problem

Before you can optimize anything, you need to know who owns what. Without attribution, every cost conversation becomes a finger-pointing exercise between teams.

The unit of attribution in AWS is the cost allocation tag. The strategy is to tag at the resource level with at least four dimensions:

• team: which team owns the resource (e.g., platform, search, checkout)
• service: the application or microservice (e.g., payments-api, image-resizer)
• env: production, staging, dev
• feature: optional, but valuable during large feature rollouts (e.g., new-checkout-flow)

The catch is that tags only work if they are applied consistently and at creation time. Retroactive tagging is painful. The fix is to enforce tags as part of your infrastructure-as-code.

Here is a TypeScript function for a CDK stack that enforces required tags across all resources:

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";

interface TaggingProps {
  team: string;
  service: string;
  env: "production" | "staging" | "dev";
  feature?: string;
}

export function applyRequiredTags(scope: Construct, props: TaggingProps): void {
  const requiredTags: Record<string, string> = {
    Team: props.team,
    Service: props.service,
    Environment: props.env,
    ManagedBy: "cdk",
  };

  if (props.feature) {
    requiredTags["Feature"] = props.feature;
  }

  for (const [key, value] of Object.entries(requiredTags)) {
    cdk.Tags.of(scope).add(key, value);
  }
}

// Usage in a stack
export class PaymentsApiStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: cdk.StackProps) {
    super(scope, id, props);

    applyRequiredTags(this, {
      team: "checkout",
      service: "payments-api",
      env: "production",
    });

    // All resources created in this stack inherit the tags above
  }
}

In Terraform, use default_tags on the AWS provider block:

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Team        = var.team
      Service     = var.service
      Environment = var.env
      ManagedBy   = "terraform"
    }
  }
}

Neither approach eliminates gaps entirely. Lambda functions created by automated tooling, ECS tasks spun up by third-party integrations, and resources created through the console will all escape your tagging scheme. Run a weekly query in AWS Cost Explorer’s Tag Coverage report to find untagged spend, and treat it as a flaky test: investigate and fix the root cause rather than chasing the symptom.

---

Budget Alerts and Anomaly Detection

A budget alert without context is noise. An alert that fires on Friday afternoon without an owner is a fire waiting to happen.

The two mechanisms worth configuring are AWS Budgets for threshold alerts and Cost Anomaly Detection for statistical outliers. They serve different purposes.

AWS Budgets alert when you cross a defined spend threshold within a billing period. Set one per team using the tag filter you defined above. This is the “house is on fire” alert.

Cost Anomaly Detection uses machine learning to detect unexpected cost spikes relative to your normal usage pattern. It fires before you cross a budget, and it tells you which service caused the anomaly. This is the “something unusual happened” alert.

Here is a TypeScript CDK construct that wires up both for a given team:

import * as cdk from "aws-cdk-lib";
import * as budgets from "aws-cdk-lib/aws-budgets";
import * as ce from "aws-cdk-lib/aws-ce";
import * as sns from "aws-cdk-lib/aws-sns";
import * as subscriptions from "aws-cdk-lib/aws-sns-subscriptions";
import { Construct } from "constructs";

interface TeamCostAlertsProps {
  teamName: string;
  monthlyBudgetUsd: number;
  alertEmail: string;
  anomalyThresholdUsd: number;
}

export class TeamCostAlerts extends Construct {
  constructor(scope: Construct, id: string, props: TeamCostAlertsProps) {
    super(scope, id);

    const alertTopic = new sns.Topic(this, "AlertTopic", {
      topicName: `cost-alerts-${props.teamName}`,
    });

    alertTopic.addSubscription(
      new subscriptions.EmailSubscription(props.alertEmail)
    );

    // Budget alert at 80% and 100% of monthly target
    new budgets.CfnBudget(this, "TeamBudget", {
      budget: {
        budgetName: `${props.teamName}-monthly`,
        budgetType: "COST",
        timeUnit: "MONTHLY",
        budgetLimit: {
          amount: props.monthlyBudgetUsd,
          unit: "USD",
        },
        costFilters: {
          TagKeyValue: [`user:Team$${props.teamName}`],
        },
      },
      notificationsWithSubscribers: [
        {
          notification: {
            notificationType: "ACTUAL",
            comparisonOperator: "GREATER_THAN",
            threshold: 80,
            thresholdType: "PERCENTAGE",
          },
          subscribers: [
            { subscriptionType: "SNS", address: alertTopic.topicArn },
          ],
        },
        {
          notification: {
            notificationType: "ACTUAL",
            comparisonOperator: "GREATER_THAN",
            threshold: 100,
            thresholdType: "PERCENTAGE",
          },
          subscribers: [
            { subscriptionType: "SNS", address: alertTopic.topicArn },
          ],
        },
      ],
    });

    // Anomaly detection monitor scoped to team tag
    new ce.CfnAnomalyMonitor(this, "AnomalyMonitor", {
      monitorName: `${props.teamName}-anomaly-monitor`,
      monitorType: "CUSTOM",
      monitorDimension: "SERVICE",
    });
  }
}

One operational note: route these alerts to a team Slack channel via an SNS-to-Slack Lambda, not just email. Email gets buried. A Slack notification in #team-checkout-alerts gets seen.

---

Automated Right-Sizing

Right-sizing is the highest-ROI activity in FinOps, and it is almost entirely mechanical once you have the data pipeline wired up. The idea: pull CPU and memory utilization metrics, compare them to what you provisioned, and flag or automatically resize resources that are consistently over-provisioned.

The tricky part is that “right-sized” means different things for different workloads. A payment processing API with spiky traffic patterns needs headroom. A batch data ingestion job that runs at 2 AM does not.

Here is a TypeScript script that queries CloudWatch for EC2 instance utilization and outputs right-sizing recommendations:

import {
  CloudWatchClient,
  GetMetricStatisticsCommand,
} from "@aws-sdk/client-cloudwatch";
import {
  EC2Client,
  DescribeInstancesCommand,
  Instance,
} from "@aws-sdk/client-ec2";
import {
  PricingClient,
  GetProductsCommand,
} from "@aws-sdk/client-pricing";

interface UtilizationReport {
  instanceId: string;
  instanceType: string;
  team: string;
  avgCpuPercent: number;
  p95CpuPercent: number;
  recommendation: "downsize" | "right-sized" | "monitor";
  estimatedMonthlySavings: number;
}

const ec2 = new EC2Client({ region: "us-east-1" });
const cloudwatch = new CloudWatchClient({ region: "us-east-1" });

async function getCpuUtilization(
  instanceId: string,
  lookbackDays: number
): Promise<{ avg: number; p95: number }> {
  const endTime = new Date();
  const startTime = new Date(
    endTime.getTime() - lookbackDays * 24 * 60 * 60 * 1000
  );

  const [avgResult, p95Result] = await Promise.all([
    cloudwatch.send(
      new GetMetricStatisticsCommand({
        Namespace: "AWS/EC2",
        MetricName: "CPUUtilization",
        Dimensions: [{ Name: "InstanceId", Value: instanceId }],
        StartTime: startTime,
        EndTime: endTime,
        Period: 3600,
        Statistics: ["Average"],
      })
    ),
    cloudwatch.send(
      new GetMetricStatisticsCommand({
        Namespace: "AWS/EC2",
        MetricName: "CPUUtilization",
        Dimensions: [{ Name: "InstanceId", Value: instanceId }],
        StartTime: startTime,
        EndTime: endTime,
        Period: 3600,
        ExtendedStatistics: ["p95"],
      })
    ),
  ]);

  const datapoints = avgResult.Datapoints ?? [];
  const avg =
    datapoints.reduce((sum, d) => sum + (d.Average ?? 0), 0) /
    (datapoints.length || 1);

  const p95Datapoints = p95Result.Datapoints ?? [];
  const p95Values = p95Datapoints
    .map((d) => d.ExtendedStatistics?.["p95"] ?? 0)
    .sort((a, b) => b - a);
  const p95 = p95Values[Math.floor(p95Values.length * 0.05)] ?? 0;

  return { avg, p95 };
}

async function analyzeInstances(
  lookbackDays = 14
): Promise<UtilizationReport[]> {
  const instances = await ec2.send(
    new DescribeInstancesCommand({
      Filters: [
        { Name: "instance-state-name", Values: ["running"] },
        { Name: "tag:Environment", Values: ["production"] },
      ],
    })
  );

  const allInstances: Instance[] = (instances.Reservations ?? []).flatMap(
    (r) => r.Instances ?? []
  );

  const reports: UtilizationReport[] = [];

  for (const instance of allInstances) {
    if (!instance.InstanceId || !instance.InstanceType) continue;

    const team =
      instance.Tags?.find((t) => t.Key === "Team")?.Value ?? "unknown";
    const util = await getCpuUtilization(instance.InstanceId, lookbackDays);

    let recommendation: UtilizationReport["recommendation"];
    if (util.p95 < 20) {
      recommendation = "downsize";
    } else if (util.p95 < 50) {
      recommendation = "monitor";
    } else {
      recommendation = "right-sized";
    }

    reports.push({
      instanceId: instance.InstanceId,
      instanceType: instance.InstanceType,
      team,
      avgCpuPercent: Math.round(util.avg * 10) / 10,
      p95CpuPercent: Math.round(util.p95 * 10) / 10,
      recommendation,
      // Placeholder: integrate with AWS Pricing API for actual savings
      estimatedMonthlySavings: recommendation === "downsize" ? 50 : 0,
    });
  }

  return reports;
}

// Run and output to stdout for piping into a dashboard or Slack notification
analyzeInstances(14).then((reports) => {
  const downsizeCandidates = reports.filter(
    (r) => r.recommendation === "downsize"
  );
  console.log(
    `Right-sizing scan complete. ${downsizeCandidates.length} downsize candidates found.`
  );
  console.table(
    downsizeCandidates.map((r) => ({
      id: r.instanceId,
      type: r.instanceType,
      team: r.team,
      avgCpu: `${r.avgCpuPercent}%`,
      p95Cpu: `${r.p95CpuPercent}%`,
    }))
  );
});

Run this as a scheduled Lambda or GitHub Actions workflow weekly. The output feeds into a Slack message or a cost dashboard. The key signal is p95 CPU, not average. A batch job that idles for 23 hours and spikes for one will look under-utilized on average but is actually correctly sized.

---

Tradeoffs in Right-Sizing Strategy

Approach	Pros	Cons
Manual right-sizing	Full control, no automation risk	Does not scale, forgotten between reviews
Automated resizing on schedule	Consistent, no toil	Can disrupt stateful workloads, needs rollback path
Recommendation-only (flag + human action)	Safe, builds team awareness	Recommendations age and get ignored
AWS Compute Optimizer (managed)	Zero setup, integrates with Cost Explorer	Recommendations lag by days, no custom logic

For most teams starting out, recommendation-only with a weekly Slack report is the right balance. Automate the resize only for stateless workloads (Lambda memory, ECS task sizing) where the blast radius is low.

---

Reserved Instances and Savings Plans for Startups

Commitments make sense when you have stable baseline load. The mistake startups make is buying too early, before usage patterns have stabilized, or buying the wrong commitment type.

The decision framework:

1. Run on On-Demand for at least 90 days after launch
2. Analyze your baseline (the minimum compute you use 24/7)
3. Cover that baseline with a 1-year Compute Savings Plan (not EC2 Reserved Instances)
4. Keep everything above baseline On-Demand

Compute Savings Plans are more flexible than EC2 RIs. They apply across instance families, regions, and even Fargate and Lambda. For a team that is still iterating on architecture, this flexibility is worth the slightly lower discount rate compared to Standard RIs.

A practical sizing heuristic for early-stage teams: if you have been running at $X/month in EC2/Fargate costs for three consistent months, commit to covering 60% of that with a 1-year Savings Plan. Leave 40% On-Demand as a buffer for growth.

Avoid 3-year commitments until you have at least 18 months of stable load data. The savings look attractive but the opportunity cost of being locked into yesterday’s architecture is real.

---

Unit Economics: Cost Per API Call and Cost Per User

Aggregate cloud spend is a lagging indicator. Unit economics make cost a first-class engineering metric that shows up in architecture decisions.

Two metrics worth tracking:

Cost per API call: total monthly infrastructure cost divided by total API requests in that period. Track this over time. If you ship a new feature and cost per API call goes up 20%, something in that feature’s implementation is expensive.

Cost per active user: useful for SaaS products. Tracks the marginal infrastructure cost of serving one user.

Here is a TypeScript module that calculates cost per API call by pulling from CloudWatch metrics and AWS Cost Explorer:

import {
  CostExplorerClient,
  GetCostAndUsageCommand,
} from "@aws-sdk/client-cost-explorer";
import {
  CloudWatchClient,
  GetMetricStatisticsCommand,
} from "@aws-sdk/client-cloudwatch";

interface UnitEconomics {
  periodStart: string;
  periodEnd: string;
  totalCostUsd: number;
  totalApiRequests: number;
  costPerRequest: number;
  costPerThousandRequests: number;
}

const ce = new CostExplorerClient({ region: "us-east-1" });
const cw = new CloudWatchClient({ region: "us-east-1" });

async function getMonthlyUnitEconomics(
  year: number,
  month: number,
  teamTag: string,
  apiGatewayName: string
): Promise<UnitEconomics> {
  const start = `${year}-${String(month).padStart(2, "0")}-01`;
  const nextMonth = month === 12 ? 1 : month + 1;
  const nextYear = month === 12 ? year + 1 : year;
  const end = `${nextYear}-${String(nextMonth).padStart(2, "0")}-01`;

  const [costResult, requestResult] = await Promise.all([
    ce.send(
      new GetCostAndUsageCommand({
        TimePeriod: { Start: start, End: end },
        Granularity: "MONTHLY",
        Filter: {
          Tags: { Key: "Team", Values: [teamTag] },
        },
        Metrics: ["UnblendedCost"],
      })
    ),
    cw.send(
      new GetMetricStatisticsCommand({
        Namespace: "AWS/ApiGateway",
        MetricName: "Count",
        Dimensions: [{ Name: "ApiName", Value: apiGatewayName }],
        StartTime: new Date(start),
        EndTime: new Date(end),
        Period: 2592000, // 30 days in seconds
        Statistics: ["Sum"],
      })
    ),
  ]);

  const totalCostStr =
    costResult.ResultsByTime?.[0]?.Total?.UnblendedCost?.Amount ?? "0";
  const totalCost = parseFloat(totalCostStr);
  const totalRequests =
    requestResult.Datapoints?.[0]?.Sum ?? 0;

  return {
    periodStart: start,
    periodEnd: end,
    totalCostUsd: totalCost,
    totalApiRequests: totalRequests,
    costPerRequest: totalRequests > 0 ? totalCost / totalRequests : 0,
    costPerThousandRequests:
      totalRequests > 0 ? (totalCost / totalRequests) * 1000 : 0,
  };
}

Export this data to your observability platform alongside latency and error rates. When your p99 latency doubles, you want to see if cost per request moved in the same commit range.

---

Cost Dashboards Engineers Actually Use

Most cost dashboards fail because they are owned by finance and optimized for monthly budget reviews, not daily engineering decisions. A dashboard engineers use has three properties:

1. It shows data at the commit or deploy level, not just the billing period level
2. It is embedded where engineers already look (Grafana, DataDog, or a Slack report)
3. It surfaces actionable signals, not just totals

The most effective pattern is a daily Slack digest per team that shows:

• Yesterday’s cost vs. 7-day average (with delta percentage)
• Top 3 most expensive services for the team
• Any anomaly detection alerts from the previous 24 hours
• Current month trajectory vs. budget

This takes about 30 minutes to wire up as a Lambda on a cron schedule using the Cost Explorer API and a Slack webhook. The weekly right-sizing report (from the script above) can be appended to the same channel.

For interactive exploration, AWS Cost Explorer has improved significantly. The tag-based filtering means a team can self-serve their own cost breakdown without needing finance team access. Pair it with a saved filter per team and bookmark it in your team’s Notion or Confluence page.

One anti-pattern to avoid: per-resource cost attribution in dashboards. Showing engineers the exact cost of each Lambda invocation or S3 PUT creates noise without actionable signal. The right granularity is service or feature, not individual resource.

---

Production Considerations

A few things that only become obvious after running this in production:

Tag drift is inevitable. Automated enforcement in CDK or Terraform helps but does not eliminate it. Schedule a monthly “cost hygiene” item in your team’s backlog to audit untagged spend in Cost Explorer.

Savings Plan coverage has a cliff. If you buy a Savings Plan that covers exactly your current baseline and then onboard a new customer that doubles your load, you will suddenly be running unprotected On-Demand at full price during a growth period. Size commitments conservatively.

Right-sizing recommendations lag. CloudWatch metrics and Compute Optimizer both look back at historical data. If you right-size an instance based on last month’s traffic and this month is a seasonal peak, you will have an incident. Add a mechanism to pause right-sizing automation during known high-traffic windows.

Anomaly detection has a warm-up period. AWS Cost Anomaly Detection needs about two weeks of data before its baseline is reliable. Expect false positives in the first two weeks, especially if you are running a new workload.

Cloudflare costs are different. Cloudflare Workers charges per invocation and CPU time, not provisioned capacity. Right-sizing there means optimizing code execution time, not instance type. Track CPUTime in your Worker analytics and set up billing alerts at the account level via the Cloudflare dashboard. There is no tag-based attribution at the service level in Cloudflare’s billing model, so you need to instrument cost per route in your application layer by tracking invocation counts per Worker name.

---

The fundamental shift FinOps asks of engineering teams is treating cost as a non-functional requirement, the same way latency and availability are. It does not require a new team or a new tool. It requires tagging at creation time, alerts in the places where engineers already pay attention, and unit economics that connect infrastructure decisions to business outcomes. Everything else is optimization on top of that foundation.