AWS bills RDS per instance — so on a shared SQL Server you can't see which database, team, or client is actually driving the cost. DBSteward reads the engine's own metrics and splits that single bill down to every database.
Consolidating databases onto shared RDS instances saves money — and erases the cost trail. Here's what that costs you.
AWS charges for the RDS instance as a whole. Ten databases on one instance show up as a single, undivided number.
When cost spikes, nobody can prove which database caused it. Right-sizing and reclaim conversations stall on guesswork.
Finance can't bill teams or clients for shared-database usage, so infrastructure cost quietly erodes margin.
DBSteward reads SQL Server's own DMVs to measure what each database actually consumes, then maps the real AWS bill onto that usage.
Point DBSteward at a server. It self-provisions a small management database — no agents on the box.
Per-database CPU, memory, IO stalls, and storage are sampled on a schedule, straight from the engine.
The fair-share engine maps the actual Cost Explorer bill onto usage — and never lets any database exceed 100%.
Tag, allocate, and export frozen PDF/XLSX billing reports per team, client, or tenant.
Every allocation is fully transparent — here's how DBSteward turns one instance bill into a defensible per-database number, shown on a real report layout.
For every metric, share = this database's consumption ÷ the instance total. Counters like CPU and I/O are summed as reset-aware deltas; gauges like memory, disk, and log are averaged.
Shares are blended on a fixed weighting (CPU 20% · Memory 20% · Disk 30% · Log 10% · I/O 20%), renormalized so a database missing a metric never inflates the others.
Score = Σ(weight × share). Cost = instance bill × score. The denominator is anchored to max(instance series, Σ per-database), so no database's share can ever exceed 100%.
What no user database can claim — system databases, tempdb, background work, shared baseline — is shown as Unallocated rather than smeared across teams.
| # | Database | Score | Bill % | Cost |
|---|---|---|---|---|
| 1 | Northwind_Retail | 0.1620 | 16.20% | $149.04 |
| 2 | Atlas_Logistics | 0.0590 | 5.90% | $54.28 |
| 3 | Meridian_Hotels | 0.0235 | 2.35% | $21.62 |
| 4 | Cobalt_Finance | 0.0205 | 2.05% | $18.86 |
| 5 | Lumen_Media | 0.0198 | 1.98% | $18.22 |
| 6 | Verde_Travel | 0.0041 | 0.41% | $3.77 |
| 7 | Pinnacle_Edu | 0.0003 | 0.03% | $0.28 |
| Unallocated (shared baseline) | 71.08% | $653.94 | ||
| Total | 100.00% | $920.00 |
Weights: CPU 20% · Memory 20% · Disk 30% · Log 10% · I/O 20%. Sample data — fictional names, illustrative figures.
One landing view: spend, projected cost, managed databases, and unallocated %, across every instance.
See exactly how an instance's bill splits across its databases, with unallocated cost made visible.
Weighted allocation across CPU, memory, IO, and storage — reset-aware, with a sum-of-parts floor.
Uses your real as-billed AWS figures, currency-aware, with a period-to-date estimate fallback.
CPU-hours, storage and memory trends, plus freshness badges that flag stale collection at a glance.
Attach team, client, or environment tags to each database so cost rolls up the way your org thinks.
Snapshot a month's allocation to immutable PDF and XLSX — auditable, shareable, defensible.
Optional per-database top-SQL detail when you need to explain a cost spike down to the query.
No CloudWatch, no Lambda, air-gap friendly. Secrets via AWS Secrets Manager and IAM roles.
Per-database CPU, memory, IO, and storage attribution — pulled from DMVs, with zero CloudWatch or Lambda to operate.
CPU attribution from plan-cache, IO-stall counters, storage and memory gauges — all reset-aware and collected on your cadence.
Allocate shared-database cost to teams, clients, or environments — currency-aware, tied to real AWS figures, exportable for audit.
Map shared-database infrastructure back to customers and tenants for accurate margins, pricing, and capacity planning.
No CloudWatch, no Lambda, nothing installed on the database host. It reads the engine's own DMVs.
Vendored assets and local dependencies mean it runs in locked-down environments without external CDNs.
The sum-of-parts floor guarantees no database's share exceeds 100%, even when plan-cache metrics dip.
Onboarding provisions its own management database and idempotent collection routines — minimal setup.
Book a walkthrough and we'll show DBSteward against a shared SQL Server instance like yours — from DMV collection to a finished chargeback report.
No spam. We'll reach out within one business day.