Skip to main content

> ARCHITECTURE CANON // V1.0

Cloud Economics & FinOps Canon

The Cloud Bill Bible: FOCUS 1.0 Attribution, Architectural Sizing & Waste Elimination

WIZARD

Cloud Sizing Wizard

Model workload dimensions; compute BOM and savings.

18 ARCHITECTURES

Architecture Catalog

From serverless to bare-metal colocation across 54 tiers.

10 MANUALS

Engineering Manuals

Deep runbooks for Karpenter, vLLM, S3 tiering, and PgBouncer.

26 TOOLS

Comparison Matrix

Open-source, cloud-native, and commercial SaaS evaluation.

Architectures18 Families (54 Tiers)
Waste Typologies24 Playbooks
Bilingual Manuals10 Chapters (20 Files)
FinOps Tools26 Systems (FOCUS 1.0)
// INSTITUTIONAL FINOPS FOUNDATIONS

6 Core Cloud Cost Engineering Pillars

FinOps is not a finance mandate; it is a core software architecture discipline. The foundational principles driving enterprise gross margin expansion:

1. Rate Optimization & Commitments

Programmatic 75-80% floor baseline coverage with Compute Savings Plans, Spot GPU fleets, and Convertible RIs.

2. Karpenter & High-Density Compute

Just-in-Time Graviton ARM64 node provisioning, automated node consolidation, and > 82% bin-packing efficiency.

3. Storage Cascades & EBS gp3

S3 Intelligent-Tiering, automated multipart upload abort rules, and zero-downtime gp2 to gp3 online conversion.

4. Network Egress Shielding

Bypassing $0.045/GB NAT Gateway processing fees with free S3 Gateway Endpoints and global CDN origin shielding.

5. Database Pooling & Ceilings

PgBouncer transaction-mode connection pooling, unindexed query CPU elimination, and serverless ACU scaling caps.

6. Observability Cost Governance

OpenTelemetry edge log filtering, healthcheck suppression, and preventing high-cardinality metric explosion.

// CLOUD WASTE & ANOMALY CATALOG

24 Canonical Cloud Waste Typologies

Detection queries and automated CLI remediation commands across compute, storage, networking, database, AI/ML, and observability.

Explore All Playbooks
WST-CMP-01CRITICAL

Kubernetes Pod CPU & Memory Request Overprovisioning

Engineers set generous resource requests (e.g. 4 CPU, 16GB RAM) as safety buffers, while P99 actual utilization rarely exceeds 10%, causing cluster node autoscalers to pack nodes at low density.$3,000 - $45,000 / cluster
WST-CMP-02HIGH

Zombie & Abandoned Staging/Dev EC2 Instances

Ephemeral QA and feature testing instances provisioned during sprints but never terminated after pull request merges.$800 - $12,000 / account
WST-CMP-03HIGH

Autoscaling Group Inelastic Minimum Node Flooding

Setting minSize higher than night-time valley traffic requires, disabling elasticity and forcing payment for idle compute 24/7.$1,500 - $18,000 / group
WST-CMP-04MEDIUM

Legacy Generation Compute Lock-in (x86 vs ARM64 Graviton)

Running services on m5/c5 Intel hardware when modern ARM64 (m7g/c7g Graviton3/4) delivers 25% lower price-to-performance.$2,000 - $25,000 / fleet
WST-CMP-05MEDIUM

Overallocated Serverless Function Memory & Execution Timeout

Defaulting AWS Lambda or Google Cloud Functions to 3GB RAM or 15-minute timeouts for tasks requiring only 256MB and 500ms.$500 - $7,000 / service
WST-CMP-06LOW

Static Bastion Host & Jumpbox Virtual Machine Sprawl

Maintaining dedicated t3.medium virtual machines 24/7 with public IPs solely for SSH access into private VPC subnets.$300 - $2,500 / vpc
WST-STR-01CRITICAL

Detached & Orphan EBS Volumes

When EC2 instances terminate, secondary EBS volumes remain in 'available' state and continue to bill monthly per GB.$1,200 - $15,000 / account
WST-STR-02HIGH

Accumulated Zombie Automated Snapshot Bloat

Backup cron jobs taking daily snapshots without lifecycle expiration rules, accumulating decades of outdated incremental delta blocks.$2,000 - $20,000 / fleet
WST-STR-03HIGH

Incomplete S3 Multipart Upload Chunks Accumulation

Failed client uploads leave hidden multi-part chunks in S3 buckets that do not show in standard directory listings but accrue standard storage fees.$500 - $10,000 / bucket
AI Summary & Agent Operating Digest
AEO / GEO / Perplexity Indexable

