Illustrated technology atlas · Terraform and AWS CDK for ECS/Fargate, EKS and Lambda

Terraform × AWS CDK · Illustrated AWS Deployment Atlas

Best practices

For a software engineer learning infrastructure delivery on AWS. Best practices depth follows the explicitly requested fundamentals and production practices, with a focused AWS CDK comparison. Covers Terraform 1.x and AWS CDK v2 concepts, AWS ECS rolling deployments, EKS managed-node/Fargate distinctions and conventional Lambda functions with standard SQS polling. Code blocks are illustrative fragments with omitted declarations; they were reviewed against primary documentation but not compiled, applied or deployed to AWS. The three cases are worked scenarios, not reported customer outcomes. No regional prices, benchmark results or exhaustive feature coverage are claimed.

Research date: 2026-10-10

Choose your route: start with topics 1–3 for the mental models; use 4–6 for AWS case studies; read 7–10 before production; finish with 11–12 for migration and improvement.

A numbered notebook overview groups fundamentals, AWS application cases, operating practices, recovery, and decision criteria. — Four learning stages, plus a comparison lens. The worked scenarios do not report measured customer outcomes.

Part 1 · Fundamentals

Terraform: desired configuration meets observed reality

Prerequisites: Start here / basic technical literacy

Configuration, stored bindings and provider observations feed planning. Apply operates through providers and records results; arrows show control/data flow, not an atomic transaction. [S02] [S41]

Objective and mental model verified

Understand what Terraform remembers and what it asks AWS. Configuration expresses desired attributes; state binds resource addresses to remote IDs. Terraform uses provider reads to observe managed objects and computes proposed changes. State is neither the running application nor a backup of its data.

[S02]

Mechanism verified

Write configuration, initialize dependencies/backend, inspect a plan, then apply. Dependencies constrain ordering; unrelated operations may run in parallel. Terraform normally runs when invoked or scheduled, rather than continuously reconciling every AWS change.

[S01] [S41]

Worked example synthesis

Changing an ECS image reference can create a task-definition revision and update a service. Updating a variable does nothing to AWS until a deployment runs. A data source reads an existing object; it does not automatically give Terraform ownership of that object. This is a worked interpretation of the resource model.

[S51]

Decision, pitfall and next improvement synthesis

Review the actual plan for replacements and deletions, not just the HCL diff. A successful plan cannot prove IAM permissions, account quotas, network reachability or application health. Improve the baseline with a disposable environment and workload smoke checks; keep a recovery runbook for interrupted applies.

[S34]

The small workflow synthesis

terraform init
terraform fmt -check
terraform validate
terraform plan -out=release.tfplan
# Review this saved plan in the authorized deployment workflow.
terraform apply release.tfplan

[S35]

Keep this: A plan is a proposed reconciliation; an apply is a sequence of remote operations.

Check yourself: If apply fails halfway, did AWS return to its previous state?

No. Some operations may have completed. Inspect the actual resources and state, fix the cause, and generate a fresh plan; Terraform does not automatically roll back partial applies.

Part 2 · Fundamentals

HCL, dependencies and stable resource identity

Prerequisites: 01-terraform-engine

Cluster and task-definition references constrain the service creation order. A stable service key maps to a remote service ID; source-file position does not establish execution order. [S02] [S05] [S56]

Objective and vocabulary verified

Distinguish providers, resources, data sources, variables, locals, outputs and modules. A provider supplies resource schemas and API behavior. A module composes configuration behind an input/output interface. Prefer an abstraction such as private-api-service over a wrapper that only renames one resource.

[S03] [S04]

Why references matter synthesis

Referencing another resource attribute creates an implicit dependency. In this example, the ECS service depends on the cluster and task definition. Add depends_on for a real hidden dependency, such as required IAM permissions; broad dependencies reduce parallelism and can postpone reads.

[S56]

Worked fragment: one service per stable key synthesis

locals {
  apis = { quotes = 2, documents = 2 }
}
# Fragment: referenced resources are defined elsewhere.
resource "aws_ecs_service" "api" {
  for_each        = local.apis
  name            = each.key
  cluster         = aws_ecs_cluster.platform.arn
  task_definition = aws_ecs_task_definition.api[each.key].arn
  desired_count   = each.value
  launch_type     = "FARGATE"
  # network_configuration omitted here
}

[S05]

Decision and pitfall synthesis

Use semantic keys that remain stable across releases. Removing quotes from the map removes its managed instance; renaming it changes its address. Keys must be known before apply. Index-based count is reasonable for interchangeable objects, but shifting indices is a poor identity model for named services.

[S05]

Improve the baseline synthesis

Version modules deliberately and document which team owns each output. Use moved blocks for compatible address changes instead of recreating resources. A naming convention helps humans; a migration declaration tells Terraform what happened.

[S42]

Keep this: Stable addresses make refactoring boring. Boring is a production feature.

Check yourself: Does moving a resource into another .tf file change its identity?

Not by itself within the same module. Changing its module path, resource name or instance key changes its address; use a compatible moved mapping when preserving the object.

Part 3 · Fundamentals

AWS CDK: a programming interface to CloudFormation

