Amazon Solutions Architect (Entry Level) Interview Preparation Guide

Direct answer

Vertical scaling means giving one machine more resources, more vCPU, more RAM; horizontal scaling means adding more machines and spreading load across them. Vertical scaling is simpler because the application doesn't have to change at all, but it has a hard ceiling, the biggest machine available, and concentrates failure in one box. Horizontal scaling has effectively no ceiling and shrinks the blast radius of any single machine failing, but it requires the application to tolerate running as multiple, coordinated instances rather than one.

Structured elaboration

Concrete examples

• Vertical: moving a relational database from a 4-vCPU/16 GB box to a 16-vCPU/128 GB box, with no code change required.
• Horizontal: adding more stateless web server instances behind a load balancer, whose internal balancing algorithm is its own topic and not re-derived here.

Failure domain
Vertical scaling keeps a single point of failure regardless of how big the box gets. Horizontal scaling spreads risk, but only if the application is actually stateless or its state is externalized to a shared cache or session store; otherwise "horizontal" is cosmetic, since any one instance still holds state nothing else can serve.

Cost is not just a resilience argument
Cloud pricing for a single bigger machine is usually not linear with its capacity; the largest instance sizes often carry a premium. That is a computable, not just intuitive, reason horizontal scaling is often cheaper at a given capacity level, not only more resilient (worked example below).

A practical default
Default to horizontal for anything stateless and customer-facing. Reach for vertical only for components that are genuinely hard to distribute, a single-writer relational database primary, some legacy single-threaded systems, and even then pair it with a replication and failover plan, since vertical scaling alone still leaves a single point of failure.

Worked example

Say a 4-vCPU instance costs $0.20/hour and a 32-vCPU instance, 8 times the vCPUs, costs $2.40/hour, 12 times the price, a common cloud pattern where the largest instance sizes carry a premium rather than a linear price-per-vCPU:

$\frac{\$0.20/\text{hr}}{4 \text{ vCPU}} = \$0.05 \text{ per vCPU-hour (small instance)}, \qquad \frac{\$2.40/\text{hr}}{32 \text{ vCPU}} = \$0.075 \text{ per vCPU-hour (large instance)}$

To cover 100 vCPU-equivalents of load, the same figure from the instance-sizing question above:

$\left\lceil \frac{100}{4} \right\rceil = 25 \text{ small instances} \times \$0.20/\text{hr} = \$5.00/\text{hr (horizontal)}$

$\left\lceil \frac{100}{32} \right\rceil = 4 \text{ large instances} \times \$2.40/\text{hr} = \$9.60/\text{hr (vertical, chunkier boxes)}$

Scaling out with many small instances here is essentially half the cost of the same capacity in a few large boxes, purely from the assumed per-vCPU pricing premium at the top end, and it spreads that 100 vCPU-equivalents of load across 25 failure domains instead of 4. This is illustrative pricing, not any specific vendor's current rate, but the shape, larger instances costing more per unit of capacity, is common enough to be worth checking for any real vendor before assuming vertical scaling is free of a cost penalty beyond its availability risk.

Trade-offs & pitfalls

• Assuming vertical scaling is always simpler and cheaper because it "requires no code changes"; it can cost more per unit of capacity and still leave a single point of failure.
• Scaling horizontally without externalizing state first, sessions or in-memory caches tied to one instance, producing a fleet of instances that isn't actually interchangeable and defeats the point.
• Not having a plan for vertical scaling's eventual ceiling; if a component structurally can't be distributed, that is a standing operational risk worth naming explicitly, not a decision to defer indefinitely.
• What separates a senior answer: bringing in the cost-per-unit-of-capacity angle alongside the resilience angle, since stakeholders outside engineering often hear only the failure-domain argument and miss that horizontal can also be the cheaper option.

Direct answer

I would run a structured sixty-to-ninety-minute blameless retrospective within a week of the engagement closing: a clear staged agenda, the right mix of participants, two concrete artifacts, and a lightweight but real tracking mechanism so action items do not die in a document nobody reopens.

