AWS · capacity planning · case study
From a regional planning tool to the platform behind data-center capacity planning
I went from building a regional capacity-planning tool myself, to building the data foundation under AWS capacity planning, to leading the team that runs the planning platform planners use today.
- Context
- Amazon Web Services, data-center capacity planning. Professional work; not a personal project.
-
Regional capacity-planning and simulation tool
Infrastructure, database, APIs and interface, built by me.
Personally built the infrastructure, database, APIs and UI; planners fully adopted it within 3 months, replacing offline tracking files
-
Redesigned the foundation: chapter 2
Data foundation under capacity planning
Re-architected demand data ingestion instead of tuning the old system.
Cut demand data ingestion from 3 hours to under 10 minutes by redesigning the architecture (in-memory pipeline, partitioned data domains) instead of tuning the old system
-
Capacity-planning and S&OP platform
Lead the team that builds and runs it; I own technical direction and production operations.
375k Amazon-ians used a platform I created or managed. ~2,500 monthly users
Why the problem mattered
Data-center capacity planning decides where and when new infrastructure gets built. When I started in capacity planning at AWS, much of that work ran on Excel-based reports and offline tracking files that individual planners kept for their own regions.
That made the planning logic hard to share. The logic, and the organizational knowledge behind it, lived in spreadsheets and with the people who maintained them, rather than in systems that every planner could use and the organization could build on.
Chapter 1 · 2017–2019 · Capacity Planner / Developer · tool built Q3 2019
A regional planning tool I built myself
My contribution: Personally built
My first answer to the spreadsheet problem was a regional capacity-planning and simulation tool. I built all of it: the infrastructure it ran on, the database, the APIs and the user interface. Planners used it to track and simulate regional capacity in one shared place instead of in their own files.
What the resume reports
- Build and adoption: Personally built the infrastructure, database, APIs and UI; planners fully adopted it within 3 months, replacing offline tracking files
Chapter 2 · 2019–2022 · Senior Data Engineer
Building the data foundation underneath planning
My contribution: Built and redesigned
As a Senior Data Engineer, I moved from one tool to the data every planning tool depends on. I built the data foundation for AWS capacity planning, integrating infrastructure and planning data from many sources through Python, AWS Lambda, ETL pipelines, S3, databases and data lakes.
For demand data ingestion, I redesigned the architecture rather than tuning the existing system. With my team, I also delivered the first version of a data monitoring and alerting service after a long period of scoping. I built its site, APIs, database and indexes; my team built its scheduling service and ticketing workflow.
These are three separate systems with separate users. The figures below belong to each system on its own and should not be read as one combined audience.
What the resume reports
- Data foundation database: ~90K users each month
- Ingestion redesign: Cut demand data ingestion from 3 hours to under 10 minutes by redesigning the architecture (in-memory pipeline, partitioned data domains) instead of tuning the old system
- Monitoring and alerting service: Built v1 in under 2 months after a year of scoping: I built the site, APIs, database and indexes, and my team built the scheduling service and ticketing workflow. It now runs 1,500+ SQL alarms and automates 100K+ tickets monthly, saving 3–8 people worth of manual work
Chapter 3 · 2022–present · Software Development Team Manager
Leading the planning platform
My contribution: Led the team
Today I lead the team that owns the capacity-planning and S&OP platform for AWS data-center planning: the data pipelines, planning tools and dashboards behind it. The team builds and runs it. My part is technical direction across Python, AWS Lambda, S3, Redshift, OpenSearch, ETL and APIs, and ownership of the roadmap and production operations.
Together we turned Excel-based capacity reports, planning logic and organizational knowledge into self-service planning systems.
I also own how the platform is run: the on-call escalation rotation, operational health reviews, quarterly roadmaps and annual operating planning. And I changed how we work with customers, replacing ticket-based intake with engineers working directly with the planners they build for.
Operations and engagement, as the resume reports them
- Operations: Weekly on-call escalation, WBR/MBR health reviews, weekly shipping, and customer prototypes built within days
- Customer engagement: Replaced ticket intake with direct engineer–customer engagement; 5 engineers delivered 40 capabilities in 8 months
Setting a performance requirement
My contribution: Set the requirement and contributed to design
For critical planning tools, I set the page-load requirement the team builds against, and I contributed to the backend design that meets it. I did not design that backend alone; it was a team effort. The requirement itself is listed with the platform outcomes below.
Before and after
Before
Kept separately by individual planners
- Offline tracking files Kept by individual planners for their own regions
- Excel-based capacity reports Spreadsheet reports planners produced themselves
- Planning logic and knowledge Held inside the files and by the people who kept them
After
Shared, automated, self-service
- Data pipelines From many infrastructure and planning sources: Python, AWS Lambda, ETL, S3
- Shared data foundation Databases and data lakes every planning tool reads from
- Self-service planning tools and dashboards Used by planners in each planning cycle
In words
Before: planners kept their own offline tracking files and produced Excel-based capacity reports. The planning logic, and the knowledge behind it, lived inside those files and with the people who maintained them. After: data pipelines bring infrastructure and planning data from many sources into a shared data foundation, and planners use self-service planning tools and dashboards built on it instead of building their own reports. This shows how the work is organized, not the system's internal design.
Outcomes
These outcomes belong to the planning platform my team runs. They are reported results for that platform, not independent audits, and each one keeps its own subject and period.
-
AWS capacity-planning and S&OP platform (users)
375k Amazon-ians used a platform I created or managed. ~2,500 monthly users
Led the team that owns the platform.
-
Planning-cycle duration
30% shorter planning cycles
Led the team that built the self-service planning systems.
-
Annual savings enabled through right-time data-center delivery
$60M–$120M in annual savings, enabled by delivering data centers when they're needed and getting more from existing infrastructure
Enabled by the planning systems my team built; not a direct cost cut.
-
Critical dashboard refresh
Critical dashboard refresh cut from 8+ hours to 40 minutes or less, with zero failures across 7 consecutive planning cycles
Team result; my individual contribution is to be confirmed.
-
Critical planning-tool performance requirement
Set a sub-3-second requirement for 40 GB+ demand plans and contributed to the OpenSearch/DuckDB backend design
Set the requirement and contributed to the backend design.