Cloud Cost Diagnostic Report Sample (Synthetic Data)

Disclaimer: this sample shows the structure and analysis method of a Reallier cloud cost diagnostic report. The scenario and every number are synthetic — written to the methods and conventions of real projects, but not corresponding to, or inferable about, any real client. Real reports are delivered to the commissioning client only.

Engagement Background

Client profile (fictional): a B2B industrial-parts distributor in eastern China, around 120 employees. Self-built order and customer management system (monolithic Java application), Elasticsearch powering full-text search over products and customers, self-managed MySQL rather than RDS — everything running on a public cloud.

The ask: “Cloud spend has climbed past ¥50k a month. It feels like half of it is wasted, but nobody can say exactly where.”

Billing basis (synthetic): 8 cloud hosts + cloud disks + public bandwidth, about ¥48,000/month, about ¥580k annualized. Shapes and utilization are invented and do not match any real console screenshot.

Resource Inventory and Utilization Overview

Instance	Size	Role	CPU	Memory	Disk
app-01/02	12 vCPU/16G × 2	App + search mixed	41%	44%	86%
db-01	8 vCPU/24G	Self-managed MySQL	22%	76%	49%
gw-01	2 vCPU/4G	VPN gateway	7%	33%	15%
edge-01	2 vCPU/4G	Overseas access node	11%	47%	19%
test-01/02	4 vCPU/8G × 2	Test machines	6%	20%	27%

Total: 44 vCPU / 80G memory, weighted average CPU utilization about 28% — about 12 cores doing work, the rest idle.

Instance-by-Instance Analysis (Three Representatives)

app-01/02: the “everything-on-one-box” app + search tier

12 cores at a sustained 41% is not a plain web workload — it is the typical footprint of a monolithic application stacked on a full-text index. Memory sits at 44% while disk has reached 86%: product images, quotation PDFs, search indices, and logs all pile onto the same cloud disk with no hot/cold tiering. An 86% disk is a capacity risk — one full write can interrupt the business.

db-01: paying for concurrency that does not exist

Memory at 76% with CPU at 22% is the textbook self-managed database profile: MySQL packs hot data into the buffer pool — on the order of a dozen GB of effective hot data — while most of the 8 cores idle. This workload wants memory, not cores: fewer cores, keep the RAM, add read/write splitting.

gw-01: the idle gateway

CPU in the single digits: a 2 vCPU/4G instance doing nothing but VPN forwarding. The same networking can run on a WireGuard setup without occupying a dedicated cloud host, and drops the day-to-day certificate and security-group maintenance.

Business Scale Profile (Synthetic Inference)

Dimension	Estimate
Concurrent users (business hours)	About 60-100 simultaneously active
Active business data	3-5 million records (orders / customers / products)
Total data volume	About 500GB-1TB including attachments and indices
Monthly data growth	About 3-5%, no lifecycle policy — all of it on the most expensive cloud disks
Backups	No cross-instance backup policy in place

Key Findings

Systemic over-provisioning: real demand is about 35% of the current allocation; roughly six tenths of the annual cloud spend is dead weight
Capacity risk: app-01/02 disks at 86% with no cleanup or tiering mechanism
Data assets exposed: order and customer data with no off-site backup — a full disk or an instance failure is a business-level incident
Static assets served from ECS: images and quotation PDFs without CDN — slow to access and paid for twice (bandwidth + disk)
Idle around the clock: no auto-scaling; nights and weekends billed at full rate

Savings Path Proposal

Path	Content	Expected annual spend	Reduction
A. Cloud-only optimization	Downsize + reserved plans + data tiering + auto-scaling	¥290-400k	30-50%
B. Hybrid cloud (recommended)	Database and search moved to physical servers in the client’s own room; public-facing services stay on cloud + CDN	¥90-150k	70-85%
C. Fully private	Everything off cloud	¥60-100k	85%+

Why path B: the client’s headquarters has spare rack space with dual power feed; DB and ES — workloads that want memory and IOPS rather than cores and elasticity — are exactly what physical servers do best; the public storefront and CDN stay on cloud for elasticity.

Switchover plan: parallel deployment on new physical servers → dual-write data verification → DNS cutover in a low-traffic window → cloud side retained for a 2-week rollback window.

ROI Model (Path B)

Item	Amount
One-time investment (servers + implementation + switchover)	¥160-240k
Annual cloud savings (¥580k → ¥110k basis)	About ¥470k
Payback period	About 4-6 months
Side benefits	Capacity risk eliminated, backups in place, search latency down (local SSD IOPS 1.5×+ over comparable cloud disks)

For the method and deliverables behind this report, see Cloud Cost Diagnostics: How We Work and What You Get.