Prerequisites: 01-terraform-engine

Terraform applies through providers and keeps its resource bindings in a backend. AWS CDK synthesizes templates; CloudFormation owns the stack records and deployment. Both still rely on AWS service APIs. [S06]

A CDK cloud assembly can include template and asset manifests. Publishing sends file assets to S3 and image assets to ECR before CloudFormation deploys the stack. [S09]

Objective and mechanism verified

AWS CDK executes application code to build a construct tree, then synthesizes a CloudFormation template and cloud assembly. Deployments are performed through CloudFormation. Values represented as tokens can resolve later; a resource ARN token is not necessarily a concrete string during synthesis.

[S06]

Abstraction ladder verified

L1 constructs expose CloudFormation resource properties. L2 constructs provide service-oriented APIs and helpers. L3 patterns compose a working arrangement, such as an ALB and Fargate service. The generated resources and defaults still need review; a short program can create a substantial stack.

[S07] [S16]

Assets and bootstrap synthesis

Modern CDK environments have publishing/deployment roles and asset infrastructure. The CLI packages and publishes files or Docker images before deploying the stack. This is useful for application packaging; it adds a build toolchain and an asset-lifecycle responsibility. Keep build inputs reproducible.

[S08] [S09]

Worked choice and trade-off synthesis

For an AWS-only TypeScript team that ships small application stacks, CDK can colocate packaging and infrastructure. Terraform can provide a consistent workflow across AWS and supported external services. This is a fit judgment, not a claim that AWS-specific HCL becomes portable cloud infrastructure.

[S03] [S54]

Pitfall and improvement verified

Construct-tree refactoring can change generated logical IDs and replace resources. Inspect synthesized templates and protect stable stateful IDs. Make synthesis deterministic; add focused assertions instead of treating all pattern defaults as your security policy.

[S10]

Do not confuse the names verified

AWS CDK and CDK for Terraform are different products with different deployment paths. HashiCorp deprecated CDKTF on December 10, 2025 and stopped maintaining it. This atlas compares Terraform HCL with AWS CDK v2; it does not propose new CDKTF adoption.

[S11]

Keep this: Compare deployment engines and ownership, not just HCL versus TypeScript.

Check yourself: Does choosing CDK remove the need to understand CloudFormation?

No. Resource replacement, stack dependencies, deployment status and rollback behavior still come from CloudFormation.

Terraform and AWS CDK under the same criteria

Criterion	Terraform	AWS CDK v2	Evidence
Authoring model	HCL describes resources and relationships.	Code builds a construct tree; synthesis emits a template.	[S03] [S06]
Deployment engine	Terraform Core and provider operations.	CloudFormation deploys the synthesized resources.	[S56] [S06]
Remembered ownership	Resource bindings in the selected backend.	CloudFormation-managed stack/resource records.	[S02] [S06]
Reuse	Modules with explicit inputs and outputs.	Constructs and higher-level service patterns.	[S04] [S07]
Application artifacts	Choose an explicit build/publish release contract.	Asset packaging and publishing are integrated.	[S09]
Preview	Plan normally includes provider observations.	Diff compares template information; change sets can add detail.	[S34] [S44]
Live drift	Run reviewed plans/drift workflows on a schedule.	Use CloudFormation drift detection separately; coverage is limited.	[S34] [S39]
Failed deployment	A partial apply has no automatic rollback.	Rollback can be attempted and can itself fail.	[S41] [S40]
Refactoring	Use compatible moved mappings for address changes.	Review logical IDs and supported refactor/import operations.	[S42] [S10] [S53]
EKS workload control	Kubernetes/Helm providers need live API access.	EKS manifest helpers use a kubectl/custom-resource path.	[S50] [S22]
Team fit — synthesis	Common provider/state conventions for platform teams.	AWS app composition and asset workflow for app teams.	[S03] [S54]

Scroll the table horizontally on a narrow screen. Fit judgments are labeled synthesis.

Part 4 · Applications

Case study: a NestJS API on ECS/Fargate

Prerequisites: 02-hcl-graph, 03-cdk-comparison

HTTPS ingress reaches a public ALB and then private Fargate task ENIs across two AZs. Execution-role startup and task-role application calls are distinct; deployment ownership is outside the request path. [S12] [S13] [S14]

A completed revision is a potential recovery target. A failed new rolling deployment can return to it; the first-ever deployment has no completed revision. Database changes remain a separate recovery problem. [S15]

Scenario and assumptions synthesis

Worked scenario, not a customer benchmark: an AWS-only quote API needs two replicas and independent application releases. A public HTTPS ALB forwards to Fargate tasks in private subnets across two AZs. The diagram omits DNS, certificate validation and database failover. Select ECS when Kubernetes APIs/operators are not requirements.

[S14] [S16]

Startup and application identity verified

The execution role is used for startup operations such as image pulls and agent log delivery. The task role grants application AWS access. Grant a quote API only the bucket/queue operations it needs; adding S3 permission to the wrong role does not fix application access.

[S12] [S13]

Terraform service fragment synthesis