Structured elaboration

Agenda: frame the session explicitly as blameless at the start, the goal is process and ambiguity, not people; reconstruct the engagement timeline chronologically so ambiguity points are visible in context rather than recalled out of order; identify the specific moments where ambiguity caused a wrong turn, an assumed requirement, an unowned scope boundary; brainstorm systemic fixes, not "communicate better" but a specific process change; then prioritize and assign two to four concrete action items with owners and dates, deliberately capped so they are achievable.

Participants: the engagement's core team, plus the delivery lead, and, where the ambiguity was client-facing, the account or relationship owner who can speak to what the client actually communicated. I deliberately exclude anyone attending purely as an audience, since a blameless retro works best with the people who were actually in the ambiguity.

Artifacts produced: a short written retro summary, timeline, root causes, action items with owners and dates, circulated to the team and to leadership if the pattern is recurring; and a lighter "pattern note" added to the shared team knowledge base so the lesson survives past the people in the room.

Tracking and closing follow-ups: action items go into the same tracker the team already uses for engagement work, not a separate retro-only backlog that gets ignored, each with an owner and a due date, reviewed at the next team sync until closed. An item is only marked closed once there is evidence it happened, a template updated, a checklist added to the playbook, not just "discussed."

Worked example

The engagement assumed the client's data model was stable; mid-project it turned out three fields we depended on were being redefined by another vendor at the same time, causing two weeks of rework. In the retro, the timeline reconstruction showed the ambiguity point was that "confirm the data contract with the client's other vendors" had never been explicitly assigned to anyone at kickoff. The systemic fix: add a standing kickoff checklist item, "identify and confirm all upstream data contracts in writing," now part of the engagement playbook, that is the pattern note. The action item, "update the engagement kickoff template," was assigned to the delivery lead with a two-week due date, tracked in the same project board as engagement deliverables, and closed only once the updated template was merged into the shared playbook and actually used on the next kickoff.

Trade-offs and pitfalls

A retro that produces more than three or four action items usually produces zero completed ones, since ownership gets diffuse. If the retro runs more than a couple of weeks after the engagement, memory of exactly where the ambiguity entered gets fuzzy and the discussion drifts into vague generalities. And "blameless" is a stated intent, not a guaranteed outcome: if a senior person in the room reacts defensively when a specific decision is examined, psychological safety collapses for the rest of the session, so the facilitator has to actively protect the framing throughout, not just announce it once at the start.

A secure, low-impact Elastic Block Store (EBS) snapshot strategy schedules snapshots off-peak through automation (Amazon EventBridge plus Lambda, or AWS Backup), takes a brief application-consistent pause rather than snapshotting a live, mid-write filesystem, encrypts everything with a customer-managed AWS Key Management Service (KMS) key, copies to a second AWS Region for disaster recovery with re-encryption at the destination, and cleans up automatically on a retention policy rather than accumulating snapshots forever. The core tension to manage is consistency versus application impact: the more thoroughly you quiesce the application before the snapshot, the more consistent the result, but the longer the, usually brief, pause the application feels.

Scheduling

Trigger snapshots on an EventBridge schedule, or use AWS Backup, which wraps this pattern with built-in retention and cross-Region or cross-account copy, at off-peak hours for the workload, with frequency matched to the recovery point objective: hourly for a critical database, daily for a less critical volume.

Application-consistent snapshots

An EBS snapshot on its own is crash-consistent, similar to how a filesystem looks after an unclean shutdown, which is good enough for many workloads but not for a database mid-transaction. For a genuinely consistent snapshot:

• Use the application's own quiesce mechanism where one exists, a database's native backup-start and backup-stop hooks, so writes are safely paused rather than assumed to be safe.
• Where there is no native hook, briefly freeze the filesystem immediately before triggering the snapshot and unfreeze immediately after the snapshot request is accepted, since the freeze only needs to cover the moment the snapshot is initiated, not its full completion.
• Keep the freeze window as short as possible and measure its actual application impact before relying on it in production, since a pause that looks trivial in testing can matter under real production load.

