AWS Certified DevOps Engineer - Professional (DOP-C02) Course

In the Waterfall Model, phase deliverables are reviewed before the project proceeds. A phase gate is a decision against defined exit criteria, not simply a calendar milestone. The decision identifies the reviewed deliverable versions, the approving authority, and any conditions or unresolved risks.

An increment adds usable capability to the existing product. Teams revisit planning, requirements analysis, design, implementation, testing, deployment, and maintenance as that product evolves. These activities can overlap: a failing integration test can reopen design, and operational feedback can reopen requirements. An iteration boundary does not require a production release.

Agile Development and the Waterfall Model differ in when they commit to requirements and when new evidence can reshape the plan. Both involve analysis, design, implementation, and testing. The distinction is whether teams repeatedly revisit those activities around small increments or organize the project primarily around sequential phases.

Waterfall describes how a project governs lifecycle progress: requirements, design, implementation, and acceptance proceed predominantly through reviewed phase deliverables. Pipeline order describes dependencies within an execution: a package must exist before that package can be deployed. These are different levels of sequencing.

The software development lifecycle connects requirements, design, implementation, verification, deployment, and maintenance. These are responsibilities, not necessarily separate calendar periods. Requirements define observable acceptance criteria; design identifies interfaces and failure assumptions; implementation produces changes; verification supplies evidence; operation reveals behavior that test environments did not reproduce.

A cross-account deployment is a chain of separately authorized requests. This diagram follows a CodePipeline action that reads artifacts using a destination-account role. It shows the artifact-read authorization path, not provider-specific deployment execution roles.

The pipeline service role is the identity CodePipeline assumes to orchestrate a pipeline. Its trust policy permits the service principal codepipeline.amazonaws.com to assume it. Its permissions authorize pipeline operations, including artifact access and calls to action providers.

Separation of duties prevents one actor from combining incompatible authority. For a production change, distinguish authority to propose content, approve that content, and execute resource changes. Automation may execute an approved change; the critical question is who can command or reconfigure that automation.

Authentication establishes which IAM principal is making a Git request; it does not grant repository access. CodeCommit supports HTTPS Git credentials and SSH keys associated with IAM users, as well as HTTPS access backed by AWS credentials. A console password is not a Git password, and an AWS access key ID is not a CodeCommit Git username.

A private repository needs two separate controls: authentication to the registry and authorization for repository operations. The publishing role needs ecr:GetAuthorizationToken in an identity-based IAM policy with Resource: "*"; this action cannot be scoped to a repository ARN. The token inherits the principal's permissions—it does not grant permission to push. Use aws ecr get-login-password with Docker's --password-stdin, rather than exposing the password in command arguments.

In an S3 general purpose bucket, an object key is the complete name of an object. In artifacts/payments/2.8.1/bundle.zip, the slashes are characters in the key, not directories with independent update semantics. Prefixes organize naming and listing; they do not make a collection of objects transactional.

A private general purpose bucket needs several independent controls. A bucket policy grants or denies actions against resources: s3:ListBucket uses the bucket ARN, while s3:GetObject and s3:PutObject use object ARNs, usually restricted to a prefix. A prefix is a naming boundary, not a separate authorization container. An applicable explicit deny overrides an allow; cross-account access generally requires authorization from both the caller's account and the bucket's account.

A domain groups CodeArtifact repositories within an AWS Region and provides shared storage and encryption infrastructure. It is not a package-manager endpoint or a merged package namespace. Each repository has its own package inventory and format-specific endpoint; upstream relationships stay within the same domain.

CodeArtifact access is not one permission. A workload uses AWS credentials to obtain an authorization token and discover a repository endpoint. Its package manager then presents the token to read or publish packages. Permission to obtain a token does not, by itself, authorize package access.

A protected branch makes the repository enforce conditions before accepting a proposed change. Require a pull request, successful required checks, and approval from an eligible reviewer other than the author. These conditions are an AND gate: passing tests cannot replace review, and approval cannot replace failed or missing checks.

A commit identifier identifies a Git commit object, including its tree, parent references, and commit metadata. Changing that object produces a different identifier. Record the full identifier in release records: abbreviated identifiers can become ambiguous as a repository grows. A commit identifier establishes identity, not approval or author authenticity.

AWS CodeConnections lets a pipeline reference an authorized provider integration through a connection ARN, rather than embedding a developer's personal access token. The ARN identifies the connection; it is not a credential and does not itself grant repository access.

A connection-based source action defines where CodePipeline retrieves code: the connection, repository, and configured BranchName. Its action provider is still named CodeStarSourceConnection, although the connection service is called AWS CodeConnections. The action produces source output for the execution.

Gitflow assigns roles to branches; pipeline configuration turns those roles into actions. A feature branch starts from develop and returns through a pull request. Required checks should validate the proposed integration, not just the isolated feature tip. After merging, validate the resulting develop revision because concurrent changes can alter the combined result.

Trunk-Based Development keeps one shared integration branch, usually main, close to a releasable state. Integrate small changes frequently, using direct commits or short-lived reviewed branches. A small change reduces the amount of code that must be understood, validated, and potentially reverted together. Merely naming a branch main does not provide this property: long review queues and large batches still delay integration.

Gitflow separates released history on main from future-release integration on develop. Trunk-based development integrates small changes frequently into one shared mainline, directly or through short-lived branches. The distinction is not whether branches or reviews exist, but how long work remains separate from the shared integration point.

AWS CodePipeline owns the release workflow: stages, actions, their ordering, and whether execution can progress. For an action whose provider is AWS CodeBuild, CodePipeline starts a build and tracks its outcome; CodeBuild supplies the execution environment and runs the project's build and test commands.

A reproducible build recreates identical artifact bytes from the same declared inputs in independently prepared environments. Treat the build as a function of an input manifest: source commit and submodules, dependency bytes, build scripts, toolchain and plugins, target architecture, and output-affecting settings. Record immutable identifiers and content digests, and retain the referenced bytes. A digest detects substitution; it does not ensure that an input remains available.

Dependency pinning constrains which external components a build selects. Reproducibility constrains the result: independent builds using the same source and declared build inputs produce byte-identical artifacts. These are different claims about different parts of the build.

A CodeBuild build combines a project environment, a source revision, and a buildspec. The project selects the compute environment, operating system, architecture, build image, service role, and artifact destinations. The buildspec supplies commands and output-selection rules. By default, CodeBuild reads buildspec.yml from the source root; project configuration or a build request can select another buildspec.

A CodeBuild source webhook answers a launch decision: does this repository event qualify for a build? For GitHub, an EVENT filter can list events such as PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED. Those values are alternatives within that event filter, not three events that must happen together.

CodeBuild runs the commands in your buildspec; it does not infer command success from text such as “tests failed” in a log. A test command must return a nonzero exit status for CodeBuild to recognize its failure. Configure the runner to fail on failed assertions, and do not use a phase failure policy that continues past a failure you intend to block the build.

A failed CodeBuild action is a summary, not a diagnosis. Open the exact build execution and inspect its phase history. The BatchGetBuilds API exposes this in builds[].phases[]: phaseType identifies where execution was, and phaseStatus records that phase's outcome. A failure in PROVISIONING or DOWNLOAD_SOURCE is not evidence that a compiler command ran.

Both services can hold encrypted build and deployment secrets. The main lifecycle distinction is credential rotation: changing a credential in its issuing system and making the replacement available to consumers. Writing a new stored value alone does not rotate the credential at its source.

Parameter Store names such as /prod/checkout/db-password organize values by environment, application, and purpose. The hierarchy is part of the parameter name, not a separate container with inherited permissions. Match IAM resources to the intended parameter ARNs; the ARN resource portion is parameter/prod/checkout/db-password, without an extra leading slash after parameter/.

A build or deployment job retrieves a secret using its execution identity, not the identity of the person who started the pipeline. Here, a CodeBuild job calls GetSecretValue with its service-role credentials. The diagram shows the request and audit paths; response traffic is omitted.

Credential rotation coordinates three distinct states: what the validating system accepts, what the secret store publishes, and what consumers actually use. Updating storage alone does not change a database password. Successful rotation must also establish working consumer access and retire the predecessor.

Scheduled rotation must coordinate a stored secret with the system that accepts its credentials. This lesson follows Lambda-based rotation of an Amazon RDS database credential: changing the secret value alone does not change the database password.

A rolling deployment changes a serving fleet in successive batches. Its safe batch size is bounded by two different budgets: how much healthy capacity may be removed, and how much replacement capacity may be added. With ten healthy units, a healthy floor of eight permits removing two; a total ceiling of twelve permits starting two before removing anything. These are permissions, not guarantees: the remaining fleet must still handle demand, including uneven load across failure domains.

Blue-green deployment prepares a replacement environment without immediately exposing it to production traffic. This example uses separate Amazon ECS task sets behind an Application Load Balancer. Blue remains available while green is deployed and validated; the two application versions share a compatible database.

Blue-green deployment prepares a complete replacement application environment while the current environment remains available. Rolling deployment changes the serving fleet in batches, either updating existing members or replacing them. The distinction is the unit of change: a complete environment versus part of a fleet.

A canary deployment publishes a candidate without immediately giving it all production traffic. The release needs three separate controls: an exposure mechanism, evidence attributed to the candidate, and a decision that promotes it or returns traffic to the stable version.

Rolling deployment controls how a serving fleet changes: instances or tasks are updated or replaced incrementally. Canary deployment controls initial exposure to a candidate version so that production evidence can inform further release decisions. Both can run old and new versions simultaneously, but coexistence alone does not make a rollout a canary.

Blue-green describes environment separation: the current release runs in blue while a distinct replacement environment, green, is prepared. Separation can mean different instance groups or container task sets; it does not require different accounts or a duplicate of every dependency.

An ECS service deployment replaces tasks with tasks launched from the selected task definition revision; it does not edit containers already running. Registering a revision alone does not update a service. Updating the service to that revision starts replacement, while a force new deployment can replace tasks without changing the revision.

An Elastic Beanstalk deployment policy controls how an application version reaches the instances in an environment. For a load-balanced environment, All at once updates every instance together, interrupting service during deployment. It needs no additional instances, but a failed release can affect the entire serving fleet.

An EC2 deployment group binds fleet selection to deployment behavior: deployment type, deployment configuration, load balancer integration, alarms, and automatic rollback settings. The application groups revisions and deployment groups; the deployment group identifies which instances a deployment targets. Treat its selectors as production controls, not descriptive labels.

For an ECS service using the CODE_DEPLOY deployment controller, CodeDeploy coordinates a replacement task set and load balancer routing instead of updating the original tasks in place. The ECS AppSpec identifies the replacement task definition and the container name and port used for load balancing; the deployment group identifies the service, target-group pair, and listeners.

A Lambda deployment shifts an alias between already published versions. In this example, callers invoke live, initially pointing to version 41. Version 42 is published before deployment; CodeDeploy changes alias routing rather than rewriting either version. Calls made directly to a version bypass that routing.

Elastic Beanstalk manages an application environment, not just the act of installing a release. An environment combines an application version, a platform, configuration, and running AWS resources. For a load-balanced EC2 web environment, Beanstalk provisions and coordinates instances, an Auto Scaling group, and a load balancer, and provides application health reporting.

A regression gate must distinguish a code change from a change in its surroundings. Dependency isolation gives tests controlled collaborators: inject a fixed clock, predetermined client responses, and explicit configuration instead of reading live services or ambient credentials. Keep the real business logic under test; replacing that logic with a mock would remove the behavior the gate is meant to protect.

An integration quality gate must establish more than successful invocation. It runs a candidate against realistic dependencies and asserts the resulting outputs, stored state, and failure behavior. Here, a Lambda function writes to DynamoDB; the test runner invokes the function and independently reads the table to check the result.

A unit test checks a coherent behavior while isolating it from dependencies outside that unit. An integration test checks an interaction between connected components. The distinction is not the number of functions called, whether the test runs locally, or whether it uses a network. It is which implementations participate in the behavior being asserted.

