Cloud / AWS CodeDeploy Interview questions

AWS CodeDeploy is a managed deployment service that automates releasing application code to Amazon EC2 instances, on-premises servers, AWS Lambda functions and Amazon ECS services. You hand it a packaged revision and a deployment plan, and it copies the files, runs your scripts, shifts traffic and rolls back when something goes wrong.

It replaces hand-run SSH sessions and one-off shell scripts in the release process. Because the revision can hold code, binaries, configuration or scripts, it is language-agnostic.

Core capabilities include in-place and blue/green deployments, canary and linear traffic shifting for Lambda and ECS, automatic rollback on failure or CloudWatch alarms, and integration with CodePipeline, Auto Scaling and Elastic Load Balancing.

CodeDeploy supports three compute platforms: EC2/On-Premises, AWS Lambda and Amazon ECS. The platform is picked when you create the application, and it decides which deployment types, AppSpec format and hooks apply.

Amazon EKS is not a CodeDeploy compute platform, so Kubernetes rollouts use other tooling.

CodeDeploy is built from a handful of objects that you configure once and reuse for every release.

• Application - a named container that also fixes the compute platform.
• Deployment group - the set of targets plus settings such as rollback, alarms and load balancer.
• Deployment configuration - the pace rules, either minimum healthy hosts or a traffic-shifting schedule.
• Revision - the versioned bundle you deploy, which contains the AppSpec file.
• AppSpec file - the instructions for what to copy, which permissions to set and which hooks to run.
• CodeDeploy agent - the process on EC2/on-premises servers that executes the instructions.
• Service role and instance profile - the IAM identities used by the service and the agent.

A single deployment is the act of applying one revision to one deployment group using one configuration.

A deployment group defines where a revision is deployed and under which rules. For EC2/on-premises it identifies instances by tags, Auto Scaling groups or both. For Lambda it names the function, and for ECS it names the cluster and service.

It also carries the settings that do not belong inside a revision: the service role, deployment configuration, load balancer or target groups, triggers, CloudWatch alarms, rollback behavior and blue/green options.

One application usually has several deployment groups, such as dev, staging and prod. The same revision can be promoted through them while each group keeps its own safety settings.

A revision is the versioned unit that CodeDeploy ships. For EC2/on-premises it is an archive (zip, tar or tgz) holding your application files, scripts and an appspec.yml at the root of the bundle. For Lambda and ECS the revision is only an AppSpec file, stored in S3 or supplied inline.

EC2/on-premises revisions live in Amazon S3 or GitHub and are identified by the bucket, key and version or ETag, or by a commit ID. Turn on S3 versioning so a past revision can always be redeployed, since rollback depends on it.

aws deploy push \
  --application-name web-app \
  --s3-location s3://my-bucket/web-app-v12.zip \
  --source ./build

The push command zips the folder, uploads it and prints the matching create-deployment command.

The CodeDeploy agent is a small service that runs on each EC2 or on-premises server. It polls CodeDeploy for work, downloads the revision, unpacks it and runs the lifecycle hooks from your AppSpec file. Lambda and ECS deployments do not use it.

It has to be installed and running before the first deployment, it needs outbound HTTPS to the CodeDeploy endpoints and to S3 or GitHub, and the instance needs credentials to read the revision. On Linux it runs as the codedeploy-agent service.

sudo service codedeploy-agent status
cat /etc/codedeploy-agent/conf/codedeployagent.yml

Unpacked bundles are cached under /opt/codedeploy-agent/deployment-root.

The AppSpec file tells CodeDeploy what to do during a deployment. Its structure depends on the compute platform, but it always starts with version: 0.0, which is the only value currently accepted.

Indentation mistakes are a common cause of failures, so validate the YAML before packaging.

CodeDeploy offers two deployment types: in-place and blue/green.

In an in-place deployment the application on the existing instances is stopped, the new revision is installed and the application is started again, usually in batches so the fleet keeps serving traffic. It is available only for EC2/on-premises.

In a blue/green deployment the new version runs in a separate environment and traffic is moved over once it is ready. For EC2 this means replacement instances behind a load balancer. For Lambda and ECS, blue/green is the only option and works by shifting traffic between versions or task sets.

Lifecycle event hooks are the points in a deployment where your own logic runs. On EC2/on-premises a hook points to a script. On Lambda and ECS a hook names a Lambda function that validates the release.

A script hook can set location, timeout (default 3600 seconds) and runas. A non-zero exit code or a timeout fails the event.

hooks:
  BeforeInstall:
    - location: scripts/stop_app.sh
      timeout: 300
      runas: root
  ValidateService:
    - location: scripts/health_check.sh
      timeout: 120

A deployment configuration sets the pace and the success rules of a deployment. For EC2/on-premises it defines the minimum healthy hosts, as a number or a percentage. For Lambda and ECS it defines the traffic-shifting schedule: all at once, canary or linear.

AWS ships predefined configurations, and you can create custom ones. The deployment group holds a default, and you can override it when you start a deployment.

aws deploy create-deployment-config \
  --deployment-config-name Web75Percent \
  --minimum-healthy-hosts type=FLEET_PERCENT,value=75

With this setting at least 75 percent of the fleet must stay healthy, so a 12-instance fleet is updated at most three instances at a time.

CodeDeploy provides three predefined configurations for EC2/on-premises deployments. They differ in how many instances are updated at the same time.

With OneAtATime, the deployment stops at the first failed instance, so a bad revision reaches only one host. If none fits, create a custom configuration with your own minimum healthy hosts value.

For EC2/on-premises, CodeDeploy can pull a revision directly from Amazon S3 or GitHub. S3 revisions must be a zip, tar or tgz archive, and you should reference a specific object version. GitHub revisions are identified by repository and commit ID, and CodeDeploy needs an authorized GitHub connection.

For Lambda and ECS the AppSpec file can come from S3 or be pasted inline when you create the deployment.

Other repositories such as AWS CodeCommit or Bitbucket are not direct sources. The usual pattern is to let CodePipeline or a CI job package the code into a zip in S3, then deploy that archive.

The service role is the IAM role CodeDeploy assumes to act on your behalf. It lets the service read instance tags, describe Auto Scaling groups, register and deregister instances with load balancers, read CloudWatch alarms and publish to SNS. It is attached to the deployment group.

Its trust policy must allow the CodeDeploy service principal:

{
  "Effect": "Allow",
  "Principal": { "Service": "codedeploy.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

AWS provides managed policies per platform: AWSCodeDeployRole for EC2/on-premises, AWSCodeDeployRoleForLambda and AWSCodeDeployRoleForECS.

Start from the managed policy and add only what your setup needs. For example, blue/green copies of Auto Scaling groups that use encrypted EBS volumes require extra KMS permissions on the role.

The instance profile gives the CodeDeploy agent on an EC2 instance the permissions it needs, mainly to download the revision from S3 (such as s3:Get* and s3:List* on the revision bucket). Without it deployments fail with credential errors before any hook runs.

It is different from the service role, which belongs to the CodeDeploy service itself.

On-premises servers cannot use an instance profile, so they authenticate with an IAM user or an IAM role session instead.

You package and upload a revision, start the deployment, then watch its status.

1. Push the bundle to S3 with aws deploy push.
2. Start the deployment with aws deploy create-deployment.
3. Track it with aws deploy get-deployment, or block until it finishes with aws deploy wait.

aws deploy push --application-name web-app \
  --s3-location s3://my-bucket/web-app-v12.zip --source ./build

aws deploy create-deployment \
  --application-name web-app \
  --deployment-group-name prod \
  --s3-location bucket=my-bucket,key=web-app-v12.zip,bundleType=zip \
  --description "release 12"

aws deploy wait deployment-successful --deployment-id d-ABCDE1234

Use list-deployment-instances to see which individual instances failed.

An EC2/on-premises appspec.yml has five top-level parts: version, os, files, permissions and hooks.

version: 0.0
os: linux
files:
  - source: /app
    destination: /var/www/app
permissions:
  - object: /var/www/app
    pattern: "**"
    owner: webapp
    mode: 755
hooks:
  ApplicationStop:
    - location: scripts/stop.sh
  AfterInstall:
    - location: scripts/configure.sh
  ApplicationStart:
    - location: scripts/start.sh
  ValidateService:
    - location: scripts/check.sh
      timeout: 60

• os - linux or windows.
• files - which files from the bundle are copied where.
• permissions - owner, group, mode and ACLs applied to the copied files.
• hooks - scripts to run at each lifecycle event.

On-premises servers are registered, tagged and then targeted like EC2 instances. Only in-place deployments are supported for them.

1. Create an IAM identity for the server. An IAM role session with temporary credentials is preferred over a long-lived IAM user.
2. Register the server with aws deploy register-on-premises-instance.
3. Tag it with aws deploy add-tags-to-on-premises-instances.
4. Install the agent and place the on-premises configuration file with the credentials and region.
5. Point a deployment group at the tag and run a deployment.

The server needs outbound HTTPS to the CodeDeploy and S3 endpoints. Each instance update is billed at a small per-update rate.

On Linux you download the installer from the regional CodeDeploy S3 bucket and run it, or let Systems Manager do it. The console can create an AWS Systems Manager association that installs the agent and keeps it updated.

sudo yum update -y
sudo yum install -y ruby wget
cd /home/ec2-user
wget https://aws-codedeploy-us-east-1.s3.us-east-1.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent status

Replace the region in the URL with your own. For Auto Scaling groups, bake the agent into the AMI or install it from user data in the launch template, otherwise new instances cannot receive deployments.

On Linux instances the agent writes three main logs:

On Windows the logs are under C:\ProgramData\Amazon\CodeDeploy\log. Start with scripts.log when a hook fails, since it contains the stdout and stderr of your scripts. To avoid logging in to servers, ship these files to CloudWatch Logs with the CloudWatch agent.

The console also lists every lifecycle event with its status and error message, and aws deploy get-deployment-instance returns the same per-event detail from the CLI. If the logs are too quiet, enable the :verbose: setting in codedeployagent.yml and restart the agent.

There is no additional charge for deployments to EC2, Lambda and ECS. You only pay for the underlying resources, such as the instances and the S3 storage for revisions.

For on-premises servers, CodeDeploy charges $0.02 per on-premises instance update. A deployment to three instances is three updates, and instances that are skipped are not charged. Check the AWS pricing page for current rates, since prices can change by Region.

The real cost driver is usually what surrounds CodeDeploy. A blue/green EC2 deployment runs two fleets at once, so shortening the wait before original instances are terminated saves money. CloudWatch alarms, Lambda hook invocations and S3 requests are billed by their own services.

An in-place deployment updates the application on the instances that are already running. A blue/green deployment builds a replacement environment, moves traffic to it and then retires the original.

Choose in-place for on-premises servers, stateful hosts or tight budgets. Choose blue/green for customer-facing production where fast rollback and untouched capacity matter more than temporary extra cost.

In an in-place deployment the agent walks through a fixed sequence of events on every instance. Your scripts hang off the events in the middle.

flowchart LR
  A[ApplicationStop] --> B[DownloadBundle]
  B --> C[BeforeInstall]
  C --> D[Install]
  D --> E[AfterInstall]
  E --> F[ApplicationStart]
  F --> G[ValidateService]

1. ApplicationStop - stops the running app, using the script from the previous revision.
2. DownloadBundle - the agent fetches the revision.
3. BeforeInstall - backups, cleanup, dependency prep.
4. Install - the agent copies files to their destinations.
5. AfterInstall - configuration, file permissions, migrations.
6. ApplicationStart - starts the new version.
7. ValidateService - health or smoke checks.

When a load balancer is attached, BeforeBlockTraffic, BlockTraffic and AfterBlockTraffic run first, and BeforeAllowTraffic, AllowTraffic and AfterAllowTraffic run last. DownloadBundle, Install, BlockTraffic and AllowTraffic are handled by the agent and cannot run your scripts.

A blue/green deployment on EC2 creates the new ("green") instances, installs the revision on them, and only then moves load balancer traffic away from the old ("blue") instances.

flowchart TD
  A["Provision replacement instances"] --> B["Install revision and run hooks"]
  B --> C{Wait for approval?}
  C -- Yes --> D["Manual reroute approval"]
  C -- No --> E["Register replacement instances with load balancer"]
  D --> E
  E --> F["Deregister original instances"]
  F --> G["Terminate or keep originals after wait time"]

Replacement instances are either created by copying the Auto Scaling group or chosen from tagged instances you launched yourself. The regular install events run on them, followed by BeforeAllowTraffic, AllowTraffic and AfterAllowTraffic.

The original instances run BeforeBlockTraffic, BlockTraffic and AfterBlockTraffic when they are taken out of rotation. They can be terminated after a configurable wait, or kept for debugging.

The agent exposes a few variables to every hook script on EC2/on-premises: APPLICATION_NAME, DEPLOYMENT_ID, DEPLOYMENT_GROUP_NAME, DEPLOYMENT_GROUP_ID and LIFECYCLE_EVENT.

The most useful one is DEPLOYMENT_GROUP_NAME, because it lets one revision behave differently in each environment without rebuilding it.

#!/bin/bash
set -e
case "$DEPLOYMENT_GROUP_NAME" in
  prod)    cp config/prod.env /var/www/app/.env ;;
  staging) cp config/staging.env /var/www/app/.env ;;
  *)       cp config/dev.env /var/www/app/.env ;;
