AWS Cloud curriculum

Isolation is the default in both directions: no data leaves without an explicit configuration, and no failure arrives from elsewhere. That is why a resource list looks empty after switching Regions in the console, and why a disaster-recovery plan is work rather than a setting — replication is something you build.

The separation is physical — independent power, cooling and flood plain — while the interconnect is fast enough for synchronous replication between zones. That combination is the whole design: failures are meant to be uncorrelated, and latency low enough that spreading across them costs nothing noticeable.

One protects against losing a building and is nearly free to adopt; the other protects against losing a Region and changes data modeling, latency and cost everywhere. Most systems need the first and very few genuinely need the second, so the honest question is which failure you are actually buying insurance against.

The letter suffix is shuffled per account so load spreads evenly rather than everyone crowding into the first one. Two accounts comparing notes about the same named zone are usually talking about different hardware, which matters when coordinating placement across accounts — the stable identifier is the one that does not move.

A handful of services have one worldwide view; the rest exist separately in each Region and are invisible from the others. The practical tell is the console's Region selector greying out. It also explains why an identity created once works everywhere while a queue created in one Region cannot be found in another.

These sit close to users to cache content and terminate connections, and they are not places you can run general workloads. Confusing them with Regions produces plans to "deploy to the edge" that the architecture does not support — what runs there is deliberately limited in time, memory and capability.

The line falls between the infrastructure and what you put on it, and the useful reading is that nothing on your side has a default that is safe. The provider's half is genuinely handled; the half that causes incidents — access, configuration, data classification — is entirely yours and is not covered by anything.

The line moves with the service: on a virtual machine you own patching, on a managed database you do not. What never moves is who decides who may read the data and whether it is encrypted — those stay with you at every level, which is why "managed" is never an answer to a security question.

An account is the only boundary that holds under a mistake — a wrong tag, an over-broad policy or a runaway script cannot cross it. Separating environments by tag inside one account gives you naming, not isolation, and the difference only becomes visible on the day it matters.

No policy can restrict it, which means the usual defenses do not apply and the only real controls are physical: a hardware second factor, no programmatic keys, and no routine use. A handful of operations genuinely require it, and those are the only times it should ever be signed in.

Grouping accounts into a tree means a control applied high up governs everything beneath it, so a new account inherits the rules of wherever it is placed rather than needing its own setup. The structure is therefore a policy decision — where an account sits determines what it can do.

It sets a ceiling and never grants anything, so removing one does not break access and adding one cannot create it. Permission is the intersection of the ceiling and the identity's own policy, which is why a request can be denied while the identity's policy plainly allows it — the ceiling is lower.

One holds credentials that exist until someone rotates them; the other holds none and issues short-lived ones on request. That difference is why roles are the default for anything automated — there is no secret to leak, no rotation schedule to miss, and an access grant expires by itself.

A group is a convenience for attaching the same policies to several identities, not an identity itself — nothing can assume it and nothing can name it as a trusted party. That trips people up when they try to grant cross-account access to a group and find there is nothing to point at.

Two separate questions, answered by two separate documents: who is allowed to take on this role, and what that grants once taken. Both must permit the operation, so an access failure here is ambiguous until you check which of the two refused — and they are edited in different places.

It is the plumbing that delivers a role's credentials to a running machine, so an application can call services without any secret ever being written to the filesystem or baked into an image. Anything reaching for a stored key pair on an instance is almost always missing this.

One is attached to who is asking and names no subject; the other is attached to the thing being asked for and must name who may ask. Knowing which kind you are writing determines whether a principal element is required or forbidden — and getting it wrong produces a document that will not save.

Access between accounts is granted by a role in the destination whose trust document names the source, so nothing is copied and nothing long-lived is shared. Distributing access keys instead recreates every problem roles exist to solve, and it is invisible to the destination account's own audit trail.

