learntodriveai.dev/Cloud Engineering/Cost Allocation and Capacity Planning at Organizational Scale
Cloud Engineering·Project 17·6 units

Cost Allocation and Capacity Planning at Organizational Scale

**Track:** Cloud Engineering

§ Brief

You're designing a cost-allocation methodology and a 12-month capacity projection for Clarisse Uwimana, Director of Infrastructure Services at the Rwanda Digital Transformation Authority (RDTA), a government agency in Kigali running shared AWS infrastructure for 8 ministries under World Bank funding, expanding to 14 next year.

The discipline skills: a tag taxonomy that names what is direct, shared, and unattributable; an apportionment formula for shared infrastructure three ministries use; a build-vs-buy analysis that prices operational time against list price; a 12-month projection with low / expected / high scenarios and named assumptions; and a mapping table that translates the AWS bill into the World Bank's programme budget lines.

The AI-direction lesson is that allocation is methodology, not arithmetic. AI generates a tagging configuration when you ask for one, but does not propose what gets attributed where, how shared costs are split, or what an "Unattributed" line should cover. AI compares list prices for build-vs-buy and forgets the engineer-hours the managed service absorbs. AI extrapolates capacity linearly and returns one confident number with no range. You design the model and write the disciplines into Conventions so AI does not slip back into single-number projections or charge-back defaults.

Your Role

You own the methodology. Clarisse knows AWS, can navigate Cost Explorer, and understands that allocation tagging exists — what she does not have is a methodology her World Bank programme officer will accept. The first contact is a four-paragraph email in formal English; there is no methodology document, no tag taxonomy template, no projection model in the materials. The deliverables are your design.

You direct Claude through the tag-taxonomy authoring, the Cost-and-Usage-Report (CUR) provisioning, the Athena queries that roll costs up per ministry and per programme line, the build-vs-buy analysis, the projection scenarios, and the executive summary. Priya Subramanian, a senior cloud engineer who replies in 1-3 sentences and tends to start with "so" or "right," appears twice to test edges — at the build-vs-buy boundary and at the projection methodology. She does not propose the methodology. You do.

What's New

Last time at NordPay you reconstructed a runtime dependency graph from a distributed trace, built a symptom-vs-cause procedure, encoded a blast-radius gate as both a CLAUDE.md Convention and an OPA policy, and ran a simulated cascade walkthrough. You leave with the framework-as-deliverable habit, the encoded-standards CLAUDE.md, and the budget-alarm-first engagement rhythm.

This time the cognitive mode flips from reactive to analytical. The work is planned, deliberate, mostly markdown and SQL, and the audience is a World Bank auditor who reads the methodology before the numbers. Communication switches from instant Slack to business-day email — careful messages, 24-hour response loops. The senior-colleague register switches from Marco's warm war-stories to Priya's terse code-blocks; you do more interpretive work per word.

The hard part: AI's defaults are reasonable on their own and dangerous in an audit-grade artifact. The tagging configuration looks fine until you notice nothing apportions the shared RDS. The build-vs-buy table looks decisive until you add operational hours and the conclusion flips. The projection looks confident until a funder asks "what does that depend on?"

Tools

  • AWS Cost Explorer — carrying forward; the orientation surface this engagement.
  • AWS Cost and Usage Report (CUR) — new. The source-of-truth surface for cost-at-scale, written to a small S3 bucket.
  • AWS Athena — new, paired with CUR. The SQL engine for the per-ministry and per-programme-line rollups.
  • AWS Trusted Advisor and AWS Compute Optimizer — read for cost-optimization and right-sizing inputs.
  • Terraform — reused for the budget alarm, the CUR S3 bucket, and the Athena workgroup.
  • AWS MCP server (read-only) — reused from P12 for reading Cost Explorer and CUR data via Athena.
  • CLAUDE.md — extended with two new Conventions: show-back-not-charge-back, and projections-need-confidence-ranges.
  • scripts/verify.sh — extended with a cost-allocation reconciliation check that refuses to declare the per-ministry report complete if attributed-plus-shared-plus-unattributed costs do not match the AWS bill within tolerance.
  • Claude Code — carrying forward.

Materials

In the project zip:

  • Clarisse's first-contact email (clarisse-first-contact-email.md) — four paragraphs, formal English, no methodology references.
  • RDTA ministries inventory (rdta-ministries.csv) — 14 rows: 8 existing plus 6 planned. Education and Health are large; Tourism and Sports are small.
  • Sanitized 6-month Cost Explorer export (rdta-cost-explorer-export-6mo.json) — monthly cost by service. About 35-45% of resources are tagged inconsistently. That is realistic.
  • World Bank reporting-format note (world-bank-reporting-format.md) — the five top-level programme budget lines and the reporting cadence. The mapping from AWS services to these lines is not in the file. You design it.
  • Programme budget-lines CSV (world-bank-budget-lines.csv) — the same five lines with funding-agreement allocation percentages.
  • CLAUDE.md — engagement governance with RDTA facts in place and two TODO markers for the new Conventions.
  • Reconciliation script starter (scripts/check-allocation-totals.py) — TODO body. You write the implementation.

You produce the tag taxonomy, the apportionment methodology, the build-vs-buy report, the 12-month projection, the AWS-to-World-Bank mapping table, the per-ministry CSV report, the executive summary, and the handover README.