# Amazon SageMaker Feature Group

> Feature groups bill on two stores at once: the online store meters reads, writes, and per-GB storage for low-latency serving, while the offline store accrues S3 storage indefinitely. ZopNight discovers feature groups on the 6-hour cycle, tracks both costs from Cost Explorer or CUR 2.0, and flags groups whose models are gone.

Source: https://zop.dev/integrations/aws/sagemaker-feature-group
Updated: 2026-08-19

---

A SageMaker Feature Store feature group stores curated ML features, billed for online store reads/writes and offline store storage. Feature groups that outlive their models keep charging for storage and provisioned throughput.

## Two stores, two ways to pay

A feature group can maintain an online store for low-latency inference lookups, metered on reads, writes, and per-GB storage, with a provisioned-capacity mode that bills for configured throughput whether consumed or not. A feature group can also maintain an offline store, an S3-backed history that accrues per-GB-month storage as long as ingestion continues. The two meters fail differently. Online-store waste is throughput-shaped: provisioned reads and writes for models that stopped serving. Offline-store waste is sediment-shaped: append-only feature history growing monthly, long after the last training job read any of it.

## Feature groups against their consumers

ZopNight discovers feature groups automatically on the 6-hour cycle, with storage and throughput cost tracked from Cost Explorer or CUR 2.0. The unused-feature-group recommendation reconnects features to their reason for existing: a group whose consuming endpoints are deleted and whose offline store no training job has queried in months is infrastructure serving a model that no longer exists. Provisioned online stores make the finding urgent, since capacity-mode billing continues at the configured rate regardless. Pure offline groups make it chronic instead, a storage line growing quietly forever.

## The pipeline that never stops feeding

Feature engineering pipelines are the leak's engine: ingestion jobs keep writing fresh feature values on schedule because nothing downstream tells them to stop. The model was retired; the pipeline's owner changed teams; the feature group keeps growing and, in provisioned mode, keeps billing writes for data with no reader. Duplicate groups compound it, as reorganized teams re-create features under new naming conventions and leave the old generation ingesting in parallel.

## Feature Store housekeeping

The SageMaker console's Feature Store section lists groups with their online/offline configuration and creation dates. The audit question per group is a join: which pipelines write to it, which endpoints or training jobs read it, and whether the read side still exists. Write-only groups are the cleanup list.