Nothing is permitted until something permits it, so the absence of a rule is a refusal rather than an omission. That makes every grant additive and auditable — but it also means a permission failure is usually a missing statement rather than a wrong one, which is a different thing to go looking for.

A single refusal anywhere in the evaluation beats every permission, wherever it came from — the identity's policy, the resource's, a boundary or an organizational ceiling. That is what makes a guardrail reliable, and it is why chasing a denial by adding permissions gets you nowhere.

The elements answer separate questions — what happens, to which operations, on which resources, for whom, and under what circumstances — and the subject element belongs only where the document is attached to a resource. Including it on an identity document is a common malformation.

Wildcards match inside an identifier, which is useful for a prefix and dangerous as a whole value: a grant scoped to everything turns a purpose-built role into a general-purpose one. It is the commonest over-grant precisely because it makes the immediate problem go away.

Conditions gate a statement on the circumstances of the request — where it came from, whether a second factor was used, which Region, what the resource is tagged with, whether encryption was requested. They are what turns a coarse permission into a usable one without enumerating every resource.

A boundary caps what an identity's own policies can achieve, so the effective permission is the overlap of the two rather than their sum. That is what makes it safe to let a team grant permissions to their own roles: whatever they write, the ceiling still applies.

A request crossing accounts must be permitted on both sides, so a resource document alone does not grant access to an outside caller — their own account must also allow the call. Debugging this means checking two policies in two places, and the error message names neither.

Three values come back and all three must be presented; sending the pair without the session token produces a signature failure that reads like a wrong secret. That is the most common first encounter with temporary credentials, and it is a transport mistake rather than a permission one.

Expiry is the feature: there is no long-lived secret to rotate, and a leaked credential is useful only for as long as it has left. It also imposes a discipline on code — anything caching credentials for longer than their lifetime will fail at an unpredictable point rather than immediately.

A policy supplied at assume time can only subtract, never add, so it cannot be used to widen access beyond what the role already has. That is what makes it safe to hand a session to a less-trusted process: the worst case is the role's own permissions, not an escalation.

A third party holding roles for many customers can be persuaded to use the wrong one unless each customer supplies a shared value they must present. Without it, knowing your role's identifier is enough for another of their customers to reach your account through them.

Credentials arrive from a link-local endpoint and rotate without intervention, which removes the stored secret entirely. The versioned protocol requires obtaining a token first, and that single change is what stops a server-side request forgery bug from reading credentials by tricking the application into fetching a URL.

The primary range is fixed at creation and cannot be reduced, so a network chosen casually is a decision you live with. Overlap is the expensive version of the mistake: two networks using the same range can never be connected directly, and discovering that usually happens years later during a merge.

A subnet never spans zones, which is why zone redundancy means several subnets rather than one large one. It also explains a common surprise: a load balancer registered in a single subnet cannot reach targets in another zone, however the targets themselves are configured.

Five addresses in every subnet are taken for the network, the router, DNS, a future use, and broadcast, so the usable count is always five below the arithmetic. On a small subnet that is a large fraction, which is how a carefully sized range runs out of addresses sooner than planned.

Nothing marks a subnet as public except its route table pointing the default route at an internet gateway. There is no flag and no naming convention that makes it so, which is why a subnet called public with a private route table behaves privately and looks correct in every console listing.

It lets private instances reach out and accepts nothing inbound, which is exactly the asymmetry a private tier needs for updates and outbound calls. It must itself live in a subnet with a route to the internet, which is the configuration people most often get backwards.

The most specific matching route wins regardless of the order rules appear in, so a narrow route overrides a broad one. Where two are equally specific a defined precedence applies, with a manually added route taking priority over one learned dynamically — which is how an override is expressed.

Because the return path of an allowed connection is permitted automatically, outbound rules do not need to anticipate replies. That is why removing the default outbound rule breaks new connections the instance initiates while leaving inbound service traffic working — the two directions are not symmetrical.