The TinyCTO Cloud Economics & FinOps Architecture Canon ('The Cloud Bill Bible') establishes an operational engineering discipline for cloud financial governance. Built upon the FinOps Foundation FOCUS 1.0 open specification, the canon details 18 production cloud architectures across 6 archetypes, 24 cloud waste typologies with detection queries and CLI remediation playbooks, a deterministic sizing wizard engine with itemized Bill-of-Materials calculations, 10 deep bilingual engineering manuals, and a 26-tool comparison matrix.

FOCUS 1.0 Ontology & AttributionStandardized 12-column billing dataset mapping BilledCost, EffectiveCost, and ChargeSubcategory across AWS, GCP, Azure, and Bare Metal with mandatory 5-key tagging.
18 Architectures & Breakeven Curves54 maturity configurations across Serverless, Containers, Karpenter Kubernetes, Streaming, GenAI GPUs, and Bare-Metal Colocation with mathematical breakeven inflection models.
24 Cloud Waste TypologiesExhaustive waste detection queries and automated remediation commands covering Compute, Storage, Networking, Database, AI/ML, and Observability cost leaks.
Deterministic Sizing WizardInteractive calculation engine modeling throughput, storage, and egress to produce itemized BOMs, realistic savings projections, and waste vulnerability disclosures.

Cloud Economics & FinOps Technical FAQs

Why is FinOps defined as an operational engineering discipline rather than a finance cost-cutting exercise?

Traditional top-down finance mandates cut arbitrary budgets and damage developer velocity. In modern cloud architecture, FinOps gives engineering teams real-time visibility into unit economics (such as Cost Per Active Customer or Cost Per Million Invocations). By treating cloud cost as an architectural constraint alongside latency, reliability, and security, engineers can make informed trade-offs that drive higher gross margins without sacrificing deployment speed.

What is the FOCUS 1.0 standard and why is it essential for multi-cloud governance?

The FinOps Open Cost and Usage Specification (FOCUS 1.0) standardizes billing and usage telemetry across AWS, Google Cloud, Microsoft Azure, and Oracle Cloud. Historically, each cloud provider used proprietary terminology (e.g. AWS 'BlendedRate' vs Azure 'EffectivePrice' vs GCP 'Cost'). FOCUS 1.0 normalizes these into canonical dimensions such as BilledCost, EffectiveCost, ProviderName, and ServiceCategory, enabling automated cross-cloud chargeback, unified anomaly detection, and reproducible FinOps auditing.

How does Karpenter Just-in-Time provisioning differ from traditional Kubernetes Cluster Autoscaler?

Legacy Cluster Autoscaler (CAS) scales worker nodes through static, rigid Auto Scaling Groups (ASGs). When pods are unschedulable, CAS spins up predefined instances, often stranding 50% to 80% of CPU and memory idle. Karpenter eliminates ASGs entirely. It talks directly to the cloud provider's Fleet API, evaluates unscheduled pod requests, selects the optimal mix of ARM64 Graviton and Spot instances, and continuously bin-packs and consolidates nodes within 60 seconds of traffic falling.

Why is achieving 100% Compute Savings Plan coverage considered a dangerous FinOps anti-pattern?

Workload compute consumption is never flat; it fluctuates with diurnal cycles, seasonality, product deprecations, and architectural refactors. If an organization commits to 100% of its peak or even average spend under a 1-year or 3-year contract, any architectural optimization (like migrating to Graviton, upgrading to vLLM, or rightsizing) creates unused commitment breakage where the company pays for hours it no longer uses. The mathematical optimum is 75% to 80% coverage of the rolling 30-day baseline floor.

What are the hidden costs of AWS NAT Gateways and how can they be structurally eliminated?

AWS NAT Gateways charge both an hourly provisioning fee and a $0.045/GB ($45/TB) data processing fee on every single byte passing through them, in addition to outbound internet egress. When internal microservices download container images from Amazon ECR, stream logs to CloudWatch, or upload datasets to S3 via a NAT Gateway, bills explode. Deploying free S3 Gateway Endpoints and DynamoDB Gateway Endpoints routes this traffic over AWS's internal private backplane with zero processing fees.

At what point does Cloud Repatriation to dedicated bare-metal colocation become mathematically justified?

Repatriation becomes financially compelling when steady-state compute spend exceeds $20,000/month, database memory requires > 512GB RAM, or outbound network egress exceeds 30 TB/month. Dedicated bare-metal nodes (such as AMD EPYC servers on Hetzner or OVHcloud) provide 100% dedicated non-oversubscribed cores, enterprise NVMe storage at $0 additional cost, and unmetered gigabit bandwidth at a 75% to 85% discount over equivalent public cloud On-Demand instances, easily amortizing the operational engineering burden.