Answers: <p>This question is very valid, as the setup you create today will stay with you for longer. And believe me, it become more tough to change every single day later :)</p>
  <p>So, what options do you have?</p>
  <p>In the simplest but &quot;ok-ish&quot; solution. Create VPCs per environment in your account. All resources must be properly tagged (for example key: environment, value: production&quot;). In this way you will have logical separation withing one account, you can set boundaries, who can access what (using the tag I mentioned) and also you will have reasonably good way of understand your costs.</p>
  <p>There is a better solution. Every environment goes to its own account. Now, you may think &quot;omg, this will be overcomplicated&quot;. I know, it looks like this on the beginning. So I will go further, and create fourth account :D Let's call it master. This account is the one where you will create organization and SSO.</p>
  <p>But let's forget now about this fourth one.</p>
  <p>With accounts dedicated to environment you have full separation and you use full power of AWS.</p>
  <p>Now CI/CD. Infrastructure is a beautiful but treacherous thing :) You will learn in time, that to work with IaC in CI/CD you have to have a slightly different approach than for your applications. Generic CI/CD tools, however powerful, don't ofer full control over the whole life cycle of infrastructure. Well, yes, you can do it, but you need to invest a lot into it.</p>
  <p>I suppose you use IaC (terraform, cloudformation, etc) for the rest of my answer.</p>
  <p>You need to stage your Jenkins pipelines. First, I recommend to do some SAST test of the quality of your IaC. <a href="https://www.checkov.io/" rel="nofollow noreferrer">Checkov</a>, <a href="https://github.com/aquasecurity/tfsec" rel="nofollow noreferrer">tfsec</a>, etc are your friends here. After that you can create stages for all your environments.
  Example:</p>
  <p>tfsec -&gt; deploy_on_dev -&gt; deploy_on_staging -&gt; deploy_on_prod</p>
  <p>You can have some tests between stages:</p>
  <p>tfsec -&gt; deploy_on_dev -&gt; tests_on_dev -&gt; deploy_on_staging -&gt; tests_on_staging -&gt; deploy_on_prod -&gt; tests_on_prod</p>
  <p>You can force the manual acceptance, something like:</p>
  <p>... -&gt; tests_on_staging -&gt; manual accept -&gt; deploy_on_prod ...</p>
  <p>And so on. These are like the generic approaches.</p>
  <p>The point is, you should separate your environments. On AWS and in your pipelines.
  Of course, this requires more work related to authentication, but hey, you want easy things or secure things? ;)</p>
  <p>I hope this helps. If you have any more questions, ping me!</p>
  <p>On the end, the best way of manage IaC is to use dedicated tools, like <a href="https://spacelift.io/" rel="nofollow noreferrer">Spacelift</a>. I mention it, because I am Developer Advocate there :) But orchestration tools plays very important role in proper management of huge environments. You will be there someday (I mean, with huge infrastructure :) )</p>
  <p>Best,
  Pawel</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-08-05T20:22:56.720Z
Answers: are you trying to say that we can keep a common CI/CD pipeline across 3 different environments(testing, staging,production), ie across 3 different VPCs? can it be done?
Answers: myquest9 sh
Answers: CC BY-SA 4.0
Answers: 2023-08-08T07:27:35.567Z
Answers: Exactly. That is the goal. 
  What CI/CD tool are you using?
Answers: Pawel Piwosz
Answers: CC BY-SA 4.0
Answers: 2023-08-09T14:39:21.823Z
Answers: I am going to use Jenkin
Answers: myquest9 sh
Answers: CC BY-SA 4.0
Answers: 2023-08-01T08:10:39.467Z
Answers: 2023-08-01T08:10:39.467Z
Answers: Pawel Piwosz
Body: <p>I want to deploy a public facing web project on aws, for which I have setup ec2 for front end and another ec2 for backend (leave discussion about hpa and other services etc for now). I have to integrate Jenkins CI/CD pipeline with this. The setup has 3 environments (staging, production and development with 3 individual databases).</p>
  <p>How to setup these 3 individual environments? Do I need to create 3 different individual projects in AWS, including frontend ec2, backend ec2 and a CI/CD pipeline? Code will be committed in all the environments by the developer manually, and a respective CI/CD pipeline will take care of rest in the respective environment? Or, there would be one infrastructure with separate databases per environment, and a common CI/CD?</p>
  
