What is “deployment”?

Deployment is the act of taking a finished piece of code — already built and tested — and installing it onto the servers or platforms that real users interact with. This sounds simple until you have hundreds of servers, and doing it by hand (logging into each one, copying files, restarting the application) is slow, error-prone, and terrifying to do at 2 a.m. during an outage fix.

What is AWS CodeDeploy, specifically?

AWS CodeDeploy is a fully managed deployment service that automates pushing application code, configuration files, executables, and scripts to a set of “compute” destinations. It supports four compute platforms: Amazon EC2 instances, on-premises servers (physical machines in your own data center), AWS Lambda functions, and Amazon ECS (container services). Rather than writing custom scripts to SSH into every server, CodeDeploy handles the orchestration: which servers get the update first, how long to wait between batches, what to do if health checks fail, and how to roll everything back instantly if needed.

Why does this matter?

Manual deployments are one of the leading causes of production outages — a missed step, a typo in a config file, or forgetting to restart a service can bring down an application. CodeDeploy removes human inconsistency from the process by running the exact same, tested deployment steps every single time, on every single target, in a defined order.

flowchart TB
    S3["Revision Bundle
(app files + appspec.yml)
in Amazon S3 / CodeCommit"] --> CD["AWS CodeDeploy
Deployment Orchestrator"]
    CD --> DG["Deployment Group
(target selection + rollout rules)"]
    DG --> EC2A["EC2 Instance Batch 1
(CodeDeploy Agent)"]
    DG --> EC2B["EC2 Instance Batch 2
(CodeDeploy Agent)"]
    DG --> Lambda["AWS Lambda
(traffic-shifting alias)"]
    DG --> ECS["Amazon ECS Service
(new task set)"]
    EC2A --> Hooks1["Lifecycle Hooks:
BeforeInstall -> Install -> AfterInstall -> ApplicationStart -> ValidateService"]
    EC2B --> Hooks2["Lifecycle Hooks
(same sequence)"]
    CD --> Alarm["Amazon CloudWatch Alarms
Health Monitoring"]
    Alarm -->|"alarm triggers"| Rollback["Automatic Rollback
to last known-good revision"]
    CD --> CW["CloudWatch Logs & Events"]
        

Notice that EC2 and on-premises deployments rely on an installed agent doing the local work, while Lambda and ECS deployments work differently — CodeDeploy shifts traffic between old and new versions directly at the platform level, since there’s no “server” to install an agent on.

For EC2 and on-premises deployments, the CodeDeploy Agent is the workhorse. It runs continuously on each target instance, periodically checking in with the CodeDeploy service to ask, “is there a deployment waiting for me?” When one is, the agent:

For Lambda deployments, there is no agent at all — CodeDeploy instead manipulates a Lambda alias (a named pointer to a specific function version), gradually shifting a percentage of invocation traffic from the old version to the new one according to the deployment configuration you choose. For ECS deployments, CodeDeploy works with an Application Load Balancer to spin up a new task set alongside the old one and shift traffic between them.

Step 1 — Package. The finished, tested application is bundled together with an appspec.yml file describing how to install it, then uploaded to Amazon S3 (or referenced from CodeCommit/GitHub).

Step 2 — Create a deployment. A deployment is started, referencing the application, the deployment group (which servers, functions, or containers to target), and the revision to deploy.

Step 3 — Select a deployment type. For EC2, you choose in-place (update servers where they stand) or blue/green (stand up entirely new, replacement servers and switch traffic once they’re verified healthy).

Step 4 — Rollout begins according to configuration. CodeDeploy applies your chosen deployment configuration — for example, updating one instance at a time, half at a time, or all at once — pausing between batches to check health.

Step 5 — Lifecycle hooks execute. On each target, the sequence of install-and-validate scripts defined in the appspec file runs in order.

Step 6 — Health is verified. CodeDeploy checks whether each instance, function version, or task set reports healthy — using its own validation hooks and, optionally, CloudWatch alarms.

Step 7 — Success or automatic rollback. If everything reports healthy, the deployment completes and moves to the next batch (or finishes). If a failure or alarm threshold is detected, CodeDeploy can automatically redeploy the last known-good revision, undoing the change without a human needing to react at 3 a.m.

CodeDeploy is built to handle deployments ranging from a single EC2 instance to fleets of thousands. Deployment configurations let you control the pace precisely: deploy to one instance at a time for maximum safety, half at a time for a balance of speed and safety, or all at once when speed matters more (such as deploying to a staging environment).

For Lambda and ECS, “scalability” takes a different shape: instead of batches of servers, CodeDeploy shifts a percentage of traffic — for example, a canary configuration might send 10% of traffic to the new version, wait ten minutes, then shift the remaining 90%, or a linear configuration might increase traffic by a fixed percentage every few minutes until it reaches 100%.

CodeDeploy’s reliability story is really about protecting your application’s availability during the riskiest moment of its life — the moment code changes. By deploying in controlled batches rather than everywhere at once, a bad release only ever affects a fraction of your fleet before CodeDeploy notices and stops.

Blue/green deployments push this further: because the old fleet (“blue”) keeps running and serving traffic throughout, a failed deployment of the new fleet (“green”) never touches production traffic at all — the switch to green only happens after it’s already proven healthy.

In a typical setup, code changes merged into a repository (such as AWS CodeCommit or GitHub) trigger AWS CodePipeline, which runs the build and test stage using AWS CodeBuild, and then hands the finished, tested package to CodeDeploy for the actual rollout. This means a developer’s merged pull request can result in production code being live minutes later, with zero manual steps, and a documented, auditable trail of exactly what happened at each stage.