Acceptance criteria define observable business outcomes, not implementation choices. Before implementation, product owners, engineers, and testers should agree on concrete examples, including rejection paths and boundary conditions. Give each required criterion a stable identifier so a release can be traced back to its agreement.

Acceptance testing asks whether behavior satisfies agreed stakeholder requirements. Its expected result comes from an acceptance criterion: what users or consumers need the system to do. Integration testing asks whether connected components interact correctly. Its expected result concerns exchanges, state changes, and failure handling across a component boundary.

A UI release gate must establish that a particular immutable application artifact completed specified journeys under controlled conditions. Record the artifact identity, deployment endpoint, test revision, and browser configuration together. Promote the artifact that was tested rather than rebuilding it afterward. Pin framework and browser versions where practical so runner changes do not silently change the experiment.

Acceptance testing describes a test's objective: determine whether the system satisfies agreed requirements for its intended users or consumers. UI testing describes its interaction surface: exercise the application through user-facing controls and observe outcomes.

AWS Device Farm runs application tests on real mobile devices. A device pool selects the devices for a run, and the run contains device-specific jobs. Parallel jobs shorten coverage time and reveal device-dependent behavior; they do not establish a controlled backend request rate.

Static Application Security Testing (SAST) examines application code without executing the application under test. Depending on the analyzer, it follows control and data flow through source code or compiled representations. For example, it can identify untrusted request data reaching a database query without parameterization. These findings are evidence of possible weaknesses, not proof that every reported path is exploitable.

An assessment can detect a weakness only when the affected resource is in scope, the relevant check is available, and the inspection method obtains usable evidence. Resource selection and check selection are separate controls: assessing every instance with the wrong checks still leaves a detection gap.

Current Amazon Inspector discovers eligible resources and continuously assesses them for enabled scan types. Its operating model is resource coverage plus automatic reassessment—not a collection of assessment runs that you schedule yourself. Continuous does not mean instantaneous: findings depend on supported resources, available inventory, and completed evaluation.

The Test Pyramid distributes tests by scope: many focused checks, boundary checks where needed, and a small set of complete workflows. It is not a target percentage. Choose the smallest reliable scope by asking what must behave realistically for a particular defect to become visible.

A quality gate decides whether evidence justifies crossing a particular promotion boundary. Start with the failure modes that boundary could expose, then choose tests capable of detecting them. Fast unit tests, static analysis, dependency checks, and infrastructure validation belong early because they reject inexpensive defects quickly. Their success does not establish that deployed components work together.

Run fast unit checks before deployment: they exercise isolated logic without a running application. CodeBuild executes the buildspec that checks and packages the candidate. Integration checks against deployed dependencies, end-to-end journeys, and automated acceptance checks run after deployment to a test environment. Automated acceptance verifies business expectations; it is not a manual approval.

A repository webhook reports a change; it does not define which tests should run. Separate pull-request validation, which checks a proposed change, from destination-branch validation, which checks code after integration. Opening or updating a pull request belongs to the first purpose. A push to the destination branch can serve the second, including pushes caused by merges.

Load testing asks whether an application meets its requirements under defined expected demand, including expected peaks. Stress testing deliberately goes beyond sustainable capacity to discover where acceptable operation ends, how the system degrades, and whether it recovers. The distinction is the question being investigated, not the tool or the absolute request rate.

Load testing asks whether an application meets performance requirements under a defined workload. The workload includes more than traffic volume: operation mix, request sizes, data distribution, and duration determine what the result means. A pass is evidence for those tested conditions, not a claim of unlimited capacity.

Performance benchmarking asks how measured performance compares under defined, repeatable conditions. Stress testing asks where the operating envelope ends, what happens beyond it, and how the system recovers. The distinction is the question being answered, not simply whether traffic is high.

A workload model specifies more than a request rate: version the operation mix, payload sizes, authentication behavior, data distribution, connection reuse, think time, and arrival schedule. A closed-loop model waits for responses before users continue, so slower responses can reduce offered traffic. An arrival-rate model schedules new work independently of response completion; it must report arrivals that could not start, rather than silently lowering demand.

A scaling test should reveal how the system responds to a change, not just its highest throughput. Use a gradual ramp to locate where latency or saturation begins, then a controlled step increase to expose response delay. Hold the new demand long enough to observe both capacity becoming useful and any accumulated backlog draining. Finally, reduce demand and observe recovery and scale-in.

A release comparison is a controlled experiment: the candidate artifact is the intended change, and other performance-relevant inputs should remain equivalent. Version a benchmark contract containing baseline and candidate artifact identifiers, infrastructure and runtime configuration, dataset snapshot, workload script, measurement windows, and acceptance rules. Pin immutable identifiers rather than mutable labels such as latest.

A controlled stress run deliberately crosses the application's capacity boundary without making the traffic unbounded. Define a workload manifest: target allowlist, request mix, authentication, payloads, synthetic dataset, random seed, arrival schedule, timeouts, retry policy, maximum in-flight requests, and a hard end time. Increase traffic through bounded plateaus, rather than running an unlimited loop until something fails.

An overload acceptance gate evaluates a scenario contract, not a universal error-rate threshold. Version that contract with the test: specify the workload, phase boundaries, permitted responses, measurement windows, correctness invariants, and recovery deadline. Decide these before execution; otherwise expected throttling can become either a false failure or an excuse for a regression.

A health probe translates an application assertion into a process result. Define the assertion first: for example, the endpoint must respond within a deadline, return the required HTTP status, and report that it is ready. Return zero only when every required assertion passes; return nonzero when an assertion fails or the check cannot complete. A running application process does not establish these facts.

A process exit code describes whether a command completed according to that command’s rules: zero conventionally means success, and nonzero means failure. It does not automatically describe application health. A deployment command can succeed while the deployed application serves errors; a running process can be deadlocked.

Coverage maps execution data back to source code. Each metric has its own denominator: executable lines, statements, functions, or branch outcomes. A line containing a decision can execute without both outcomes being taken. Even complete branch coverage does not establish that every combination of conditions or every possible path was tested.

A pipeline needs a noninteractive execution contract: a known AWS CLI version, temporary credentials supplied through the runner's role or federation, an explicit target Region, and machine-readable output. Do not run browser login or credential configuration inside the job. Disable presentation features with export AWS_PAGER=''; export AWS_CLI_AUTO_PROMPT=off, and select JSON with --output json.

An identity policy describes actions a role may perform on specified resources. A resource policy, such as an S3 bucket policy, describes access from the resource owner's side. A role's trust policy is a resource-based policy with a special job: it controls who may assume that role, not what the resulting session may do.

A digital signature binds signed bytes to a signing key. The signing algorithm uses a private key and generally incorporates a cryptographic hash; verification uses the corresponding public key, the signature, and the message. Signing is not “encrypting with the private key.” It produces evidence about the message without concealing the message.

Encryption at rest protects the stored representation. With S3 server-side encryption, S3 decrypts an object for an authorized read. The caller receives the object's original bytes, not its storage ciphertext. An encrypted artifact bucket therefore does not make downloaded artifacts unreadable to the build or deployment process.

A release signature binds signed data to a private key; it does not establish that the build was safe or approved. Restrict access to signing operations, not just key export. A compromised build role with permission to sign can authenticate malicious releases without extracting the key. Separate release approval and signing permissions from ordinary build permissions, and bind approval to the artifact digest.

Dependency pinning separates choosing dependencies from generating an artifact. A manifest expresses requirements; a lockfile records resolved selections and dependency relationships supported by that package manager. Commit the manifest and lockfile together so a source revision identifies the intended dependency graph.

An immutable artifact has a stable content identity. For a container image, record its manifest digest and deploy using a digest-qualified reference rather than a movable tag. ECR tag immutability prevents configured tags from being overwritten; it does not prevent deletion. Rebuilding the same source commit is not promotion: dependencies, base images, or build tools can change the bytes.

Age-based retention preserves a time window; count-based retention preserves a number of artifacts within a defined scope. Specify the clock, scope, and ordering: for example, time since publication and the newest successful builds per application. A deployment date is not necessarily the artifact's publication date.

In an S3 general purpose bucket, an enabled Lifecycle rule combines a filter with actions. The filter selects objects; the actions define when to transition or expire them. Rules apply to matching existing objects as well as future objects. Enabling a rule can therefore make old objects immediately eligible.

EC2 Image Builder automates the creation, testing, and distribution of AMIs. An image recipe specifies a parent image, versioned components, and block-device mappings. Components contain configuration and test instructions executed through the AWS Task Orchestrator and Executor, or AWSTOE. The infrastructure configuration supplies build-instance settings; the distribution configuration controls image destinations and sharing.

A repeatable build needs a controlled input closure: source revision, Dockerfile, build scripts, dependency lockfiles, downloaded artifacts, base images, and builder toolchain. Pin every stage's base image by digest, not a movable tag. Use dependency versions with integrity hashes and retained artifacts; a lockfile alone cannot keep a deleted package available.

An Image Builder pipeline binds one recipe to an infrastructure configuration, with optional distribution settings and a schedule. It references either an imageRecipeArn for an AMI or a containerRecipeArn for a container image, not both. Creating the configuration does not itself build an image; execution produces an image build resource and its resulting artifacts.

An in-place deployment changes application software on existing EC2 instances. With AWS CodeDeploy, the agent executes the revision's AppSpec lifecycle hooks and installation instructions. Instances retain their identities and any unmanaged machine state; reinstalling an application does not remove configuration drift.

For EC2 and on-premises deployments, CodeDeploy orchestrates while the installed CodeDeploy agent retrieves revisions and performs local deployment work. The agent polls for commands; CodeDeploy does not open an inbound connection to push scripts onto the machine.

Amazon ECS exposes an AWS-native orchestration API. A task definition is a versioned specification for one or more containers and their runtime settings; a task is a running instance of that definition. An ECS service maintains a desired population of tasks. Registering a new task-definition revision does not itself change an existing service: the service must be updated to use it.

On Amazon EKS, a Deployment declares the desired application state; Kubernetes controllers continually compare that declaration with observed state. An accepted API update is not proof that the application has deployed. The controllers still have work to do, and each reports its own observations.

Rollback restores acceptable service by reversing an application deployment. Stop further rollout and preserve release identifiers, failure events, and relevant logs before replacing resources where practical. Identify the target precisely: an application artifact, container image digest, task definition revision, or published function version. A mutable image tag is not a reliable record of the code you intend to restore.

An application replacement creates a new compute identity; it does not automatically transfer the old instance's disks. Amazon EBS volumes have a lifecycle independent of the EC2 instance, but termination can still delete them. Inspect each attachment's DeleteOnTermination setting: set it to false when that volume must survive instance termination. Do not infer retention from whether a volume is called a root disk or a data disk.

A deployment replaces executable code, not the application's durable state. In this design, both application releases call the same versioned S3 bucket and durable reference registry. Neither store is recreated or emptied when application tasks are replaced. Local files are only disposable working copies.

A shared filesystem namespace gives replicas access to the same files independently of their lifetimes. For example, Linux replicas can mount a retained Amazon EFS filesystem at /srv/state. Replacing a replica replaces a client of that filesystem; it does not require moving its uploaded files to the replacement. The filesystem must have a lifecycle independent of the deployment: recreating an empty filesystem for each release defeats persistence.

Block storage exposes an address space of logical blocks. With Amazon EBS, the operating system sees a disk-like device and issues reads and writes against locations within it. A filesystem translates file names and byte offsets into block operations; a database can instead manage its own layout on a block device. EBS does not interpret those blocks as database pages, files, or directories.

A block device exposes addresses and bytes, not filenames or directories. With an ordinary local filesystem such as ext4 or XFS, each host's kernel manages allocation, directory entries, metadata caches, and its filesystem journal. Attaching the same device to another host does not connect those kernels' filesystem state.

Shared access means more than letting several clients retrieve the same bytes. A shared filesystem exposes directory entries, file identities, and operations on that namespace. Object storage exposes keys and API operations. Here, Amazon S3 examples refer to general purpose buckets; specialized namespace features should be evaluated separately.

