AWS DevOps Handoff: Terraform, Deployment Pipelines, and Database Recovery

A deployment pipeline can be green while the next engineer still cannot explain which Terraform state controls production, which application artifact is approved, or how to recover the database. Those gaps become urgent when an infrastructure engineer leaves, a platform role stays open, or release ownership moves between teams.

An AWS DevOps handoff should let an incoming owner make safe decisions with evidence. Start with one production workload and its dependencies. Expand after the team can explain how that workload changes, fails, and returns to service.

1. Inventory ownership and access before changing infrastructure

Build a compact register connecting each workload to its AWS account and Region, code repository, Terraform root module, pipeline, database, and on-call owner. Include dependencies that sit outside the application repository: DNS, certificates, secrets, image registries, network routes, and deployment runners.

• Decision owner: who approves infrastructure changes, releases, database migrations, and recovery?
• Operating owner: who receives alerts and can investigate when the usual engineer is unavailable?
• Access path: which role provides routine access, who approves it, and where is the emergency access procedure?
• Evidence location: where are the latest deployment record, restore result, runbook, and unresolved risks?

Record access references, not passwords or tokens. Confirm the receiving engineer can use the approved access path. A role name in a document does not establish that its trust policy, network path, or identity assignment works.

Start with a read-only inventory

This illustrative shell sequence reads repository, identity, and RDS instance metadata. Replace REVIEW_PROFILE and REVIEW_REGION with an approved profile and Region. Run it from the intended repository; keep identifiers in the internal handoff record.

git status --short
git log -1 --format='%H'
terraform version

aws sts get-caller-identity \
  --profile REVIEW_PROFILE --output json --no-cli-pager

aws rds describe-db-instances \
  --profile REVIEW_PROFILE --region REVIEW_REGION \
  --query 'DBInstances[].{Database:DBInstanceIdentifier,Engine:Engine,Status:DBInstanceStatus}' \
  --output table --no-cli-pager

The AWS calls use GetCallerIdentity and DescribeDBInstances. They do not change resources. This is a starting inventory: Aurora cluster recovery settings and non-RDS dependencies need separate inspection. An access-denied response is a handoff item, not a reason to broaden permissions automatically.

2. Make Terraform state and review reproducible

Document the backend, state key, workspace mapping, Terraform version, provider lock file, module sources, and variable sources for each environment. Identify any resources changed manually or managed by CloudFormation, configuration management, or another Terraform state. Unclear ownership between tools makes the next plan difficult to trust.

For an S3 backend, verify state access, bucket versioning, and the actual locking configuration. HashiCorp documents S3 locking as opt-in through use_lockfile; DynamoDB-based locking is deprecated. Record the mechanism in use and its compatibility requirements before planning a migration. Do not assume that storing state remotely prevents concurrent writes. See HashiCorp's S3 backend reference.

Trace one recent change from commit to reviewed plan to apply. The reviewer should see the target account, environment, proposed replacements or deletions, and expected service impact. Apply the reviewed saved plan through the approved workflow; if inputs or infrastructure have changed, regenerate and review it. Saved Terraform plans can contain sensitive values, so restrict artifact access and retention.

3. Connect deployment approval to the artifact that runs

A release record should connect a source commit, build run, artifact digest or immutable version, test results, approval, target environment, and deployment outcome. Promote the tested artifact instead of rebuilding an untraceable replacement for production. Retain the previous compatible artifact and the configuration needed to run it.

In GitHub Actions, confirm that deployment jobs reference the intended environment and that its protection rules match the release policy. Required-reviewer availability depends on the GitHub plan and repository visibility; merely naming an environment does not create an approval gate. Check self-review and bypass behavior against the team's policy. GitHub documents these environment controls.

Where appropriate, verify artifact attestations against the expected repository and build workflow. They provide provenance evidence, not proof that an application is correct or secure. The handoff should explain how the team verifies that evidence, not just show that an attestation exists. See GitHub's attestation model.

Include configuration in the release record. A known image can behave differently after an environment variable, secret version, feature flag, or database endpoint changes. Name the configuration owner and record how values are promoted without exposing secrets. The person responding to a failed release needs to distinguish an application defect from a configuration change.

4. Separate application rollback from database recovery

Rolling back an application image does not reverse a schema migration or undo committed data. Before a database release, record the migration order, compatibility window, expected locking behavior, validation queries, and decision owner. Rehearse against representative data volumes because a fast change on an empty database says little about production lock duration.

For an illustrative change that replaces a column, an expand-and-contract sequence can preserve compatibility: introduce the new representation, backfill and validate it, deploy compatible application changes, then remove the old representation in a separately approved release. The exact steps depend on the engine, workload, and consistency requirements.

Define when to stop deployment, roll back application code, apply a forward fix, or restore into a separate environment. If new transactions make restoration a data-loss decision, the business owner must be involved. A runbook that says only “restore the snapshot” leaves reconciliation, application compatibility, and traffic switching unresolved.

5. Prove database recovery with a drill

Agree workload-specific recovery objectives with the business. RTO is the target time to recover service; RPO describes the tolerable data-loss interval. AWS recommends defining both per workload. They are objectives to test, not guarantees supplied by a backup setting.

[Example: a 60-minute RTO and a 15-minute RPO] requires more than a database reaching “available.” Measure the recovery point used, restore duration, access and network setup, application reconnection, and business validation. If the drill exceeds either objective, record the gap and an owner rather than marking recovery ready.

Use an approved, isolated destination with the required encryption-key access and cost controls. Validate representative reads and business checks; ensure test applications cannot trigger real customer notifications or payments. Record cleanup ownership. AWS Backup restore testing can automate supported restore tests, but application validation and workload dependencies still need deliberate design.

Keep a dated record of the recovery method, selected recovery point, validation results, and remaining limitations. For RDS or Aurora, distinguish instance-level settings from cluster-level settings. Confirm that the documented procedure applies to the actual engine and deployment model, and schedule another exercise after a material architecture or recovery-policy change.

6. Accept the handoff through an operating exercise

Every actionable alert needs an owner, a dashboard, an initial investigation path, and an escalation condition. Review database connections, storage growth, replication health, backup failures, and deployment failures alongside the workload's customer-facing symptoms. Remove assumptions that only the departing engineer can explain.

Finish with a receiving-engineer exercise: locate the correct environment, explain a reviewed infrastructure change, trace a release artifact, walk through a failed migration decision, and demonstrate the recovery validation procedure in the approved test environment. Capture unresolved access or documentation gaps while the original owner can still help.

The acceptance record should name the workload, receiving owner, evidence reviewed, exercises completed, unresolved risks, and next review date. A handoff is complete when ownership and operating decisions are repeatable. The document is the record of that capability.