Each direction is judged on its own, so a permitted inbound connection still needs an outbound rule covering the high-numbered ports the reply uses. Forgetting that produces a connection that establishes and then hangs, which looks like an application fault rather than a network rule.

There is no way to write a refusal — you exclude something by not including it. That makes them safe to compose, since no rule can override another, and it also means blocking one specific address requires the other mechanism entirely.

Rules are read in numeric order and the first match ends the evaluation, so a broad permission at a low number makes every more specific rule below it unreachable. Numbering with gaps is the usual convention precisely so a rule can later be inserted above one.

Naming another group rather than an address range means the rule keeps meaning the same thing as instances come and go, scale out, or change addresses. It also documents intent: the rule says which tier may talk to which, rather than encoding a snapshot of today's addressing.

Traffic to a supported service travels over the internal network instead of out through a gateway, which removes the need for public addressing on the instances that use it. It is also a control point — an endpoint policy can restrict which buckets or resources are reachable through it.

A peering connection carries traffic only between its two ends, so three networks fully connected need three connections and the count grows quadratically. That is the whole argument for a hub: transitive routing has to come from something designed for it rather than from more peerings.

The states describe what is running and what is billed, and only one of them is irreversible. Knowing that termination is final is what makes termination protection worth enabling on anything that matters — the other transitions are recoverable, and this one is not.

Stopping keeps the identity and the attached root volume so the machine can come back as it was; terminating releases both and, by default, deletes that volume with it. The default is the part that bites — the data disappears with no separate confirmation step.

Storage physically attached to the host disappears when the instance stops or the host fails, with no recovery path. It is fast and free of network variance, which makes it right for scratch space and caches, and disqualifying for anything whose loss would matter.

An image exists in the Region where it was created until it is deliberately copied, so a recovery plan that assumes images are available elsewhere has a missing step. The copy is straightforward and it is exactly the kind of task nobody remembers until the Region they need is the one that is down.

It executes on first boot, which makes it a bootstrap rather than a way to keep configuration correct over time. Anything expected to converge, re-apply or update needs a configuration-management tool — using this for that produces drift that nothing reports.

The models trade commitment against price: pay per hour for unpredictable work, commit to a baseline for a discount, or take reclaimable spare capacity for the largest saving. Most bills improve by matching the model to the shape of the workload rather than by resizing anything.

Capacity can be reclaimed at short notice, with a brief warning, so the workload has to be able to stop and resume. That makes it excellent for batch, rendering and anything checkpointed, and unusable for work that must finish once started unless there is a fallback.

The group's job is to keep a target number of healthy instances running between two bounds, replacing failures without intervention. The bounds are also a safety mechanism — a maximum stops a runaway scaling policy, and a minimum stops an aggressive one from scaling to nothing.

The infrastructure check only knows whether the machine is alive; the load balancer's check knows whether it is serving correctly. Leaving it on the first means an instance that boots and then returns errors is never replaced, which is the failure most likely to happen in practice.

One holds a chosen metric at a set point and works out the thresholds itself; the other reacts in graded jumps to an alarm you define. The first is right for the common case and needs almost no tuning, and the second exists for the situations where the response has to be shaped deliberately.

One understands the request — it can route on host, path or header, and terminate TLS; the other forwards connections and preserves the client address. The choice is usually decided by whether you need content-based routing or whether the application needs to see the real source address.

Removing a target immediately would cut in-flight requests, so the target is held in service until they finish or a timer expires. Setting it shorter than the longest legitimate request turns every scale-in and deploy into a small number of user-visible errors.

Adding instances has no ceiling short of quotas and needs no interruption; making one bigger has a maximum size and requires a restart. That asymmetry is why the architectural work — statelessness, session offloading — pays for itself, since it is what makes the first option available at all.

Each environment handles a single event at a time, so concurrency comes from running more of them rather than from threading inside one. That simplifies the code — no shared-state races within an invocation — and it means anything limiting concurrency downstream, such as a database connection limit, is reached by multiplication.