An EBS volume has an identity and lifecycle separate from the instance using it. Replacing application code does not inherently replace its data, but terminating an instance can delete its attached volumes. The attachment's DeleteOnTermination setting controls that termination behavior; inspect it rather than assuming every data volume is retained.

Amazon EFS keeps application files independently of the instance, task, or function environment using them. A replacement client mounts the same file system and directory view; it does not recover files from the retired client. The diagram shows mounted file access, not deployment orchestration.

Amazon EBS exposes a block device to an attached EC2 instance. The operating system or application interprets those blocks: a filesystem such as ext4 or XFS manages directory entries, allocation metadata, and caches on that host. EBS does not itself provide a shared file namespace or coordinate filesystem metadata between hosts.

Amazon S3 exposes objects through an API. In a general purpose bucket, a key identifies an object, not an open file: ordinary updates replace the object's contents rather than modify bytes through a file descriptor. Slashes in keys can organize a namespace, but do not provide filesystem directory operations.

Controlled reconciliation restores an approved desired state, not simply the oldest recorded value. Before changing anything, identify the owning controller, the baseline version, and the properties it owns. Preserve the observed values, resource identity, observation time, and relevant change records. AWS CloudTrail can help attribute API changes; it does not decide whether those changes were authorized.

Idempotency means that repeating the same logical deployment request does not add another intended effect. A timeout leaves the outcome unknown: the destination may have completed the change even though the caller never received its response. Safe automation must handle that uncertainty, not interpret every timeout as proof that nothing happened.

Immutable infrastructure treats deployed compute as a replaceable instance of a controlled definition. Mutable deployments install changes on existing hosts or inside running containers. Immutable deployments build and test a new image, then replace the affected compute. This does not mean that memory, temporary files, or application data stop changing.

Idempotency asks what happens when the same logical operation repeats: does it preserve the intended result without adding unintended effects? Immutability asks how deployed resources change: are existing resources modified, or replaced with resources built from a controlled definition?

CodePipeline orchestrates a release as stages and actions. Its deploy action delegates work to a provider and waits for the result before dependent work proceeds. CodeDeploy executes a deployment: it coordinates target updates, lifecycle validation, and configured deployment safety controls. A failed pipeline action therefore does not, by itself, identify which controller failed.

An IAM user is a persistent identity that can have a console password or long-term access keys. An IAM group collects users so they inherit attached permissions; it has no credentials, cannot assume a role, and cannot be a principal in a resource policy. Groups contain users, not roles or other groups.

IAM maintains identity and authorization configuration: users, groups, roles, identity providers, and policies. An IAM role is a persistent identity with a trust policy controlling who can assume it and permissions policies defining its allowed actions. A role does not have its own long-term access keys.

AWS Organizations service control policies (SCPs) set permission ceilings for principals in member accounts. They require the organization’s all features mode. An SCP Allow makes an action eligible for authorization; it does not authorize the action. An applicable SCP Deny blocks the action even if an IAM policy grants administrator access.

A permissions boundary is an AWS managed or customer managed policy attached to an IAM user or role as a ceiling on its identity-based permissions. Attaching it as a boundary does not grant the permissions written in it.

Least privilege starts with an access contract: the principal, required API actions, target resources, and request conditions. Replace “read invoices” with “the InvoiceReader role lists keys under invoices/ and reads current objects under that prefix in the example-records bucket.” Explicitly exclude deletion, policy changes, and other prefixes. Separate deployment duties from runtime duties rather than combining their permissions.

Envelope encryption encrypts data with a data key, then protects that key with a KMS key. For a symmetric KMS key, GenerateDataKey returns both a plaintext data key and an encrypted copy. The application encrypts locally, stores the encrypted key alongside the ciphertext, and removes the plaintext key from memory as soon as practical. The KMS key itself is not returned.

A deployment job can use its workload role to assume a narrower artifact-reader role. The target role must trust the caller, and the caller must be authorized to assume it. AWS STS returns an access key ID, secret access key, session token, and expiration. The job must use all three credential fields for authenticated AWS API requests.

CloudWatch metrics answer questions about magnitude and change: how many requests failed, whether CPU utilization rose, or how a latency percentile changed. A metric's namespace, name, and dimensions identify its time series; the selected period and statistic determine the summary you inspect. That summary does not preserve individual request paths.

A precise CloudWatch Logs Insights query starts with its input. Select the log groups for the relevant application and environment, then set the smallest useful time range. The time selector bounds events by their event timestamp, represented by @timestamp, rather than their ingestion timestamp, @ingestionTime.

In Kubernetes, including Amazon EKS, a probe is a contract between an application and the kubelet. Readiness asks whether the container can accept new work. A failed readiness probe makes the Pod not ready, excluding it from normal Service traffic; it does not restart the container or cancel requests already running.

A load-balancer probe tests a configured contract, not general application correctness. For an Application Load Balancer, configure the health-check protocol, port, path, timeout, interval, and success-code matcher on the target group. The check port can differ from the traffic port. A successful response proves only what that endpoint checks.

Service Auto Scaling, through Application Auto Scaling, changes an ECS service's desired task count. An EC2 Auto Scaling group capacity provider with managed scaling adjusts the compute supply. Increasing desired count requests more tasks; it does not guarantee that suitable instances already exist.

The Kubernetes scheduler places a pod only where its resource requests fit within the node’s remaining allocatable resources. Allocatable excludes resources reserved for the operating system and Kubernetes. Existing pods, including DaemonSet pods, consume that scheduling budget through their requests. Free CPU observed in monitoring is not the same as unreserved CPU.

Configuration rollback restores explicitly recorded values, not an entire earlier environment. Here, a custom AWS Systems Manager Automation runbook restores an RDS parameter after a harmful change. It coordinates the writer, retrieves a recovery manifest, restores the setting, and checks recovery.

An AWS account boundary separates resource ownership and administrative authority. An administrator in one account does not automatically administer another, even when both belong to the same organization. This can contain a mistaken deployment or stolen identity within one workload's account.

An AWS account is the resource and isolation boundary; an organizational unit (OU) groups accounts that need common governance. Start with stable differences such as production, nonproduction, security, and restricted workloads. Keep the hierarchy shallow enough to understand, and use account tags for dimensions such as owner or cost center rather than reproducing every reporting relationship as an OU.

A service control policy (SCP) limits permissions; it never grants them. SCPs require all features and the SCP policy type enabled in the organization. For an action by a principal in a member account, examine the organization root, every parent organizational unit (OU), and the account itself. At each level, at least one attached SCP must allow the action for the request's context. Allows from policies attached at the same level combine; the resulting permissions intersect across levels.

AWS Organizations provides the multi-account foundation: account membership, organizational units (OUs), consolidated billing, and organization policies. Policy-based governance, including service control policies (SCPs), requires the all features feature set. Organizations remains the foundation whether you operate it directly or adopt AWS Control Tower.

Automate the Account Factory product through AWS Service Catalog in the Control Tower home Region, using an authorized principal in the management account. The caller needs access to the product and its launch path, not merely permission to call a provisioning API.

For an existing Control Tower landing zone, OU registration brings an organizational unit under Control Tower governance. Registering an existing OU also initiates enrollment of its eligible member accounts. Account enrollment applies the account-level baseline to an existing account; it does not create a replacement account or migrate its workloads.

Control behavior determines when a control acts. A preventive control restricts an action; a detective control evaluates resource state; a proactive control checks supported resources before provisioning through AWS CloudFormation. Guidance such as mandatory, strongly recommended, or elective is a separate classification, not an enforcement mechanism.

AssumeRole creates a new role session; it does not transfer the caller's permissions into another account. For a principal in account A to assume a role in account B, the caller needs an identity-based allow for sts:AssumeRole on the target role, and the target role's trust policy must authorize that caller. Neither side replaces the other.

IAM Identity Center supports its own identity directory, Microsoft Active Directory through AWS Directory Service, or an external identity provider. An instance uses one identity source at a time. This lesson follows an external corporate identity provider connected to an organization instance, which can manage AWS account access.

IAM Identity Center and direct federation through IAM identity providers can both give employees temporary access to IAM roles without creating IAM users for them. The important distinction is who manages the connection between workforce identities, AWS accounts, and permissions—not whether federation occurs.

A service control policy (SCP) sets a permissions ceiling for principals in an AWS Organizations member account. It does not grant access. An IAM administrator can delegate permissions only within that ceiling; attaching an administrator policy does not override it.

A service control policy (SCP) limits the permissions available to principals in an AWS Organizations member account; it does not grant permission. For an action to remain available, an applicable Allow must exist at every level on the account's path: the organization root, each parent organizational unit (OU), and the account. At a single level, applicable Allows from attached SCPs combine.

GuardDuty coverage depends on the evidence available to its detectors. Foundational detection analyzes CloudTrail management events, VPC flow logs, and DNS query logs. Management events expose control-plane activity, such as suspicious credential use or changes to account resources. Flow and DNS telemetry expose network behavior, such as communication with known malicious infrastructure.

Amazon GuardDuty continuously analyzes supported activity using threat intelligence and detection techniques to produce security findings. A finding identifies potentially malicious behavior and gives an analyst a starting point; it is not a complete reconstruction of an incident.

An Amazon Detective behavior graph is a Regional investigation boundary with an administrator account and member accounts. AWS Organizations integration lets the organization management account designate a Detective delegated administrator. Delegation gives that account authority to manage the organization's Detective membership; it does not turn the organization into one global graph.

Amazon GuardDuty asks whether observed activity indicates a potential threat. It analyzes supported telemetry using threat intelligence and detection techniques, then produces findings about suspicious or malicious behavior. That is threat detection, not a standards-based assessment of resource settings.

Security Hub CSPM evaluates resource configurations against security controls associated with enabled standards, such as AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark. A standard organizes requirements; a security control defines a particular check. The same control can belong to several standards.

Security Hub CSPM central configuration uses AWS Organizations to manage service settings across accounts and Regions. The Organizations management account designates a delegated administrator; that administrator enables and operates central configuration. The management account itself remains self-managed rather than becoming a configuration-policy target.

Security Hub CSPM receives findings in the AWS Security Finding Format (ASFF). Shared fields such as severity, resources, account, Region, and workflow make different providers' findings filterable together. Normalization does not merge all reports about one resource: ProductArn and Id identify a finding for updates.

AWS Lambda runs computation; AWS Step Functions manages workflow progress. A Lambda function can coordinate several calls using ordinary code, but that coordination remains inside one invocation unless you explicitly arrange continuation elsewhere. This is a good fit for short, tightly coupled work whose complete restart is acceptable.

A state machine describes states and transitions in Amazon States Language (ASL). A Standard Workflow durably records execution progress, including waits and task outcomes. Its Task states invoke services through integrations; a successful API call is not necessarily successful business work.

EventBridge puts routing decisions in rules on an event bus. Producers publish facts; rules inspect the event envelope and detail to select targets. Choose it when independent consumers need different views of a shared event stream, especially events already emitted by AWS services. Multiple rules can match the same event: this is not a first-match routing table.

Direct service events describe service-defined activity, such as an EC2 instance changing state. CloudTrail-delivered events describe recorded API activity, including the caller and request parameters. A successful stop request and an instance reaching the stopped state are different facts, not interchangeable notifications.

An EventBridge rule invokes a target; it does not itself change an instance configuration. This architecture starts with events already on the bus. Two independent rules select different repairs: custom tag repair through Lambda, and an IMDSv2 repair through a Systems Manager Automation runbook. Neither target calls the other.

A control-plane operation contract defines a particular management action: its request shape, constraints, response fields, errors, and state semantics. Read the operation reference together with its linked parameter types and service-specific guidance. An operation named Create or Update does not, by its name alone, promise synchronous completion, replacement behavior, or safe retries.

An SDK paginator repeatedly calls a list operation using continuation information from earlier responses. One successful response does not mean the inventory is complete. Continue until the operation's continuation contract says there are no more results; an empty page alone is not a reliable stopping condition.

Inventory-driven targeting joins the expected fleet with observed operating systems, software, ownership, and maintenance tags. Systems Manager Inventory describes reporting managed nodes; it is not proof that every expected instance is managed or reachable. Keep an independent expected-instance list, and investigate missing observations rather than dropping those instances from scope.

A workflow retry repeats a task; a function retry loop repeats application code; an SDK retry repeats an API request. These are different retry scopes. Nesting three independent policies multiplies downstream traffic rather than creating one coordinated policy. Our example creates one immutable DynamoDB item through a synchronous Lambda task in a Step Functions Standard workflow.

The important IaC choice is who manages the resource lifecycle: identity, dependency ordering, updates, failures, and deletion. A declarative definition describes a desired configuration; an imperative provisioning script specifies operations. Using a programming language does not make provisioning imperative: CDK code normally produces a declarative CloudFormation template.

A CloudFormation template describes a resource graph, not an ordered script. Logical IDs identify resources within the template; their position in YAML or JSON does not set creation order. When one resource property references another resource, CloudFormation uses that relationship to infer a dependency.

A provisioning engine turns a difference in desired state into operations using resource identity and resource-specific update rules. In CloudFormation, a resource's logical ID identifies it within the template; its physical ID identifies the actual resource. Keeping the logical ID does not guarantee keeping the physical resource.

A reusable CloudFormation template is an interface plus an implementation. Its Parameters expose supported variation; resource properties define the resulting infrastructure. Use Ref to connect inputs to properties. For example, expose an environment name and an approved encryption-key ARN while keeping S3 public-access blocking and encryption configuration inside the implementation.

A change set separates review from mutation. CreateChangeSet prepares proposed changes for a stack; it does not apply them. Wait for change-set creation to finish, then inspect the resource actions, changed properties, and replacement information. A successful preview is not proof that execution will succeed: permissions, resource constraints, and service-side failures can still block it.

AWS CDK is a programmatic infrastructure modeling framework. Its application runs in a supported programming language and builds a tree of constructs. Functions, loops, classes, and packages help compose that model. Synthesis turns the model into CloudFormation templates within a cloud assembly; CloudFormation does not execute the original application code.

cdk synth executes the CDK application and produces a cloud assembly, normally in cdk.out. The assembly contains CloudFormation templates, an assembly manifest, asset manifests when needed, and staged asset content. Its metadata describes stack environments, dependencies, asset destinations, and deployment-role information; a template alone is not the complete deployment input.

A governed construct library packages organizational infrastructure decisions as reusable code. A custom construct can compose resources and expose a small, business-oriented interface: for example, an approved encryption key and a data classification, rather than every bucket property. Composition lets the library own security-sensitive configuration while exposing only supported choices.

AWS SAM extends CloudFormation templates with serverless-specific declarations such as AWS::Serverless::Function. CloudFormation supplies the general-purpose infrastructure model: resource types, properties, references, dependencies, and stack lifecycle operations. CloudFormation can already provision serverless resources directly; SAM makes common serverless patterns more concise.

A reusable SAM template separates application structure from deployment inputs. Declare the fixed transform Transform: AWS::Serverless-2016-10-31, define inputs in Parameters, and reference them with Ref or Fn::Sub. For example, an Environment parameter can supply a function environment variable without maintaining separate development and production templates.

AWS CloudFormation answers: “How should these resources be created and managed?” It interprets a template, resolves resource dependencies, and manages resources as a stack. A reusable template can encode infrastructure standards, but sharing that template does not create an approved self-service catalog.

An infrastructure gate must authorize a specific proposed change, not merely a branch name or a successful build. This design uses CloudFormation change sets, a native CodePipeline manual approval action, and scripted CodeBuild verification. The arrows show logical workflow handoffs coordinated by the pipeline, not direct service-to-service API connections; scheduling calls are omitted.

A configuration baseline is an approved, versioned description of the state a fleet should reach: package versions, file contents, service settings, and their dependencies. Identify the complete release, not just its script. A pinned script that installs latest can produce different machines on successive runs.

AWS Config can evaluate recorded resource configuration against rules and publish compliance-change events through Amazon EventBridge. A transition to NON_COMPLIANT is evidence to investigate or remediate, not permission to modify every similar resource. Evaluation and event delivery are asynchronous; the resource can change again before execution starts.

A managed node needs a supported operating system, an installed and running SSM Agent, a usable AWS identity, and access to the correct regional endpoints. Do not assume an image includes the agent: verify its package, service state, and version. The CloudWatch agent collects telemetry; it does not replace SSM Agent or register a Systems Manager node.

A State Manager association binds an SSM document and its parameters to targets, an execution schedule, and execution controls. For managed-node configuration, SSM Agent runs the document on matching nodes. Repetition enforces desired state only when the document checks and corrects that state; repeatedly running an arbitrary script does not make it convergent.

A patch baseline defines which updates are approved for an operating system. Approval rules filter patch metadata, such as product, classification, and severity where supported. Automatic approval delays make matching patches eligible after a specified age; they do not schedule installation. Explicit approved and rejected patch lists provide exceptions. Available rule fields and approval behavior differ by operating system.

AWS OpsWorks is shut down. Support ended on 2024-05-01, and the service must not be used for new workloads. This lesson reconstructs how OpsWorks Stacks worked so that you can understand historical configurations and their operational behavior.

AWS OpsWorks is shut down. Support ended on May 1, 2024; it must not be used for new workloads. Its Chef-based configuration model is useful here as a historical reference when evaluating supported alternatives such as AWS Systems Manager State Manager.

An AWS Config configuration recorder records supported resource configurations within an account and Region. Its recording scope determines which resource types enter the recorded inventory and history. Recording must be running, and Config needs permission to read the resources. Enabling Config in one Region does not establish coverage in every Region.

AWS Config assesses AWS resource configuration. It records supported resource attributes and relationships as configuration items, then uses rules to evaluate applicable resources. For example, an EC2 instance's attached security groups are resource configuration; its installed operating-system packages are not ordinary EC2 configuration-item attributes.

AWS AppConfig controls application configuration changes: feature flags, tuning values, and other settings that application code consumes. Choose it when the task is to change runtime behavior without deploying new code, while controlling the exposure to that change.

A rule reports NON_COMPLIANT; its remediation configuration tells AWS Config what to execute. Associate the rule with a Systems Manager Automation document, its version, and its input parameters, then enable automatic execution. Map the affected resource's ID into the runbook's resource parameter using RESOURCE_ID; provide fixed settings as static parameters.

AWS Config can attach an Automation remediation action directly to a rule. Alternatively, EventBridge can match a Config compliance-change event and invoke an Automation runbook. The diagram shows both entry paths for comparison; normally choose one owner for each remediation to avoid duplicate starts.

Organization-wide integration starts with an organization using all features, not consolidated billing only. Trusted access authorizes a supported AWS service to integrate with Organizations. It lets that service obtain organization information and perform its supported cross-account work, using service-linked roles where required.

A StackSet holds a template, parameters, and deployment configuration. A stack instance records a deployment in one account and one Region; the corresponding stack owns the resources. Updating the StackSet is not an atomic transaction across those stacks.

AWS Config rules evaluate resource configuration against declared requirements. A security group restricts traffic and storage encryption protects data; Config assesses whether those preventive controls are configured as required. The assessment itself does not enforce the control or reject the configuration change.

An organization Config rule centrally deploys one rule definition across eligible accounts in an AWS organization. You manage the organization-level definition rather than independently maintaining a copy in every member account. Evaluations still run in the target account and Region.

AWS AppConfig changes configuration independently of application code. An application contains environments; a configuration profile identifies configuration data and its validators. A deployment selects a configuration version, an environment, and a deployment strategy. The application must already know how to retrieve and apply that configuration.

Reusable IaC describes infrastructure to create or modify. A CloudFormation module, AWS CDK construct, or AWS Service Catalog product can supply secure defaults. Those defaults are not an enforcement boundary if consumers can override them, modify the resulting template, or deploy through another path.

For a CloudFormation-backed product, an administrator publishes a reusable template as a provisioning artifact, the Service Catalog object representing a product version. Its parameters are the choices consumers can make; its resource definitions encode the infrastructure pattern. Treat each released template as a fixed contract and publish a new version when that contract changes.

A failure boundary defines the resources you assume become unavailable together. An Availability Zone consists of one or more discrete data centers with redundant power, networking, and connectivity. AZs are physically separated within a Region and connected by low-latency networks. A Region is a separate geographic area containing multiple AZs.

A failure domain is the set of resources exposed to the same failure event. Availability Zones separate supporting infrastructure within a Region; Regions provide a broader geographic and infrastructure boundary. Neither boundary contains a software defect that you distribute across it.

A workload survives an Availability Zone failure only if the surviving request path still has traffic routing, application capacity, and usable state. Two application fleets do not help if both depend on a database or network appliance that exists only in the failed zone.

Aurora is part of Amazon RDS, but its storage architecture differs from non-Aurora engines. Here, standard RDS means RDS for MySQL or PostgreSQL. The RDS side of the diagram shows a Multi-AZ DB instance deployment, not a Multi-AZ DB cluster: its primary and standby have separate storage, with synchronous replication between them.

This lesson uses an RDS for MySQL Multi-AZ DB instance with a supported cross-Region read replica configuration, not a Multi-AZ DB cluster or Aurora. The same-Region standby receives synchronous replication; the remote read replica receives asynchronous replication. Those different acknowledgment paths determine their recovery behavior.

In active-active, multiple Regions serve production traffic before a disruption. Surviving Regions must absorb displaced traffic, not merely retain their existing share. In a standby architecture, another Region has deployed resources and replicated state but does not normally serve the production workload; taking over can require scaling and database promotion.

Route 53 selects a DNS endpoint when answering a DNS query. Health-aware routing makes records eligible or ineligible under the configured routing policy. Route 53 does not receive the subsequent HTTP requests, and one cached answer can serve many requests.

Route 53 uses health evaluation to decide which records are eligible for DNS selection; it does not proxy application requests. Creating a health check alone does not affect answers: associate it with the relevant record. A non-alias record without an associated check is treated as healthy.

A routing hierarchy composes decisions through alias records, rather than assigning several routing policies to one record. For example, the failover records for api.example.com can have a primary alias to a weighted record group at active.example.com and a secondary alias to a standby endpoint. The weighted group contains aliases to application endpoints in two active Regions. Each group has records with the same name and type, a common routing policy, and distinct record identifiers.

Route 53 selects DNS answers; it does not forward application packets. Its records can identify AWS or non-AWS destinations. Standard Global Accelerator instead receives TCP or UDP traffic on static anycast IP addresses and carries it over the AWS global network to supported Regional endpoints: Application Load Balancers, Network Load Balancers, EC2 instances, or Elastic IP addresses.

An SLI is a measurement of service behavior; an SLO sets a target and evaluation window for that measurement. An SLA establishes agreed commitments and commonly specifies consequences for missing them. To align availability with an SLA, first identify the business journey and the exact commitment being made to its users.

Composite availability describes a complete operation, not merely running components. Define success first: for example, an order lookup returns correct information within two seconds. Identify everything required to meet that definition. Checkout and order lookup can have different availability because they require different dependencies.

A service level objective (SLO) specifies a reliability target for a defined measurement and evaluation window. For example, at least 99.9% of eligible requests must succeed over a rolling 30-day window. The service level indicator (SLI) is the measured success proportion; it can change without the target changing.

An error-budget policy turns reliability measurements into decisions about releases and engineering work. Its purpose is to intervene before customer-facing SLA commitments are missed. An internal SLO is often stricter than the corresponding SLA, creating room for intervention. That margin is meaningful only when you understand each measure’s scope, window, and exclusions; meeting an internal SLO does not automatically prove contractual compliance.

High availability is a user-facing objective: the service must perform its required work with an acceptable level of interruption over a defined observation period. Failover is a recovery mechanism: responsibility moves from an unhealthy component to an alternative. The mechanism supports the objective, but executing it does not prove the objective was met.

Replication maintains another copy of database state. After an initial copy, storage changes, transaction logs, or logical changes keep the destination updated. That mechanism answers: What data reaches the other database?