resource "aws_ecs_service" "quotes" {
  name            = "quotes"
  cluster         = var.cluster_arn
  task_definition = var.task_definition_arn
  launch_type     = "FARGATE"
  desired_count   = 2
  wait_for_steady_state = true
  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }
  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [var.task_security_group_id]
    assign_public_ip = false
  }
  load_balancer {
    target_group_arn = var.target_group_arn
    container_name   = "api"
    container_port   = 3000
  }
}

[S17]

Equivalent CDK intent fragment synthesis

// Inside a Stack; imported modules / existing objects omitted.
const api = new ecsPatterns.ApplicationLoadBalancedFargateService(
  this, "QuotesApi", {
    cluster, certificate, publicLoadBalancer: true,
    desiredCount: 2, cpu: 512, memoryLimitMiB: 1024,
    taskSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
    assignPublicIp: false,
    circuitBreaker: { rollback: true },
    taskImageOptions: {
      image: ecs.ContainerImage.fromEcrRepository(repo, releaseTag),
      containerPort: 3000,
    },
  }
);
api.targetGroup.configureHealthCheck({ path: "/health/ready" });

[S16]

Failure drill verified

Deploy an image whose readiness endpoint fails. Observe service events and target health. The rolling deployment circuit breaker can return to the last completed deployment when rollback is enabled; a first deployment lacks that completed baseline. This is service rollback, not a database migration rollback.

[S15]

Pitfall, fit and next improvement synthesis

Private tasks still need dependency connectivity for image pulls, secrets and logs. Provide appropriate NAT or service endpoints and verify routing/DNS/security rules. For this worked case, measure ALB 5xx, target health and API p95 after deployment. Use immutable release references; confirm the service is running the intended revision even if the waiter succeeds.

[S14]

Keep this: Provision the service and verify its release health as separate responsibilities.

Check yourself: Why might a private task fail before your API starts?

Check image reference, execution-role permissions, secrets/log access, subnet routes, endpoint policies and security groups. Application task-role permissions are only one part of the startup story.

Part 5 · Applications

Case study: an EKS platform with API and worker teams

Prerequisites: 03-cdk-comparison, 04-ecs-case

AWS IaC owns cloud infrastructure; the chosen platform controller/bootstrap owns platform components; GitOps owns application objects. A private cluster API needs a reachable runner. Boundaries show the proposed scenario, not mandatory product separation. [S50] [S48]

Pod Identity on supported EC2 Linux nodes relies on its agent. IRSA relies on OIDC/service-account trust and remains the alternative illustrated for Fargate. EKS Fargate has no DaemonSets or Pod Identity support. [S18] [S19] [S20]

Scenario and ownership synthesis

Worked scenario: multiple teams require Kubernetes operators, rollout controls and a common platform. Terraform owns AWS networking, IAM, EKS and chosen managed add-ons. A separate GitOps owner handles application manifests. Split bootstrap into AWS infrastructure, platform controllers, then apps; this is a proposed operating boundary, not an EKS requirement.

[S23] [S48]

Why a single apply becomes fragile synthesis

A Kubernetes or Helm provider must authenticate to a reachable cluster endpoint. Private API endpoints require a deployment runner with a valid network path. Creating a cluster and immediately configuring in-cluster resources in one run adds readiness, credential and destruction-order coupling. Choose staged deployment when those lifecycles differ.

[S50]

Terraform control-plane fragment synthesis

resource "aws_eks_cluster" "platform" {
  name     = "platform"
  role_arn = var.cluster_role_arn
  version  = var.kubernetes_version
  vpc_config {
    subnet_ids              = var.cluster_subnet_ids
    endpoint_private_access = true
    endpoint_public_access  = false
  }
}
# Worker capacity, access entries, IAM policy dependencies
# and compatible add-ons belong to the complete implementation.

[S50]

What changes with AWS CDK? synthesis

CDK can own AWS cluster resources through CloudFormation. The EKS Cluster construct can also manage Kubernetes manifests using kubectl operations. If you use addManifest or Helm support, account for its custom-resource execution path and permissions. Do not let that path and a GitOps controller manage the same objects.

[S22]

Identity choice verified

On supported Linux EC2 capacity, EKS Pod Identity uses the agent and an association to provide workload AWS credentials. Fargate pods do not support EKS Pod Identity. IRSA uses the cluster OIDC provider and service-account identity; use a supported identity path for each compute type. A pod execution role is not an application permission substitute.

[S18] [S19]

Fargate boundary and failure drill verified

EKS Fargate requires matching profiles; it does not support DaemonSets, privileged containers or EBS-backed pods. Test a pending pod by checking profile selectors and scheduling constraints. A node-agent assumption can break your telemetry plan; design supported collectors before migrating workloads.

[S20]

Next improvement synthesis

Rehearse cluster upgrades: deprecated APIs, add-on compatibility, node versions and disruption budgets. For the scenario, measure API errors and worker lag during drain/upgrade. A managed control plane does not make workload compatibility or the whole upgrade sequence automatic.

[S21]

Keep this: Cluster infrastructure and Kubernetes workloads need explicit ownership and reachable control planes.

Check yourself: Can an EKS Fargate pod inherit app access from its pod execution role?

