Proposal: add AWS Cost Explorer / CUR / Pricing API surface

[ShubhamDX]

Hi Floci maintainers,

Love what you're building - the 24ms startup + 13MiB idle footprint makes Floci the local AWS emulator fast enough to run alongside
every unit test, not just integration ones. Congrats on the LocalStack Community sunset timing; Floci genuinely is the no-strings-attached alternative.

I'd like to propose adding a Cost Explorer + CUR + Pricing API surface in three separate PRs.

Why

FinOps tooling (cost detection, attribution, budget guards, invoice reconciliation) is the one category of AWS consumers that Floci cannot currently support because the billing APIs are absent. Today anyone building against AWS cost data has two options:

• Run integration tests against real AWS - expensive, credential-gated, slow and risks cross-contaminating CI state with production
  spend.
• Synthesize CUR Parquet manually - fragile, drifts from the real CUR schema, misses edge cases like promotional-credit offset rows and FOCUS 1.2 columns.

Floci is the only local emulator in the right performance envelope to serve as the integration-test backend for cost-oriented tools and the one clearly not going to be gated behind an auth token. Adding the CE / CUR / Pricing surface opens Floci up to the entire FinOps tooling ecosystem - budget guards, anomaly detection, commitment-optimizer test harnesses, right-sizing recommenders, CUR parser libraries, etc.

Scope proposal (3 PRs)

1. pricing:* (~300-500 LOC) — GetProducts, DescribeServices, GetAttributeValues, GetPriceListFileUrl, ListPriceLists.
   Stateless service; ships with bundled region-scoped AWS Price List JSON as build-time fixture. Env var FLOCI_PRICING_SNAPSHOT_PATH overrides the bundle.
2. ce:* (~1000-1500 LOC) — GetCostAndUsage, GetCostAndUsageWithResources, GetDimensionValues, GetTags,
   GetReservationCoverage, GetReservationUtilization, GetSavingsPlansCoverage, GetSavingsPlansUtilization. Synthesizes
   cost data from existing Floci resource state (S3 buckets, EC2 instances, Lambda functions) × Pricing API snapshot × configurable
   time periods. Supports GROUP_BY=RECORD_TYPE so Usage / Credit / Tax / DiscountedUsage rows are emitted correctly - essential for testing any code path that distinguishes gross usage from net
   billable outlay (credit-offset accounts, spend-limit checks, invoice-reconciliation code).
3. cur:* + bcm-data-exports:* (~800-1200 LOC) — CUR 2.0 export definitions + Parquet emission to Floci's own S3 service. Ships with the FOCUS 1.2 schema. Uses the Apache Parquet Java lib you already pull in for Athena / DuckDB. The write path goes through Floci's S3 service so bucket policies and TLS-only checks still apply - no new state store.

Design questions I'd love your input on before writing code

1. Bundled pricing data size. Full AWS Price List for us-east-1 alone is ~70MB compressed. I propose shipping the core image
   unchanged and adding a second tagged image floci/floci:latest-pricing that bundles the snapshot. Or we keep
   snapshot files small (top-N services per region) and expose a bootstrap script for the full set. Which fits your distribution
   philosophy?
2. Cost synthesis model. CE cost data is a synthetic view over Floci's existing resource state. I propose making the cost model
   pluggable via a CostSynthesisBackend interface so users can swap in their own business rules (important for emulating accounts with non-trivial pricing like Savings Plans, EDP discounts, etc.). Does that fit your stateless service pattern?
3. CUR emission cadence. AWS CUR emits daily but tests need on-demand. I propose a config flag FLOCI_CUR_EMIT_MODE=synchronous|daily|off with synchronous as default for tests. Pushing to S3 goes through your existing
   bucket-policy + TLS-only checks.

Contribution posture

• One feature per PR. I'll split into the three above + smaller P1 work (Savings Plans, Cost Anomaly Detection, Reserved Instances
  describe) after.
• Every new service matches the existing SSM/IAM/STS pattern - stateless JAX-RS handler, state via StorageBackend if needed,
  compatibility-tests/ coverage against boto3 + AWS CLI.
• Docs page in docs/services/ for each new service.
• No breaking changes to existing APIs or compat flags.

Transparency

To unblock my own CI before the upstream review cycle completes, I'm also developing these additions in a public soft-fork. Every commit is cherry-pickable to upstream - same commits, same scope, no consumer-specific code. The fork's main will fast-forward to upstream each time you merge a PR, so the fork shrinks rather than grows. Happy to link the fork in the PR descriptions if that helps review.

Ask

Before I write any Java: does the scope fit your roadmap? Any of the three design questions above you'd like to pin down differently? I'd
much rather align with your architectural preferences on day 1 than reshape a PR at review time.

Happy to hop on Slack / Discussions for any back-and-forth.

[hectorvent]

Hi @ShubhamDX,

Thanks for your proposal and we can proceed with it. Please get issues created per scope so we can track the progress.

[hectorvent]

@ShubhamDX is there anything else pending for the pricing API? Is it ok to close this discussion?

[ShubhamDX]

Yes, all three P0 PRs merged. Happy to close. Thanks for the reviews.