Everything in Cloud Platforms, page 10
Cloud Unit Economics: Tying Spend to Value
Instead of just a total cloud bill, unit economics calculates cost per meaningful unit, like 'cost per customer.' This helps justify rising costs with business growth and lets product owners make data-driven pricing tradeoffs.
Cost Anomaly Detection: Catching Runaway Cloud Bills
Think of cost anomaly detection as a fraud alert for your cloud bill. It uses machine learning to learn your normal spending patterns and automatically flags unexpected spikes before they become a crisis.
Start/Stop Automation: Pay Only For What You Use
Start/stop automation is like putting your cloud resources on a timer to save money. It's essential for non-production environments like dev and staging used only during business hours.
Showback vs. Chargeback: Who Pays the Cloud Bill?
Showback shows teams their cloud costs for visibility; Chargeback makes them pay for it by moving costs to their budget. This helps control cloud spend by making engineers cost-aware. The footgun is treating Chargeback as inherently more mature than Showback.
FinOps Framework: Aligning Cloud Cost with Business Value
FinOps treats cloud spend as a business metric, not just an IT cost. It provides a shared framework for engineering, finance, and business to collaborate on data-driven spending decisions.
AWS Savings Plans: A Bulk Discount for Compute
Think of Savings Plans as a bulk discount for AWS compute. You commit to a consistent hourly spend for 1-3 years to get a lower rate on EC2, Fargate, and Lambda. The footgun is over-committing; you pay for your commitment even if you don't use.
Cloud Rightsizing: Stop Overpaying for VMs
Rightsizing stops you from overpaying for idle cloud capacity. It involves analyzing CPU and memory usage to shrink over-provisioned VMs. Always collaborate with application owners before making changes.
Cloud Budgets: Your Guardrail Against Overspending
A cloud budget is a spending alarm for your cloud account. It warns you when costs approach a limit you've set, preventing surprise bills. Use it to track monthly spend or monitor usage. The main footgun: billing data lags, so you can overspend before an.
AWS Cost Explorer: Visualize and Forecast Your Cloud Spend
Cost Explorer is your cloud bill's interactive dashboard, turning raw data into trend graphs and forecasts. Use it to find which service is driving up costs or to predict next quarter's bill. The main footgun: once enabled, it cannot be disabled.
Consolidated Billing: Combine Cloud Bills for Bigger Discounts
Consolidated Billing is like a family phone plan for AWS accounts. It rolls multiple accounts into one bill, letting you share volume and savings plan discounts across the entire organization.
Policy as Code: Rules as Versioned, Testable Code
Policy as Code (PaC) treats rules like code: versioned, tested, and automated. Instead of manual UI clicks, you define guardrails in a declarative language. Use it in CI/CD to block bad deploys or in Kubernetes to enforce runtime rules.
IaC State: The Map Between Your Code and the Cloud
Terraform state maps your configuration to managed resources. Keep it secure and use a backend with appropriate locking for shared work. State can contain sensitive values, so do not commit it to a source repository.
Cloud Cost Management: Taming Your Bill
Treat cloud spend like a utility bill you can actively control, not a fixed cost. It's essential when your AWS, GCP, or Azure bill is growing unpredictably. The biggest footgun is treating cost management as a one-time cleanup instead of a continuous process.
SLIs & SLOs: Measuring What Matters for Service Reliability
SLIs are what you measure (e.g., latency); SLOs are the target you aim for (e.g., 99% success). They replace vague feelings about service health with concrete numbers. This is how SREs define and manage reliability.
Centralized Logging: A Universal Inbox for Your Systems
Centralized logging is a universal inbox for all your system events. Instead of SSHing into each server, agents forward logs to one searchable location, making it possible to debug issues that span multiple services. The footgun is inconsistent log formats.
CQRS: Separate Models for Reading and Writing Data
CQRS splits your application into two parts: one for changing data (Commands) and one for reading it (Queries), often with separate data models. Use it in complex systems with different read/write patterns.
The Saga Pattern: Transactions Across Microservices
The Saga pattern manages transactions across services by chaining local operations. If a step fails, compensating actions undo previous work. It's common in booking systems.
Serverless State Machines: The Conductor for Your Functions
A serverless state machine is the conductor for your microservices, telling each function when to run and how to handle errors. It's built for multi-step processes like ETL pipelines or coordinating parallel tasks. The footgun is creating a visual monolith.
The Fan-out Pattern: One Message, Many Receivers
The fan-out pattern uses a single message to trigger multiple parallel actions, like a press conference where one announcement reaches many reporters. Use it for events like a new user signup that triggers emails, analytics, and fraud checks.
Idempotent Event Handlers: Don't Double-Count Events
An idempotent event handler ensures processing the same event multiple times has the same effect as processing it once. This is vital in event-driven systems to prevent data corruption from redelivered messages. The footgun is assuming exactly-once delivery.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles