DVA-C03 CI/CD: CodePipeline, CodeDeploy, ECS/EKS Deployments, Strategies and Rollback

A Lambda function is deployed either as a .zip archive (optionally with layers) or as a container image stored in Amazon ECR, and the right choice follows mostly from size and from how often each part of the package changes. The size quotas are fixed: they cannot be raised through Service Quotas.

Uploading through S3 lifts only the 50 MB zipped limit; it does nothing for the 250 MB unzipped limit. Past that, the answer is a container image, not more layers (layers count toward the same 250 MB) and not ephemeral storage (that is /tmp space at run time, not package size). Mounting dependencies from Amazon EFS also works around size, but it splits the dependencies from the versioned deployment artifact.

Layers make code deployments smaller

A layer is a .zip archive that Lambda extracts into /opt in the execution environment. Putting third-party libraries that change rarely into a layer means they are uploaded once per layer version, while each code deployment uploads only the handler code. Layer versions are immutable and functions reference a specific version ARN:

• Publishing a new layer version changes no function. Each function's configuration (the Layers property in SAM or CloudFormation) must be updated to the new version ARN, and then versions and aliases moved forward.
• Deleting a layer version does not remove it from functions that already use it. They keep running the old content; only new attachments are blocked.
• Container image functions cannot use layers. Copy the dependencies into the image at build time instead.

Container image functions: two behaviours that catch people out

• Lambda resolves the image when you set the function code. When you create or update the function with an image URI, Lambda resolves the tag to a specific image and prepares it. Pushing a rebuilt image to the same tag changes nothing, even on new execution environments, and publishing a version or moving an alias keeps the old image. Call update-function-code --image-uri (or deploy a template whose ImageUri changes) to deploy it.
• Package type is fixed at creation. An existing .zip function cannot be converted to an image function, or the reverse. Create a new function with PackageType: Image from an ECR repository in the same Region (it can be in another account with the right permissions), then point every trigger (an API Gateway integration, an event source mapping) at the new function and give it the invoke permissions the old one had.

Building, tagging and storing the image in ECR belong to Task 3.1 and are covered in the deployment-artifacts lesson; this lesson is about getting that artifact running.

Infrastructure as code (IaC) deploys an application by submitting a template to AWS CloudFormation, which creates or updates a stack; AWS SAM is a CloudFormation extension (the AWS::Serverless transform) with shorthand for functions, APIs and tables plus a CLI. The deployment mechanics that matter are previewing, packaging and permissions.

• Change sets preview an update. A change set lists, per resource, whether the update will add, modify or remove it and, for a modification, whether CloudFormation must replace it. Nothing changes until you execute it, so it is how you confirm a database will not be replaced. Drift detection compares live resources with the current template, validate-template checks syntax only, and a stack policy blocks updates but gives no preview.
• Packaging turns local paths into AWS locations. During development CodeUri: ./src points at a folder on your machine, which CloudFormation cannot read. sam package uploads each local artifact to S3, pushes image functions to ECR (with --image-repository), and writes a new template with those locations; aws cloudformation package does the S3 part only. A pipeline passes this packaged template to its CloudFormation deploy action. sam build prepares dependencies but keeps local paths. sam deploy packages and deploys in one step from a workstation or build job.
• Capabilities acknowledge risky changes. A template that creates IAM resources needs CAPABILITY_IAM (or CAPABILITY_NAMED_IAM for custom names), and one that uses macros or nested applications needs CAPABILITY_AUTO_EXPAND. A pipeline's deploy action must pass them too.

sam sync for development, sam deploy or a pipeline for production

sam sync compares your local project with a deployed development stack. For code-only changes it updates resources such as Lambda function code directly through service APIs instead of creating a CloudFormation change set, so an edit is running in the cloud within seconds; --watch does this every time you save. Infrastructure changes still go through CloudFormation. Because these shortcuts let the stack drift from the template, AWS recommends sam sync only for development; production stays on sam deploy or a pipeline. sam local runs code on your laptop, not in the stack, and is a testing tool (Task 3.2).