A request arriving at a brand-new environment pays for its setup before the handler runs, which shows up as a latency tail rather than a slow average. Keeping environments warm removes it at a cost, and reducing initialization work removes it for free — the second is usually the better first move.

Code outside the handler runs once per environment and is reused for every subsequent event, which is where clients and connection pools belong. It is equally where per-request state must not live: a variable set during one invocation is still there for the next one on the same environment.

One partitions the account's limit so a function is guaranteed a share and capped at it; the other pre-initializes environments so they are warm. They are often confused because both are set as a number on the function, and only the second affects latency.

A caller waiting for the result sees a failure immediately; an event-driven invoke returns an acknowledgment and retries out of band before giving up to a failure destination. The retry behavior is invisible to whoever triggered it, which is why a duplicated side effect here surprises people.

Processing power is allocated in proportion to memory, so a compute-bound function given more memory often finishes fast enough to cost less overall despite the higher rate. That makes the setting a performance knob as much as a capacity one, and it is worth measuring rather than assuming.

The definition pins everything about how a container runs — image, resources, ports, permissions — and each deployment is a new revision. A running task is an instantiation of one specific revision, which is what makes a rollback a matter of pointing at the previous one.

One removes host management entirely and bills per task; the other keeps the hosts, which allows packing many small tasks onto a machine and using specialized hardware. The trade is operational surface against control and, at high density, cost.

The native scheduler has the smaller operational surface and integrates directly with the surrounding services; the Kubernetes option brings portability and a large ecosystem at the cost of running and upgrading a control plane's worth of concepts. It is a team decision more than a technical one.

Two roles doing unrelated jobs: one is what the application uses to call services, the other is what the platform uses to pull the image and ship logs before the application exists. A failure to start usually points at the second, and a permission error inside the app at the first.

A service continuously reconciles what is running toward what was asked for, replacing unhealthy tasks and registering new ones behind the load balancer. That reconciliation loop is why a task killed by hand comes back, and why the way to stop something is to change the desired state.

There are no directories — a key is one long string and the console draws folders from the separators inside it. That is why deleting a folder means deleting every key under a prefix, why an empty folder cannot really exist, and why listing is a prefix scan rather than a directory read.

A write is immediately visible to the next read, including for overwrites and deletions, so the defensive patterns built for the old behavior are now pure cost. Code still sleeping or retrying to let a write settle is working around a property the service no longer has.

The classes trade how quickly an object can be retrieved, and what a retrieval costs, against what storage costs. Archive tiers add a minimum billed duration, which is how moving short-lived objects to a cheap tier can raise the bill rather than lower it.

A rule moves or expires objects by age and prefix with no application involvement, which is how tiering and cleanup happen reliably rather than through a script somebody maintains. It is also the right place to expire incomplete uploads, which otherwise accumulate invisibly and are billed.

A deletion in a versioned bucket writes a marker that hides the object rather than removing anything, so the data is still there and still billed. Actually reclaiming space means deleting the versions themselves, which is what a lifecycle rule for non-current versions exists to do.

Policies are the supported mechanism and the per-object legacy lists are disabled by default under the modern ownership setting. That default is a security improvement: it removes a second, easily-overlooked place where an object could be made readable independently of the bucket's own policy.

These settings override any policy that would otherwise expose objects, at both the bucket and the account level. That is deliberate — it makes accidental exposure require two separate deliberate actions, and it is why a policy granting public read can appear correct and still not work.

The link carries the signer's own permissions for a bounded period, so anyone holding it has that access until it expires — there is no further check on who presents it. Treat the URL itself as the credential, keep the expiry short, and never put one somewhere it can be logged or shared.

The options differ in who holds the key material, whose audit trail records its use, and who pays for the key operations. The managed-key option is the one that gives you a usage trail and access control over the key itself, which is usually what a compliance requirement is actually asking for.

