I'm new to AWS and have been building my infrastructure manually. Now, I'm eager to automate my setup using CI/CD with CloudFormation. Specifically, I want to create a GitHub Actions OIDC provider, an IAM role to assume, and the policies attached to that role. Initially, I'll use the AWS CLI to bootstrap my setup since GitHub won't have AWS permissions right away. After that, I want to ensure that my CI/CD pipeline handles updates to my CloudFormation stacks effectively.
My concern is that I have multiple stacks for S3, CloudFront, and Route53, and if I set up one workflow that triggers on every push, it would unnecessarily redeploy all of these stacks—even if there are no changes. This feels redundant. Instead, I'd prefer to create separate workflows: one for bootstrapping (OIDC provider, IAM role, policies) and another for S3 + CloudFront + Route53. This way, if I only change something in the S3 stack, the bootstrap workflow shouldn't trigger.
I plan to implement GitHub Actions path filters to ensure that each workflow only runs when there are relevant changes in the appropriate directories. Additionally, I aim to use CloudFormation change sets or the `--no-fail-on-empty-changeset` option to avoid unnecessary runs when there's nothing to update. I'm also thinking of adding a manual trigger for the initial bootstrap and maybe a scheduled drift detection run later.
Does this plan make sense, or is there a more efficient method to avoid unnecessary redeploys across my multiple stacks?
6 Answers
In our setup, we keep a separate stack for less frequently changing resources like S3 and CloudFront. It deploys with each push, but if nothing has changed, it runs super quickly, usually just a few seconds. Just a heads-up: using directory filters might lead to some unintentional issues later on if any shared resources are added, leading to redundant deployments.
Segregating your Infrastructure as Code (IaC) into related components is a solid approach. Your idea to trigger workflows based on changes in specific directories should help manage deployments effectively and keep things clean.
Your plan seems to make sense! CloudFormation is pretty good about not doing anything if your stack template hasn’t changed. Having a single workflow for all stacks might feel over-engineered unless you're dealing with a ton of resources. If you're fine with the slight time taken for a redeploy, then it should work well enough.
Have you considered using nested stacks? You could create a parent stack that organizes your bootstrap and other components as child stacks. This way, you only deploy the parent stack, and CloudFormation will track which child stacks have changed. It will only redeploy what's necessary, saving you from unnecessary runs.
If you opt for the AWS CDK, it can manage multiple stacks and will only apply changes if there are any detected. It has partial validation features too, so you can avoid unnecessary updates while keeping everything organized.
AWS has a bunch of comprehensive guidelines on this topic. Check out the AWS Deployment Pipeline Reference Architecture—it has tons of insights and sample implementations that could help streamline your approach.
Related Questions
How To Get Your Domain Unblocked From Facebook
How To Find A String In a Directory of Files Using Linux