mikeaorlando.com Michael Orlando
  • Home
  • Start Here
  • About
  • Work & Ventures
  • Ideas & Writing
  • Collaborate
  • Search

▶AWS Cloud Adoption FinOps Initiative

AWS Cloud Adoption FinOps Initiative

Building a FinOps program for a 150-person engineering organization that had just left its own data center — tagging, cost allocation, committed-use strategy, and teaching cloud cost to engineers who had never bought capacity by the hour.

Routing Notes

  • Parent Projects for Work
  • Signal Working Systems

Overview

The second body of work in a two-year engagement with a US Department of Education loan servicer, through AspirationalX: building a FinOps program for a 150-person engineering organization. The data center migration moved the workloads. This program addressed what changes about money once they land.

The program was not the assignment I was hired for. It came out of working as a general AWS and infrastructure-as-code resource across the organization and noticing the same gap repeatedly: spend was visible in aggregate and attributable to nobody. I put together the case — what the structural savings were, what it would take to reach them — and brought it to leadership, who backed it as its own workstream rather than letting it be absorbed into other work. That willingness to fund an internal improvement on evidence is not something every organization has.

The mechanics were tagging and cost allocation first, because nothing downstream works without them. Untagged spend cannot be allocated, unallocated spend cannot be owned, and unowned spend cannot be reduced by the people actually creating it. On top of that: a committed-use strategy for the workloads stable enough to commit, and standing review cadences so cost became a recurring engineering conversation instead of an annual finance event. Tooling — AWS native first, third party where it earned its place — was evaluated in writing by purpose, then sequenced by ease of adoption and by how much access and training each option would require, so the rollout did not outrun the team’s ability to use it.

The teaching was the largest part. These were capable engineers whose prior experience of capacity was that someone bought it once a year in a purchase cycle they never saw. Reserved capacity, per-hour elasticity, the idea that an architectural choice made on a Tuesday shows up on a bill — none of that is intuitive when your prior model was a fixed box in a room. So the program ran as sessions, written guidance, and ongoing support rather than a dashboard handoff.

The trade-off is worth naming: a FinOps program spends engineering attention to save money, and in a federal environment with FedRAMP and SOC 2 constraints, the cheapest option is frequently not an available one. Compliance bounds the optimization space before cost does.

The results were measured: $350,000 saved in the program’s first 18 months, with roughly $3 million in annual savings projected as the practices reached the rest of the organization.

The client is described generically by agreement.

Explore

  • ✎Posts
  • ○Categories
  • ◉Projects for Fun
  • ▶Projects for Work
  • ◎Systems Across Domains
  • ▪Technical Tools
  • ◆Transferable Skills
  • ✕Value Multipliers
  • ◇Ventures

Michael Orlando

Systems, ventures, writing, and public proof arranged so the right people can find the right next step.

© 2026 Michael Orlando

Privacy & Data Handling

about.me Substack Credly Polywork