Do not design for that. Configure a supported application workload identity such as IRSA, with scoped AWS permissions and a compatible SDK.

Part 6 · Applications

Case study: SQS-driven document notifications on Lambda

Prerequisites: 03-cdk-comparison

A producer sends messages to SQS. Lambda mapping polls the queue and invokes the worker; successful records are removed and failures become visible again. Queue redrive eventually moves poison messages to its DLQ. [S24] [S25]

In a standard-queue batch with A and C successful, return B in batchItemFailures. This reduces repeated successful work but does not remove the need for idempotency or guarantee exactly-once effects. [S25]

Scenario and delivery contract synthesis

Worked scenario: a document-ready event triggers a notification worker. Producers send messages to SQS; Lambda event-source mapping polls and invokes the function. Delivery can repeat. Use a durable business operation key and make repeated processing safe; the IaC tool cannot supply exactly-once side effects.

[S24] [S28]

Terraform trigger fragment synthesis

resource "aws_lambda_event_source_mapping" "documents" {
  event_source_arn        = var.queue_arn
  function_name           = var.function_alias_arn
  batch_size              = 10
  function_response_types = ["ReportBatchItemFailures"]
  scaling_config {
    maximum_concurrency = 5
  }
}
# Function role needs SQS permissions; encrypted queues also
# need compatible KMS access. Queue redrive/visibility configured separately.

[S49]

Equivalent CDK trigger fragment synthesis

// Existing queue and function/alias; imports omitted.
worker.addEventSource(new eventsources.SqsEventSource(queue, {
  batchSize: 10,
  reportBatchItemFailures: true,
  maxConcurrency: 5,
}));
// Set the function reserved concurrency independently.
// This example uses standard polling, not provisioned mode.

[S30]

Partial-batch failure drill verified

Send three messages and intentionally fail the second. With ReportBatchItemFailures enabled, return the failed message ID; successful items need not be retried as part of that failed batch. If the handler throws, the whole batch fails. For FIFO queues, stop after the first failure and report failed and unprocessed records to preserve ordering.

[S25]

Scaling decision verified

Reserved concurrency reserves and caps the function. Per-mapping maximum concurrency limits how much an SQS source consumes. Coordinate the limits with database capacity and other triggers. SQS provisioned polling mode uses poller settings and cannot be combined with the maximum-concurrency setting used in this example.

[S26] [S29]

Release and pitfall synthesis

Publish versions and route invocation through an alias to make releases identifiable. Versions retain immutable code/configuration snapshots, but queue messages and external side effects do not rewind when code changes. A redrive policy belongs on the source SQS queue; do not confuse it with a function-level asynchronous invocation DLQ.

[S27] [S24]

Improve the baseline synthesis

Track oldest-message age, errors, throttles and DLQ depth; rehearse safe replay. For a crash between sending a notification and marking it complete, use downstream idempotency or an outbox/transactional design where possible. A simple processed flag alone leaves a crash window. These are design proposals, not measured results.

[S28]

Keep this: Infrastructure connects the trigger. Application logic makes duplicate delivery safe.

Check yourself: Does partial-batch reporting eliminate duplicate notifications?

No. It reduces one retry source. At-least-once delivery, timeouts and crash windows remain; side effects need durable idempotency design.

Part 7 · Best practices

State, locks and blast radius

Prerequisites: 01-terraform-engine, 05-eks-case

Separate network, ECS, EKS and Lambda states constrain the proposed blast radius. Each state has its own lock. The arrows are explicit output contracts; no lock or output alone provides account isolation. [S02] [S31]

Objective and baseline verified

Use protected remote state for collaboration. The S3 backend supports opt-in locking via use_lockfile; DynamoDB-based locking is deprecated. Enable bucket versioning for recovery, encryption and least-privilege access. Provision the backend before initializing configurations that depend on it.

[S31]

Backend teaching fragment synthesis

terraform {
  required_version = ">= 1.11, < 2.0"
  backend "s3" {
    bucket       = "company-prod-terraform-state"
    key          = "platform/ecs/terraform.tfstate"
    region       = "ap-southeast-1"
    encrypt      = true
    use_lockfile = true
  }
}
# Example lower bound, not a recommendation to run an old release.
# The bucket already exists and has versioning/access controls.

[S31]

Isolation decision synthesis

Proposed split: account/region/environment first, then network, platform and application boundaries where ownership and release cadence differ. Avoid one enormous state for all prod services. Too many tiny states create contracts, permissions and deployment-order overhead; split for a real boundary, not one file per resource.

[S04]

Locking pitfall synthesis

The S3 state-object and lock-object permissions differ. A lock cannot serialize a second independent backend that also manages the same AWS resource. Nor does it coordinate manual console actions. Align CI concurrency with the state key and assign one authoritative owner per resource.

[S31]

Reproducible dependencies verified

Commit .terraform.lock.hcl to preserve provider selections and checksums. It does not pin remote module selections; pin module versions or immutable source revisions separately. Upgrade dependencies as reviewed changes and run a plan against each affected environment.

[S33]

Next improvement synthesis