esac
echo "$LIFECYCLE_EVENT finished for $DEPLOYMENT_ID" >> /var/log/app-deploy.log

This keeps the artifact identical across environments, which is what you want when promoting a tested build.

Minimum healthy hosts is the number or percentage of instances that must stay healthy during an EC2/on-premises deployment. CodeDeploy uses it to decide how many instances it can take offline at once, and whether the deployment as a whole succeeded.

An instance counts as healthy when its last deployment succeeded. An instance being updated is temporarily treated as unavailable, so the batch size is the fleet size minus the required healthy count. With 10 instances and a 70 percent minimum, at most three are updated at a time.

If too many instances fail, the deployment stops with a HEALTH_CONSTRAINTS error. If the requirement cannot be met at all, for example 100 percent healthy on an in-place deployment, the deployment fails before doing useful work.

When a load balancer is attached to the deployment group, CodeDeploy takes each instance out of rotation before updating it and puts it back afterwards, so users do not hit a half-updated host.

1. BlockTraffic deregisters the instance from the target group or Classic Load Balancer and waits for connection draining.
2. The revision is installed and the application is restarted.
3. AllowTraffic registers the instance again, and the load balancer health check decides whether it counts as healthy.

The catch is timing. The target group's deregistration delay (300 seconds by default) is applied to every instance, so a long delay multiplies across batches. Lower it if your requests are short. Application Load Balancers and Network Load Balancers use target groups, while Classic Load Balancers are attached by name.

You can attach one or more Auto Scaling groups to a deployment group instead of, or alongside, tags. CodeDeploy then deploys to every instance in the group and keeps future instances in sync.

On attach, CodeDeploy adds a managed launch lifecycle hook to the Auto Scaling group. When the group scales out, the new instance is held in a pending state while CodeDeploy installs the last successful revision. Only after that does the instance go in service, so it never serves traffic without the application.

For blue/green deployments CodeDeploy copies the Auto Scaling group, deploys to the copy, reroutes traffic, and later deletes the original.