Cross-Region copy for disaster recovery

After the snapshot completes in the source Region, copy it to the disaster-recovery Region, specifying the destination Region's own KMS key so the copy is re-encrypted there rather than depending on cross-Region access to the source key. Tag the copy with its origin and retention policy so cleanup automation in the disaster-recovery Region can apply the same rules independently.

Encryption and key management

Use a customer-managed KMS key, not the AWS-managed default, so key policy, rotation, and access can be scoped deliberately: restrict decrypt and data-key-generation permissions to the specific roles that create and restore snapshots, and confirm the disaster-recovery Region's key exists with compatible permissions before the first cross-Region copy runs, not after.

Automated lifecycle cleanup

Tag every snapshot with its retention policy at creation time, and run a scheduled cleanup, a Lambda function or the AWS Backup lifecycle policy natively, that deletes snapshots past their retention window in both the source and disaster-recovery Region independently. Alert on cleanup failures rather than assuming they always succeed, since a silently failing cleanup job is how accounts accumulate years of forgotten, still-billed snapshots.

Worked example

A PostgreSQL database on an EBS-backed EC2 instance needs hourly snapshots retained for 7 days locally and daily snapshots copied to a second Region retained for 90 days, for compliance. Every hour, EventBridge triggers a Lambda that calls PostgreSQL's native backup-start hook (pausing checkpoint writes without blocking reads or transactions), creates the EBS snapshot, then calls backup-stop once the snapshot request is accepted, a pause typically well under a second. Once daily, the same Lambda additionally copies that hour's snapshot to the disaster-recovery Region with encryption enabled and the destination Region's own KMS key ID specified explicitly. A separate scheduled Lambda runs nightly, reads each snapshot's retention tag, and deletes anything past 7 days in the source Region or past 90 days in the disaster-recovery Region, logging failures to CloudWatch so a broken cleanup run pages someone instead of silently piling up snapshots.

Trade-offs and pitfalls

• Skipping application-level quiesce and relying only on crash consistency is fine for stateless or easily rebuilt data, but for a transactional database it risks a snapshot that restores into a corrupted or inconsistent state; know which category the workload falls into before deciding not to quiesce.
• Cross-Region copy requires the destination KMS key to exist and be permissioned before the first copy, a step that is easy to forget until the first disaster-recovery copy fails.
• Automated cleanup without alerting on failure is the most common way accounts end up with years of accumulated, still-billed snapshots; treat cleanup failures as seriously as backup failures.
• Restoring a snapshot is not the same as validating that the application actually comes up correctly from it; periodically test a real restore, not just confirm the snapshot exists.
• The same quiesce discipline used here also matters for an EBS-to-EFS storage migration runbook: when cutting over from an EBS volume to Amazon Elastic File System (EFS), briefly pausing writes to validate that every byte has actually been copied, rather than assuming a copy job caught everything, is the same consistency-during-migration technique as pausing writes for an application-consistent snapshot. Treat cutover validation with the same rigor as a snapshot's consistency window, not as a lesser step because the data is "just being copied."

Direct answer

Rather than either refusing a compressed timeline outright or quietly skipping testing to meet it, the right move is to negotiate a phased delivery: give the stakeholder real, usable value early on a narrower, lower-risk slice of the feature, while the full safety and compliance testing continues on the riskier parts in parallel, with interim controls covering the gap.

Structured elaboration

