Cloud Architect Interview Preparation Guide - Entry Level (FAANG Standards)

Direct answer
The security delta between Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS) in a regulated environment is mostly about where AWS-native controls plug in, not which platform is inherently more secure: ECS grants AWS permissions to workloads via a task role (one IAM role per task definition) and integrates natively with Amazon Elastic Container Registry (ECR) image scanning; EKS gives you the same image-provenance controls plus Kubernetes-native admission control, and grants AWS permissions to pods via IAM Roles for Service Accounts (IRSA) or the newer EKS Pod Identity feature, both scoped to a Kubernetes service account rather than a whole node. The bigger axis for a regulated, kernel-module-requiring workload is actually compute platform, not orchestrator: AWS Fargate and AWS Lambda run on AWS-managed microVMs with no exposed kernel to load a module into, so a workload that genuinely needs a custom kernel module has to run on self-managed Amazon EC2 (with or without ECS/EKS layered on top), never on Fargate or Lambda.

Structured elaboration

1. Image provenance / supply chain (same practice on both platforms)

• Enable ECR scan-on-push so every pushed image gets a vulnerability scan before it's eligible to run, and require image signing (for example, via Cosign) plus a generated Software Bill of Materials (SBOM) in the CI pipeline; gate deployment on both a passing scan and a valid signature, not just whatever tag exists in ECR.
• EKS adds a natural enforcement point ECS lacks: a Kubernetes admission controller (Open Policy Agent Gatekeeper or Kyverno) can reject any pod spec referencing an unsigned or unscanned image at admission time, inside the cluster. ECS has no equivalent native admission hook, so that gate has to live entirely in CI/CD, before anyone calls RegisterTaskDefinition or UpdateService.

2. Granting AWS permissions to workloads

• ECS task role: one IAM role per task definition; every container in that task shares the same role's permissions (task-level granularity).
• EKS IRSA: maps a Kubernetes service account to an IAM role via the cluster's OIDC identity provider; a pod using that service account gets credentials scoped to exactly that role, at pod granularity, without relying on node-level IAM permissions.
• EKS Pod Identity: AWS's newer, simpler alternative to IRSA that removes the OIDC-provider setup step, associating an IAM role with a service account directly through EKS, with credentials delivered by a Pod Identity Agent DaemonSet on each node. It grants the same pod-scoped access as IRSA; new EKS deployments should default to Pod Identity, but existing IRSA setups don't need to migrate for a security benefit, both remain supported.
• Both models beat relying on the worker node's own EC2 instance role in a regulated environment, because a node-level role is implicitly reachable by every pod scheduled on that node unless Instance Metadata Service (IMDS) access is explicitly locked down.

3. Compute-platform isolation, the axis that decides "can this even run here"

4. Runtime hardening once you're on EC2-backed compute (ECS-on-EC2 or EKS-on-EC2): seccomp profiles, dropped Linux capabilities, read-only root filesystems where the workload allows it, and behavioral runtime monitoring to catch container-escape attempts, since a shared kernel means an escape reaches every other workload on that host, not just its own task or pod.

Worked example
A regulated workload needs a custom eBPF-based network kernel module for deep packet inspection. Working through the table: Lambda and both Fargate options are eliminated immediately on the kernel-module requirement alone. That leaves EC2 self-managed, ECS-on-EC2, or EKS-on-EC2. Because the organization already runs Kubernetes-native policy tooling and wants IRSA/Pod-Identity-scoped AWS access per workload rather than one task role per definition, EKS-on-EC2 with a dedicated, tainted node group (so only this workload schedules there, bounding the shared-kernel blast radius) is the concrete choice, with ECR scan-on-push plus signature verification enforced at admission by Gatekeeper before any pod referencing that image can schedule.

Trade-offs & pitfalls