The AMI or launch template must already contain the CodeDeploy agent, and the service role needs Auto Scaling permissions.

You can enable automatic rollback on a deployment group for two triggers: a deployment failure and a CloudWatch alarm threshold being reached.

The mechanics depend on the platform:

• EC2/on-premises in-place - CodeDeploy starts a new deployment of the last known good revision, with a new deployment ID. Files from the failed revision are removed.
• EC2 blue/green - traffic is sent back to the original instances, if they have not been terminated.
• Lambda and ECS - traffic is shifted back to the original version or task set.

Rollback needs something to roll back to. If there has never been a successful deployment, or the old revision was deleted from S3, the rollback itself fails. You can also stop a deployment manually and choose to roll back.

You can attach up to 10 CloudWatch alarms to a deployment group. If any of them goes into the ALARM state while a deployment is running, CodeDeploy stops the deployment, and with automatic rollback enabled for alarms it then rolls back.

Pick alarms that measure user impact, such as 5xx count, p99 latency, or Lambda errors for the new version. Combined with a canary configuration, a small share of traffic exposes the problem before most users see it.

The service role needs permission to read alarm state. The option ignore poll alarm failure decides whether the deployment continues when CodeDeploy cannot retrieve an alarm's status, so set it deliberately.

There are three common ways, and they can be combined.

• Triggers on the deployment group publish deployment and instance events (start, success, failure, stop, rollback, ready) to an SNS topic. The topic policy must allow CodeDeploy to publish.
• EventBridge rules match events such as CodeDeploy Deployment State-change Notification and route them to Lambda, SQS or Step Functions.
• Notification rules in the Developer Tools console send selected events to SNS or to Slack and Microsoft Teams through AWS Chatbot.

Use EventBridge when you need to react to a deployment automatically, for example opening a ticket on failure. Use triggers or notification rules when people just need to be told.

CodeDeploy only deploys code onto compute you already manage. Elastic Beanstalk is a platform service that provisions the environment (instances, load balancer, scaling) and deploys your application on it.

Choose CodeDeploy when you already own the infrastructure or need on-premises and serverless targets. Choose Beanstalk when you want the platform handled for you.

CodePipeline orchestrates the whole release workflow: source, build, test, approval and deploy stages. CodeDeploy does one job within that workflow, which is applying a revision to the target compute.

A typical flow is Source (repository), Build (CodeBuild creates the zip with appspec.yml), then a Deploy stage whose action calls CodeDeploy. The pipeline passes its output artifact to CodeDeploy as the revision.

They are independent. You can run CodeDeploy from the CLI or another CI system without CodePipeline, and CodePipeline can deploy using other providers such as CloudFormation or Elastic Beanstalk.

CodeDeploy does not upload your function code. You publish a new function version first, and CodeDeploy then moves an alias from the current version to the target version by adjusting its weighted routing.

flowchart LR
  A["Publish new version"] --> B["BeforeAllowTraffic hook"]
  B --> C["Shift alias weight to new version"]
  C --> D["AfterAllowTraffic hook"]
  D --> E["Alias at 100 percent new version"]
  C -. alarm or hook failure .-> F["Shift back to old version"]

version: 0.0
Resources:
  - OrdersFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "orders-api"
        Alias: "live"
        CurrentVersion: "6"
        TargetVersion: "7"
Hooks:
  - BeforeAllowTraffic: "PreTrafficCheck"
  - AfterAllowTraffic: "PostTrafficCheck" 

The deployment configuration decides whether the shift is canary, linear or all at once. Callers must invoke the alias, not a fixed version, or the shift has no effect.

Both shift traffic gradually on Lambda and ECS. Canary sends a small share first, waits, then moves the rest in one step. Linear moves traffic in equal increments at fixed intervals until it reaches 100 percent.

Canary suits a quick go/no-go decision from one small sample. Linear suits services where load-related problems appear gradually. Pair either with alarms so a bad release stops automatically.