Practice state recovery and validate bindings before resuming. Restoring an old state snapshot changes bookkeeping; it does not restore deleted AWS resources or database records. A CLI workspace is a state namespace, not an IAM/account security boundary.

[S02]

Keep this: A lock protects one state writer; architecture protects the size of its mistakes.

Check yourself: What does restoring yesterday’s state file roll back?

Only Terraform’s remembered bindings and metadata. AWS resources and application data must be recovered through their own mechanisms.

Part 8 · Best practices

A release pipeline with one owner per changing field

Prerequisites: 04-ecs-case, 05-eks-case, 06-lambda-case

Artifact build and infrastructure preview meet at a reviewed release. Deployment runs under one owner; runtime health and intended-version checks follow. State/stack concurrency and a replayable audit record are separate controls. [S35] [S54]

Objective and ownership decision synthesis

Choose an app release contract before automation. Option A: Terraform/CDK owns every task-definition revision or Lambda release. Option B: a release controller owns those changes while IaC owns stable infrastructure. In either case, the declared desired release and the running release must remain auditable.

[S27]

Worked ECS conflict verified

Application Auto Scaling raises desired_count from 2 to 6. A later Terraform apply can try to restore 2 unless ownership is delegated deliberately. ignore_changes = [desired_count] is a narrow Terraform escape hatch for that shared-management case. Ignoring task_definition is a different decision with a separate owner and drift policy.

[S17]

Build once, promote the artifact synthesis

Proposed pipeline: build/test → publish immutable artifact → generate plan or cloud assembly → review → apply/deploy → verify the intended workload revision and health. Protect the reviewed inputs and deployment artifact. A CDK asset build and a Terraform release variable should refer to the same approved release identity.

[S54] [S35]

Saved-plan pitfall verified

A saved Terraform plan may contain sensitive input values. Applying that plan does not prompt again; the release process must supply its approval gate. If state changed or inputs need changing, regenerate and review a new plan instead of treating the old artifact as a reusable deployment recipe.

[S34] [S35]

EKS controller boundary synthesis

Assign application objects to one selected GitOps controller or IaC/custom-resource path. Keep prerequisites, CRDs and app resources in a documented bootstrap order. Do not have Terraform Helm, CDK addManifest and Argo CD repeatedly rewrite the same Deployment. This boundary is a proposed practice for the case study.

[S22] [S48]

Next improvement synthesis

Record source commit, artifact digest, environment, plan/template identity and verification outcome. Measure deployment failure rate and recovery time. Start with one controlled deployer per state/stack; increase parallelism only across independent owners.

[S01]

Keep this: Two reconcilers with conflicting desired values create a tug-of-war.

Check yourself: Why should you avoid ignore_changes = all?

It makes planned updates invisible for the resource. Delegate only specific fields with a known external owner, and keep drift monitoring for the rest.

Part 9 · Best practices

Deployment credentials, runtime roles and secrets

Prerequisites: 04-ecs-case, 05-eks-case, 06-lambda-case

CI federation reaches a deployment role; Terraform calls providers and CDK uses the CloudFormation execution path. Runtime roles separately allow ECS, EKS or Lambda code to use AWS resources. Arrows denote permissions, not inheritance. [S36] [S08] [S12] [S19]

Objective and credential flow verified

Use short-lived federated CI credentials. For GitHub OIDC, constrain the role trust subject to the intended organization/repository and branch or environment, and constrain audience. A broad subject gives other workflows an unintended route into deployment permissions. Runtime task/pod/function roles remain separate.

[S36]

Worked incident synthesis

An ECS API gets AccessDenied reading a document. Check the task role and resource policy. An image-pull startup error points toward execution-role permissions and connectivity. In EKS, verify the service-account identity and its trust/association rather than granting every node a broad role. This diagnosis follows the documented permission planes.

[S12] [S13] [S19]

State and plan are sensitive assets verified

sensitive = true redacts ordinary displays; it does not generally prevent values entering state or plan. Prefer secret references and supported runtime retrieval over fetching plaintext into persistent infrastructure arguments. Ephemeral/write-only capabilities depend on Terraform and provider support; verify the actual resource schema before assuming omission.

[S32]

CDK deployment trust synthesis

Review bootstrap deployment, CloudFormation execution and publishing roles for every account/region. A trusted build role that can invoke a powerful deployment role is part of the effective permission chain. Separate bootstrap administration from ordinary application releases and enforce organizational boundaries.

[S08] [S10]

Pitfall and improvement synthesis

Do not print plans, state or resolved secrets into public CI logs. Set controlled artifact retention and scoped access, and verify a negative permission test in a sandbox. For this atlas, secret values are deliberately absent; references still require correct resource policies and runtime IAM.

[S32]

Keep this: The deployer’s power and the workload’s power are different permission planes.

Check yourself: Does marking an output sensitive encrypt your state file?

No. Redaction and storage protection are separate concerns. Encrypt and restrict backend/plan storage, and avoid persisting values when the selected features support that.

Part 10 · Best practices

Drift, failed applies and evidence that a release works

Prerequisites: 07-state-boundaries, 08-release-ownership

