AWS CodeDeploy is a service that automates software deployments to a variety of compute services, such as Amazon EC2, AWS Lambda, and instances running on-premises. AWS CodeDeploy makes it easier for you to release new features rapidly, helps you avoid downtime through application deployment, and handles the complexity to update your applications. You can use AWS CodeDeploy to automate software deployments and eliminate the need for error-prone manual operations. The service scales to match your deployment needs, from a single AWS Lambda function to thousands of Amazon EC2 instances.
AWS CodeDeploy standardizes and automates deployments of any types of content or configuration to Amazon EC2 instances, on-premises servers, or AWS Lambda functions. Because of its flexibility, it is not restricted to deploy only application code, and it can perform various administrative tasks that are part of your deployment process. Additionally, you can create custom deployment configurations tailored to your specific infrastructure needs.
You can install and enable NGINX as part of a deployment of configuration files to reverse proxy instances. The service itself does not involve any changes to your current source code, and it only requires you to install a lightweight agent on any managed instances or on-premises servers.
Should deployments fail in your environment, you can configure AWS CodeDeploy with a predetermined failure tolerance. Once this tolerance is breached, deployment will automatically roll back to the last version that works. You can automate deployment of AWS CodeDeploy with AWS Lambda functions through traffic switching. When updates to functions deploy, AWS CodeDeploy will create new versions of each updated function and gradually route requests from the previous version to the updated function. AWS Lambda functions also support custom deployment configurations, which can specify the rate and percentage of traffic to switch.
When you deploy to Amazon EC2 on-premises instances, a revision occurs.
A revision is an artifact that contains both application files to deploy and an AppSpec configuration file. Application files can include compiled libraries, configuration files, installation packages, static media, and other content. The AppSpec file specifies what steps AWS CodeDeploy will follow when it performs deployments of an individual revision. A revision must contain any source files and scripts to execute on the target instance inside a root directory. Within this root directory, the appspec.yml file must exist at the topmost level and not in any subfolders.
/tmp/ or c:\temp (root folder)
|--content (subfolder)
| |--myTextFile.txt
| |--mySourceFile.rb
| |--myExecutableFile.exe
| |--myInstallerFile.msi
| |--myPackage.rpm
| |--myImageFile.png
|--scripts (subfolder)
| |--myShellScript.sh
| |--myBatchScript.bat
| |--myPowerShellScript.ps1
|--appspec.ymlWhen you deploy to AWS Lambda, a revision contains only the AppSpec fi le. It contains information about the functions to deploy, as well as the steps to validate that the deployment was successful. In either case, when a code revision is ready to deploy, you package it into an archive fi le and store it in one of these three repositories:
When you use GitHub or Bitbucket, the source code does not need to be a .zip archive, as AWS CodeDeploy will package the repository contents on your behalf. Amazon S3, however, requires a .zip archive file.
AWS Lambda deployments support only Amazon S3 buckets as a source repository.
A deployment is the process of copying content and executing scripts on instances in your deployment group. To accomplish this, AWS CodeDeploy performs the tasks outlined in the AppSpec confi guration fi le. For both Amazon EC2 on-premises instances and AWS Lambda functions, the deployment succeeds or fails based on whether individual AppSpec tasks complete successfully . There are two types of deployments supported by AWS CodeDeploy: in-place and blue/green.
In in-place deployments , revisions deploy to new infrastructure instead of an existing one. After deployment completes successfully, the new infrastructure gradually replaces old code in a phased rollout. After all traffi c routes to the new infrastructure, you can keep the old code for review or discard it.
In in-place deployments , revisions deploy to new infrastructure instead of an existing one. After deployment completes successfully, the new infrastructure gradually replaces old code in a phased rollout. After all traffi c routes to the new infrastructure, you can keep the old code for review or discard it.
On-premises instances do not support blue/green deployments.
When you deploy to AWS Lambda functions, blue/green deployments publish new versions of each function, after which traffi c shifting routes requests to the new function versions according to the deployment confi guration that you defi ne.
You can stop deployments via the AWS CodeDeploy console or AWS CLI. If you stop deployments to Amazon EC2 on-premises instances, this can result in some deployment groups being left in an undesired deployment state. For example, when you deploy to instances in an Auto Scaling group, if you stop the deployment, it may result in some instances having different application versions. In situations where this occurs, you can confi gure the application to roll back to the last valid deployment automatically. To do this, you submit a new deployment to the instances with the previous revision, and they appear as a new deployment in the console.
Some instances that fail the most recent deployment may still have scripts run or files placed that are part of the failed deployment. If you configure automatic rollbacks, AWS CodeDeploy will attempt to remove any successfully created files.
AWS CodeDeploy achieves automatic rollbacks by redeploying the last working revision to any instances in the deployment group (this will generate a new deployment ID). If you do not confi gure automatic rollbacks for the application, you can perform a manual rollback by redeploying a previous revision as a new deployment. This will accomplish the same result as an automatic rollback. During the rollback process, AWS CodeDeploy will attempt to remove any fi le(s) that were created on the instance during the failed deployment. A record of the created fi les is kept in the location on your instances.
Linux: /opt/codedeploy-agent/deployment-root/deployment-instructions/ [deployment-group-id]-cleanup Windows: C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\ [deployment-group-id]-cleanup
The AWS CodeDeploy agent that runs on the instance will reference this cleanup fi le as a record of what files were created during the last deployment.
By default, AWS CodeDeploy will not overwrite any files that were not created as part of a deployment. You can override this setting for new deployments.
AWS CodeDeploy tracks cleanup fi les; however, script executions are not tracked. Any confi guration or modifi cation to the instance that is done by scripts run on your instance cannot be rolled back automatically by AWS CodeDeploy. As an administrator, you will be responsible for implementing logic in your deployment scripts to ensure that the desired state is reached during deployments and rollbacks
If you would like to test whether a revision will successfully deploy to an instance you are able to access, you can use the codedeploy-local command in the AWS CodeDeploy agent. This command will search the execution path for an AppSpec fi le and any content to deploy. If this is found, the agent will attempt a deployment on the instance and provide feedback on the results. This provides a useful alternative to executing the full workfl ow when you want simply to validate the deployment package. The following example command attempts to perform a local deployment of an archive file located in Amazon S3: codedeploy-local --bundle-location s3://mybucket/bundle.tgz --type tgz
The codedeploy-local command requires the AWS CodeDeploy agent that you install on the instance or on-premises server where you execute the command.
A deployment group designates the Amazon EC2 on-premises instances that a revision deploys. When you deploy to AWS Lambda functions, this specifies what functions will deploy new versions. Deployment groups also specify alarms that trigger automatic rollbacks after a specified number or percentage of instances, or functions fail their deployment.
For Amazon EC2 on-premises deployments, you can add instances to a deployment group based on tag name/value pairs or Amazon EC2 Auto Scaling group names. An individual application can have one or more deployment groups defi ned. This allows you to separate groups of instances into environments so that changes can be progressively rolled out and tested before going to production. You can identify instances by individual tags or tag groups. If an instance matches one or more tags in a tag group, it is associated with the deployment group. If you would like to require that an instance match multiple tags, each tag must be in a separate tag group. A single deployment group supports up to 10 tags in up to three tag groups.
When you create deployment groups, you can also configure the following:
Amazon SNS notifications Any recipients that subscribe to the topic will receive notifications when deployment events occur. You must create the topic before you configure this notification, and the AWS CodeDeploy service role must have permission to publish messages to the topic.
Amazon CloudWatch alarms You can configure alarms to trigger cancellation and rollback of deployments whenever the metric has passed a certain threshold. For example, you could configure an alarm to trigger when CPU utilization exceeds a certain percentage for instances in an AWS Auto Scaling group. If this alarm triggers, the deployment automatically rolls back. For AWS Lambda deployments, you can configure alarms to monitor function invocation errors.
Automatic rollbacks You can configure rollbacks to initiate automatically when a deployment fails or based on Amazon CloudWatch alarms. To test deployments, you can disable automatic rollbacks when you create a new deployment.
You can host instances for an Amazon EC2 on-premises deployment group in either an AWS account or your own data center. To configure an on-premises instance to work with AWS CodeDeploy, you must complete several tasks. Before you begin, you need to ensure that the instance has the ability to communicate with AWS CodeDeploy service endpoints over HTTPS (port 443). You will also need to create an IAM user that the instance assumes and has permissions to interact with AWS CodeDeploy.
aws deploy register --instance-name AssetTag12010298EX \
--iam-user-arn arn:aws:iam::8039EXAMPLE:user/CodeDeployUser-OnPrem \
--tags Key=Name,Value=CodeDeloyDemo-OnPrem \
--region us-west-2aws deploy install --override-config \
--config-file /tmp/codedeploy.onpremises.yml \
--region us-west-2After you complete the previous steps, the instance will be available for deployments to the deployment group(s).
When you deploy to Amazon EC2 Auto Scaling groups, AWS CodeDeploy will automatically run the latest successful deployment on any new instances created when the group scales out. If the deployment fails on an instance, it updates to maintain the count of healthy instances. For this reason, AWS does not recommend that you associate the same Auto Scaling group with multiple deployment groups (for example, you want to deploy multiple applications to the same Auto Scaling group). If both deployment groups perform a deployment at roughly the same time and the first deployment fails on the new instance, it terminates by AWS CodeDeploy. The second deployment, unaware that the instance terminated, will not fail until the deployment times out (the default timeout value is 1 hour). Instead, you should combine your application deployments into one or consider the use of multiple Auto Scaling groups with smaller instance types.
You use deployment configurations to drive how quickly Amazon EC2 on-premises instances update by AWS CodeDeploy. You can configure deployments to deploy to all instances in a deployment group at once or subgroups of instances at a time, or you can create an entire new group of instances (blue/green deployment). A deployment configuration also specifies the fault tolerance of deployments, so you can roll back changes if a specified number or percentage of instances or functions in your deployment group fail to complete their deployments and signal success back to AWS CodeDeploy.
When you deploy to Amazon EC2 on-premises instances, you can configure either in-place or blue/green deployments.
In-Place deployments These deployments recycle currently running instances and deploy revisions on existing instances.
Blue/Green deployments These deployments replace currently running instances with sets of newly created instances.
In both scenarios, you can specify wait times between groups of deployed instances (batches). Additionally, if you register the deployment group with an elastic load balancer, newly deployed instances also register with the load balancer and are subject to its health checks.
The deployment configuration specifies success criteria for deployments, such as the minimum number of healthy instances that must pass health checks during the deployment process. This is done to maintain required availability during application updates. AWS CodeDeploy provides three built-in deployment configurations.
For in-place deployments, AWS CodeDeploy will attempt to deploy to all instances in the deployment group at the same time. The success criteria for this deployment configuration requires that at least once instance succeed for the deployment to be successful. If all instances fail the deployment, then the deployment itself fails. For blue/green deployments, AWS CodeDeploy will attempt to deploy to the entire set of replacement instances at the same time and follows the same success criteria as in-place deployments. Once deployment to the replacement instances succeeds (at least one instance deploys successfully), traffic routes to all replacement instances at the same time. The deployment fails only if all traffic routing to replacement instances fails.
For in-place deployments, up to half of the instances in the deployment group deploy at the same time (rounded down). Success criteria for this deployment configuration requires that at least half of the instances (rounded up) deploy successfully. Blue/green deployments use the same rules for the replacement environment, with the exception that the deployment will fail if less than half of the instances in the replacement environment successfully handle rerouted traffic.
For in-place and blue/green deployments, this is the most stringent of the built-in deployment configurations, as it requires all instances to deploy the new application revision successfully, with the exception of the final instance in the deployment. For deployment groups with only one instance, the instance must complete successfully for the deployment to complete. For blue/green deployments, the same rule applies for traffic routing. If all but the last instance registers successfully, the deployment is successful (with the exception of single-instance environments, where it must register without error).
For in-place deployments, AWS CodeDeploy will attempt to deploy to all instances in the deployment group at the same time. The success criteria for this deployment configuration requires that at least one instance succeed for the deployment to be successful. If all instances fail the deployment, then the deployment itself fails. For blue/green deployments, AWS CodeDeploy will attempt to deploy to the entire set of replacement instances at the same time and follows the same success criteria as in-place deployments. Once deployment to the replacement instances succeeds (at least one instance deploys successfully), traffic routes to all replacement instances at the same time. The deployment fails only if all traffic routing to replacement instances fails.
For in-place deployments, up to half of the instances in the deployment group deploy at the same time (rounded down). Success criteria for this deployment configuration requires that at least half of the instances (rounded up) deploy successfully. Blue/green deployments use the same rules for the replacement environment, with the exception that the deployment will fail if less than half of the instances in the replacement environment successfully handle rerouted traffic.
This is the most stringent of the built-in deployment configurations, as it requires that all instances successfully deploy the new application revision (both in-place and blue/green deployments), with the exception of the final instance in the deployment. For deployment groups with only one instance, the instance must complete successfully for the deployment to complete. For blue/green deployments, the same rule applies for traffic routing. If all but the last instance registers successfully, the deployment is successful (with the exception of single-instance environments, where it must register without error).
AWS CodeDeploy handles updates to AWS Lambda functions differently than to Amazon EC2 or on-premises instances. When you deploy to AWS Lambda, the deployment configuration specifies the traffic switching policy to follow, which stipulates how quickly to route requests from the original function versions to the new versions. You can configure AWS CodeDeploy to deploy instances only in a blue/green fashion. AWS Lambda does not support in-place deployments. This is because AWS CodeDeploy will deploy updates to new functions. AWS CodeDeploy supports three methods for handling traffic switching in an AWS Lambda environment.
Traffic shifts in two percentage-based increments. The first increment routes to the new function version, and it is monitored for the number of minutes you define. After this time period, the remainder of traffic routes to the new version if the initial increment of request executes. AWS CodeDeploy provides a number of built-in canary-based deployment configurations, such as CodeDeployDefault.LambdaCanary10Percent15Minutes. If you use this deployment configuration, 10 percent of traffic shifts in the first increment and is monitored for 15 minutes. After this time period, the 90 percent of traffic that remains shifts to the new function version. You can create additional configurations as needed.
Traffic can be shifted in a number of percentage-based increments, with a set number of minutes between each increment. During the waiting period between each increment, the requests routed to the new function versions must complete successfully for the deployment to continue. AWS CodeDeploy provides a number of built-in linear deployment configurations, such as CodeDeployDefault.LambdaLinear10PercentEvery1Minute. With this configuration, 10 percent of traffic is routed to the new function version every minute, until all traffic is routed after 10 minutes.
All traffic is shifted at once to the new function versions.
An application is a logical grouping of a deployment group, revision, and deployment configuration. This serves as a reference to the entire set of objects needed to complete a deployment to your instances or functions.
The AppSpec configuration file is a JSON or YAML file that manages deployments on instances or functions in your environment. The actual format and purpose of an AppSpec file differs between Amazon EC2/on-premises and AWS Lambda deployments.
For Amazon EC2 on-premises deployments, the AppSpec file must be YAML formatted and follow the YAML specifications for spacing and indentation. You place the AppSpec file (appspec.yml) in the root of the revision’s source code directory structure (it cannot be in a subfolder). When you deploy to Amazon EC2 on-premises instances, the AppSpec file defines the following:
The AppSpec file specifies scripts to execute at each stage of the deployment lifecycle. These scripts must exist in the revision for AWS CodeDeploy to call them successfully; however, they can call any other scripts, commands, or tools present on the instance. The AWS CodeDeploy agent uses the hooks section of the AppSpec file to reference which scripts must execute at specific times in the deployment lifecycle. When the deployment is at the specified stage (such as ApplicationStop), the AWS CodeDeploy agent will execute any scripts in that stage in the hooks section of the AppSpec file. All scripts must return an exit code of 0 to be successful.
For any files to place on the instance, the AWS CodeDeploy agent refers to the files section of the AppSpec file, where a mapping of files and directories in the revision dictates where on the instance these files reside and with what permissions. Here’s an example of an appspec.yml file:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html/WordPress
hooks:
BeforeInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
AfterInstall:
- location: scripts/change_permissions.sh
timeout: 300
runas: root
ApplicationStart:
- location: scripts/start_server.sh
- location: scripts/create_test_db.sh
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: rootIn the previous example, the following events occur during deployment:
The high-level structure of an Amazon EC2 on-premises AppSpec file is as follows:
version: 0.0
os: operating-system-name
files:
source-destination-files-mappings
permissions:
permissions-specifications
hooks:
deployment-lifecycle-event-mappingsversion Currently the only supported version number is 0.0. os The os section defines the target operating system of the deployment group. Either windows or linux (Amazon Linux, Ubuntu, or Red Hat Enterprise Linux) is supported. files The files section defines the mapping of revision files and their location to deploy on-instance during the install lifecycle event. This section is not required if no files are being copied from the revision to your instance. The files section supports a list of source/ destination pairs.
files:
- source: source-file-location
destination: destination-file-locationThe source key refers to a fi le or a directory’s local path within the revision (use / for all files in the revision). If source refers to a fi le, the fi le copies to destination , specifi ed as the fully qualifi ed path on the instance. If source refers to a directory, the directory contents copy to the instance.
permissions For any deployed fi les or directories, the permissions section specifies the permissions to apply to fi les and directories on the target instance. You can also apply permissions to fi les on the instance by AWS CodeDeploy using the files directive of the AppSpec configuration.
permissions:
- object: object-specification
pattern: pattern-specification
except: exception-specification
owner: owner-account-name
group: group-name
mode: mode-specification
acls:
- acls-specification
context:
user: user-specification
type: type-specification
range: range-specification
type:
- object-typeEach object specifi cation includes a set of fi les or directories to which the permissions will apply. You can select fi les based on a pattern expression and ignore them with a commadelimited list in the except property. The owner, group , and mode properties correspond to their Linux equivalents. You can apply access control lists with the acls property, providing a list of user/group permissions assignments (such as u:ec2-user:rw). The context property is reserved for SELinux-enabled instances. This property corresponds to a set of context labels to apply to objects. Lastly, you use the type property to specify to which types of objects ( file or directory ) the specifi ed permissions will apply.
Windows instances do not support permissions.
hooks The hooks section specifies the scripts to run at each lifecycle event and under what user context to execute them.
One or more scripts can execute for each lifecycle hook.
ApplicationStop Before the application revision downloads to the instance, this lifecycle event can stop any running services on the instance that would be affected by the update. It is important to note that, since the revision has not yet been downloaded, the scripts execute from the previous revision. Because of this, the ApplicationStop hook does not run on the first deployment to an instance.
DownloadBundle The AWS CodeDeploy agent uses this lifecycle event to copy application revision files to a temporary location on the instance.
Linux /opt/codedeploy-agent/deployment-root/[deployment-group-id]/[deployment-id]/deployment-archive Windows C:\ProgramData\Amazon\CodeDeploy\[deployment-group-id]\[deployment-id]\deployment-archive
This event cannot run custom scripts, as it is reserved for the AWS CodeDeploy agent.
BeforeInstall Use this event for any pre-installation tasks, such as to clear log files or to create backups.
Install This event is reserved for the AWS CodeDeploy agent.
AfterInstall Use this event for any post-installation tasks, such as to modify the application configuration.
ApplicationStart Use this event to start any services that were stopped during the ApplicationStop event.
ValidateService Use this event to verify deployment completed successfully. If your deployment group is registered with a load balancer, additional lifecycle events become available. These can be used to control certain behaviors as the instance is registered or deregistered from the load balancer.
BeforeBlockTraffic Use this event to run tasks before the instance is deregistered from the load balancer.
BlockTraffic This event is reserved for the AWS CodeDeploy agent.
AfterBlockTraffic Use this event to run tasks after the instance is deregistered from the load balancer. BeforeAllowTraffic Similar in concept to BeforeBlockTraffic, this event occurs before instances register with the load balancer. AllowTraffic This event is reserved for the AWS CodeDeploy agent. AfterAllowTraffic Similar in concept to AfterBlockTraffic, this event occurs after instances register with the load balancer.
hooks:
deployment-lifecycle-event-name:
- location: script-location
timeout: timeout-in-seconds
runas: user-nameIn the hooks section, the lifecycle name must match one of the previous event names, which are not reserved for the AWS CodeDeploy agent. The location property refers to the relative path in the revision archive where the script is located. You can configure an optional timeout to limit how long a script can run before it is considered failed. (Note that this does not stop the script’s execution.) The maximum script duration is 1 hour (3,600 seconds) for each lifecycle event. Lastly, the runas property can specify the user to execute the script. This user must exist on the instance and cannot require a password.
When you deploy to AWS Lambda functions, the AppSpec fi le can be in JSON or YAML format, and it specifi es the function versions to deploy as well as other functions to execute for validation testing.
AWS Lambda deployments do not use the AWS CodeDeploy agent.
The high-level structure of an AWS Lambda deployment AppSpec fi le is as follows:
version: 0.0
resources:
lambda-function-specifications
hooks:
deployment-lifecycle-event-mappingsversion Currently the only supported version number is 0.0.
resources The resources section defi nes the AWS Lambda functions to deploy.
resources:
- name-of-function-to-deploy:
type: "AWS::Lambda::Function"
properties:
name: name-of-lambda-function-to-deploy
alias: alias-of-lambda-function-to-deploy
currentversion: lambda-function-version-traffic-currently-points-to
targetversion: lambda-function-version-to-shift-traffic-toName each function in the resources list both as the list item name and in the name property. The alias property specifi es the function alias, which maps from the version specifi ed in currentversion to the version specifi ed in targetversion after the update deploys.
hooks The hooks section specifi es the additional AWS Lambda functions to run at specific stages of the deployment lifecycle to validate success. The following lifecycle events support hooks in AWS Lambda deployments:
BeforeAllowTraffic For running any tasks prior to traffic shifting taking place AfterAllowTraffic For any tasks after all traffic shifting has completed
hooks:
- BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName
- AfterAllowTraffic: AfterAllowTrafficHookFunctionNameAWS CodeDeploy reserves the Start, AllowTraffic , and End lifecycle events.
For any functions in the hooks section, the function is responsible for notifying AWS CodeDeploy of success or failure with the PutLifecycleEventHookExecutionStatus call API from within your validation function. Here’s an example for Node.js:
*** CodeDeploy the prepared validation test results.***
codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) {
if (err) {
// Validation failed.
callback('Validation test failed');
} else {
// Validation succeeded.
callback(null, 'Validation test succeeded');
}
});The AWS CodeDeploy agent is responsible for driving and validating deployments on Amazon EC2 on-premises instances. The agent currently supports Amazon Linux (Amazon EC2 only), Ubuntu Server, Microsoft Windows Server, and Red Hat Enterprise Linux, and it is available as an open source repository on GitHub (https://github.com/aws/aws-codedeploy-agent).
When the agent installs, a codedeployagent.yml configuration file copies to the instances. You can use this file to adjust the behavior of the AWS CodeDeploy agent on instances throughout various deployments. This configuration file is stored in /etc/codedeployagent/conf on Linux instances and C:\ProgramData\Amazon\AWS CodeDeploy on Windows Server instances.
The most common settings are as follows:
max_revisions Use this to configure how many application revisions to archive on an instance. If you are experiencing storage limitations on your instances, turn this value down and release some storage space consumed by the agent.
root_dir Use this to change the default storage location for revisions, scripts, and archives.
verbose Set this to true to enable verbose logging output for debugging purposes.
proxy_url For environments that use an HTTP proxy, this specifies the URL and credentials to authenticate to the proxy and connect to the AWS CodeDeploy service.
AWS CodeDeploy enforces the service limits, as shown in the table. An asterisk (*) indicates limits that you can increase with a request to AWS Support.
| Limit | Value |
|---|---|
| Applications per account per region | 100 |
| Allowed revision file types | .zip, .tar, .tar, and.gz |
| Concurrent deployments per deployment group | 1 |
| Concurrent deployments per account | 100 |
| Maximum deployment lifecycle event duration | 3600 seconds |
| Custom deployment configurations per account | 25 |
| Deployment groups per application* | 100 |
| Tags per deployment group | 10 |
| Auto Scaling groups per deployment group | 10 |
| Instances per deployment | 500 |
AWS CodeDeploy can integrate automatically with AWS CodePipeline as a deployment action to deploy changes to Amazon EC2 on-premises instances or AWS Lambda functions. You can configure applications, deployment groups, and deployments directly in the AWS CodePipeline console when you create or edit a pipeline, or you can do this ahead of time with the AWS CodeDeploy console or the AWS CLI or AWS SDK. After you define the deployment provider, application name, and deployment group in the AWS CodePipeline console, the pipeline will automatically configure to pass a pipeline artifact to AWS CodeDeploy for deployment to the specified application/group.
AWS CodeDeploy monitors the progress of any revisions to deploy and report success or failure to AWS CodePipeline.