Failover changes which resource serves the workload. Backup and restore recovers a preserved data state. A standby can be ready to accept connections yet contain exactly the same incorrect records as the primary. Service availability and data correctness are separate properties.

In asynchronous replication, the writer can acknowledge a committed transaction without waiting for a replica to apply it. Separate three boundaries: committed on the writer, durably received by the replica, and replayed into the replica's query-visible state. A successful write response establishes the writer's acknowledgment boundary, not the replica's replay boundary.

A successful commit means only what the database's acknowledgment rule promises. Check which copies must durably record the change before success, which failures those copies survive, and which copies are eligible for promotion. A synchronous acknowledgment can mean durable receipt rather than completed replay.

A safe takeover transfers write ownership, not just traffic. An eligible replica must have a recoverable data state, support promotion, and have enough capacity and working dependencies to serve the workload. A reachable replica is not necessarily an eligible writer.

Health-driven failover changes where new work goes when a destination stops being eligible. This design uses a standard AWS Global Accelerator for regional routing and an Application Load Balancer in each Region for target selection. Both regional endpoint groups are enabled to receive traffic. Each EC2 fleet spans two Availability Zones, with cross-zone routing enabled on its ALB target group.

For a conventional Aurora MySQL or Aurora PostgreSQL cluster, an in-Region writer failover promotes an eligible Aurora Replica against the same cluster storage. Place a suitable replica in another Availability Zone so losing the writer's zone does not also remove the intended replacement. Storage durability alone does not provide a ready replacement database instance.

Aurora Global Database has a primary regional cluster and secondary regional clusters receiving asynchronous, storage-based replication. A commit acknowledged in the primary Region is not proof that a secondary has received it. Promoting a secondary changes which Region owns the writer role.

For node-based Valkey and Redis OSS, a replication group contains a primary and its replicas; with cluster mode enabled, each shard has its own primary and replicas. The diagram shows one shard before failure, with Multi-AZ and automatic failover enabled. It draws write traffic, replication, and metric publication, not response traffic or failover-control messages.

A global table joins DynamoDB tables in different Regions into one replicated dataset. Each regional replica can accept reads and writes. DynamoDB manages replication; the application addresses a regional endpoint rather than a single endpoint that automatically selects a healthy Region.

A business availability target becomes useful only after defining what the user must accomplish, how quickly, and over which measurement window. For example, a successful checkout might require a durable order and confirmation within two seconds. Running servers are not enough: errors, lost orders, and responses beyond that deadline violate this success condition.

High availability (HA) aims to keep a service usable through specified failures. Disaster recovery (DR) establishes how to restore usable service when the normal environment is unavailable or untrustworthy. The distinction is not simply short outage versus long outage: it is maintaining service within a designed failure envelope versus recovering from a disruption that requires restoration.

Fault tolerance means continued operation during specified failures, with the required behavior preserved. High availability means meeting a service availability objective over an observation period. That objective can allow brief recovery interruptions. The concepts overlap: fault tolerance can support high availability, but meeting an uptime target does not establish fault tolerance.

Fault isolation limits the spread of a failure. High availability concerns whether users can still complete the required operations. A fault can remain entirely within its intended boundary while the service becomes unavailable: containment says where the fault stopped, not whether another usable request path exists.

A health check tests the configured protocol, port, and application response—not every capability of a backend. ALB uses HTTP or HTTPS health checks; HTTP-based checks evaluate a configured path and success-code matcher. For gRPC target groups, configure the health-check method and gRPC success-code matcher instead of treating gRPC codes as HTTP status codes.

For an ALB or NLB using EC2 instance targets, distinguish enabling an Availability Zone from registering targets there. Enabling a zone gives the load balancer a presence in that zone. A registered instance in a zone that is not enabled does not become eligible for application traffic merely because it is registered.

Recovery Point Objective (RPO) limits how much recent data recovery may lose, expressed as time. Recovery Time Objective (RTO) limits how long service restoration may take. These are requirements; the recovered-data gap and elapsed recovery time are the observed results compared with them.

A Recovery Time Objective (RTO) is a target for acceptable business downtime, not a database restore duration or a provider guarantee. Define it for a business capability and a failure scope: for example, accepting orders within 30 minutes after a Regional disruption.

RTO is the target maximum time to restore the business service after disruption. RPO is the maximum acceptable data loss, measured in time. Derive both from business impact and define the recovery boundary: accepting a login is not recovery if customers still cannot complete an order.

A resilience policy in AWS Resilience Hub records the recovery objectives an application should meet. Start with the business capability being protected: what must work again, how long it can be unavailable, and how much recent data the business can lose. Define recovery as usable business functionality, not merely a running instance or an available database.

A redundant workload path must reach working compute and usable state without depending on the failed component. This example targets loss of either application Availability Zone, not loss of the Region. Clients enter through an Application Load Balancer, either stateless pool handles the request, and both pools use regional application state.

A single point of failure is a component or shared dependency whose failure leaves no effective path for a required business operation. Define that operation before counting replicas. For order submission, success might mean durably committing an order and returning confirmation within the latency target—not merely returning a healthy web page. Establish acceptable interruption, data loss, and degraded behavior with the business owner.

AWS Trusted Advisor fault tolerance checks look for resource configurations that depart from particular reliability best practices. For example, the Amazon RDS Multi-AZ check can expose a database instance without Multi-AZ deployment. That identifies a redundancy gap against the check's criteria; it is not a simulated database failure or an assessment of the application's complete dependency chain.

Cross-Region Replication (CRR) asynchronously copies eligible object versions between S3 general purpose buckets in different Regions. Enable versioning on both buckets. An accepted source write is not proof that its replica exists: source availability and destination recoverability are separate facts.

A CloudFront origin group contains a primary and a secondary origin. A cache behavior targets the group rather than either origin individually. When CloudFront needs an origin response, it tries the primary first; an eligible failure can make it try the secondary. A cache hit needs neither origin.

An Application Load Balancer (ALB) evaluates listener rules, such as host and path conditions, to choose a forwarding action and target group. Within that group, target selection depends on registration, health, zone eligibility, and the configured routing algorithm. These are separate decisions: a healthy target in the wrong group cannot serve a matching request.

A cross-Region promotion changes where production runs, not merely which binary runs. Each environment needs working regional dependencies and independent multi-AZ capacity. The diagram shows the prepared, pre-promotion state: blue owns writes, green validates reads, and the routing branches are configured alternatives—not a claim that both receive production traffic.

Demand is the work offered to a system; utilization is the capacity currently consumed. Neither alone tells you how much work is waiting. Saturation means a resource cannot immediately serve all the work competing for it. At a capacity ceiling, utilization can flatten while queues, throttling, and latency continue to rise.

The CloudWatch agent configuration selects what the host collects; installing the agent does not select every available measurement. On Linux, metrics.metrics_collected names collectors such as mem, and each collector's measurement list selects its measurements. These agent-published measurements are custom metrics, separate from EC2's default metrics.

A metric filter evaluates incoming events in a CloudWatch Logs log group. Its filter pattern selects events and extracts fields; its metric transformation specifies the metric namespace, name, value and optional unit. Metric filters require the Standard log class and do not backfill historical events.

A metric alarm evaluates a time series, not a resource in general. For a directly selected metric, verify the account and Region, then the namespace, metric name, and complete dimension set. Different dimension combinations identify different metrics. Omitting a dimension from a custom metric does not automatically aggregate its dimensioned series. AWS-provided and custom metrics use the same alarm evaluation model.

A scaling policy translates a demand signal into desired capacity; it does not make new capacity immediately usable. For target tracking, choose a metric that measures load per unit of capacity: at constant demand, adding capacity should reduce the metric approximately proportionally. Average CPU utilization works when CPU tracks the workload, and ALBRequestCountPerTarget measures requests per target.

A queue-backed worker pool separates accepting work from executing it. This design uses an SQS Standard queue and ECS workers: accepted messages wait while workers are busy or unavailable, subject to retention. Queue acceptance is not business completion.

ReceiveMessage returns a message and a receipt handle, then temporarily hides that message from subsequent receives. Receiving does not remove the message. If the consumer does not delete it, visibility expiry makes it eligible for another delivery. Each receive produces a new receipt handle; use the latest handle for visibility changes and deletion, not the message ID.

Resilient fan-out gives each consuming application its own delivery path and backlog. Here, an ECS publisher sends order events to one Amazon SNS Standard topic. Two subscriptions deliver every event to separate Amazon SQS Standard queues; each worker fleet reads only its own queue.

Competing consumers share one queue's processing obligation. Each message is intended to be completed by one worker, not by every worker. Adding workers divides the pending work; it does not create an independent copy for each worker.

Amazon SQS gives consumers a shared work backlog. Workers polling the same queue are competing consumers: they divide the work rather than each receiving an intentional copy. Adding workers increases processing capacity; it does not create another independent business subscription.

A retained event stream separates record lifetime from consumer progress: reading does not remove a record. A work queue stores pending work: successful acknowledgment or deletion removes that work from normal delivery. These are different recovery contracts, not simply different ways to buffer data.

Publish-subscribe messaging distributes a publication to matching subscriptions. The subscription determines who receives it. That distribution contract does not, by itself, promise that a subscription created tomorrow can receive yesterday’s publications.

Competing consumers share one work backlog. With an Amazon SQS standard queue, workers receive messages, process them, and delete them after success. A received message becomes temporarily invisible, but duplicates remain possible. Adding workers increases processing capacity; it does not give each worker its own copy of every event.

A command requests an action from the capability that owns it. AcceptOrder asks the order service to evaluate a requested change; the service can accept or reject it. An event asserts an occurrence. OrderAccepted reports that the owning service has already established acceptance. It does not ask recipients to decide whether that acceptance happened.

Serverless answers an operational question: who provisions and maintains the infrastructure that executes the workload? The provider manages the execution hosts; the application team configures higher-level resources instead of administering those hosts. This is more specific than merely using a managed service: EC2 has provider-managed physical infrastructure, but customers still administer their instances' guest operating systems.

A stateless worker can handle a request without remembering an earlier invocation. Business state still exists, but its authoritative copy lives outside the execution environment. A useful test is to replace the worker immediately before any invocation: the request and durable records must still be enough to produce the correct outcome.

A serverless application scales through several independently limited services. This design accepts orders through a direct API Gateway integration with an SQS standard queue, processes batches through a Lambda event source mapping, and writes results to a DynamoDB table. The diagram shows the forward work path, not acknowledgments or polling calls.

A synchronous API has two capacity boundaries: API Gateway admits requests, and Lambda admits executions. This diagram shows the request direction for a REST API with a synchronous Lambda integration; responses return through the same services.

An orchestrator reconciles desired state with running workloads: ECS services maintain tasks; Kubernetes controllers maintain Pods. Scheduling answers where another replica can run, while autoscaling changes replica count or available compute. Increasing desired replicas does not create usable capacity by itself: workloads can remain pending when resources, placement rules, or supported compute configurations do not fit.

Amazon ECS is the orchestration layer: it manages the lifecycle of tasks using the configuration you supply. A task definition describes the containers and their runtime requirements; a task is a running instantiation. An ECS service maintains a desired number of tasks, while standalone tasks do not have that service-level desired-count loop.

For ECS tasks on Fargate, task-level CPU and memory select a supported resource configuration. They are not independent sliders: a CPU value permits particular memory values. Start with the combined needs of every container, including logging, proxy, and monitoring sidecars, then choose a supported pair with headroom.

AWS Auto Scaling provides application-wide management through scaling plans. A plan identifies supported resources, using sources such as application tags or a CloudFormation stack, and manages scaling instructions for those resources. It does not create the application's infrastructure or manage every resource carrying the same tag.

Quota headroom is the difference between an applied limit and demand measured in the same units and scope. Identify the target account, service, quota, and AWS Region; then inspect whether the quota is Regional, global, or resource-specific. Automation should use service codes and quota codes, plus resource context where required, rather than matching display names alone.