Terraform may leave completed changes and needs inspection/replanning. CloudFormation can attempt rollback but may enter UPDATE_ROLLBACK_FAILED. Application/schema side effects lie outside both infrastructure recovery paths. [S41] [S40]

Objective: three different comparisons verified

Terraform normally observes managed resources during planning, then compares observed attributes to configuration. cdk diff compares synthesized and deployed template information; it is not a full inspection of live AWS configuration. CloudFormation drift detection is a separate feature with support and property coverage limits.

[S34] [S44] [S39]

Failure behavior verified

Terraform does not automatically undo a partial apply; inspect what succeeded and replan after fixing the cause. CloudFormation can attempt rollback, but rollback itself may fail when dependencies cannot be restored. Neither mechanism restores external application side effects or reverses a destructive data migration.

[S41] [S40]

Unit checks versus live tests verified

Terraform test defaults can create real resources; use isolated accounts and explicit cleanup when running live tests. Mock/plan tests check configuration assumptions. CDK fine-grained assertions check synthesized properties; snapshots can help detect shape changes but cannot establish real AWS permissions or runtime behavior.

[S37] [S38]

Worked failure matrix synthesis

ECS: bad readiness path → inspect target/service events and intended revision. EKS: private API unreachable → check runner path before retrying the workload step. Lambda: poison message → observe retries and queue redrive. In all cases, the diagnosis separates provisioning success from serving/processing success.

[S15] [S50] [S25]

Pitfall and further improvement synthesis

Schedule drift checks, classify intentional and accidental changes, and review remediation. CloudFormation drift checks do not include nested stacks automatically and only track supported explicit properties. A refresh-only Terraform run updates state observations; it does not change resources to the declared desired configuration.

[S39] [S52]

Keep this: A clean preview is useful evidence; it is not proof of a healthy workload.

Check yourself: Can a template snapshot test catch an ECS container failing readiness?

No. It can assert configured health-check properties; only a live rollout/runtime check can show the container serving successfully.

Part 11 · Further improvements

Refactor or migrate without accidentally replacing the world

Prerequisites: 02-hcl-graph, 03-cdk-comparison, 10-failure-testing

Compatible Terraform moves preserve a binding. Cross-tool migration freezes writers and transfers ownership of the same remote object using supported workflows; resource support and configuration equivalence must be verified first. [S42] [S43]

Objective: address changes verified

Use moved blocks to preserve a compatible Terraform object binding through a resource/module address change. The desired attributes may still trigger an update or replacement. Keep migration declarations available for environments that have not upgraded yet; review the resulting plan per environment.

[S42]

Worked Terraform move synthesis

moved {
  from = aws_ecs_service.quotes
  to   = module.quotes.aws_ecs_service.this
}
# The destination module/resource must actually exist.
# This maps identity; it does not waive property changes.

[S42]

CDK refactoring boundary synthesis

Construct IDs and tree paths influence CloudFormation logical IDs. Before a stateful-resource refactor, inspect old and new templates and replacement actions. Use a supported refactor/import workflow when applicable; a syntactic TypeScript rename is not sufficient evidence that physical resources will stay intact.

[S10]

Worked cross-tool handover synthesis

Proposed sequence: inventory resource IDs and dependencies; freeze writes; prepare target configuration; test supported import/adoption in a sandbox; release source ownership while retaining the object; import into the target; inspect a fresh plan/change set; verify service behavior; retire the old owner. Never actively manage the same resource from both systems.

[S43] [S53]

Pitfall and next improvement synthesis

Not every resource supports the same import or refactoring operations. Generated defaults, names and update semantics may differ between a CDK pattern and Terraform resources. Migrate one boundary first, retain recovery records, and require evidence of no unintended replacement before moving shared data services.

[S43] [S07]

Keep this: Import changes ownership bookkeeping; a safe migration proves the target configuration matches.

Check yourself: Will importing a resource guarantee the next plan is empty?

No. Import establishes a binding. Differences between target configuration, provider defaults and the observed object can still produce changes or replacements.

Part 12 · Further improvements

Choose a baseline, then measure the trade-offs

Prerequisites: 04-ecs-case, 05-eks-case, 06-lambda-case, 10-failure-testing

The upper cards compare operating needs for Terraform and AWS CDK; the lower cards compare ECS/Fargate, EKS and Lambda by workload constraints. This is an engineering judgment guide, not a benchmark ranking. [S03] [S54] [S21] [S55]

Objective: make fit explicit synthesis

Synthesis: Terraform is a strong candidate when a platform team needs common state/review conventions across several providers. AWS CDK is a strong candidate for AWS-only app teams that benefit from programming-language composition and integrated assets. Both can target ECS, EKS and Lambda; neither choice determines the runtime architecture.

[S03] [S54] [S09]

Target decisions synthesis

Worked judgment: begin with ECS/Fargate for long-running container APIs when Kubernetes capabilities are unnecessary. Choose EKS when operators, Kubernetes APIs or platform needs justify its upgrade/controller burden. Choose Lambda for event handlers with compatible invocation limits and side effects designed for retries. Validate those premises with a small vertical slice.

[S51] [S21] [S55]

