An AWS deployment moves versioned application and infrastructure artifacts through environments using a repeatable, observable process.
CloudFormation or another infrastructure-as-code tool defines resources; CodePipeline, CodeBuild, CodeDeploy, or external CI systems can build, test, approve, and release changes.
A release is complete only after health verification, telemetry review, and either confirmed stability or a practiced rollback.
Build once, test the exact artifact, and promote it by version or digest. Avoid rebuilding from a moving branch separately in each environment because the released bytes may differ.
Review CloudFormation change sets and keep environment differences in explicit parameters or configuration. Protect stateful resources from accidental replacement and detect manual drift.
Rolling releases conserve capacity, blue-green releases make environment rollback clearer, and canaries limit initial exposure. The right strategy depends on startup time, compatibility, capacity, and failure cost.
Run smoke tests through the real entry point, inspect errors and latency, and confirm background jobs and alarms. A rollback must restore application behavior without corrupting data or leaving incompatible infrastructure.
Build an application artifact once from a reviewed commit, test that exact artifact, and promote it by version or digest. Record source, dependency lockfile, builder, test evidence, vulnerability result, and artifact checksum. Rebuilding from the same branch separately in production can produce different bytes and defeats promotion confidence.
Keep environment configuration outside the artifact while validating its schema before deployment. Retrieve secrets through a runtime or deployment mechanism that keeps values out of source, templates, build logs, and artifact layers. Sign or attest artifacts where the supply-chain policy requires it and restrict who can overwrite or delete released versions.
A release manifest should connect application, container or package, infrastructure template, database migration, configuration version, and feature flags. That manifest makes rollback and incident analysis possible when several repositories change one workload.
Organize stacks by lifecycle and ownership so one change does not replace unrelated infrastructure. Use parameters for true environment input, outputs and controlled references for shared resources, and nested stacks or modules only where they reduce meaningful duplication. Avoid one giant stack and avoid a tiny stack per resource.
Create and review a change set before critical updates. Look for replacement, deletion, policy, network exposure, and data effects; a syntactically valid template can still replace a database or open a security group. Apply deletion policies, stack policies, backup, and termination protection according to the resource recovery need.
CloudFormation records desired resources but cannot make every application migration safe. Custom resources and hooks execute code with permissions and failure behavior that must be reviewed. Keep templates in version control, validate them, lint policy, and deploy through narrow roles rather than broad personal administrator sessions.
An in-place or rolling release changes a bounded portion of the existing fleet and uses less spare capacity, but old and new versions coexist and rollback is another deployment. Blue-green creates a replacement environment and shifts traffic, making environment rollback clearer at higher temporary capacity and data-compatibility cost.
Canary and linear shifts expose a new revision gradually. Define the initial percentage, observation window, promotion signal, and automatic rollback alarms before deployment. All-at-once is appropriate only when the workload and failure cost justify it. A small traffic percentage may still reach every critical code path poorly, so supplement it with synthetic and targeted tests.
CodeDeploy supports different strategies by compute platform, while ECS, Lambda, Kubernetes, and other platforms also provide native release controls. Choose the simplest mechanism that preserves health checks, traffic control, evidence, and rollback for that workload.
Use expand-and-contract database changes: add compatible structures, deploy code that can handle old and new forms, backfill with bounded work, switch readers and writers, then remove the old form only after rollback no longer needs it. A destructive migration performed before application health is known can make code rollback ineffective.
Version events, API contracts, configuration, and secrets with the same compatibility discipline. A producer and consumer may deploy at different times, and queued messages can outlive a release. Feature flags can separate code release from feature exposure, but every flag needs an owner, safe default, audit history, and removal date.
Test production-like data volume, lock behavior, connection pools, and backfill throttling. Protect database capacity from migration work and checkpoint a resumable job. Define whether rollback reverses data, stops the new writer, or rolls forward with a correction.
Verify the release through the real DNS, TLS, edge, load balancer, authentication, application, dependency, and data path. Check one read, one write, one denied action, one background job, and one operational signal where applicable. Publish a deployment marker so changes align with error and latency charts.
Automatic rollback should use signals that are fast enough and specific enough to indicate the new revision. A shared dependency outage can cause both old and new versions to fail, while a shallow health check can keep a broken release alive. Preserve manual authority when automation cannot interpret the incident safely.
Rollback is a new deployment of a known revision, not time travel. Test whether old code works with current schema, configuration, and external contracts and whether failed scripts left side effects. Keep the failed artifact and logs for diagnosis and record the reason before another attempt.
CloudFormation drift detection can identify supported resources changed outside the template, but it does not prevent manual change or cover every property and resource. Run detection on an appropriate schedule, investigate before overwriting emergency changes, and feed legitimate fixes back into code. Control who can change resources outside the pipeline.
Give build, infrastructure, application-deploy, and runtime stages distinct roles. Restrict artifact repositories, branch or environment approval, role passing, CloudFormation capabilities, and secret access. Protect the pipeline because permission to change deployed code often becomes permission to act as the workload.
Audit every promotion with actor, commit, artifact digest, change set, approvals, time, test result, and rollback result. Exercise compromised-artifact revocation, failed infrastructure update, expired secret, unavailable dependency, and pipeline outage. A deployment system is reliable when the team can release and recover without bypassing its controls.
Rehearse the production sequence in a representative environment using the same roles, artifact promotion, change-set review, migration mechanism, traffic shift, alarms, and rollback command. Seed enough realistic data and concurrency to expose lock, startup, health-check, quota, and timeout behavior. A pipeline test that ends before traffic reaches the new revision is incomplete.
Run one deliberate application failure and one infrastructure update failure. Confirm that automatic behavior stops at the intended boundary, operators receive the correct evidence, and rollback preserves data and configuration. Measure time to decide and time to restore, then compare them with the release and recovery objectives.
Before approval, name the release commander, monitoring owner, rollback authority, communication channel, and no-return point for irreversible work. After release, close temporary access, capacity, feature flags, and old environments on a scheduled checklist rather than leaving them as permanent cost and attack surface.
aws cloudformation deploy \
--stack-name orders-api-dev \
--template-file template.yaml \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides Environment=dev ImageTag=1.0.0A service release renames a database column while old and new tasks overlap during deployment.
Constraints: Rollback must remain possible and the database cannot be locked for a long migration.
Decision: Use expand-migrate-contract: add the new column, dual-write, backfill and verify, switch reads, then remove the old column later.
Verification: Both task versions pass during overlap, row counts and checksums match, and rollback uses the still-present old column.
Failure test: Stop the backfill halfway and confirm restart resumes without duplicating or losing data.Expected evidence: Both task versions pass during overlap, row counts and checksums match, and rollback uses the still-present old column.Explore 500+ free tutorials across 20+ languages and frameworks.