Replication is asynchronous and requires versioning on both ends, so it produces a copy that lags rather than a synchronous mirror. Anything depending on the copy being current — a failover, a read-your-write across Regions — is depending on a property replication does not provide.

A volume can only attach to an instance in its own zone, so moving data across zones goes through a snapshot and a restore. That constraint shapes zone-redundant designs: the data layer either replicates itself or lives in something that is not zone-bound.

The types differ in what they guarantee: a general-purpose baseline that bursts, provisioned performance for when latency is contractual, and cheap sequential throughput for large scans. Choosing by price alone is how a database ends up on a volume optimized for streaming reads.

Only changed blocks are stored, yet each snapshot restores a complete volume, because the unchanged blocks are shared between them. That is why deleting an old snapshot does not damage a newer one, and why snapshot storage costs far less than the volume sizes suggest.

A shared file system many machines mount at once across zones solves a different problem from a volume attached to one instance. The trade is latency and cost per operation, so it suits shared content and configuration rather than a database's data files.

Three access models, not three price points: whole objects fetched over HTTP, a raw device a filesystem is built on, and a filesystem several hosts share with POSIX semantics. Most storage mistakes are choosing by cost and then needing an access pattern the service does not provide.

The instance form keeps one synchronous standby purely for failover — it serves no queries, so it adds availability and no read capacity, which is the point most often misread. The cluster form keeps two standbys that do serve reads, which is a different product answering a different question.

Replicas are asynchronous and readable, and can be promoted deliberately, but nothing fails over to them automatically. They may also return rows slightly behind the primary, so an application reading its own recent write from a replica sees the past.

Recovery works by repointing the endpoint's name at the standby, which means anything caching the resolved address stays pointed at a machine that is gone. That is why a database can be healthy again while the application is still failing, and why client-side DNS caching matters here.

Automated backups enable recovery to any point inside a retention window and are removed when the instance is, which surprises people during a decommission. A manual snapshot persists independently until deleted, which is what makes it the right artifact to keep before a risky change.

Compute is separated from a replicated storage layer that every replica reads, so adding a reader copies no data and a failover promotes an instance that already sees the same storage. That architecture is the reason its scaling and recovery behavior differs from the engine-native equivalents.

Patching, backups and monitoring are handled; schema design, indexing, query cost and connection limits are not, and those are what most database incidents are actually about. Managed removes the operations that were never the hard part.

The key is hashed to choose where an item lives, so a key with few distinct values concentrates all traffic onto a few partitions. The table then throttles while its overall capacity looks underused — a symptom that reads as a capacity problem and is a data-modeling one.

A composite key stores items in order within a partition, so one read can return an ordered slice — everything for a customer in a date range, the most recent events, a bounded page. That is what makes a time series cheap to read and why the key design decides which queries are possible.

One reads by key inside a partition and costs what it returns; the other reads the entire table and costs what it read, regardless of how much matched. A scan is occasionally the right answer and should always be a deliberate choice, because nothing about it fails as the table grows — it just gets slower and dearer.

One has its own key and its own capacity and is eventually consistent; the other shares the partition key, shares capacity, and must be created with the table. The second is therefore a decision you cannot revisit, which is the practical difference that matters most.

Provisioned capacity is cheaper for predictable load and can scale on a schedule or a metric; on-demand absorbs unpredictable traffic with nothing to tune. Switching between them is possible but rate-limited, so the choice is worth making before a launch rather than during one.

The default read may return a slightly stale item and costs half as much as the strongly consistent alternative. Most reads tolerate that, and the ones that do not — a read immediately after a write in the same flow — are usually a small, identifiable subset rather than the whole application.

An ordered record of item-level changes per key is what lets replication, aggregation and event-driven processing happen without the writer knowing about them. Ordering is guaranteed per key rather than globally, which is the constraint any consumer design has to be built around.

Filling on a miss means only requested data is cached and stale entries are possible; writing through keeps entries fresh and pays on every write, including for data nobody reads. Most systems end up combining them with an expiry, because each alone has a failure mode the other covers.

