AWS DevOps Blog

AWS CodeDeploy: Deploying from a Development Account to a Production Account

AWS CodeDeploy helps users deploy software to a fleet of Amazon EC2 or on-premises instances. A software revision is typically deployed and tested through multiple stages (development, testing, staging, and so on) before it’s deployed to production. It’s also a common practice to use a separate AWS account for each stage. In this blog post, we will show you how to deploy a revision that is tested in one account to instances in another account.

Prerequisites

We assume you are already familiar with AWS CodeDeploy concepts and have completed the Basic Deployment Walkthrough. In addition, we assume you have a basic understanding of AWS Identity and Access Management (IAM) and have read the Cross-Account Access Using Roles topic.

Setup

Let’s assume you have development and production AWS accounts with the following details:

  • AWS account ID for development account: <development-account-id>
  • S3 bucket under development account: s3://my-demo-application/
  • IAM user for development account: development-user (This is the IAM user you use for AWS CodeDeploy deployments in your development account.)
  • AWS account ID for production account: <production-account-id>

You have already tested your revision in the development account and it’s available in s3://my-demo-application/. You want to deploy this revision to instances in your production account.

Step 1: Create the application and deployment group in the production account

You will need to create the application and deployment group in the production account. Keep in mind that deployment groups, and the Amazon EC2 instances to which they are configured to deploy, are strictly tied to the accounts under which they were created. Therefore, you cannot add an instance in the production account to a deployment group in the developer account. Also, make sure the EC2 instances in the production account have the AWS CodeDeploy agent installed and are launched with an IAM instance profile. You can follow the steps in this topic. For example, in this post, we will use the following settings:

  • Application name: CodeDeployDemo
  • Deployment group name: Prod
  • IAM instance profile: arn:aws:iam::role/CodeDeployDemo-EC2

Step 2: Create a role under the production account for cross-account deployment

Log in to production account and then go to IAM console. Select “Roles” in the menu and click “Create New Role“. You need to create a new role under the production account that gives cross account permission to the development account. Call this role “CrossAccountRole“.

Click “Next Step“, under “Select Role Type“, choose “Role for Cross-Account Access“. Choose “Provide access between AWS accounts you own“

Click “Next Step“, in the “Account ID” field, type the AWS account ID for the development account.

Attach the AmazonS3FullAccess and AWSCodeDeployDeployerAccess policies to this role. Follow the wizard to complete role creation.The policy section for the Prod Role should look like this:

 

Step 3: Give the IAM instance profile permission to the S3 bucket under the development account

Now log in to development account. The AWS CodeDeploy agent relies on the IAM instance profile to access the S3 bucket. In this post, development account contains the deployment revision. Update bucket policy for the S3 bucket under development account to give the production account “IAM instance profile” (arn:aws:iam::role/CodeDeployDemo-EC2) permission to retrieve the object from the bucket. You can follow the steps in granting cross-account bucket permission.

You can find the IAM instance profile by going to EC2 console and check the IAM Role associated with your EC2 instances under production account.

Here is what the policy looks like:

{
  "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "Example permissions",
        "Effect": "Allow",
        "Principal": {
        "AWS": "arn:aws:iam::role/CodeDeployDemo-EC2"
      },
     "Action": [
     "s3:List*",
     "s3:Get*"
     ],
    "Resource": "arn:aws:s3:::my-demo-application/*"
    }
  ]
}

Step 4: Give the IAM user under the development account access to the production role

In the development account IAM console, select the development-user IAM user and add the following policy.

{
  "Version": "2012-10-17",
    "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<production-account-id>:role/CrossAccountRole"
  }
}

This policy gives the development-user enough permission to assume the CrossAccountRole under the production account. You’ll find step by step instructions in the walkthrough Granting Users Access to the Role.

Step 5: Deploy to production account

That’s it. In four simple steps, you have set up everything you need to deploy from a development to a production account. To deploy:

Log in to your development account as development-user. For more information, see How Users Sign In to Your Account in the IAM documentation. In the upper-right, choose the user name. You will see the “Switch Role” link:

Alternatively, you can use the sign-in link, which you will find under “Summary” on the IAM role details page.

On the “Switch Role” page, provide the production account role information:

You only need to complete these steps once. The role will appear in the role history after you add it. For step-by-step instructions, see this blog post. After you switch to the production account role, open the AWS CodeDeploy console and deploy to the targeted application and deployment group.

Wait for the deployment to be completed successfully. The changes will be released to the production fleet.

Next steps

  • The CrossAccountRole we created in step 2 has access to any S3 bucket. You can scope the permissions down to just the required bucket (in this case, my-demo-application). Similarly, CrossAccountRole has access to deploy to any application and deployment group. You can scope this down to just the required application and deployment group. For more information, see AWS CodeDeploy User Access Permissions Reference. And also instead of using root account as trust entity, you can update trust relationships to only allow specific IAM User (e.g. development-user under development account) to assume this role.

We hope this blog post has been helpful. Are there other deployment workflow questions you would like us to answer? Let us know in the comments or in our user forum.