1. Negotiate timeline and scope together: do not treat the deadline as fixed and scope as the only variable, or the reverse; present both as connected, here is what can be delivered by the requested date, and here is what needs the extra time and why.
2. Deliver early value in phases: identify a genuinely lower-risk subset of the feature, fewer decision types, a smaller population, human-reviewed rather than fully automated, that can pass an appropriately scaled but real check faster, and ship that first.
3. Manage residual risk: put interim controls in place for anything shipped ahead of full testing, mandatory human review of every automated decision, tighter monitoring, a defined rollback, define checkpoints where the team explicitly re-confirms it is safe to keep going.
4. Preserve buy-in on both sides: keep the requesting party informed of what ships when and why some pieces need more time, while never letting the deadline override what is genuinely non-negotiable, such as a compliance review of automated lending decisions, since incorrect automated decisions in lending carry real legal exposure.

Worked example

A bank client wants an AI-assisted loan pre-qualification feature live in 6 weeks; the vendor's standard security and compliance review for a new automated lending decision typically takes 12 weeks.

Phase 1, weeks 1 to 6: ship a version where the AI produces a recommendation but a human loan officer makes the final call on every application, since human-reviewed recommendations carry far less regulatory exposure than a fully automated decision and can pass an appropriately scoped review faster. Every AI recommendation is logged alongside the human's final decision during this phase, building an audit trail and a dataset for evaluating the AI's accuracy before it ever makes decisions alone. In parallel, starting week 1, the standard 12-week security and compliance review for full automation continues on its own timeline. At the week-6 checkpoint, the logged recommendation-versus-decision data feeds into that same review as extra evidence. Once the full review completes around week 12, roughly six weeks after phase 1 ships, a defined lower-risk subset of applications, for example smaller loan amounts, moves to full automation, with the review having passed for that subset specifically.

Preserving buy-in: the client gets a working, valuable feature at week 6, real time savings for loan officers, instead of nothing for 12 weeks, and understands exactly why full automation on larger loans waits for the complete review.

Trade-offs and pitfalls

The pitfall on one side is caving entirely and skipping the safety and compliance review to hit the requested date, risking real legal and financial exposure. The pitfall on the other side is refusing any compressed option and insisting on the full review timeline with nothing delivered in between, risking the relationship and the deal. The human-in-the-loop phase resolves this: it delivers real value fast while keeping a person, not the untested model, accountable for the actual decision until the review is complete.

Direct answer

Capacity planning for a fixed target load is a four-step exercise: measure how much load one instance can safely handle, add a burst/growth buffer to the raw peak, convert that into an instance count, then validate the fleet still meets the target after you lose a zone. The safety margin exists to absorb burstiness, retries, and the cost of running hot for a bounded period, not to compensate for skipping the measurement step.

Structured elaboration

Data to collect

From data to a per-instance capacity number