A received message is hidden rather than removed, so a consumer that crashes mid-work causes redelivery rather than loss. The timeout has to exceed the real processing time, or a slow message is delivered to a second consumer while the first is still working on it.

Nothing leaves the queue until the consumer explicitly removes it, which is what makes crash recovery automatic. It also means deleting before the work is finished converts a retryable failure into a lost message — the delete belongs after the side effect, not after the receive.

After a configured number of deliveries a message is moved aside rather than retried forever, which stops one poisonous item consuming the consumer's attention indefinitely. The queue then needs someone to look at it — an unmonitored dead-letter queue is a silent data-loss mechanism.

One offers effectively unlimited throughput with at-least-once delivery and best-effort ordering; the other guarantees order and deduplication within a group, at a lower ceiling. Ordering is per group rather than per queue, so the group identifier is the real design decision.

Waiting briefly for a message rather than returning empty immediately cuts both the request count and the noise of constant empty responses. It is a per-receive setting people leave at the default, and it is one of the few changes that reduces cost and latency at the same time.

One publish reaches every subscriber, and giving each consumer its own queue means a slow or broken consumer buffers rather than losing messages. That combination is the standard shape for decoupling one producer from several independently-paced consumers.

Rules match on the content of the event, so a producer emits what happened and consumers subscribe to what they care about — the producer never learns who is listening. Adding a consumer is then a change to one rule rather than a change to the producer.

Keeping workflow state, retries, branching and waits outside the code means a long process is not one oversized function holding everything in memory. The trade is that the flow lives in a definition rather than in the language, which is a readability and testing decision as much as a technical one.

A metric is identified by its namespace, name and the full set of dimension values, so adding a dimension value creates a separate metric rather than a breakdown of an existing one. That is why high-cardinality dimensions are expensive and why an aggregate across them has to be built deliberately.

Memory and disk usage live inside the operating system and the hypervisor cannot see them, so they require an agent. The result is a default dashboard that looks complete and is missing exactly the two metrics people reach for first when an instance is misbehaving.

Three states, and the third — not enough data — behaves differently from both of the others and is easy to forget when designing a response. The period and the number of datapoints required together decide how quickly an alarm reacts and how often it flaps on a noisy metric.

Three different questions: who made which API call, how the system is behaving, and whether a resource's configuration has drifted from a rule. Reaching for the wrong one is why an investigation stalls — performance data cannot tell you who changed something.

Stitching per-service segments into one trace attributes latency to a specific hop, which separate dashboards cannot do. The value appears only when every service in the path participates — a gap in instrumentation shows up as an unexplained span rather than as missing data.

A key service encrypts a data key, and that data key encrypts the bulk data, so the plaintext never leaves your environment and only a small key crosses the boundary. That is what makes encrypting large objects practical, and it is why a key service's request rate is about keys rather than bytes.

Every key carries its own resource policy, and an identity policy alone cannot grant its use — the key's own policy has to permit it. That is a second place to check when a decryption fails, and it is why a key locked by a policy nobody can change is a genuine operational hazard.

The customer-managed option gives you the policy, the rotation schedule, cross-account grants and deletion control; the managed alternative gives none of those and costs nothing. The question is whether you need to control who uses the key, which is usually what a compliance requirement means.

One protects the wire and the other protects the disk, they are configured separately, and neither implies the other. An encrypted volume says nothing about the connection to it, which is why a review has to ask both questions rather than accepting one answer.

One adds managed rotation, cross-account sharing and a per-secret charge; the other is a cheaper home for configuration and can still store an encrypted value. The deciding factor is usually rotation — if nothing rotates, the cheaper option is doing the same job.

One inspects and filters application-layer requests against rules you choose; the other absorbs volumetric network floods before they arrive. They defend different layers, so having one says nothing about the other — and the attack that takes a site down is often the one nobody configured for.