ECS deployments are always blue/green. CodeDeploy creates a replacement task set running the new task definition, routes traffic to it in steps, then retires the original task set.

It requires an Application or Network Load Balancer with two target groups, a production listener and optionally a test listener, plus an ECS service that uses the CODE_DEPLOY deployment controller.

flowchart TD
  A["Create replacement task set"] --> B["Register with green target group"]
  B --> C["Route test traffic via test listener"]
  C --> D["AfterAllowTestTraffic hook"]
  D --> E["Shift production traffic per configuration"]
  E --> F["Terminate original task set after wait time"]

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:us-east-1:111122223333:task-definition/web:7"
        LoadBalancerInfo:
          ContainerName: "web"
          ContainerPort: 8080
Hooks:
  - AfterAllowTestTraffic: "SmokeTestFunction" 

The test listener lets a Lambda hook exercise the new tasks before any real user traffic reaches them.

Lambda and ECS do not run shell scripts. Each hook in the AppSpec file names a Lambda function that CodeDeploy invokes, and the function reports success or failure back.

A failed hook stops the deployment and triggers a rollback if it is enabled.

A validation hook is a Lambda function that tests the new version, then calls PutLifecycleEventHookExecutionStatus with Succeeded or Failed. If it never reports, the deployment waits and eventually fails.

import boto3

codedeploy = boto3.client("codedeploy")
lam = boto3.client("lambda")

def handler(event, context):
    status = "Succeeded"
    try:
        resp = lam.invoke(FunctionName="orders-api", Qualifier="7",
                          Payload=b'{"smoke": true}')
        if resp["StatusCode"] != 200 or "FunctionError" in resp:
            status = "Failed"
    except Exception:
        status = "Failed"

    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=event["DeploymentId"],
        lifecycleEventHookExecutionId=event["LifecycleEventHookExecutionId"],
        status=status,
    )

Two permissions are needed. The hook function's role must allow codedeploy:PutLifecycleEventHookExecutionStatus, and the CodeDeploy service role must be allowed to invoke the hook function. Test the new version, not the alias, since the alias still points at the old code in BeforeAllowTraffic.

AWS SAM wraps CodeDeploy for Lambda through the DeploymentPreference property. Add an AutoPublishAlias so every deployment publishes a version and moves the alias, and SAM creates the CodeDeploy application, deployment group and service role for you.

Resources:
  OrdersFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.12
      AutoPublishAlias: live
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref OrdersErrorsAlarm
        Hooks:
          PreTraffic: !Ref PreTrafficCheckFunction
          PostTraffic: !Ref PostTrafficCheckFunction

The Type accepts the same canary, linear and all-at-once names. Alarms trigger rollback, and the hooks map to BeforeAllowTraffic and AfterAllowTraffic. SAM expects hook function names to start with CodeDeployHook_, which is how it scopes the permissions it grants them.

file_exists_behavior decides what happens when a file from your revision is already present at the destination on an EC2/on-premises instance and was not put there by a previous deployment.

aws deploy create-deployment ... --file-exists-behavior OVERWRITE

You can set it per deployment in the CLI or console, or at the top level of the AppSpec file. Use OVERWRITE for the first deployment onto a server with files copied by hand, and RETAIN for files such as local configuration that must survive releases.

A deployment group can identify EC2 or on-premises instances with up to three tag groups. The matching rule has two levels.

• Inside one tag group, an instance matches if it has any of the listed tags (OR).
• Across tag groups, an instance must match at least one tag in every group (AND).

Use consistent tag keys, since a typo silently removes an instance from the deployment group and it keeps running the old revision.

The deployment fails on that instance at the ApplicationStop event, and the rest of the lifecycle never runs. The subtle part is which script ran. The agent uses the ApplicationStop script from the last successfully deployed revision, not from the revision you are deploying now.

A bug in an old stop script therefore blocks every new deployment, even if the new revision already contains the fix. On the very first deployment there is no previous revision, so the event is skipped.

