Federated Cloud Governance and a GPU Request at Harbor Retail
Harbor Retail Group operates 14 business units with 9 AWS accounts, 3 Azure subscriptions, and 2 GCP projects. Monthly cloud spend is $1.8M, up 38% year on year while revenue is flat. Each unit holds its own procurement card and can create accounts; finance allocates cost by invoice, not by consumption. Tagging coverage is 42%. The CISO wants central logging and a single identity provider; the EU store estate requires data residency; a new machine-learning team requests 64 A100 GPUs for a six-month demand-forecasting pilot. The CFO wants 20% savings and monthly showback. The CIO must decide whether to centralize cloud procurement or retain federated control. No formal exception process exists, and two units have already signed three-year commitments.
1. Evaluate centralization versus federation of cloud procurement and account creation for Harbor. Recommend a decision-rights model and justify it.
Read the worked answer
Pure centralization would fix fragmented commitments but would likely slow the 14 business units and push spending to shadow channels. Pure federation is already failing: 38% growth with flat revenue, 42% tagging, and three-year commitments signed without portfolio visibility show that local incentives are not aligned with enterprise risk. The defensible model is federated delivery with centralized guardrails and commercial control.
Decision rights should be explicit. The CIO or a cloud governance board owns the multi-cloud policy, account-vending standard, and commitment approval above a threshold. FinOps owns showback, unit-cost reporting, and commitment strategy. The platform team owns account vending, identity integration, logging, and network patterns. Business units own workload choices, budgets, and tagging accuracy within quotas. The CISO owns identity and logging standards with delegated implementation. Procurement owns vendor negotiations but cannot sign commitments without FinOps modelling. An exception process with expiry and a named risk owner is mandatory because two units have already locked in three-year deals.
The 20% target should be decomposed into waste removal, commitment optimization, and demand management, not treated as a blanket cut. Account creation should be automated through a vending machine that applies logging, identity, budget, and residency controls by default. That preserves speed while removing the current ability to create ungoverned accounts. Central logging and a single identity provider are non-negotiable enterprise controls, but they should be delivered as platform services rather than as central approval gates for every workload.
2. Design the guardrails and budget controls that let the machine-learning team get GPUs quickly while containing financial and regulatory risk.
Read the worked answer
Treat the GPU request as a time-boxed service product, not a one-off exception. Publish a pre-approved GPU pattern with quota, approved regions, approved data classes, and a six-month maximum term. The team gets fast provisioning through the account-vending pipeline, but the pattern enforces tags for owner, experiment, cost centre, and expiry; a budget cap; and automatic shutdown or review at the end of the pilot.
Financial controls should include monthly showback at experiment and team level, a forecast of total cost including storage and networking, and a comparison against reserved or committed capacity. Because the pilot is six months, do not buy three-year GPUs for it; use on-demand or short commitments, and require a business case before extension. The 20% savings target should be funded first from orphaned resources, idle non-production environments, and commitment optimization, not from blocking the pilot. If the pilot has a quantified forecast-accuracy benefit, it can be funded as a strategic exception with a capped budget.
Regulatory guardrails must be policy-as-code: EU store data cannot leave approved EU regions; logging is centralized through organization-level trails; identity comes from the single provider; storage and datasets carry classification tags. The ML team should be able to self-serve only within these boundaries. Usage above quota triggers an approval workflow, not a hard block for everything. This separates speed for low-risk experimentation from control for production and residency-sensitive data.