Cost model: Fargate synthesis

Fargate compute charges depend on requested CPU, memory, architecture and task/pod duration. Right-sizing and idle replicas matter. Include load balancing, network egress/NAT or endpoints, logs and storage in the scenario estimate. This atlas gives cost drivers, not an unverified regional price quote.

[S45]

Cost model: EKS synthesis

EKS has cluster/support charges plus compute and other consumed services. Upgrade discipline affects support tier exposure. The platform also consumes engineering time for compatibility and operations; compare a complete workload estimate rather than cluster cost alone.

[S46]

Cost model: Lambda synthesis

For conventional Lambda functions, requests and memory-duration are central compute drivers. Add queue, logging, networking and any optional provisioned features. Test representative payloads; lower memory is not automatically lower cost if execution time increases.

[S47] [S28]

Four improvement experiments synthesis

1. ECS: faulty image drill; measure recovery time and false health alarms. 2. EKS: stage an add-on/node upgrade; measure disruption and worker lag. 3. Lambda: duplicate/poison-message drill; measure repeated side effects and backlog recovery. 4. IaC: intentional sandbox drift; measure detection and reviewed remediation. These are proposed experiments. No latency, cost saving or reliability result was measured for this atlas.

[S15] [S21] [S24] [S39]

Keep this: Choose the smallest operating model that fits the workload and the team.

Check yourself: Is a hybrid Terraform foundation plus CDK app layer automatically the best design?

No. It can work with explicit resource ownership and versioned outputs. It also adds two toolchains and handover contracts; use it only when those benefits outweigh its coordination cost.

Target fit — worked engineering judgments

Target	When it earns its place	Operational work	Tool implication	Evidence
ECS/Fargate	Continuous container processes; straightforward AWS service scheduling.	Task/execution IAM roles, private networking, health checks and release ownership.	Both tools fit; CDK offers packaged patterns, Terraform exposes provider/module composition.	[S12] [S13] [S14] [S16]
EKS	Kubernetes APIs, operators and platform controls justify the operating burden.	API reachability, bootstrap order, pod identity, compatible add-ons and upgrades.	Separate AWS infrastructure from app reconciliation when lifecycles differ.	[S50] [S18] [S21] [S48]
Lambda	Event handlers fit the selected invocation limits and retry contract.	Artifact/version/alias, mapping concurrency, durable idempotency and poison-message replay.	CDK is convenient for event/asset composition; Terraform fits a common platform workflow.	[S24] [S27] [S29] [S55]

Scroll the table horizontally on a narrow screen. Fit judgments are labeled synthesis.

A compact glossary

Provider	Terraform plugin exposing resource/data schemas and remote operations.
Backend	Where Terraform stores state and, where supported, coordinates locking.
State binding	Association between a Terraform resource address and remote object identity.
Resource address	Module path, resource type/name and optional instance key.
Data source	A configured read of remote information; reading does not adopt ownership.
Plan	Proposed changes based on configuration, state and available observations.
Construct	CDK composition unit; may emit one or many resources.
Synthesis	Executing CDK code to produce templates/assembly metadata.
Token	A value that may resolve later rather than at synthesis time.
Stack	CloudFormation deployment and lifecycle boundary.
Drift	Actual managed configuration differs from its declared expectation.
Runtime identity	Permissions used by the application while it runs.
Idempotency	Repeating the same operation preserves the intended business effect.

Terminology synthesis: [S02] [S03] [S06] [S28]

Sources & further reading