Ways out of the trap:

1. Redeploy with --ignore-application-stop-failures so the failure is ignored once.
2. Fix the cached script on the instance, then retry.
3. Write stop scripts to be idempotent, for example tolerate an already-stopped process with || true.

aws deploy create-deployment \
  --application-name web-app --deployment-group-name prod \
  --s3-location bucket=my-bucket,key=web-app-v13.zip,bundleType=zip \
  --ignore-application-stop-failures

The outcome depends on the deployment configuration. CodeDeploy marks the failing instance as Failed and then checks whether the minimum healthy hosts rule can still be met.

In-place updates are not atomic, so the failed instance may be left with a partly installed revision. Automatic rollback redeploys the last good revision, while --update-outdated-instances-only lets a retry target only the instances that are not yet on the new revision.

Work from the outside in: error code first, then the agent, then scripts.

1. Open the deployment in the console and read the error code and message on the failed event.
2. Confirm the agent is running: sudo service codedeploy-agent status.
3. Read codedeploy-agent.log and the deployment's scripts.log for the real script error.
4. Check the instance profile and S3 bucket policy if the revision download returns 403.
5. Check that appspec.yml is at the bundle root and is valid YAML.
6. Check disk space, since the agent keeps several old revisions.

The message reads roughly: the overall deployment failed because too many individual instances failed, too few healthy instances were available, or some instances are experiencing problems. It means CodeDeploy could not honor the minimum healthy hosts rule.

HEALTH_CONSTRAINTS usually means too many instances failed and the threshold was crossed. HEALTH_CONSTRAINTS_INVALID means the requirement could not be met at all, for example the configuration needs more healthy hosts than the group can keep.

1. List instance statuses with aws deploy list-deployment-instances and inspect the failed ones first.
2. Fix the underlying hook failure on those instances; one bad script often fails the whole batch.
3. Check for instances that were already unhealthy before the deployment started, because they count against the minimum.
4. Review the minimum healthy hosts value. A fleet of three with a 70 percent minimum can only update one host at a time.
5. Add capacity or lower the threshold only after the root cause is fixed.

Security for CodeDeploy is mostly about who can start a deployment, who can read the revision, and what the scripts can do.

• Least privilege on the instance profile. Limit S3 read access to the revision bucket and prefix, and add kms:Decrypt if the bucket uses SSE-KMS.
• Protect the revision bucket. Enable versioning, block public access and restrict write access, because whoever can write a revision can run code as root on your servers.
• Limit deployment permissions. Scope codedeploy:CreateDeployment to specific applications and groups, and require approvals before production.
• Keep secrets out of bundles. Read them at run time from Secrets Manager or Parameter Store.
• Run scripts with the right user. Use runas rather than defaulting to root where possible.
• Harden the network path. Use VPC interface endpoints for private subnets, and enforce IMDSv2 on instances.
• Audit. CloudTrail records CodeDeploy API calls and EventBridge can alert on unexpected deployments.

The agent is pull-based. It polls CodeDeploy over HTTPS (port 443) for commands, so the instance needs no inbound ports and CodeDeploy never logs in to it.

sequenceDiagram
  participant A as CodeDeploy agent
  participant C as CodeDeploy service
  participant S as S3 or GitHub
  A->>C: PollHostCommand
  C-->>A: Command for deployment
  A->>C: PutHostCommandAcknowledgement
  A->>S: Download revision
  A->>A: Run lifecycle hooks
  A->>C: PutHostCommandComplete

Instance credentials from the instance profile sign these calls. In a private subnet with no internet route, create the interface VPC endpoints com.amazonaws.<region>.codedeploy-commands-secure and, for API calls, com.amazonaws.<region>.codedeploy, plus S3 access for the revision download.

Since the agent starts every connection, the firewall only needs outbound 443. If polling fails, for example because of a proxy, the instance never picks up its command and the deployment stalls on that host. Set :proxy_uri: in codedeployagent.yml when a proxy is required.

