Optimizing Cloud Storage Infrastructure for Enterprise AI Platform Operations

h2o.ai · Tech · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI platform cloud storage operations

H2O.ai needed to reduce AWS EBS waste and improve scalability for Kubernetes-hosted model training and AI workloads.

Constraints:

The platform managed more than 2 petabytes of storage.
Utilization was around 25%.
Storage scaling could not cause downtime.
The solution had to fit Kubernetes, Terraform, and GitOps workflows.

Architecture

H2O.ai deployed Datafi autonomous storage management to dynamically scale EBS volumes up and down based on actual usage without downtime, integrated into existing Kubernetes/Terraform/GitOps operations.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  kubernetes-ai-workloads["Kubernetes AI Workloads"]
  aws-ebs-volumes["AWS EBS Volumes"]
  datafi-storage-manager["Datafi Storage Manager"]
  terraform-and-gitops["Terraform and GitOps"]
  kubernetes-ai-workloads --> aws-ebs-volumes
  aws-ebs-volumes --> datafi-storage-manager
  datafi-storage-manager --> terraform-and-gitops

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Kubernetes AI Workloads`	Run model training and AI workloads that consume storage.	`AWS EBS Volumes`
`AWS EBS Volumes`	Provide block storage for AI platform workloads.	`Datafi Storage Manager`
`Datafi Storage Manager`	Autonomously resizes storage based on actual usage.	`Terraform and GitOps`
`Terraform and GitOps`	Keep storage operations aligned with existing platform workflows.	—

Data flow

Kubernetes AI workloads consume EBS volumes, Datafi monitors actual usage, dynamically resizes volumes without downtime, and the changes fit existing Terraform and GitOps operations.

“implemented Datafi, an autonomous storage management solution that dynamically scales EBS volumes up and down based on actual usage without downtime.”summary, stated

“integrated seamlessly with their existing Kubernetes, Terraform, and GitOps workflows”summary, stated

Why this architecture

Autonomous resizing attacked the utilization problem directly while avoiding disruption to existing platform engineering workflows.

“poor utilization rates (around 25%), leading to substantial cloud costs and limited ability to scale efficiently.”summary, stated

“without downtime.”summary, stated

Models used: Datafi autonomous storage management

Scale

H2O.ai managed more than 2 petabytes of storage.
“managing over 2 petabytes of storage”summary, stated
Utilization improved from about 25% to 80%.
“improving storage utilization to 80%”summary, stated
The storage footprint fell from 2 PB to less than 1 PB.
“reducing their storage footprint from 2 petabytes to less than 1 petabyte”summary, stated

Alternatives considered (roads not taken)

Static overprovisioned EBS volumes

Rejected because: They produced about 25% utilization and high cloud cost.

“poor utilization rates (around 25%)”summary, stated

Patterns

`cost-aware-routing` (infrastructure)

Autonomous EBS resizing reduced storage footprint and improved utilization.

“reducing their storage footprint from 2 petabytes to less than 1 petabyte”summary, stated

`tool-use-orchestration` (platform-automation)

Datafi automated storage actions inside Kubernetes, Terraform, and GitOps workflows.

“existing Kubernetes, Terraform, and GitOps workflows”summary, stated

Tradeoffs

Automate storage resizing

Chose Datafi autonomous scaling over Manual or static provisioning.

Rationale: Automation improved utilization and reduced footprint without downtime.

“without downtime.”summary, stated

Gotchas (what bit them)

AI training storage can be massively overprovisioned.

Root cause: Static EBS sizing did not track actual workload usage.

Resolution: Dynamically scale volumes up and down based on actual usage.

“dynamically scales EBS volumes up and down based on actual usage”summary, stated

Evaluation

H2O.ai measured storage utilization, storage footprint, and customer performance impact.

Metrics: Storage utilization · Storage footprint · Performance

“ultimately improving storage utilization to 80% and reducing their storage footprint from 2 petabytes to less than 1 petabyte”summary, stated

Outcomes

Storage utilization improved to 80%.
Storage footprint fell from 2 PB to under 1 PB.
Performance improved for customers.

The platform started from more than 2 PB of EBS-backed AI workload storage.

“while simultaneously improving performance for customers.”summary, stated