[S01] Terraform core workflow
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Write, plan, apply and collaborative review.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S02] Purpose of Terraform state
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Resource addresses map to remote object identities; state retains metadata.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S03] Provider requirements
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Providers have source addresses and version constraints.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S04] Creating modules
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Modules should introduce an architectural abstraction.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S05] for_each reference
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Stable map keys identify instances and must be known before apply.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S06] AWS CDK core concepts
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: CDK synthesizes infrastructure into CloudFormation templates.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S07] AWS CDK constructs
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: L1 resource definitions, L2 abstractions, and higher-level patterns.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S08] CDK bootstrapping
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Per-environment asset stores and deployment/publishing roles.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S09] CDK assets
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: File and container image assets are published before stack deployment.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S10] AWS CDK best practices
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Stable logical IDs, deterministic synthesis and organization guardrails.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S11] CDK for Terraform deprecation
HashiCorp · documentation · accessed 2026-10-10 · Deprecation effective 2025-12-10 · Not stated / rolling documentation
Supports: CDKTF deprecated on December 10, 2025; maintenance ceased.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S12] ECS task IAM role
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Application containers use task-role credentials.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S13] ECS task execution IAM role
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Agent uses execution-role permissions for task startup operations.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S14] Fargate task networking
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Task ENIs, subnet routing and connectivity to image/dependency services.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S15] ECS deployment circuit breaker
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Rolling deployment health detection and rollback require a completed baseline.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S16] ApplicationLoadBalancedFargateService API
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Fargate pattern properties include certificate, subnets and circuit breaker.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S17] Terraform AWS ECS service resource
HashiCorp AWS provider maintainers · documentation · accessed 2026-10-10 · Maintainer documentation on main, retrieved through GitHub; not a pinned provider release · Not stated / rolling documentation
Supports: Service network, load balancer, lifecycle and wait-for-steady-state fields.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S18] EKS Pod Identity
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Pod Identity agent and EC2 workload support; excludes Fargate pods.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S19] IAM roles for service accounts
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: IRSA uses OIDC identities to scope pod AWS permissions.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S20] Amazon EKS on Fargate
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Fargate profiles, no DaemonSets or privileged containers, and EBS limitations.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S21] EKS cluster upgrade best practices
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Check APIs, add-ons, node versions and disruption constraints during upgrades.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S22] AWS CDK EKS Cluster API
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Cluster constructs and kubectl-managed addManifest resources.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S23] AFT and Terraform EKS Blueprints
AWS · maintainer architecture walkthrough · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Published account provisioning and repeatable EKS platform pattern.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S24] Using Lambda with SQS
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Lambda polls queues; event delivery can repeat.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S25] SQS event-source error handling
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: ReportBatchItemFailures and FIFO ordering considerations.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S26] Lambda reserved concurrency
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Reserved concurrency reserves and caps function concurrency.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S27] Lambda versions
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Published versions preserve immutable code/configuration snapshots.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S28] Lambda best practices
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Idempotency, connection reuse and operational measurements.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S29] SQS event-source scaling
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Maximum concurrency and provisioned polling mode are separate alternatives.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S30] CDK SqsEventSourceProps API
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Batch size, partial failure reporting and maxConcurrency properties.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S31] Terraform S3 backend
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Opt-in S3 lockfile, bucket versioning and deprecated DynamoDB locking.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S32] Managing sensitive Terraform data
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Sensitive redaction is distinct from omitting persisted values.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S33] Terraform dependency lock file
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Lockfile pins provider selections/checksums, not remote module versions.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S34] terraform plan
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Plan refresh, saved plan artifacts and sensitive contents.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S35] terraform apply
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Saved plans are applied without an additional interactive approval.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S36] IAM role for OIDC federation
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Constrain GitHub OIDC subject and audience in the role trust policy.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S37] Terraform tests
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Test runs can provision real infrastructure; mock/plan modes have limits.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S38] AWS CDK testing
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Fine-grained template assertions and snapshots serve different purposes.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S39] CloudFormation drift detection
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Drift covers supported types and explicit properties; nested stacks need separate checks.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S40] CloudFormation troubleshooting
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Rollback can fail when dependent resources cannot be restored.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S41] Apply Terraform configuration
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Dependency ordering and no automatic rollback of a partially completed apply.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S42] Refactoring Terraform modules
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: moved blocks retain compatible resource bindings through refactoring.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S43] Import Terraform resources
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Import binds a remote resource to a configured address.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S44] cdk diff
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Diff compares synthesized/deployed templates, with change-set support.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S45] AWS Fargate pricing
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Resource allocation, architecture and task/pod duration drive compute charges.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S46] Amazon EKS pricing
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Cluster support charges coexist with compute and other AWS charges.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S47] AWS Lambda pricing
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Function request and memory-duration charges; extra features have separate costs.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S48] Choosing EKS GitOps tools
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: GitOps ecosystem choices include Argo CD and Flux.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S49] Terraform Lambda event source mapping
HashiCorp AWS provider maintainers · documentation · accessed 2026-10-10 · Maintainer documentation on main, retrieved through GitHub; not a pinned provider release · Not stated / rolling documentation
Supports: SQS batch responses and mapping concurrency fields.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S50] Terraform EKS cluster resource
HashiCorp AWS provider maintainers · documentation · accessed 2026-10-10 · Maintainer documentation on main, retrieved through GitHub; not a pinned provider release · Not stated / rolling documentation
Supports: Control-plane IAM and private/public API endpoint fields.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S51] Amazon ECS task definitions
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Task definitions describe workload configuration and have revisions.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S52] Refresh-only state synchronization
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: Refresh-only operations update state observations without changing infrastructure.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S53] cdk import
AWS · documentation · accessed 2026-10-10 · Current documentation accessed on 2026-10-10 · Not stated / rolling documentation
Supports: CloudFormation-supported resource adoption requires target configuration and an import workflow.
Follow this primary reference for the linked mechanism; verify your pinned version before deployment.
[S54] AWS CDK apps
AWS · documentation · accessed 2026-10-10 · Current documentation accessed 2026-10-10 · Not stated / rolling documentation
Supports: App, stack, construct hierarchy and synthesis.
Study this primary mechanism reference before changing deployment boundaries.
[S55] Lambda quotas
AWS · documentation · accessed 2026-10-10 · Current documentation accessed 2026-10-10 · Not stated / rolling documentation
Supports: Workload fit depends on invocation and account limits.
Study this primary mechanism reference before changing deployment boundaries.
[S56] Terraform dependency graph
HashiCorp · documentation · accessed 2026-10-10 · Current documentation accessed 2026-10-10 · Not stated / rolling documentation
Supports: References produce dependency edges; graph operations can run concurrently.
Study this primary mechanism reference before changing deployment boundaries.