Scaling activity history records operations attempted by an Auto Scaling group. In the console, open the group's Activity tab; through the API, use DescribeScalingActivities. Read the Cause, StatusCode, StatusMessage, timestamps, and affected instance together. Cause explains why the operation started; StatusMessage provides diagnostic detail about its outcome.

Resource utilization describes consumption relative to available capacity, for a particular resource and observation period. Right-sizing chooses a resource's type, size, and quantity to meet workload requirements at an appropriate cost. Utilization is evidence for that choice, not the choice itself.

Start with a performance target: a required request rate, a latency percentile and an error-rate limit for a defined request mix. Measure offered requests as well as successful completions. When completions stop increasing but queues and tail latency grow, extra demand is becoming waiting work rather than useful throughput.

Load balancing chooses where traffic goes within a target pool. Elasticity changes the capacity available to do the work as demand changes. The first changes the assignment of work; the second changes the resources available for work.

A cache reduces average work; it does not impose an upper bound on origin work. With one origin read per miss, request rate λ, and hit ratio h, demand is approximately λ × (1 − h), before refreshes and retries. Dropping from 99% to 90% hits multiplies that demand by ten at unchanged traffic. Design around an origin budget, not an expected hit ratio.

Tune the loop around origin demand per useful target, not traffic before caching. For comparable cacheable requests, origin rate ≈ viewer rate × (1 − hit ratio). A hit ratio falling from 90% to 80% doubles origin demand at unchanged viewer traffic. Uncacheable traffic must be added separately. Cache expiration and invalidation therefore belong in capacity tests, not just cache tests.

Blue-green retains two independently promotable versions: blue serves production while green is installed and tested. The diagram shows the request paths for an ECS deployment managed by CodeDeploy, including an optional test listener. Its two production branches represent different phases, not simultaneous forwarding. Each ECS card includes the tasks registered in its own target group.

Data locality concerns the entire access path, not just the customer's nearest endpoint. Regional compute still makes remote calls when its data lives elsewhere. This design serves customers through regional applications while keeping stale-tolerant reads near their consumers; both Regions are approved for this dataset.

Active-active means both Regions serve production traffic now; their shares need not be equal. Each regional stack must serve its supported operations without a synchronous call to the other Region. Local application instances span Availability Zones, but only the separate regional stacks address regional loss.

A standard accelerator accepts connections through static anycast IP addresses. Its listener defines the protocol and ports; each Regional endpoint group contains destinations for that listener. Global Accelerator selects destinations using client location, endpoint health, and your traffic settings—not a global round-robin rotation.

A token bucket has a refill rate r, measured in requests per second, and a capacity B, measured in tokens. Each admitted request consumes one token. Unused tokens accumulate only up to B; the bucket does not reset at calendar-second boundaries. API Gateway rejects requests that exceed its throttles rather than holding them in a queue.

Recovery Point Objective (RPO) is the maximum acceptable window of lost data. For a disruption at time T, a recovery point representing committed data through P meets a required limit R only if T − P ≤ R. This comparison assumes the point is usable for the failure being addressed.

AWS Backup manages protection and restoration through retained recovery points for supported resources. The restore unit depends on the resource and its supported restore features: a resource-level restore and an item-level restore are not interchangeable capabilities. A recovery point is recoverable data, not an already running replacement application.

Pilot light keeps an essential recovery core operational before a disruption. That core commonly includes a database receiving replicated changes. Application compute can remain stopped or undeployed, so an operational core is not the same as a recovery environment ready to serve users.

A backup-plan copy action names a destination vault ARN and can specify the copied recovery point's lifecycle. Create that vault in the recovery Region before using it. The source backup and its copy have separate jobs: source-backup success does not establish that a usable regional copy exists. Confirm cross-Region copy support for the resource type and Regions before relying on the design.

A repeatable restore starts with a versioned recovery manifest: source resources, recovery-point identifiers or supported point-in-time targets, dependency relationships, destination settings, application version, and validation rules. Record the incident reference time and any known corruption cutoff. Freeze the chosen inputs for this execution; do not select “latest” again after a retry.

AWS Elastic Disaster Recovery (DRS) continuously replicates server disks into a relatively small staging area, rather than continuously running a full duplicate application fleet. The diagram separates steady-state replication from recovery-time launch. Its arrows show logical data and configuration dependencies, not every temporary resource or control-plane call.

A pilot light keeps an essential recovery core running, but serving the application still requires activation. This example uses an asynchronous RDS cross-Region read replica and application instances created during recovery. The diagram shows activation commands and validation probes, not replication, responses, or normal application traffic.

A recovery runbook is a versioned contract for moving a workload from a defined failure state to a verified service state. Record its owner, trigger, supported starting states, exact inputs, expected results, escalation contacts, and stopping conditions. Pin the procedure version and resolved resource identifiers for each execution; an instruction such as “restore the latest backup” leaves an important decision undefined.

Systems Manager Automation coordinates recovery; it does not replicate backups. Before recovery starts, a supported recovery point must already be available in the target Region, with usable encryption keys and destination infrastructure. This example restores an EC2 application from an AWS Backup recovery point copied there.

A failover hypothesis names the fault, the affected workload, and the customer outcomes that must remain within limits. For example: “When the selected application capacity in one Availability Zone becomes unavailable, checkout errors remain below the approved limit, service recovers within its recovery-time objective, and no acknowledged orders disappear.” Define the traffic mix and load too: failover under idle conditions does not demonstrate failover at peak demand.

An AWS FIS experiment template defines actions, targets, an execution role, and stop conditions. Starting it creates an experiment run. Each action names an actionId, supplies that action's parameters, and maps its target names to target definitions. For example, aws:rds:failover-db-cluster can initiate an Aurora cluster failover; it does not prove that application connections recovered.

An end-to-end failover test places a synthetic order through the application hostname, then verifies its owner, contents, and durable state. A healthy endpoint alone is not recovery. This diagram covers database-AZ and regional drills; application hosts stay healthy during the database-AZ drill. Database cards represent clusters, not individual instances.

A cross-Region copy addresses regional unavailability. A separate destination account addresses production-account compromise only if production identities cannot administer that account. Recoverability also requires protected retention and usable encryption keys; geography alone supplies neither.

A structured event contract defines field names, types, meanings, allowed values, and presence rules. JSON is only an encoding: {"rejected_count":12} and {"rejected_count":"12"} are both valid JSON, but only the first satisfies an integer contract. Keep a readable message for people; monitoring should use explicit fields rather than extract words from it.

CloudWatch Logs does not discover arbitrary logs automatically. A source must collect or generate records, select a destination, and deliver them. This architecture uses a host-based collector for application files and a service-managed delivery path for network records.

Amazon Managed Service for Prometheus stores Prometheus-compatible metrics in workspaces. A time series is identified by its metric name and complete set of labels. For example, http_requests_total{service="checkout",status="500",instance="a"} is distinct from the same metric with instance="b". Labels are both identity and query inputs: PromQL can select matching series and aggregate away labels at query time. The backend manages storage and query infrastructure; it does not remove the need to design instrumentation and collection.

A workspace in Amazon Managed Service for Prometheus stores and queries Prometheus-compatible time series. In this architecture, two self-managed Prometheus collectors on EC2 scrape the same EKS workload endpoints and use remote write to send samples to one workspace. EC2 hosts the collectors; it does not scrape metrics automatically.

A span's duration is inclusive elapsed time: it includes time spent waiting for nested operations. Adding parent and child durations double-counts work; adding concurrent child durations double-counts their overlap. For a parent spanning 0–200 ms, children A at 20–120 ms and B at 60–180 ms cover a combined interval of 20–180 ms: 160 ms, not 220 ms.

Structured logging represents events as records with explicit fields. A record such as {"event":"payment_retry","trace_id":"T","attempt":2} says that an event was reported in a particular context. Searching for trace_id=T retrieves related records; it does not establish how their operations were connected.

This managed path uses an API Gateway REST API stage with tracing enabled and a Lambda function with Active tracing. For a sampled request, both services contribute tracing data without application instrumentation being required for their managed segments. X-Ray is a telemetry destination, not a proxy through which the invocation travels.

OpenTelemetry instrumentation creates spans inside applications. The ADOT collector receives those spans over OTLP, processes them, and uses its awsxray exporter to translate them into X-Ray segment documents. Running a collector does not, by itself, instrument an application.

An X-Ray service map aggregates observed service relationships, latency, and response outcomes over a selected period. A slow edge or several faulting nodes identifies where to investigate; it does not show the sequence of one request. Aggregated latency can also hide a slow minority behind many fast requests.

Within an AWS account and Region, a CloudWatch metric is identified by its namespace, metric name, and complete set of dimension name-value pairs. Dimensions are part of the series key, not descriptive tags. Changing, adding, or removing a dimension selects a different metric. Reordering the same pairs does not.

Metric cardinality is the number of distinct metric time series within a defined scope and time window—not the number of measurements. Within one AWS account and Region, CloudWatch identifies a metric by its namespace, metric name, and complete set of dimension name-value pairs.

Temporal aggregation summarizes observations within time intervals, not across resources. First select the intended metric: its namespace, name, and dimensions identify a series within an account and Region. Different dimension combinations identify separate custom metrics; CloudWatch does not automatically combine them.

At-least-once delivery permits repeated delivery of an accepted event; it does not promise successful downstream processing. First establish durable acceptance: the shipper must retain responsibility until the stream accepts the record. A lost response leaves acceptance uncertain, so retry with the same event identity. With PutRecords, inspect individual results and retry failed records rather than every successful record.

This pipeline uses Amazon Kinesis Data Streams as a retained event log. Two independent Kinesis Client Library (KCL) applications read the same records: one maintains an audit history, and one evaluates incident-response actions. Reading records does not remove them, and each application maintains its own checkpoints.

Amazon Kinesis Data Streams retains records and exposes them to consumers. Consumer applications control their processing logic and reading progress. Reading a record does not remove it: independent consumers can process the same input at different positions, subject to the stream's read-capacity constraints.

A producer supplies a partition key with each log record. Kinesis hashes that key into a shard's hash-key range. Without an explicit hash-key override, records sharing a key reach the same shard. Write capacity is constrained by both bytes and record count: many small records can exhaust record capacity before byte capacity.

A CloudWatch Logs subscription filter selects log events and names a destination stream and delivery role. This diagram uses a same-account subscription and a Lambda consumer connected through a Kinesis event source mapping. The stream accepts authorized writes; it does not interpret subscription filters or decompress log batches.

Amazon Kinesis Data Streams is the ingestion and retained-record layer. Producers append log records, and consumers read them independently. Reading does not delete a record: it remains available for replay until it expires under the stream's configured retention policy.

Amazon Kinesis Data Streams retains partitioned records; your consumer defines errors, maintains window counts, and detects anomalies. This design uses long-running Kinesis Client Library (KCL) workers on EC2, with control over their host operating system. KCL coordinates shard ownership and recovery; it does not supply the error-analysis algorithm.

Backpressure makes downstream capacity govern upstream activity. Follow this log-record path from an EC2 logging agent through Kinesis Data Streams and a custom ECS consumer to OpenSearch Service. The diagram shows record movement only; responses and control signals are not separate edges.

The protection boundary is the point beyond which stored telemetry remains ciphertext without an additional decryption capability. With server-side encryption, the storage service receives readable data and decrypts authorized reads. Encrypting the storage does not stop an identity that is authorized to retrieve the decrypted contents.

Authenticated TLS is a per-connection property. Inventory each sender, receiver, expected server name, trust store, protocol policy, and termination point. The diagram shows request and telemetry delivery connections; arrows do not represent response traffic, certificate provisioning, or management APIs.

A telemetry record can exist as network traffic, a buffered batch, an archive object, and an exported file. Encryption in transit protects traffic between connection endpoints. Authenticated TLS protects confidentiality and integrity on that connection; it does not determine how the receiver stores the record.

Application-side envelope encryption separates payload encryption from key protection. The application encrypts telemetry locally with a symmetric data key; a separate wrapping key protects that data key. The receiving storage service gets an encrypted package, not the telemetry plaintext or the plaintext data key.