It analyses logs and telemetry to raise findings and blocks nothing by itself, so its value depends entirely on something acting on what it produces. Findings nobody routes anywhere is the common failure — the detection worked and the response did not exist.

Requests are answered from a location near the user and only reach the origin on a miss, which cuts latency and origin load together. That second effect is often the larger one — a cache in front of a modest origin absorbs traffic the origin could never have served.

Everything included in the key multiplies the number of distinct cached copies, so forwarding every header, cookie and query parameter fragments the cache until almost nothing is reused. A distribution with a poor hit rate is usually caching correctly and keying badly.

Invalidating is slow and metered, while publishing under a new path is immediate and free — the old object simply stops being referenced. Building versioned paths into the deploy removes the need for the operation that people reach for during an incident.

Restricting an origin so only the distribution can read it means the bucket is never public, and access goes through one path that can be logged and controlled. Serving from a public origin behind a distribution leaves the original URLs working and bypassable.

Only the alias form can sit at the zone apex, because the DNS standard forbids a canonical name record there alongside the other records a zone apex must have. That single constraint is why apex domains need the provider-specific record type.

The policies answer different questions — split traffic by weight, pick the lowest-latency Region, fall back on failure, route by geography, or return several answers. Choosing one means deciding what should happen during a partial failure, which is a design question rather than a DNS one.

Resolvers cache an answer for as long as the record says, so failover cannot be faster than the value published before the incident. Lowering it during an outage does not help the clients already holding the old answer — the time to set it is in advance.

Resources are created, updated and deleted as one unit, and a failed update rolls back rather than leaving half the change applied. That atomicity is the main reason to use it, and it is also why a stack stuck mid-rollback is a distinct operational situation with its own recovery steps.

The preview distinguishes an in-place modification from a replacement, which is where a data-losing change is caught before it happens. Some property edits quietly require a new resource, and the only warning is in the diff nobody generated.

A resource edited by hand no longer matches its definition, and the next update may silently revert the manual change or fail on it. Detection reports the difference, which makes it worth running before any update to a stack that humans have been near.

Without an explicit instruction to keep it, deleting a stack deletes the database inside it along with its data. Marking stateful resources to be retained is the one line that separates a routine teardown from a permanent loss, and it has to exist before the deletion, not after.

It is a program that emits a template, so everything about the deployed result — the limits, the update behavior, the failure modes — belongs to the template engine underneath. Debugging a deployment therefore means reading the synthesized output, not just the source that produced it.

The pillars are a checklist of the questions a design has to answer, and their value is that they compete: a choice improving one usually costs another. Using them well means recording which trade was made and why, rather than claiming a design satisfies all six.

The assumption is that every component eventually fails, so the design question is not whether it happens but whether the system degrades or stops. That reframing is what makes health checks, retries, timeouts and graceful degradation design decisions rather than defensive afterthoughts.

Putting a queue or a load balancer between tiers means one side can scale, deploy or fail without the other noticing, which is what turns a cascading failure into a backlog. The cost is the coupling you no longer see — a queue hides a downstream problem until it is deep.

Moving session and uploaded data off the instance is what makes any instance able to serve any request, which is the precondition for both scaling out and removing a machine safely. Without it, scale-in drops user sessions and every deploy is a partial outage.

Two numbers — how long recovery may take and how much data may be lost — select the strategy, from restoring backups through to running everywhere at once. Starting from the strategy instead is how a design ends up far more expensive or far less protective than the business needed.

The largest saving comes from not running what is idle and from sizing what remains correctly, rather than from buying the same idle capacity at a discount. A commitment on over-provisioned capacity locks in the waste, which is why right-sizing comes before any purchasing decision.

Limits apply per account and per Region, and hitting one under load looks exactly like an outage while every dashboard shows healthy resources. Knowing which quotas a design approaches, and raising them ahead of a launch, is ordinary capacity planning rather than a special case.