<p>We're about to implement infrastructure-as-code on our project. We already have CI/CD pipelines that deploy:</p>
<ul>
<li>A CloudFormation stack for an ECS service</li>
<li>Several CloudFormation stacks for AWS lamdbas (some of which are packaged as containers, and others are NodeJS deployment packages on S3)</li>
</ul>
<p>The stacks mentioned above do not currently define any infra except SQS event bindings for the lambdas and an ECS task definition - all resources such as SQS queues or S3 buckets have been historically created manually from the AWS console.</p>
<p>Since our infra does not change frequently, I have an idea of separating the IaC pipeline responsible for setting up all the infra from the CI/CD one responsible for deploying the application code (namely, the ECS containers and AWS lambdas). This would allow to make the CI/CD pipeline run faster because it does not have to check for any infra changes.</p>
<p>I also have a thought of limiting access to the IaC pipeline, so only a subset of team members could update the infra, while anyone could initiate the CI/CD pipeline by pushing code changes to a designated Git branch.</p>
<p>Is this a reasonable idea?</p>
<p>If so, would it be a correct approach <strong>not</strong> to use any <code>AWS::Lambda::Function Code</code> entries in the IaC templates so that the IaC templates do not create any potential conflicts with the SAM templates already deploying the ECS service / Lambda stacks? (as those stacks would not be linked to the stack hierarchy created by the IaC templates)</p>

CC BY-SA 4.0
2023-09-26T20:49:19.317Z
In your second paragraph you say "all resources such as SQS queues or S3 buckets have been historically created manually from the AWS console" but then in your third paragraph you reference "the IaC pipeline responsible for setting up all the infra", is that IaC pipeline managing the manually-created resources?
Jesusaur
CC BY-SA 4.0
2023-10-31T12:30:43.457Z
@Jesusaur Yes, the plan was to migrate everything to Terraform, including the resources that had been created manually
DmytroL
CC BY-SA 4.0
2023-10-31T12:32:33.683Z
@Jesusaur What we did in the end was to deploy AWS Lambda function code stubs via Terraform which would then be replaced by real production code from GitHub actions. The corresponding Terraform resources would also have an `ignore_changes` lifecycle hook for the function code
DmytroL
<amazon-web-services><cicd><aws-lambda><infrastructure-as-code><aws-cloudformation>
Proper separation of IaC and code deployment via CI / CD
DmytroL
# Proper separation of IaC and code deployment via CI / CD

(Asked by: username_0 on 2022-11-01)

We're about to implement infrastructure-as-code on our project. We already have CI/CD pipelines that deploy:

* A CloudFormation stack for an ECS service
* Several CloudFormation stacks for AWS lamdbas (some of which are packaged as containers, and others are NodeJS deployment packages on S3)

The stacks mentioned above do not currently define any infra except SQS event bindings for the lambdas and an ECS task definition - all resources such as SQS queues or S3 buckets have been historically created manually from the AWS console.

Since our infra does not change frequently, I have an idea of separating the IaC pipeline responsible for setting up all the infra from the CI/CD one responsible for deploying the application code (namely, the ECS containers and AWS lambdas). This would allow to make the CI/CD pipeline run faster because it does not have to check for any infra changes.

I also have a thought of limiting access to the IaC pipeline, so only a subset of team members could update the infra, while anyone could initiate the CI/CD pipeline by pushing code changes to a designated Git branch.

Is this a reasonable idea?

If so, would it be a correct approach **not** to use any `AWS::Lambda::Function Code` entries in the IaC templates so that the IaC templates do not create any potential conflicts with the SAM templates already deploying the ECS service / Lambda stacks? (as those stacks would not be linked to the stack hierarchy created by the IaC templates)

**Tags:** amazon-web-services, cicd, aws-lambda, infrastructure-as-code, aws-cloudformation

> **Comments:**
> **username_1**: In your second paragraph you say "all resources such as SQS queues or S3 buckets have been historically created manually from the AWS console" but then in your third paragraph you reference "the IaC pipeline responsible for setting up all the infra", is that IaC pipeline managing the manually-created resources?  
> **username_0**: @username_1 Yes, the plan was to migrate everything to Terraform, including the resources that had been created manually  
> **username_0**: @username_1 What we did in the end was to deploy AWS Lambda function code stubs via Terraform which would then be replaced by real production code from GitHub actions. The corresponding Terraform resources would also have an `ignore_changes` lifecycle hook for the function code  

---

## 0 answers