An Amazon ECS deployment updates a service to run a new task definition revision: the task definition describes the containers (image, CPU, memory, ports, environment, roles, log configuration), each change registers a new numbered revision, and the service replaces its running tasks with tasks from the new revision.

Task definitions for Fargate

• Network mode must be awsvpc. Each Fargate task gets its own elastic network interface and private IP. Bridge and host modes depend on an EC2 container instance, which Fargate does not expose, and an empty network mode defaults to bridge on Linux, so it fails validation too.
• CPU and memory are set at task level, from the supported Fargate combinations.
• Two roles with different jobs. The task execution role is used by the ECS agent and Fargate to pull images from private ECR, send logs with the awslogs driver and fetch secrets for injection (the managed policy AmazonECSTaskExecutionRolePolicy covers the ECR and log actions). The task role is assumed by your application code for its own AWS calls. ECR pull permissions on the task role do not help a task that cannot start.
• Tasks need a network path to ECR. In private subnets with no NAT gateway, create interface endpoints com.amazonaws.<region>.ecr.api and com.amazonaws.<region>.ecr.dkr plus an S3 gateway endpoint (image layers are stored in S3), and a CloudWatch Logs endpoint if the task uses awslogs. A public IP is no use in a subnet without an internet gateway route. A CannotPullContainerError means one of these two pieces, permissions or path, is missing.

Rolling updates

The default ECS deployment strategy is the rolling update, controlled by two percentages of the service's desired count:

• minimumHealthyPercent (rounded up): the floor of running, healthy tasks during the deployment.
• maximumPercent (rounded down): the ceiling of running plus pending tasks.

The defaults (100/200) start new tasks first, which needs spare capacity. With no spare capacity on an EC2 cluster, set maximumPercent to 100 and lower minimumHealthyPercent so ECS can stop old tasks before starting new ones; choose a value that still keeps the number of tasks you need (minimumHealthyPercent rounds up: with 6 tasks, 50% keeps 3 running and 67% keeps 5). 100/100 can never make progress.

Why a pushed image does not reach running tasks

When a deployment starts, ECS resolves the image tag in the task definition to an image digest and uses that digest for every task the deployment launches, including replacements and scale-out. Pushing a new image under the same tag (latest, prod) therefore changes nothing: stopping tasks or raising the desired count still runs the old build. Either register a new revision with the new tag or digest, or update the service with force new deployment (--force-new-deployment), which starts a deployment and resolves the tag again. Tag immutability in ECR prevents the situation but deploys nothing.

Amazon ECS can run a deployment itself with four strategies set in the service's deploymentConfiguration: ROLLING (the default), BLUE_GREEN, LINEAR and CANARY. The older model, in which AWS CodeDeploy controls an ECS blue/green deployment through a deployment group and an AppSpec file, still exists.

The general rule: each ECS-native strategy is configured on the service itself, so its checks (lifecycle hooks), safety window (bake time) and rollback live in the service's deployment configuration. Reach for CodeDeploy only when the team already standardises on CodeDeploy deployment groups and AppSpec files across compute platforms.

Circuit breaker versus deployment alarms

The two failure detectors for rolling updates watch different things:

