AWS CodePipeline best practices with 2 AWS accounts

Question

Currently, my project uses 2 AWS accounts - one is for staging that our clients can rely on for testing and the other one is for production/live. I am trying to set up a CodePipeline for a new serverless application. I was wondering if this set up is proper and if there are ways to improve it.

Staging AWS account: GitHub Source -> AWS CodeBuild (test and build in staging env) -> Manual Approval Gate -> Deploy app in staging

Then I'll verify the changes in staging before approving production deployment:

Production AWS account: GitHub Source -> AWS CodeBuild (test and build in prod env) -> Manual Approval Gate -> Deploy app in prod

It seems like the test and build will be redundant but it seems easier to set it up like this since I can basically use the same Cloudformation template for the pipeline. Plus I don't have to worry with cross-account resource access.

Whenever I push to master it'll basically trigger both of these pipelines. Is the redundancy a flaw that can be easily fixed? Is it simpler to just have the staging account have manual approval to promote to the prod account's pipeline and trigger it?

Answer 1

Separate staging and production accounts are a good idea. Have you considered using a single pipeline (probably in a third account)? It's possible to configure cross-account actions in CodePipeline. Otherwise you're going to have a difficult time coordinating a release across two pipelines.

I would consider cross-account actions a best practice for this type of setup. That said, some possible workarounds are:

• A manual approval is probably the simplest way to coordinate releases between pipelines. It's also the most error prone because it's easy for a human to mistakenly promote the wrong thing. Pipeline 1 may observe commit 1 and pipeline 2 may observe commit 2 if commit 1 and commit 2 happen within a short amount of time.
• Have the staging pipeline publish to an S3 object that is a source for the production pipeline (i.e. don't duplicate the source, build and testing stages). The nice thing about this approach is that the production pipeline will only release changes that have traversed the staging pipeline.