When Auto Scaling launches an instance in the middle of a deployment, the new instance is given the last successful revision, not the revision that is being deployed. It can therefore end up outdated while the deployment group reports success.

The deployment group setting outdatedInstancesStrategy controls the follow-up:

• UPDATE - CodeDeploy starts a follow-on deployment to bring the new instances to the latest revision.
• IGNORE (default) - the outdated instances are left as they are until the next deployment.

aws deploy update-deployment-group \
  --application-name web-app --current-deployment-group-name prod \
  --outdated-instances-strategy UPDATE

You can also run a deployment with --update-outdated-instances-only to touch only instances that are not on the target revision. Avoid large scaling events during a release where possible.

CodePipeline hands the output of earlier stages to CodeDeploy as the revision, then waits for the deployment result.

flowchart LR
  A["Source stage"] --> B["Build stage: CodeBuild creates zip with appspec.yml"]
  B --> C["Optional manual approval"]
  C --> D["Deploy stage: CodeDeploy action"]
  D --> E["CodeDeploy runs deployment group"]
  E --> F["Result returned to pipeline"]

1. A commit starts the pipeline and the source artifact is stored in the pipeline's S3 bucket.
2. CodeBuild builds and produces an artifact that contains appspec.yml and scripts at the root.
3. The deploy action is configured with an application name and deployment group, then calls CreateDeployment with the artifact.
4. CodeDeploy runs the deployment, and its success or failure becomes the stage result.

For ECS blue/green the deploy action is Amazon ECS (Blue/Green). It takes taskdef.json and appspec.yaml as inputs and replaces an image placeholder such as <IMAGE1_NAME> with the new image. The pipeline's role needs CodeDeploy permissions such as codedeploy:CreateDeployment.

CloudFormation has two resource types for this: AWS::CodeDeploy::Application and AWS::CodeDeploy::DeploymentGroup. The application sets the compute platform (Server, Lambda or ECS), and the deployment group holds targets and safety settings.

Resources:
  App:
    Type: AWS::CodeDeploy::Application
    Properties:
      ApplicationName: web-app
      ComputePlatform: Server

  ProdGroup:
    Type: AWS::CodeDeploy::DeploymentGroup
    Properties:
      ApplicationName: !Ref App
      DeploymentGroupName: prod
      ServiceRoleArn: !GetAtt CodeDeployRole.Arn
      DeploymentConfigName: CodeDeployDefault.HalfAtATime
      AutoScalingGroups:
        - !Ref WebAsg
      AutoRollbackConfiguration:
        Enabled: true
        Events:
          - DEPLOYMENT_FAILURE
          - DEPLOYMENT_STOP_ON_ALARM
      AlarmConfiguration:
        Enabled: true
        Alarms:
          - Name: !Ref Http5xxAlarm

CloudFormation only creates these objects. The revision is still deployed by CodeDeploy itself. For ECS blue/green releases driven by CloudFormation, the AWS::CodeDeployBlueGreen transform lets a stack update trigger a CodeDeploy blue/green deployment.

Most of the time in an EC2 deployment goes to batch size, load balancer draining and slow scripts, not to CodeDeploy itself.

• Use a larger batch. Move from OneAtATime to HalfAtATime or a custom percentage once alarms and rollback protect you.
• Shorten the deregistration delay. A 300-second default is paid for every instance and every batch.
• Keep the bundle small. Exclude tests and build caches, and download dependencies from a nearby mirror.
• Bake heavy setup into the AMI. Runtimes, packages and OS patches belong in the image, not in BeforeInstall.
• Make hooks fast. Replace fixed sleep calls with a health check loop that exits early.
• Choose blue/green where it fits. The replacement environment is built while the old one still serves traffic.
• Clean old revisions. The agent keeps a limited number of archives, so check disk on small volumes.

Measure first. The deployment events in the console show how long each lifecycle event took, so the slowest one tells you where to spend the effort.