• The deployment circuit breaker watches whether new tasks reach a steady state. When they keep failing to start or failing health checks (for example an image tag that cannot be pulled, or a health check path the new version no longer serves), it marks the deployment FAILED and stops launching tasks; with rollback on, ECS returns the service to the last completed deployment. Without it, ECS can keep retrying for hours while the old tasks serve.
• CloudWatch deployment alarms (alarms with alarm names, enable and rollback) catch failures that only show in metrics. Tasks that start and pass their health checks never trip the circuit breaker, however many application errors they return afterwards; an alarm on a metric that shows the errors (for example the load balancer's target 5XX count or a latency percentile) does. ECS watches the alarms during the deployment and its bake time and fails (and optionally rolls back) the deployment if one enters ALARM.

Both can be enabled together, and either one can fail the deployment. Changing the minimum/maximum percent or the health-check timings does not make a bad release roll back.

On Amazon EKS, an application is deployed by applying Kubernetes manifests (for example with kubectl apply, Helm, or a pipeline step that runs them); a Deployment manifest declares the pod template (image, resources, probes) and the number of replicas, and Kubernetes rolls the change out.

RollingUpdate settings and probes

• strategy.type: RollingUpdate (the default) replaces pods gradually; Recreate stops all old pods first, which causes downtime.
• maxUnavailable: how many desired pods may be unavailable during the rollout. maxSurge: how many extra pods may run above the replica count. Both accept a number or a percentage (default 25% each).
• For zero lost capacity, set maxUnavailable: 0 and maxSurge of at least 1: Kubernetes adds a new pod and removes an old one only when the new pod is ready.
• A readinessProbe defines "ready": until it passes, the pod is not added to the Service's endpoints and does not count as available, so traffic waits for the application to finish loading. A livenessProbe only restarts a container that has stopped responding; it does not gate traffic. A startupProbe holds off liveness checks while a slow application starts.

Rollout commands

After an undo, the manifest in source control still holds the bad version; fix or revert it there so the next apply does not redeploy it.

AWS CodeDeploy deploys an application revision to a deployment group on one of three compute platforms, following the steps in an AppSpec file: EC2/on-premises (in-place or blue/green, with the CodeDeploy agent on each instance), AWS Lambda (shifting a function alias between versions) and Amazon ECS (blue/green between task sets).

Lifecycle hooks by platform

• EC2: stop the application gracefully in ApplicationStop, before any new files arrive, and decide success in ValidateService, the last event. DownloadBundle and Install are reserved for the agent and cannot run scripts. Traffic hooks are skipped when the deployment group has no load balancer.
• ApplicationStop runs the previous revision's script. It happens before the new revision is downloaded, so the agent uses the AppSpec and scripts of the last successful deployment on that instance. If that script is broken, fixing it in the new revision cannot help; create the deployment with the option to ignore ApplicationStop failures (--ignore-application-stop-failures) once, and the fixed script is used from then on.
• ECS: CodeDeploy can route a test listener (a second listener on its own port) to the replacement task set; AfterAllowTestTraffic runs once it does, so integration checks there can stop the deployment before production traffic moves.
• Lambda and ECS hooks are Lambda functions that must report back with PutLifecycleEventHookExecutionStatus (Succeeded or Failed); a Failed status stops the deployment and triggers rollback if it is configured.

Deployment configurations

• EC2/on-premises: CodeDeployDefault.OneAtATime, HalfAtATime, AllAtOnce, or a custom configuration with a minimum number or percentage of healthy hosts. A custom configuration states the floor directly: a minimum of 75% healthy hosts on 8 instances lets CodeDeploy take 2 out of service at a time.
• Lambda: LambdaCanary10Percent5Minutes (and other canary intervals), LambdaLinear10PercentEvery1Minute (and others), LambdaAllAtOnce.
• ECS: the matching ECSCanary…, ECSLinear… and ECSAllAtOnce configurations.

Canary and linear configurations exist only for Lambda and ECS, never for EC2 in-place deployments.

A deployment strategy decides how much of the old version keeps running while the new one takes traffic, which sets the trade-off between speed, cost, risk and how fast you can roll back.

Gradual Lambda deployments with AWS SAM

For Lambda, traffic shifting happens on an alias that points at two versions with weights. AWS SAM sets the whole thing up from the function definition:

• AutoPublishAlias: live publishes a new version whenever the code changes and points the alias at it.
• DeploymentPreference with a Type such as Canary10Percent10Minutes (10% for 10 minutes, then 100%), Linear10PercentEvery10Minutes (10% more every 10 minutes) or AllAtOnce makes SAM create the CodeDeploy application and deployment group.
• Alarms lists CloudWatch alarms; if one fires during the shift, CodeDeploy rolls the alias back.
• Hooks: PreTraffic runs before any traffic moves (test the new version first) and PostTraffic after the shift completes. Each hook function must call back to CodeDeploy with Succeeded or Failed.

Setting an alias's routing configuration by hand gives a fixed split but no timed promotion, alarms or hooks.

Other places strategies appear

• ECS: ROLLING, BLUE_GREEN, LINEAR and CANARY strategies (previous sections), or CodeDeploy ECS configurations.
• EKS: RollingUpdate in the Deployment; blue/green and canary are built from two Deployments and a Service or ingress that moves traffic between them.
• API Gateway REST APIs: a stage can carry a canary release that sends a percentage of the stage's traffic to a new deployment, which you then promote or remove.
• EC2 with CodeDeploy: in-place rolling (OneAtATime, HalfAtATime) or blue/green to a replacement fleet behind the load balancer.

AWS CodePipeline orchestrates a release as a sequence of stages (source, build, test, one per environment) made of actions that pass artifacts through an S3 artifact store; it starts from a change in a linked code repository and moves each change towards production. DVA-C03 expects you to configure and operate a pipeline (triggers, approvals, execution modes, cross-account access), not to design CI/CD architecture.

Starting a pipeline from a linked repository

GitHub, GitLab and Bitbucket repositories are linked through an AWS CodeConnections connection (formerly CodeStar Connections). In a V2 pipeline, triggers decide which Git events start it:

• Push filters on Git tags, on branches, or on branches plus file paths (tags and file paths cannot be combined).
• Pull request filters on branches, or branches plus file paths, for events such as opened, updated or closed.
• Include and exclude glob patterns (for example tags release-*, branches release/**, file paths services/orders/** for a monorepo).
• Adding a filter replaces the default behaviour of starting on any push to the source action's BranchName; that branch is still what a manual start uses.

Source control features for versions and releases

• Tags (labels) mark a specific commit as a release, such as release-2026.11. A tag-filtered push trigger turns "push a release tag" into "start the release pipeline", while everyday branch pushes do not.
• Branches separate lines of work: feature branches for preview deployments, a main branch for integration, release branches for stabilising a version. Branch filters route each to the right pipeline.
• Pull requests are where review happens; a PR trigger can build and test a change before it is merged.
• Tagging the deployed artifact with the commit ID or release tag (image tags are Task 3.1) keeps every environment traceable back to source.

Promoting through environments

• One stage per environment (Test, Staging, Prod) with the same deploy action and environment-specific parameters.
• A manual approval action before production stops the pipeline until someone with codepipeline:PutApprovalResult approves. It can publish to an Amazon SNS topic (email and other subscribers) with a review URL and comments. A rejection, or no answer within seven days, counts as a failed action, so the change goes no further. Disabling a stage transition also holds changes but sends no notification and records no sign-off.
• Cross-account deployment: the pipeline in a tooling account assumes a role in the target account. That role must read the input artifact, which needs an S3 bucket policy granting it access and artifact encryption with a customer managed KMS key whose key policy lets the target account decrypt. The default AWS managed aws/s3 key cannot be shared because its key policy cannot be changed.

Execution modes

A rollback returns an application to its last known good state, and each AWS deployment service does it in its own way: CloudFormation rolls back stack operations, CodeDeploy redeploys an earlier revision, ECS and EKS return a service to an earlier revision, and CodePipeline re-runs a stage with an earlier execution's artifacts.

AWS CodeDeploy

• A deployment group's automatic rollback can fire when a deployment fails (for example a hook script or a hook function reports failure), when alarm thresholds are met (CloudWatch alarms attached to the group, such as load balancer 5XX errors), or when a user stops a deployment and chose rollback for that case.
• A rollback is a new deployment, with a new deployment ID, of the last known good revision; it is not the failed deployment restored. A manual rollback is the same thing done by hand: deploy an earlier revision.
• CodeDeploy removes files the failed deployment installed but does not undo what hook scripts did (database changes, for instance), and it does not snapshot or restore instances.
• Deployment configurations and the "ignore poll alarm failure" option do not cause rollbacks.

AWS CloudFormation

• By default a failed create or update rolls back automatically.
• Rollback triggers extend this to problems that appear after resources are created: up to five CloudWatch alarm (or composite alarm) ARNs plus a monitoring time of 0–180 minutes. If an alarm goes to ALARM during the operation or the monitoring time afterwards, CloudFormation rolls the whole operation back. On updates it removes old resources only after a clean monitoring period.
• Preserve successfully provisioned resources (--disable-rollback, or --on-failure DO_NOTHING on create) keeps what succeeded; fix the cause and choose Retry (or update with a fixed template) to continue from the failure, or run rollback-stack to return to the last stable state. This speeds up iteration on development stacks.
• continue-update-rollback is for a different situation: a stack stuck in UPDATE_ROLLBACK_FAILED.
• CreationPolicy and UpdatePolicy handle resource signals and rolling instance replacement; they are not post-deployment alarm checks.

Containers and Lambda

• ECS: circuit breaker or deployment alarms with rollback on (automatic); blue/green bake time for a fast switch back; or update the service to the previous task definition revision (manual).
• EKS: kubectl rollout undo.
• Lambda: CodeDeploy alarm rollback during a SAM gradual deployment, or point the alias back at the previous version.

AWS CodePipeline stage rollback

• Manual: rollback-stage with the pipeline name, stage name and a target execution ID that succeeded in that stage starts a new execution of only that stage using the target's source revisions, artifacts and variables. It restores an earlier release in Prod without rebuilding, retesting or reverting commits. The target must come from the current pipeline structure version. retry-stage-execution reruns a failed stage with the same release, and starting an execution with a source revision override reruns every stage.
• Automatic (V2 stage conditions): an On Failure condition can ROLLBACK (or RETRY) a failed stage. An On Success condition can ROLLBACK or FAIL a stage that succeeded when its rules fail: a CloudWatchAlarm rule fails while the alarm is in ALARM, and its wait time is how long CodePipeline waits for the alarm to return to OK. An Entry condition can FAIL or SKIP a stage before it runs (for example outside a deployment window).
• Stage rollback is not available in PARALLEL execution mode.

AI tools support CI/CD by doing review and analysis work inside the pipeline, such as summarising what a change will deploy, drafting environment templates, and reading post-deployment test output; the pipeline's own controls (approvals, alarms, change sets, rollback) still decide whether a release proceeds. For DVA-C03 the in-scope AWS tool is Kiro, an AI development environment with a CLI.

Running Kiro CLI headless in a pipeline

• Headless mode runs the agent without a person: kiro-cli chat --no-interactive "<task>", for example in a CodeBuild action that reviews a change set or a diff and writes its findings to the build log.
• Authentication uses an API key in the KIRO_API_KEY environment variable instead of a browser login. Store the key in AWS Secrets Manager and inject it with the buildspec's env → secrets-manager section, so it never appears in the repository or build configuration as plain text.
• Tool permissions are granted up front because nobody is there to approve them. --trust-tools approves only the listed tools (for example file read and search for an analysis job); --trust-all-tools approves everything, including file writes and shell commands. Give the job the narrowest set it needs, and give the build role only the AWS permissions the job needs.

Where AI fits in the release flow

• Environment provisioning: an AI assistant can draft or update CloudFormation, SAM or CDK templates for a new environment. The output is ordinary IaC: review it, preview it with a change set and deploy it through the pipeline like any other change.
• Deployment approvals: an agent can produce the evidence a reviewer needs (what changed, test results, a change-set summary) and attach it to a manual approval, or run as a validation action that fails when checks fail. The approve/reject decision and its audit trail remain the pipeline's approval action.
• Post-deployment validation: after a deploy, an agent can run or analyse smoke tests and logs and report likely causes; a failing result fails the action, and stage conditions or CodeDeploy alarms handle the rollback.

AI test generation belongs to Task 3.2 and AI troubleshooting from logs to Task 4.1. Also note that the AWS Copilot CLI reached end of support on 12 June 2026; use task definitions, Lambda aliases, API Gateway stages and pipelines for environments instead of Copilot environments.