Tags: <amazon-web-services>
Title: How to create three different environments in AWS?
UserDisplayName: myquest9 sh
ThreadText: # How to create three different environments in AWS?
  
  (Asked by: username_0 on 2023-07-27)
  
  I want to deploy a public facing web project on aws, for which I have setup ec2 for front end and another ec2 for backend (leave discussion about hpa and other services etc for now). I have to integrate Jenkins CI/CD pipeline with this. The setup has 3 environments (staging, production and development with 3 individual databases).
  
  How to setup these 3 individual environments? Do I need to create 3 different individual projects in AWS, including frontend ec2, backend ec2 and a CI/CD pipeline? Code will be committed in all the environments by the developer manually, and a respective CI/CD pipeline will take care of rest in the respective environment? Or, there would be one infrastructure with separate databases per environment, and a common CI/CD?
  
  **Tags:** amazon-web-services
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-08-01. Score: 0
  
  This question is very valid, as the setup you create today will stay with you for longer. And believe me, it become more tough to change every single day later :)
  
  So, what options do you have?
  
  In the simplest but "ok-ish" solution. Create VPCs per environment in your account. All resources must be properly tagged (for example key: environment, value: production"). In this way you will have logical separation withing one account, you can set boundaries, who can access what (using the tag I mentioned) and also you will have reasonably good way of understand your costs.
  
  There is a better solution. Every environment goes to its own account. Now, you may think "omg, this will be overcomplicated". I know, it looks like this on the beginning. So I will go further, and create fourth account :D Let's call it master. This account is the one where you will create organization and SSO.
  
  But let's forget now about this fourth one.
  
  With accounts dedicated to environment you have full separation and you use full power of AWS.
  
  Now CI/CD. Infrastructure is a beautiful but treacherous thing :) You will learn in time, that to work with IaC in CI/CD you have to have a slightly different approach than for your applications. Generic CI/CD tools, however powerful, don't ofer full control over the whole life cycle of infrastructure. Well, yes, you can do it, but you need to invest a lot into it.
  
  I suppose you use IaC (terraform, cloudformation, etc) for the rest of my answer.
  
  You need to stage your Jenkins pipelines. First, I recommend to do some SAST test of the quality of your IaC. [Checkov](https://www.checkov.io/), [tfsec](https://github.com/aquasecurity/tfsec), etc are your friends here. After that you can create stages for all your environments.
  Example:
  
  tfsec -> deploy\_on\_dev -> deploy\_on\_staging -> deploy\_on\_prod
  
  You can have some tests between stages:
  
  tfsec -> deploy\_on\_dev -> tests\_on\_dev -> deploy\_on\_staging -> tests\_on\_staging -> deploy\_on\_prod -> tests\_on\_prod
  
  You can force the manual acceptance, something like:
  
  ... -> tests\_on\_staging -> manual accept -> deploy\_on\_prod ...
  
  And so on. These are like the generic approaches.
  
  The point is, you should separate your environments. On AWS and in your pipelines.
  Of course, this requires more work related to authentication, but hey, you want easy things or secure things? ;)
  
  I hope this helps. If you have any more questions, ping me!
  
  On the end, the best way of manage IaC is to use dedicated tools, like [Spacelift](https://spacelift.io/). I mention it, because I am Developer Advocate there :) But orchestration tools plays very important role in proper management of huge environments. You will be there someday (I mean, with huge infrastructure :) )
  
  Best,
  username_1
  
  > **Comments:**
  > **username_0**: are you trying to say that we can keep a common CI/CD pipeline across 3 different environments(testing, staging,production), ie across 3 different VPCs? can it be done?  
  > **username_1**: Exactly. That is the goal.  What CI/CD tool are you using?  
  > **username_0**: I am going to use Jenkin  
  
  ---
  
  