• Don't conflate "EKS supports IRSA/Pod Identity" with "EKS is more secure than ECS" - in a regulated environment, the decision that matters most is almost always the compute-platform row (Fargate/Lambda's managed isolation versus EC2's operational burden), not the orchestrator.
• A dedicated node group with a taint only limits scheduling; it doesn't stop a privileged container from reaching the underlying kernel. Combine it with seccomp/capability drops, it isn't a substitute for them.
• IRSA still works and is well understood; treat migrating existing IRSA workloads to Pod Identity as a "prefer for new work" recommendation, not an urgent deprecation.
• Enforcing image signing only in CI (ECS's situation) is bypassable by anyone with ecs:RegisterTaskDefinition permission who skips the pipeline; EKS's admission-controller gate is the stronger control precisely because it's enforced at the cluster, not only at the pipeline.

Direct answer

For the core text-editing path, choose between operational transformation (OT) and CRDTs (Conflict-free Replicated Data Types, data structures designed so two divergent copies can always be merged automatically without a central coordinator), both can correctly merge concurrent, even offline, edits, but they make different trade-offs between server dependence, storage, and implementation risk. Last-writer-wins (LWW), where the most recent write simply overwrites an earlier one, is not appropriate for concurrent body-text edits since it would silently discard one person's work, but it is fine for single-writer metadata like a document's title.

The three approaches

• Operational transformation (OT). Each incoming remote edit is transformed against whatever concurrent edits happened locally, so it can be applied correctly on top of a state that has since diverged. For example, if you inserted a character at position 5 while someone else concurrently deleted a character at position 2, OT rewrites your insert's target position to account for the shift caused by their delete, keeping both edits' intent intact. This is how early Google Docs-style collaborative editors worked.
• CRDTs for text (commonly a sequence CRDT such as an RGA, replicated growable array). Every character gets a stable, unique, immutable position identifier when it's inserted, so two replicas can merge their edit histories in any order, or after being offline for a while, and always converge to the same document without needing a central server to referee the merge.
• Last-writer-wins. For document editing specifically, LWW applied to the body text would let one person's entire concurrent edit simply overwrite the other's, an unacceptable loss of work; it only makes sense for metadata fields with a single natural owner, like "last editor" or the document title.

Comparison

Worked example

Two people edit the same paragraph while briefly offline from each other, one inserts a word near the start, the other deletes a sentence later in the same paragraph. A text CRDT assigns each character a stable position identifier at insert time, so when the two edit histories merge, both changes apply correctly without either needing to know about the other's edit in advance, insertions and deletions from both sides land in the right place relative to each other. The same scenario under OT routes both operations through a central server (or a peer acting as one), which transforms whichever arrives second against the one that arrived first. That part works even though both authors were offline at the same time: on reconnect each client sends its operations tagged with the server revision it last saw, and the server transforms them forward, which is exactly how offline mode in a server-backed editor is built. What OT does not give you is the same guarantee with no server in the picture at all, because peer-to-peer OT requires the transform function to satisfy a much stronger pairwise property (any two operations must transform to the same result no matter which order the peers apply them in), and that property is hard to prove and easy to get subtly wrong. The CRDT's advantage is therefore narrower than "it handles offline": both handle offline, and the CRDT is what handles offline without a sequencer.

Trade-offs and pitfalls

The most relevant trade-off for an offline-first or peer-to-peer product is that CRDTs handle the offline case naturally while classic OT generally assumes a central server is available to serialize operations; the cost is CRDTs' larger memory footprint from per-character metadata and tombstones, which needs its own garbage-collection strategy over time so it doesn't grow unbounded.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Direct answer
To know whether a postmortem process is actually working, track a small set of metrics on two levels: is the process itself being followed (leading indicators like action-item closure rate and time-to-close), and is it producing real outcomes (lagging indicators like incident recurrence rate and time between related incidents). Neither kind alone is enough: high process compliance with unchanged recurrence means the process is theater, and improving recurrence without process metrics gives you no early warning when things start slipping.

Structured elaboration
Useful metrics, split by what they tell you:

• Process health (leading): action-item closure rate within the committed deadline; median time from incident to a completed postmortem writeup; percentage of postmortems with at least one measurable, owned action item (a postmortem with zero action items is a red flag, not a sign nothing needed fixing); adoption rate, meaning the fraction of qualifying incidents that actually got a postmortem at all.
• Outcome (lagging): recurrence rate of the same or a closely related incident class; mean time between incidents in a given category; trend in overall incident severity over a quarter or two.
• Cultural signal (supporting): near-miss and self-reported-incident volume, and a periodic anonymized psychological-safety survey, since a process can look procedurally healthy while people quietly stop reporting things.

Collection should be mostly automatic: pull closure rates and time-to-close from whatever ticketing system tracks action items, rather than relying on manual reporting that decays over time. Report these on a regular cadence (monthly or quarterly) to both the engineering org and, in summary form, to leadership, since visibility is part of what keeps the process from quietly eroding.

Worked example
A team tracks action-item closure rate at 60% within the committed deadline and a database-related incident recurring three times in six months. Rather than treating these as separate facts, they cross-reference: two of the three recurring incidents trace back to the same never-closed action item from an earlier postmortem, which had been marked 'in progress' for four months with no owner actively working it. This tells the team the real problem isn't the postmortem process itself producing bad analysis, it's a downstream tracking gap: action items get created but nothing enforces follow-through. The fix is a lightweight escalation rule (any action item open past its deadline gets automatically flagged to the item owner's manager), and the team adds 'percentage of overdue action items escalated within a week' as a new leading metric to catch this earlier next time.

Trade-offs and pitfalls
A common failure is optimizing the metric instead of the outcome, for example closing action items quickly by scoping them down to something trivial just to hit a closure-rate target, which improves the number while leaving the real risk unaddressed. Guard against this by periodically auditing a sample of 'closed' items against whether the underlying incident class has actually stopped recurring, not just whether a ticket got marked done.

Direct answer

Name a single decision owner with real tie-breaking authority before any option is scored, gather each party's true constraints rather than their stated position, and force agreement on the decision criteria before anyone looks at the options, because scoring options before agreeing on criteria invites each side to reverse-engineer the criteria that favor the answer it already wanted.

Structured elaboration

Inputs to gather, one per stakeholder group

From engineering: the workload's actual technical requirements and non-functional requirements, and its current pain points. From security: which compliance, data-residency, or audit requirements are true constraints, not preferences. From procurement: the actual contract terms, current spend commitments, and any existing enterprise-agreement minimums that change the effective cost of either path.

Artifacts to produce

1. A single shared decision-criteria document, listing every requirement as a hard "must" or a "nice-to-have," agreed before anyone looks at candidate options, specifically to prevent criteria being shaped around a preferred answer after the fact.
2. A weighted-scoring table, applied jointly in one working session with all three parties present, not compiled offline by one side and presented as a fait accompli.
3. A written decision record capturing the decision made, the runner-up option, and the specific conditions that would change it later.

Driving to resolution

Name the decision owner and their tie-breaking authority up front, before scoring starts, not after a stalemate has already formed. Set a hard deadline. If the group is still split after scoring, escalate only the specific one or two criteria still in dispute to the decision owner, rather than reopening the entire decision from scratch.

Worked example

Security's true "must" turns out to be in-region data residency. Procurement's true "must" is preserving an existing $2,000,000 enterprise commitment with a specific vendor because of a contractual minimum. Engineering's true "must" is horizontal scalability past current on-premises capacity. On the surface this reads as a three-way conflict framed as "cloud versus on-premises," but once the facilitator separates each side's actual constraint from its stated camp ("cloud" or "on-premises" as tribal positions), it turns out the existing vendor's cloud offering satisfies in-region residency, satisfies the existing commitment, and satisfies the scalability requirement simultaneously. The conflict dissolves once positions are separated from the underlying interests they were standing in for, which is the core facilitation move worth applying deliberately rather than by luck.

Trade-offs and pitfalls

Scoring options before the group has agreed on criteria is the single most common way this kind of process stalls, because it invites each party to shop for criteria that justify the answer they already wanted. A facilitator with no real tie-breaking authority means the process stalls exactly at the moment it matters most, when the group is genuinely split. And treating this as a purely technical decision, when procurement's contractual constraint may actually be the binding constraint the entire debate should have started from, wastes real time relitigating options that were never viable once that constraint is known.

Direct answer. Pick one system, say what threat you designed against, name the two or three decisions you made early, name what you pushed back on and why, and finish with how you verified it was safer. Below is a story shape using a plausible example (a document-processing service for many customers); replace the details with your own real system.

Situation. A team was designing a service where many customers (tenants) upload documents that are parsed and searched. The design was one shared database and one shared storage bucket, with tenant filtering done in application code. I joined at the design stage, before any code existed.

Task. Make cross-tenant data exposure structurally hard, without delaying the first release.

Actions I took

• Decided on isolation by construction. Each tenant's objects went under a tenant-scoped prefix (a folder-like path such as tenant-123/ in the bucket, one per customer), and the service accessed storage using short-lived credentials (access keys that expire after minutes, so a leaked one soon becomes useless) restricted to that prefix. The point: a bug in the filter code can no longer read another tenant's files, because the credential itself cannot. This is least privilege (give a component only the access it needs) and blast-radius limiting (shrink what one failure can reach).
• Closed the shared-database gap. Storage prefixes do not protect rows in the shared database, where the filter in application code was still the only barrier. I asked for row-level security (the database itself refuses rows whose tenant column does not match the session's tenant, so a missing filter in code returns nothing instead of another customer's data), and I made the cross-tenant test cover API reads of database records as well as files. Had the team not been able to do that before launch, I would have recorded the database as a dated, owner-signed risk acceptance instead of calling the design safe.
• Pushed back on a shared admin credential the team wanted for the background workers to "keep it simple". I offered a per-job scoped credential instead, with the same developer effort because a platform library already issued them. The exchange went roughly like this (illustrative). Team: "One admin credential for the workers keeps it simple." Me: "A credential scoped to one tenant's prefix costs you the same one line from the platform library, and a worker bug can then only touch one tenant's files." The team agreed because the cost to them was unchanged.
• Pushed back on logging full document contents for debugging. I proposed logging document IDs and sizes, which kept debugging possible and removed a second copy of the sensitive data.
• Kept the review early and small. I asked for a one-page data-flow diagram and gave feedback within days so design was not stalled.

Result and how we knew it was safer. I did not rely on opinion. We measured with three checks:

1. A cross-tenant test in the pipeline: a test tenant tries to read another tenant's object by guessing the ID and must get a denial. It ran on every build, so the control could not silently regress.
2. A pre-launch penetration test (an authorised, simulated attack by security specialists) focused on tenant isolation, with no cross-tenant read found.
3. An alert on denied cross-tenant attempts, so after launch we could see the control working and see any probing.

The effectiveness measure for an early control is the count of failing cross-tenant tests (should stay at zero) plus the number of denied attempts that reach the alert. I would avoid quoting a made-up percentage; the honest claim is "for stored files, and for database rows once row-level security was in place, the class of bug was removed, and a test proves it stays removed".

What I would do differently. I would have written the cross-tenant test before the design review ended, not after, so the requirement was executable from day one.

Pitfalls. Do not tell a story where you only said no. Strong stories show a pushback with a cheaper alternative offered, and an outcome that someone other than you could verify.

Direct answer: The strongest version of this story names the specific technical cause of the failure, shows the verification steps that confirmed the rollback actually succeeded (not just that it was executed), and describes a concrete process or technical change made afterward, not just a vague "we learned to be more careful."

Structured elaboration. Technical cause of the failure: be specific (e.g., "a schema migration step that we believed was backward-compatible actually broke a query the still-running old application version depended on, causing a spike in application errors within minutes of cutover") rather than a generic "something went wrong." How you verified the rollback succeeded: this is often the weakest part of a candidate's answer, and the strongest candidates describe concrete verification, e.g., confirming error rates returned to baseline, confirming a data-integrity check (row counts/checksums) showed the reverted system was consistent, and confirming no writes were lost or duplicated during the rollback window, rather than just "traffic was pointed back and things looked fine." How you communicated with stakeholders: acknowledging the issue promptly, giving a realistic timeline rather than optimistic guesses, and following up with a clear post-incident summary (what happened, what was the user impact, what's being done to prevent recurrence) shows the communication maturity interviewers are actually probing for with this question. Process or technical changes implemented afterward: concrete, not aspirational — e.g., "we added an automated backward-compatibility check to the migration pipeline that would have caught this specific class of issue before it reached production" is a much stronger answer than "we started being more careful with schema changes."

Worked example. A realistic story: during a database cutover, a schema change dropped a column the OLD application version (still serving a small percentage of traffic during a canary rollout) still queried, causing 500 errors for that traffic slice within about 3 minutes of the change. The rollback: reverted the schema change (it hadn't yet been backfilled with dependent data, so this was a clean reversal), confirmed via monitoring that the error rate for the affected traffic slice returned to baseline within about 90 seconds of the reversal, and ran a data-integrity check confirming no writes had been lost during the brief window (query volume during that specific 3-minute window was cross-checked against the application's own request logs to confirm no requests silently failed without being logged). Stakeholder communication: posted an initial incident notice within 5 minutes of detecting the error spike, a resolution confirmation once verified, and a written post-incident summary within 48 hours. Process change: added an explicit pre-migration check that diffs the schema change against every currently-deployed application version's known query patterns (not just the newest version), specifically to catch backward-incompatibility with an OLD version still partially in rollout, which was the actual root cause here (the schema check that existed only validated against the NEW application version).

Trade-offs & pitfalls. A common weak point in this answer is describing the failure and the fix vividly but glossing over HOW rollback success was verified; interviewers specifically probe this because "we rolled back and it seemed fine" versus "we confirmed via X, Y, Z that it was actually fine" is a meaningful signal about whether the candidate treats verification as a real discipline or an afterthought.

Direct answer

IAM (Identity and Access Management) evaluates a request by checking every applicable policy type against a strict order, and an explicit deny in any of them wins immediately, before anything else is considered. After the deny check, the remaining layers narrow the decision: the account's service control policies (SCPs) must allow the action at all, then, for a resource that supports one, a resource-based policy may itself supply the allow, then the identity-based policy attached to the calling user or role must allow it, and finally, if the principal has a permission boundary, or the credentials came from an assumed-role or federated session with a session policy attached, those must also allow it. Nothing is granted by default: if a layer that applies to the request doesn't say allow, the request is denied.

Structured elaboration

• Identity-based policies. Attached to a user, group, or role, this is the policy that actually grants permissions to that principal. If none of the principal's identity-based policies allow the action, the request is denied, barring the resource-based policy exception below.
• Resource-based policies. Attached to the resource itself, an object storage bucket policy, a key management service (KMS) key policy, or an IAM role's trust policy. For most resource types, an allow from either the identity-based policy or the resource-based policy is enough; IAM role trust policies and KMS key policies are the two well-known exceptions that require their own explicit allow regardless of the identity policy. One subtlety worth knowing: who the resource-based policy names changes what else applies. If it names the role or user directly, a permission boundary or session policy elsewhere still caps the grant; if it names the actual assumed-role session, not the role itself, or a federated-user session created through the security token service (STS), the resource-based policy grants that session directly, and a permission boundary or session policy does not additionally restrict it, only an explicit deny would.
• Permission boundaries. Attached to a user or role to cap the maximum permissions its identity-based policies can ever grant it. The effective permission is the intersection of the identity-based policy and the boundary; the boundary never grants anything by itself.
• Service control policies (SCPs). Applied at the organization level to an account or organizational unit, capping the maximum permissions available to every principal in scope, again by intersection, never by granting.
• Session policies. Passed only when a role is assumed or a federated user session is created, for example via STS, further capping that one session's permissions to the intersection with the role's own identity-based policy, for the life of that session only.
• Order, put together. An explicit deny anywhere ends things immediately. Otherwise: the SCP must allow, then a resource-based policy may itself resolve the decision (see the subtlety above), then, if not already resolved, the identity-based policy must allow, then a permission boundary, if attached, must allow, then a session policy, if present, must allow. Missing an allow at any layer that applies to the request produces a denial, because the baseline, with no applicable policy at all, is implicit deny.

Worked example

A concise debugging checklist for an unexpected access-denied result, applied to a scenario where a role that should be able to write to an object storage bucket gets denied:

1. Confirm the exact API call, the resource's Amazon Resource Name (ARN), and the error from the account's request-logging service; some deny messages name the specific policy type that produced the deny, which shortcuts the rest of this list.
2. Search every applicable layer, identity-based policy, resource-based policy if any, permission boundary if any, SCPs on the account or organizational unit, and session policy if the credentials are a role or federated session, for an explicit deny statement matching this action or resource. An explicit deny anywhere decides the outcome immediately; find and resolve it before looking anywhere else.
3. If there's no explicit deny, check the account or organizational unit's SCPs: does an applicable SCP restrict this action? SCPs only restrict, so if none apply, this layer is a non-issue.
4. Check whether the target resource has a resource-based policy, and if so, whether it independently allows the action, paying attention to who it names, the role or user itself versus the specific assumed-role session or federated-user session, since that changes whether a boundary or session policy downstream still applies.
5. If the decision isn't already resolved by step 4, confirm the identity-based policy attached to the calling principal actually includes this action and resource, watching for an ARN or condition-key mismatch, a wrong path prefix, a missing wildcard, a condition requiring MFA or a specific source network this call doesn't satisfy, as the single most common root cause once denies and SCPs are ruled out.
6. If the principal has a permission boundary attached, confirm the boundary itself includes an explicit allow for this action; it caps the identity policy and can never widen it.
7. If the credentials came from an assumed role or federated-user session with a session policy attached, confirm the session policy also allows the action.
8. If the manual walk-through is still ambiguous, run the account's policy simulator against the exact principal, action, and resource for a layer-by-layer allow-or-deny readout rather than reasoning through it further by hand.

Trade-offs and pitfalls

The most common debugging mistake is jumping straight to the identity-based policy because it's the most familiar layer, and missing an SCP or permission boundary that's silently capping things underneath it; the checklist works because it forces the layers people forget to be checked in the order that actually decides the outcome. A resource-based policy that grants cross-account or session-scoped access is easy to forget when debugging purely from the calling principal's own policies, since nothing in the principal's own policies would explain why access does or doesn't work; the checklist has to include the resource side, not just the caller's side, and specifically who the resource policy names. Permission boundaries and SCPs are easy to conflate, since both only restrict and never grant, but they operate at different scope, one principal versus an entire account or organizational unit, and mixing them up when explaining the model is a common tell the difference isn't fully internalized. A plausible-looking but wrong condition key, or an ARN with the wrong resource-type segment, fails silently as "no match" rather than raising an error, so a debugging session can stall on a policy that looks correct at a glance; verifying the exact identifier, not just its plausibility, matters.

Direct answer
To quantify the cost of too many overlapping-responsibility microservices, measure deployment coordination overhead (how often a single logical change requires touching multiple services in lockstep), on-call and incident load per service, infrastructure cost per service (even a nearly-idle service carries a fixed baseline cost), and cross-service change frequency (how often a change to one service requires a corresponding change to another); present the trend in those numbers to executives rather than an architectural opinion about service count.

Structured elaboration
Deployment coordination overhead is measurable directly: track how many recent releases required coordinating changes across two or more services that, if consolidated, would have been a single deploy, and how much calendar time that coordination added compared to a single-service change. On-call load is measurable from incident data: total pages per service per month, and specifically how many of those incidents were caused by an inter-service contract mismatch (a caller and callee disagreeing about a field's meaning or an API version) rather than a genuine bug in one service's own logic, since contract mismatches are a direct symptom of over-decomposition. Infrastructure cost is measurable from the cloud bill: baseline compute, monitoring, and logging cost per service, multiplied by the number of services that could plausibly be consolidated without losing a real scaling or ownership benefit. Cross-service change frequency is measurable from version-control history: how often a pull request in one service's repo is immediately followed by a corresponding pull request in another service's repo within a short window, a proxy for services that are more tightly coupled in practice than their separate deployability suggests.

Worked example
A lightweight experiment to gather this evidence without a large upfront investment: instrument the deploy pipeline to tag any release that required a coordinated multi-service change, and run that for a month before making a consolidation recommendation, rather than relying on anecdotes about "it feels like everything requires touching three services." Present the finding to executives in business terms: "N% of releases in the last quarter required coordinating three or more services, adding an average of X days to the release; consolidating these two specific services would remove that coordination cost for roughly Y% of those releases," rather than a purely technical argument about service-count aesthetics.

Trade-offs and pitfalls
The risk of presenting this case poorly is framing it as "we have too many microservices" in the abstract, which invites a debate about architectural philosophy instead of a decision grounded in measured cost; naming the SPECIFIC services with the worst coordination and incident numbers, and proposing a targeted consolidation of just those, is both more persuasive and less risky than a broad "let's reduce our service count" initiative. The countervailing risk is consolidating services that look similar on paper but actually have a real, measured difference in scaling or team ownership; the same data-gathering discipline that justifies a consolidation should also be used to rule one out when the signals don't actually support it.

Direct answer

Break the estimate into three buckets, compute, storage, and network egress, state a small number of explicit assumptions for each (traffic shape, cache hit ratio, unit prices), and multiply through. For this workload, 1,000,000 requests/day and 10 TB of outbound data/month, the arithmetic below lands around 1,246 dollars/month using illustrative unit rates, with network egress the dominant line item. The one sanity check worth doing at the end is dividing total outbound data by total requests: it implies each request carries roughly 333 KB on average, which is large for a "simple web app" and should prompt asking whether the two given numbers actually describe the same traffic.

Structured elaboration

Why three buckets, always kept separate
Compute, storage, and network egress scale with different things (request rate, data volume at rest, data volume transferred), so lumping them together hides which one actually drives the bill. For a workload described mainly by a request count and an outbound-data figure, network egress is very often the surprise line item, since it scales with bytes moved, not with request count.

Stated assumptions (illustrative unit rates, not any specific vendor's current list price, so the arithmetic below is fully reproducible from these inputs alone):

• 1 TB = 1,000 GB for this estimate (a decimal convention, kept simple and stated once; real billing sometimes uses the binary definition instead).
• A 5x peak-to-average traffic ratio, a common assumption absent a stated diurnal profile.
• Compute: $0.10 per instance-hour; a minimum of 3 instances regardless of load, for basic redundancy and zero-downtime deploys.
• Storage: a flat $20/month (small, since a "simple web app" is not primarily a database- and storage-heavy workload).
• Network: 60% of requests served from a content delivery network (CDN) cache; origin egress (cache misses only) at $0.09/GB; CDN edge egress (all bytes delivered to users) at $0.06/GB.
• Miscellaneous (load balancer, monitoring, DNS): $50/month.

Worked example

Compute.

$\text{avg RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6, \qquad \text{peak RPS} \approx 11.6 \times 5 \approx 58$

Even one modest instance clears 58 req/s comfortably for a typical stateless web app, so the instance count here is driven by redundancy, not raw capacity: 3 instances.

$\text{compute} = 3 \times \$0.10/\text{hr} \times 24 \times 30 = \$216/\text{month}$

Network egress, the dominant cost for this workload. Two separate legs, both real: the cache-miss traffic the CDN pulls from the origin (pricier), and the full volume the CDN delivers to end users regardless of hit or miss (cheaper, volume-discounted).

$\text{miss traffic} = 10{,}000 \text{ GB} \times (1 - 0.6) = 4{,}000 \text{ GB}$

$\text{origin cost} = 4{,}000 \text{ GB} \times \$0.09/\text{GB} = \$360$

$\text{CDN cost (all delivered bytes)} = 10{,}000 \text{ GB} \times \$0.06/\text{GB} = \$600$

Total.

$\text{total} \approx \$216 + \$20 + \$360 + \$600 + \$50 = \$1{,}246/\text{month}$

Sanity check, the part the question explicitly asks for. Cross-check the two given numbers against each other, not just against the chosen unit prices:

$\text{requests/month} = 1{,}000{,}000 \times 30 = 30{,}000{,}000$

$\text{avg payload} = \frac{10{,}000 \text{ GB} \times 1000 \text{ MB/GB}}{30{,}000{,}000} \approx 0.33 \text{ MB} \approx 333 \text{ KB per request}$

A typical JSON API response is a few KB, not a third of a megabyte. A 333 KB average suggests this "simple web app" is actually serving images, downloads, or media, not just API calls, or that the two input numbers don't describe the same traffic, for instance if the 10 TB includes a batch export job outside the 1,000,000 daily request count. That is the real value of this sanity check: it isn't re-verifying the arithmetic, it's confronting whether the two numbers handed to you are internally consistent with the story you were told, before handing a stakeholder a dollar figure built on an unstated contradiction.

Trade-offs & pitfalls

• Pricing only one leg of egress (origin-to-CDN or CDN-to-user) and treating the network line item as done.
• Skipping the sanity check and presenting the total as precise when the underlying assumptions (cache hit ratio, peak ratio) were guesses; state which input the total is most sensitive to.
• Sizing compute purely off average load; for small-to-medium workloads, redundancy and deploy safety often set the compute line, not raw throughput math.
• What separates a senior answer: showing the arithmetic and stating which two given numbers were cross-checked at the end, and why, rather than presenting a total as if it fell out of a spreadsheet with no further scrutiny.