TLS protects application bytes while they travel between TLS endpoints. The receiving endpoint possesses traffic secrets that let it authenticate and decrypt incoming records. Returning the recovered bytes to the receiving application is the intended operation of TLS, not a weakness or bypass.

A workload identity belongs to software, not the person who deployed it. An IAM role has no long-lived access keys of its own; assuming it produces temporary role session credentials: an access key ID, secret access key, and session token. IAM groups organize user permissions; they are not principals that workloads can assume.

A service role has two separate authorization surfaces. Its trust policy identifies who may assume it and under what conditions. Its permissions policies define the actions available when the service uses the role. Allowing assumption does not, by itself, allow log delivery.

Emission-time sanitization removes sensitive values before the logging call. Use an allowlist of diagnostic fields, replace credentials completely, and sanitize nested objects and exception details before serialization. Preserve request IDs and error codes instead of request bodies or authorization headers. Sanitizing only in a forwarding agent leaves earlier console output and local copies exposed.

Amazon S3 Object Lock enforces write-once protection on individual object versions in a versioned bucket. A protected version's contents cannot be overwritten, and permanent deletion is blocked while its protection applies. Versioning alone does not block permanent deletion.

Immutable storage answers: can this protected record be altered or permanently deleted while its protection applies? The storage system rejects prohibited operations. Evidence-integrity verification answers: do the bytes being examined match a trusted baseline? A cryptographic hash or signed digest supports that comparison; it does not reject storage operations.

Amazon Data Firehose, formerly Amazon Kinesis Data Firehose, is the delivery layer for a CloudWatch metric stream. Create a Direct PUT Firehose stream in the same account and Region as the metric stream. CloudWatch pushes metric updates into it; Firehose buffers and delivers them.

Native EC2 metrics are published by the EC2 platform into the AWS/EC2 namespace. Examples include CPUUtilization, network traffic, and instance status-check metrics. Their publication does not depend on a guest agent, the instance profile, or the guest's network path to CloudWatch. Detailed monitoring changes the publication frequency of supported metrics; it does not add visibility inside the operating system.

CloudWatch Logs retention is set on a log group and applies to its log streams. Event age is based on the event timestamp, not the ingestion timestamp. A late-arriving event therefore does not receive a fresh retention period when it arrives. Without a retention policy, log events are retained indefinitely.

Storage tiering changes how retained data is stored. Log retention controls how long records remain before they become eligible for removal. S3 Lifecycle supports both through distinct actions: transition changes storage class, while expiration applies end-of-life behavior.

An S3 Lifecycle transition changes an object's storage class within S3; it does not move the object into a separate Glacier vault. For current objects, age-based transition and expiration rules use object creation time. These actions do not form a chain of timers: an expiration age is not measured from the preceding transition.

Choose a log object's destination class from its retrieval deadline, not its age alone. S3 Standard-IA and S3 Glacier Instant Retrieval support immediate object access. S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive require a restore operation before the object can be read.

Storage tiering changes where bytes are stored and the economics and access behavior of that storage. Data archiving preserves information so an authorized person can find, interpret, and use it throughout its required lifetime. Tiering can support an archive, but it establishes only part of that outcome.

CloudWatch Logs retention deletes; it does not archive. Retention eligibility follows each event's timestamp, not the time an archive job finishes. Physical deletion can lag eligibility, but that delay is not a recovery window you can safely depend on. A late-arriving event can therefore have less active-storage time remaining than a newly generated event.

A CloudWatch Logs subscription filter forwards matching log events to Lambda in batches using asynchronous invocation. This direct integration does not route through EventBridge, and it does not require a Kinesis Data Streams consumer or a Lambda event source mapping.

CloudWatch Logs filter patterns and Logs Insights QL are different languages. Filter patterns select events for searches, metric filters, and subscription filters. Their regex expressions use percent delimiters, as in %ERROR|Timeout%. This restricted regex dialect does not support parentheses or multibyte characters: changing delimiters on an application regex does not make it compatible.

Amazon Athena and CloudWatch Logs Insights query different data boundaries. Athena’s usual log-analysis path reads objects in Amazon S3, using table metadata to interpret their contents. Logs Insights queries events retained in CloudWatch Logs log groups, within the selected groups and time range.

Envelope encryption assigns different jobs to two keys. A data encryption key, or DEK, encrypts the log bytes locally. A symmetric KMS key protects the DEK; its key material is not returned to the application. Large log payloads do not pass through KMS.

A customer-managed KMS key is both a cryptographic resource and an availability dependency. Create it through a reviewed template that establishes its key policy, permitted use, rotation configuration where supported, and ownership metadata. Record the key ARN against the datasets, replicas, snapshots, and backups that depend on it; an alias is a mutable routing name, not a durable dependency identifier.

A baseline describes expected behavior for a particular metric, statistic, and population. Model the statistic you actually want to alarm on: failed-authentication events using Sum answer a different question from average latency. Keep dimensions meaningful; combining unrelated applications can hide a surge in a small, sensitive application.

RDS metrics describe resource behavior over time; engine logs record selected database events or statements. CloudWatch metrics can locate a period of rising storage latency or connection count, but they do not identify the SQL responsible. Logs can identify statements worth investigating, but they are not a complete picture of resource demand.

Amazon GuardDuty detects evidence of threats: suspicious API activity, communication with known malicious destinations, and other indicators of malicious or unauthorized activity. It applies threat intelligence, detection rules, and anomaly detection to supported telemetry. A finding calls for investigation; it is not automatically proof of compromise.

CloudTrail management events record supported control-plane activity, such as changing a bucket policy. Data events record supported resource-level operations, such as S3 GetObject. Recording a policy change does not establish whether anyone subsequently read an object. Data events require explicit selection; management-event coverage does not imply data-event coverage.

CloudTrail activity records describe supported AWS account activity. For an API event, fields such as userIdentity, eventSource, eventName, and eventTime help establish which principal invoked which operation and when. Source information, request parameters, and error details add context where available; records do not necessarily contain every request or response value.

AWS Config provides evidence of recorded resource state. A configuration item describes a supported resource at a capture time, including configuration attributes, resource metadata, and supported relationships. Comparing configuration items shows how the recorded state changed; it is not a transcript of every API request.

A trail has two independent scope choices. An account trail covers activity for its account; an organization trail covers the management account and member accounts, including accounts that subsequently join. Sending several account trails to one bucket centralizes storage, but does not turn them into an organization trail. Member accounts cannot modify the organization trail.

A protected evidence archive must do more than collect records centrally. It must demonstrate delivery, preserve original records, expose tampering, and prevent premature destruction. This architecture separates trail administration, archive custody, and evidence review.

Amazon CloudWatch dashboards support the operational monitoring loop: inspect recent telemetry, see alarm states, and investigate a workload that needs attention. Metric graphs, log query widgets, and alarm widgets put evidence together. CloudWatch can also display historical trends; it is not limited to the latest measurements.

An operational dashboard is only trustworthy when each row has a defined grain. For example, prepare one row per UTC minute, service, Region, and endpoint, with request count, error count, latency sum, and latency sample count. Normalize timestamps and units before analysis. When joining log-derived counts to metric-derived statistics, first align their time buckets and dimensions; a many-to-many join can multiply both counts without producing an obvious visual error.

Active tracing is a REST API stage setting, not a setting on individual methods. Enable it through the stage's tracingEnabled property, or TracingEnabled in CloudFormation. This setting belongs to API Gateway REST stages, not AppSync GraphQL APIs or Elastic Load Balancing listeners.

A reliable operational signal needs more than fast delivery. Each log should carry a stable event ID, an occurrence timestamp, and grouping fields such as service and Region. This design turns those records into per-service, per-Region error counts, while preserving events that arrive too late for online correction.

A reliable real-time aggregate needs a precise definition of which events belong together, when to publish, and what to do with delayed events. This pipeline implements those decisions in an Apache Flink DataStream application running on Amazon Managed Service for Apache Flink.

For S3 log analysis, distinguish three operations. A Glue crawler discovers structure and records metadata in the Glue Data Catalog. A Glue ETL job reads records, applies programmed transformations, and writes output. Athena SQL interprets a table definition and queries the referenced objects; the catalog does not hold those log records.

A Glue crawler inspects log objects in Amazon S3 and writes table and partition metadata to the Data Catalog. It does not rewrite the logs. Athena uses that metadata to interpret and locate the objects, then reads the records directly from S3. DataBrew prepares data; it is not the crawler that maintains this metadata.

An Athena external table describes how to read existing S3 objects; creating it does not import or validate the records. The SerDe interprets the record format, ordinary columns describe record fields, and partition columns describe how records are grouped into locations. A query can fail—or return misleading nulls—when the declared schema does not match the files.

A CloudWatch alarm action can publish a state-change notification to an SNS topic. That publication and delivery to a subscriber are separate operations: successful publication does not prove that the incident receiver accepted the notification.

For general purpose buckets, S3 Event Notifications can directly target a standard SQS queue, a standard SNS topic, or a Lambda function in the bucket's Region. SQS buffers work for consumers; SNS fans notifications out to subscribers; Lambda runs handler code. SNS and EventBridge are not substitutes for a retained, consumer-polled work queue or for a code runtime.

RDS storage autoscaling increases allocated storage for supported RDS DB instances as free space runs low. It is a storage-capacity mechanism, not instance autoscaling or Aurora storage management. You enable it on the DB instance; you do not need to build a CloudWatch alarm that requests each increase.

In provisioned mode, DynamoDB auto scaling adjusts provisioned capacity, not the number of database servers. Application Auto Scaling manages table reads, table writes, global secondary index reads, and global secondary index writes as separate scalable dimensions. Each enabled dimension has its own bounds and target-tracking policy.

This pipeline uses direct S3 notifications to invoke Lambda asynchronously. First, grant s3.amazonaws.com permission to invoke the function in its resource-based policy, constrained by the source bucket ARN and source account. Then configure the bucket notification for s3:ObjectCreated:*, with a prefix such as logs/ and a suffix such as .gz. The bucket and function must be in the same Region. The wildcard includes completed multipart uploads, not just ordinary PUT uploads.

AWS Health Dashboard presents AWS-published information about service events: operational issues, scheduled changes, and other notifications that can affect your resources. Its public service-health view describes AWS service status; its account-specific view provides events relevant to your account, including affected resources when available. A notification is AWS-side context, not a measurement of your application's success rate.

An AWS Health event describes an AWS-side issue, planned change or account notification. Its eventArn identifies the Health event across updates; the EventBridge envelope's id identifies a delivered event, not the entire Health lifecycle. Correlate account-specific processing with the affected account as well as the Health event ARN.

Fan-out is not a transaction. Here, an SNS topic delivers an order-created event to separate inventory and notification queues. Either branch can finish while the other remains pending or fails; neither branch's completion commits or rolls back the other.

A content-based routing policy maps an event to a set of destinations, not necessarily one destination. Define the admitted event population, the conditions for each destination, and the outcome when no condition matches. Otherwise, overlapping conditions and newly introduced event types silently change behavior.

An event is a fact that can trigger work; a process instance is the durable record of that work progressing toward an outcome. Event delivery, execution admission, task completion, and business completion are different boundaries. A successful delivery or StartExecution response proves neither that tasks finished nor that their business results were accepted.

A failure boundary is the scope whose outcome a handler can honestly decide: one record, one batch, or an entire operation. Classify exceptions by their cause and scope, not merely their language type. A parsing error in one malformed record can justify isolation; the same error across every record after a deployment can indicate a broken schema contract.

A scaling plan contains scaling instructions, not one application-wide utilization setting. Each instruction identifies a service namespace, resource ID, and scalable dimension, then supplies capacity bounds and target-tracking configuration. An ECS service's desired task count and a DynamoDB table's provisioned read and write capacity are distinct dimensions. Even one table can therefore need separate instructions and targets.

An OpsItem is a persistent operational work record, not the alarm itself. It carries fields such as title, source, severity, priority, status, affected resources, and operational data. Operators can create records manually, clients can call CreateOpsItem, and configured integrations can create them automatically.