Run a load test against a single instance (or a fixed-size shard) and raise load until the p99 latency SLO (service level objective: the latency target you've committed to, e.g. p99 under 300ms) breaches, not until CPU hits 100%. That breach point, not the theoretical ceiling, is the instance's safe capacity.

From per-instance capacity to fleet size

1. Planning target = raw peak times a growth/burst buffer.
2. Divide by (safe per-instance capacity times target operating utilization).
3. Round up to whole instances, then round up again to a multiple of the availability-zone count so load balances evenly.

Validate the zone-loss case

After removing one zone's worth of instances, confirm the remaining fleet still covers the raw peak, not the buffered planning target. Running hot for the duration of a single zone outage is an acceptable, bounded trade; running hot while also absorbing organic growth beyond the raw peak is not.

Worked example

A load test on one 4-vCPU instance shows it sustains 1,000 requests/sec at 60% CPU before p99 latency crosses the SLO. That 60% point, not 100%, is the safe ceiling.

Target steady-state operating point: 50% CPU, leaving headroom for GC pauses, noisy neighbors, and the zone-loss case.

Per-instance safe capacity at the 50% target:

$$\text{capacity}_{\text{instance}} = 1000 \times \frac{50}{60} = 833.3 \text{ req/s}$$

Add a 30% burst/growth buffer to the stated 10,000 req/s peak:

$$\text{planning target} = 10{,}000 \times 1.3 = 13{,}000 \text{ req/s}$$

Instances needed for the planning target:

$$\frac{13{,}000}{833.3} = 15.6 \rightarrow 16 \text{ instances (rounded up)}$$

Round up to a multiple of 3 availability zones for even spread: 18 instances, 6 per zone.

Validate the zone-loss case. Losing one zone removes 6 instances, leaving 12:

$$12 \times 833.3 = 10{,}000 \text{ req/s}$$

That equals the raw peak exactly: during a single-zone outage the fleet runs at its safe ceiling with zero spare margin, an acceptable, bounded degradation for a rare event but not a state to run in day to day.

Trade-offs & pitfalls

• Over-provisioning for the zone-loss case permanently (running at reduced utilization at all times to cover a rare event) wastes money; treat zone-loss headroom as a temporary, monitored state, not the steady-state target.
• Linear scaling from a single instance's load test breaks down when a bottleneck is shared across the fleet (database connection pool limits, a shared NAT gateway, a shared cache); load-test a small cluster against the real shared dependency, not one box in isolation.
• Retries during partial degradation can multiply effective load two to three times right when capacity is tightest; a plan that ignores retry amplification underestimates the real peak.
• CPU utilization is a proxy, not the constraint. An I/O-bound service can sit at 20% CPU while thread-pool exhaustion still causes timeouts, so the load test's stopping condition should always be the SLO breach, never a resource metric alone.

Direct answer

I would tell one specific story: where I watched a user, what I saw, why the data could not have shown it, and what I changed because of it. The best stories show the firsthand observation changed a decision, not just my opinion.

How to structure the story

1. Setting: which channel (an interview, a support call, or shadowing, which means sitting in on a customer doing real work without steering them), and why you were there.
2. The observation: what the user did or said, in concrete detail.
3. Why the data missed it: the gap, usually that the behavior happened outside the product or the metric measured the wrong thing.
4. What I did: verification with more users, a clear problem statement, and a change.
5. Result and caution: what happened, and how I kept one visit from becoming a false certainty.

Worked example (an illustrative story)

Product analytics said the export step had a high success rate: people clicked export and got their file. In a call a customer-success colleague invited me to join, I watched a user export a report, open a spreadsheet, spend a long stretch reformatting columns, and paste a summary into a slide for their manager.

The data could not show this because it all happened outside the product, and "export succeeded" hid the real job: producing something a manager can read. I asked three more customers for a 20-minute screen share of their last export-to-report workflow. Two showed the same pattern, which I treated as a direction, not proof. I wrote the problem statement as "users need a manager-ready summary, not raw data" and brought a short clip to planning.

We shipped a small scheduled summary with the four columns people kept. The real test was behavior afterwards: whether those customers still reformatted by hand, which I checked in follow-up conversations, and whether they kept sharing the summary. Illustrative result: of the 12 customers who received the summary in the first month, 9 stopped reformatting by hand when I asked them about it three weeks later, and 7 were still forwarding the summary to their managers, so I kept it and added the fifth column the other three asked for. The caution: this is a dozen customers who were willing to talk to me, so I read it as encouraging, not as proof for the whole base.

Pitfalls

• A story where the data and the visit agreed has little to teach. Pick one where the visit added something.
• "I always talk to users" without a specific observation and a specific change sounds rehearsed.
• Over-reading one visit. Say how you checked it.

Direct answer

A realistic case is a small product team that adopted backend-for-frontend (BFF), one dedicated API service per client type, because it was "the recommended pattern when you have multiple frontends". BFF solves a real problem: very different clients, owned by separate teams, that need very different data shapes. This team had none of those forces. Its web and mobile apps showed nearly the same screens and were built by the same engineers, so the pattern mostly bought triplicated code, drift between clients and extra operational load. The mismatch was visible early in measurable signals: nearly identical endpoints across the BFFs, business rules leaking into them, and every feature needing several pull requests.

This is the golden-hammer anti-pattern: choosing a familiar or fashionable tool before naming the problem it is meant to solve.

The case (story skeleton)

Context. A seven-engineer team builds a B2B (business-to-business) ordering product: a web app for office staff and iOS and Android apps for field sales. One core API service owns orders, pricing and customers.

Decision. Early on, the team adds three BFF services (web, iOS, Android), each aggregating calls to the core API and shaping responses for its client. The design doc cites the pattern and large companies using it; it does not state which client need the core API fails to meet.

What happened over the following months.

• Change amplification: a new field on the order screen needed a change in the core API plus the same change in three BFFs: four pull requests, four deploys, four sets of tests for one user story.
• Logic drift: "just for now", a discount-eligibility check was added in the web BFF to unblock a release. The mobile BFFs never got it, so mobile users briefly saw prices that the web app correctly refused. The bug came from business logic living in an aggregation layer, which a BFF is not supposed to hold.
• Operational load: three extra services to patch, scale, monitor and put on call, for a team with no dedicated platform engineer.
• Latency: every call now crossed an extra network hop for responses the core API could have served directly.

Remediation. The team collapsed the three BFFs into the core API, which gained optional field selection (clients request the fields they need) and a couple of screen-oriented composite endpoints. The discount rule moved into the pricing domain code where every client gets it. A single BFF was kept later, but for a genuinely different consumer: a partner integration with its own authentication, rate limits and response format.

Why it was the wrong fit

Every pattern resolves specific forces. Checking them against this context:

With none of the forces present, the pattern contributed only its costs: more deployables, more duplicated code and a new place for business logic to hide. The value of a pattern is always relative to the problem; out of context, what remains is its overhead.

Signals that would have exposed the mismatch earlier

1. The design doc named the pattern before naming the problem. A good architecture decision record (ADR, a short document capturing context, decision and consequences) states the forces first. "Because Netflix does it" is not a force.
2. Endpoint similarity. Diffing the three BFFs' routes and response shapes would have shown them to be nearly identical. If most endpoints are copies, the per-client split has no purpose.
3. Change amplification per story. Tracking how many repositories or services a typical feature touches: one story needing four pull requests is a structural smell, not a process one.
4. Business logic outside the domain. Any if about pricing, eligibility or permissions in an aggregation layer is a warning; a lint rule or review checklist can flag it.
5. Ownership mismatch. In Sam Newman's original framing, a BFF is ideally owned by the team that owns the client. One team owning all of them is a hint the split is not buying autonomy.
6. Operational cost against team size. Services per engineer rising without a matching rise in independent release cadence.

A lightweight guard against golden hammers

Before adopting any architecture-level pattern, answer four questions in writing:

1. What specific force or pain does it resolve, and is that pain happening now?
2. What does it cost to build, run and staff?
3. What is the simplest alternative, and why is it insufficient?
4. How hard is it to reverse, and what signal would tell us to reverse it?

If question 1 has no concrete answer, defer the pattern. Adding a BFF later, when a genuinely divergent client appears, is cheap; removing three that have accumulated business logic is not.

Trade-offs and pitfalls

• The overcorrection: refusing all patterns leads to the opposite smell, one general API contorted to serve incompatible clients. The point is fit, not avoidance.
• Fixing the symptom: moving the discount rule into all three BFFs "for consistency" would have hidden the drift while cementing the duplication.
• Sunk cost: teams keep an ill-fitting pattern because removing it feels like admitting a mistake. Treat reversals as a normal outcome of an ADR with an explicit reversal signal.

Direct answer

Do not referee the argument on either side's terms. Get the product manager and the sales leader to agree on the criteria a good decision should satisfy, such as impact, risk, cost, and strategic fit, before evaluating the two initiatives against them, make the actual trade-off explicit and visible to both, and if they still cannot converge, fall back to a pre-agreed neutral path, such as a specific owner or forum, rather than letting whoever argues harder win by default.

Structured elaboration

Separate positions from underlying interests

"We should build my initiative" is a position. The interest underneath it, such as protecting a committed relationship, capturing a strategic capability, or hitting a revenue target, is what actually needs to be satisfied, and there is sometimes more than one way to satisfy it.

Agree on decision criteria before ranking anything

If the criteria are picked after looking at the options, whoever's initiative fits best gets to claim the criteria were obviously the right ones. Agreeing on what matters, and roughly how much, before scoring anything removes that bias.

Make the trade-off explicit, not implied

State plainly what saying yes to one costs the other: displaced timeline, deferred capability, real opportunity cost. Vague trade-offs, such as trying to do both eventually, just relocate the disagreement to a later date.

Have a pre-agreed fallback for genuine ties

Sometimes both initiatives are legitimately close in value. Decide in advance who breaks the tie, such as a shared manager or a specific forum, and under what timeline, so a genuine tie does not become an open-ended standoff.

Worked example

A product manager wants to build a feature that improves activation for the broad user base. A sales leader wants a different feature that would help close several deals already in the pipeline. Both have real reasoning behind their case, but the reasoning is not answering the same question, so comparing the two head-on produces a false comparison, not a decision.

The facilitator, an engineering manager in this scenario, brings both together and gets agreement on criteria first: how many users or how much revenue does each option affect, how reversible is each choice if it turns out to be wrong, and how well does each align with the stated strategy for the quarter. Evaluated against the same criteria, it becomes clear the two initiatives are not actually mutually exclusive at full scope: a smaller version of the sales-driven feature can ship inside the existing capacity without displacing the activation work, while the full-scope version is deferred to the next quarter with an explicit commitment. Both leaders leave with a decision they can each explain to their own stakeholders, because they agreed on the criteria before either one saw how the evaluation would land.

Trade-offs and pitfalls

Forcing an artificial "both, just smaller" compromise when the initiatives are genuinely incompatible produces two half-built things instead of one well-built thing. The compromise only works when the criteria step reveals real headroom, not as a default peacekeeping move.

Over-structuring a call that both sides would have agreed on anyway wastes time and can read as bureaucratic theater. And skipping the criteria-first step under time pressure, going straight to picking one, reintroduces exactly the dynamic, whoever argues harder wins, that a structured process exists to avoid.

Direct answer

The observability section of an architecture document should say what signals the service emits, what "healthy" means in numbers, where an on-call engineer looks first, and how to go from a symptom to a cause. It is a map to the monitoring system, not a copy of it: it holds the design intent and the stable names, while dashboards and alert rules live in the tooling, linked from here.

Contents (in this order)

1. Service level indicators (SLIs) and objectives (SLOs): an SLI is a measured quality of the service (for example the fraction of requests that succeed); an SLO is the target for it. List the two to four that describe user-visible health.
2. Golden signals per component: latency, traffic, errors, saturation (how full the resource is). These four come from Google's Site Reliability Engineering book and are widely used as a minimal set that covers most user-visible trouble.
3. Signals mapped to the three telemetry types: metrics (numbers over time, cheap, good for alerting), traces (one request followed across services) and logs (event detail). For each SLI say which metric measures it, which trace shows why it slipped, and which log confirms the cause.
4. Instrumentation points: where in the architecture telemetry is inserted (ingress, meaning where requests enter the service; outbound calls, queue consumers, database client), and the correlation ID (a unique ID passed along a request so its logs and traces can be joined).
5. Alerts: each alert names the symptom, the SLO it protects, severity, and the runbook link (a runbook is a step-by-step guide for handling that alert). An SLA (service level agreement) is the contractual promise to customers; the SLO is set stricter than the SLA, and the error budget is the failure allowance the SLO leaves (a 99.9 percent SLO leaves 0.1 percent). Alert on symptoms users feel, not every internal cause.
6. Dashboards and dependencies: links, and the upstream and downstream services with their own health pages.
7. Known blind spots: what we cannot currently see.

Keeping it useful without becoming a monitoring manual

• Include only what a stranger woken at night needs; put threshold tuning and query syntax in the monitoring tool.
• One table, one page: signal, what it means, first action.
• Link, do not paste screenshots that rot.

Worked variants (each a small row set)

What "healthy in numbers" looks like (illustrative targets to agree with the owning team):

And the one-table deliverable for the search row:

Pitfalls: alerts with no owner or runbook; listing hundreds of metrics; describing tools instead of decisions; no statement of what "healthy" is.

Direct answer

Showback reports each team's cloud costs for visibility without moving any money: nobody's budget is actually debited. Chargeback goes further and allocates real costs to a team's budget, typically through an internal invoice or a direct debit against their cost center. The mechanics of allocation (tagging, cost pools) are identical between the two models; what differs is whether the number is informational or binding, and that single difference changes team behavior more than almost any other FinOps decision.

Structured elaboration

Operational requirements

• Showback needs accurate tagging and a reporting pipeline (dashboards built on the provider's billing export), but no accounting integration. It is comparatively cheap to stand up.
• Chargeback needs everything showback needs, plus allocation rules for shared and hard-to-attribute costs (a shared database, a platform team's infrastructure), an internal billing or budget-debit mechanism, and usually a dispute process for when a team contests its bill. It is meaningfully more operational overhead.

Behavioral impacts

• Showback creates awareness but relies on a team choosing to act on it. It works well when the goal is building cost literacy and trust in the data, and it fails quietly: a team can see an inflated bill for months and simply not prioritize fixing it, because nothing forces the issue.
• Chargeback creates direct, budget-line accountability, which reliably produces the fastest optimization response. It also produces predictable second-order effects: teams start negotiating over shared-cost allocation formulas, and some teams under-provision or avoid experimentation because the cost is now visibly theirs. Badly designed chargeback (especially unfair shared-cost splits) actively damages trust in the whole program.

When to recommend which

• Recommend showback when tagging discipline and cost data are still immature, when the organization is early in FinOps adoption and needs cultural buy-in before it can survive a contentious billing dispute, or when the goal this quarter is visibility, not enforcement.
• Recommend chargeback once allocation is trustworthy, budget owners are clearly defined, and leadership needs teams to make trade-offs against a real budget constraint (a business unit that must self-fund its cloud spend, for example).
• In practice the strongest programs run a hybrid: chargeback for costs that are cleanly attributable to a single team (dedicated compute, a service's own database), and showback for genuinely shared infrastructure (a shared Kubernetes cluster, a platform team's networking spend) where a clean per-team split would be arbitrary and would just generate disputes instead of better decisions. This avoids forcing a false precision onto costs that are structurally shared.

Worked example

A platform team's shared cluster costs $40,000 a month and hosts workloads for three product teams, roughly split 50/30/20 by measured resource requests. Under showback, all three teams see "$20,000 / $12,000 / $8,000, informational" on a dashboard, and it is up to each team whether to act on their share. Under chargeback, those same three figures are debited from each team's budget as an internal invoice line, and a team now has to justify that $20,000 (or reduce it) the same way it justifies any other budget line. A hybrid design would chargeback the dedicated services each team also runs outside the shared cluster (fully attributable, no allocation dispute possible) while keeping the shared cluster on showback, because a resource-request-based 50/30/20 split is an estimate, not a precise cost, and billing teams against an estimate they can contest is a common source of program-trust failure.

Trade-offs and pitfalls

The biggest pitfall is skipping straight to chargeback before tagging and allocation are trustworthy: teams will contest a bill they believe is wrong, and if the underlying data really is wrong, the program loses credibility fast and is hard to recover. A second pitfall is chargeback without a clear owner for genuinely shared costs, which pushes teams toward proportional formulas nobody fully agrees with and creates ongoing friction that has nothing to do with actual waste. A third, subtler failure is showback with no organizational follow-through: if visibility never translates into any consequence, teams learn to ignore the dashboard, and the "awareness" goal quietly fails too.