Event correlation asks which observations are connected and what evidence supports that connection. Timeline reconstruction asks what happened before, after, or alongside other activity, and how confidently that order can be established. A relationship claim and an ordering claim are different conclusions.

A correlation rule is a testable claim about related evidence. Start by naming the entity and relationship, not by choosing fields with similar names. For example: a permission grant to a role, followed by a sensitive object read using that role, supports a role-level access hypothesis. It does not establish that the person who changed the policy performed the read.

A defensible timeline is a set of evidence-backed claims, not just sorted log lines. For each observation, retain the source and record identifier, original timestamp and time zone, normalized time, principal or session, resource, action, result, and a reference to the preserved original. Keep your interpretation separate from the source record so another investigator can reproduce or challenge it.

A pipeline's current view is not a reliable record of an earlier failure. Start with execution history, select the failed execution, and record its pipeline execution ID, source revisions, pipeline version, and timing. Nearby executions can have different inputs or configurations; the same stage name does not make them interchangeable.

Deployment rollback restores a previously validated release or redirects traffic to it. It is justified by the deployed change and its effects, not simply by a red pipeline. Separate execution evidence, which describes what deployment tooling did, from customer-outcome evidence, which describes whether the service works. A successful deployment can introduce a regression; a failed build can leave production unchanged.

Federation lets AWS accept identity evidence from an external issuer without copying its passwords. For direct OIDC federation, an IAM OIDC provider registers the issuer and accepted audiences; a role's trust policy identifies the provider and restricts which identities may assume that role. The provider object alone grants no role access.

A SAML assertion is an XML statement from an identity provider, or IdP, about an authenticated subject. A recognizable username is not evidence of authenticity. The receiving service provider, or SP, needs an independently configured relationship with the issuer before accepting its statements.

Workload federation exchanges an externally issued identity token for temporary AWS role credentials. This example uses IAM roles for service accounts (IRSA): a deployment pod receives an EKS service-account OIDC token, and its AWS CLI uses web-identity credentials rather than an IAM user's long-lived access key.

OpenID Connect adds authentication to OAuth 2.0. Its identity artifact is an ID token: a JWT carrying claims such as issuer, subject, audience, and expiration. An OAuth access token authorizes access to a resource; it is not interchangeable with an ID token merely because both can be JWTs.

Delegated IAM administration lets a team manage selected identities without giving it unrestricted authority. A permissions boundary is a managed policy attached to an IAM user or role that limits its identity-based permissions. For an identity-based grant to authorize an action, both the identity policy and the boundary must allow it, with no applicable explicit deny.

A service control policy (SCP) limits the permissions available to principals in affected AWS Organizations member accounts. Applicable SCPs come from the organization root, every organizational unit (OU) on the account’s path, and the account itself. A matching explicit deny at any of those levels overrides member-account allows, including AdministratorAccess.

A scalable job-function role is a permission contract: approved actions, resource scope, conditions, and explicitly excluded administrative powers. Define functions such as auditor or application operator from actual tasks, rather than copying a broad administrator policy. Keep production and development assignments separate even when they share a job-function definition.

Attribute-based access control (ABAC) lets one policy authorize operations across resources whose attributes match the caller. For a supported action, an Allow can use "StringEquals": {"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"}. A principal with Project=Atlas then satisfies that condition for a resource tagged Project=Atlas, but not Project=Orion. The principal attribute comes from applicable identity or session tags; the resource attribute comes from the target resource.

Project isolation can use one shared policy instead of a separate resource list for every team. For a supported action, an Allow can compare the resource’s Project tag with ${aws:PrincipalTag/Project}. For example, a condition on secretsmanager:GetSecretValue can contain {"StringEquals":{"aws:ResourceTag/Project":"${aws:PrincipalTag/Project}"}}. A session with Project=Atlas satisfies that comparison for an Atlas secret, but not a Borealis secret.

Role-Based Access Control (RBAC) associates permissions with approved responsibilities, such as auditor or application operator. A role's permissions must specify both permitted actions and resource scope: an operator role need not cover every environment. Attribute-Based Access Control (ABAC) evaluates policy rules against attributes of the principal, resource, operation, or request context.

MFA enforcement belongs at the authentication boundary. For workforce federation through an external identity provider, require MFA in that provider's access policy for AWS sign-in. When IAM Identity Center uses that external identity source, enforce MFA there rather than assuming an AWS permission policy will prompt the user. Cover both browser access and the sign-in that supplies command-line credentials.

Inspection is enforced by routing, not by deploying a firewall nearby. This single-Availability-Zone example shows only an established, workload-initiated IPv4 internet connection and its replies. The required order is workload, firewall endpoint, public NAT gateway, internet gateway, external peer.

Stateful filtering remembers a permitted flow; stateless filtering evaluates each packet independently. State belongs to the control that created it. A security group's connection record cannot authorize a packet through a separate network ACL or firewall.

Network segmentation starts with a communication contract: source, destination, protocol, destination port, and purpose. Here, the application may initiate PostgreSQL connections to the data tier on TCP 5432; other application-to-data connections are not required. Separate subnets do not enforce that contract: a VPC normally has local routing between its subnet address ranges.

A route table selects a target using the most specific matching destination prefix. It does not authorize a TCP port. Each subnet uses an associated route table, explicitly or through the main table. The VPC's local route normally connects its subnets, so putting workloads in separate subnets—or removing an internet default route—does not by itself isolate them from each other.

Treat the inspection configuration as a versioned resource graph. In CloudFormation, AWS::NetworkFirewall::RuleGroup defines rules, AWS::NetworkFirewall::FirewallPolicy references rule-group ARNs and sets evaluation behavior, and AWS::NetworkFirewall::Firewall associates the policy with a firewall. Use resource references rather than copying ARNs between templates. Review rules, references, defaults, and associations together.

Treat a web ACL deployment as both policy and attachment. In CloudFormation, declare AWS::WAFv2::WebACL with its Scope, DefaultAction, ordered rules, and VisibilityConfig. Give rules unique priorities; lower numbers run first. Keep the template in version control so changes to statements, actions, priorities, and associations receive review together. AWS CDK can generate these same CloudFormation resources.

AWS Network Firewall inspects network traffic delivered through its inspection path. Its stateless engine evaluates packets; its stateful engine tracks flows and supports protocol-aware rules and intrusion prevention. It can inspect non-HTTP traffic as well as supported application protocols, but cannot inspect a flow that bypasses it.

A Shield Advanced subscription does not automatically register every eligible resource for Advanced protection. Create a protection for each selected resource, using its resource ARN. Supported resource types include CloudFront distributions, Route 53 hosted zones, Elastic IP addresses, Application and Classic Load Balancers, and Global Accelerator standard accelerators.

AWS Shield provides managed detection and mitigation of distributed denial-of-service attacks. Its objective is availability: resisting traffic intended to exhaust capacity or disrupt service. AWS WAF evaluates HTTP/S requests against rules in an associated web access control list, or web ACL. Its decision is whether a request matches a configured policy, not whether the application is experiencing a DDoS attack.

A protected HTTP path combines upstream DDoS mitigation, HTTP filtering, and origin isolation. AWS Shield Standard provides automatic baseline network and transport-layer protection. Shield Advanced adds capabilities for eligible protected resources, which must be enrolled. When its optional automatic application-layer DDoS mitigation is enabled for supported resources, Shield Advanced creates and manages AWS WAF rules to mitigate detected attacks. That capability does not replace application-specific access controls or eliminate all attack-related charges.

A certificate signature proves that an issuer signed a binding between an identity and a public key. It does not make that binding universally trusted. A client must build a valid path to a configured trust anchor. A root's self-signature does not create trust, and receiving a root certificate from a server does not add it to the client's trust store.

Start with the endpoint's DNS names, intended clients, and required trust anchor. A certificate binds its subject alternative names to a public key; it does not grant application access. ACM public certificate domain validation proves control of a name, not the legal identity of an organization or the authorization of a particular workload.

Certificate management: renewal and revocation is about keeping the correct certificate in service, not merely obtaining another certificate. Inventory each certificate's owner, issuer, expiration, deployment locations, and renewal method. Start replacement early enough to allow issuance failures, retries, deployment, verification, and recovery before expiration. Alert on stalled progress as well as remaining validity.

A certificate lifecycle is a set of verified handoffs, not merely a successful issuance call. This architecture uses an EC2-hosted custom controller to request an ACM-managed private certificate, check the live endpoint, and test revocation publication. The arrows show selected artifact and request flows, not every API exchange.

AWS Certificate Manager (ACM) manages certificate resources for applications. It can request publicly trusted certificates, import certificates issued elsewhere, and manage private certificates issued through AWS Private CA. Its integrations let supported AWS services use those certificates without you manually installing them.

ACM lifecycle automation has three separate gates: prove control of the domain, place the certificate where the TLS endpoint can use it, and keep that endpoint serving renewed material. An Issued status clears the first gate; it does not configure DNS routing or attach the certificate to a listener.

A trusted private CA needs an active signing configuration and a trust path that relying applications accept. Distribute the appropriate trust anchor to those applications; issuing a certificate does not establish trust by itself. AWS Private CA protects its CA private keys in AWS-managed hardware security modules. The automation caller submits a certificate signing request, not the CA private key.

A classification is an owner-approved decision about the consequences of disclosure, modification, loss, or unavailability. Discovery findings are evidence for that decision, not approval. Record the dataset identity, scope, accountable owner, approved category, approval state, and revision in a governed source of truth. Category names and their meanings are organization-specific; encryption does not lower the underlying classification.

Amazon Macie discovers sensitive data in S3 object contents. Its bucket inventory and security posture information are not evidence that every object has been classified. Configure discovery in each relevant AWS Region; an organization-wide administrator does not make discovery automatically cross-Regional.

AWS KMS and AWS CloudHSM both protect keys with hardware security modules, but expose different contracts. With KMS, an application submits AWS API requests such as Encrypt or Sign, identifying a KMS key. KMS authorizes the request and performs a supported operation. The application does not open an HSM session or manipulate HSM key objects directly.

Defense in depth starts with an attack path: reach the entry point, exploit the application, use its identity, and access or export data. Protect different transitions. AWS WAF filters HTTP requests; application authorization checks permitted actions; narrowly scoped workload and database permissions limit the consequences of compromise. An ACM-managed TLS certificate protects the connection, not the application from malicious requests.

Envelope encryption uses a data-encryption key, or DEK, for the payload and a wrapping key, or KEK, to protect the DEK. Here, software in the application encrypts the payload; CloudHSM performs the key-wrapping operations. The payload never needs to enter the HSM.

A TLS server can terminate connections while its certificate private key remains inside AWS CloudHSM. With a supported integration, the TLS library delegates the handshake's private-key signing operation to the HSM and receives a signature—not the private key.

VPC Flow Logs capture IP traffic metadata for network interfaces, not packet contents. Create a flow log on a VPC, subnet, or network interface. VPC and subnet scopes cover interfaces in that scope, including interfaces created later. Choose ACCEPT, REJECT, or ALL; use ALL when auditing both permitted and denied traffic.

An IAM user's long-lived access key consists of an access key ID and a secret access key, without a session token. The secret is used to sign requests; it is not sent as plaintext with each request. The ID alone cannot authenticate a request, but an exposed ID-and-secret pair lets another party sign requests under that user's permissions. Long-lived keys do not expire automatically.

Evidence integrity is a claim about particular bytes relative to a trustworthy baseline. Preserve each collected file as an original, with its source resource, account, Region, collection method, collection time and timezone, and collecting identity. This identifies what was collected; it does not establish that collection included every relevant event.

Validated outcomes, not alert volume or analyst dismissal clicks, should drive tuning. First identify the detector's claim: attempted access, successful access, exposed configuration, or unusual behavior. Correlate it with audit records, workload logs, configuration history, and approved changes. Severity sets priority; it does not establish that the claim is true.

Normalization changes interpretation, not just format. Collecting different logs together, or converting them all to JSON, does not make their fields mean the same thing. This pipeline keeps transport envelopes separate from the typed events derived from them.