Answers: <p>Don't worry about putting each stack in its own set of subnets, that's an overkill. </p>
  
  <p>Simply make the resources' <strong>Security Groups</strong> refer to other <em>SGs</em> in your stack templates and not to subnet CIDRs. </p>
  
  <p>What that means is for example the RDS SG sg-123456 will permit traffic from App SG sg-9876543 and not from the App subnet 10.20.30.0/24 you'll be fine from the network isolation perspective.</p>
  
  <p>We usually have the VPC infrastructure shared for dev, test and feature stacks. That's perfectly fine. Moreover we also use <strong><a href="https://aws.nz/best-practice/cloudformation-exports/" rel="nofollow noreferrer">CloudFormation Exports</a></strong> to simplify the templates.</p>
  
  <p>Hope that helps :)</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-07-26T07:11:14.480Z
Answers: It is an interesting approach. I'll see if this is a good alternative for our scenario.
Answers: Manatax
Answers: CC BY-SA 4.0
Answers: 2019-07-27T02:20:52.203Z
Answers: Loved the blog post too. I'll be adding that as well.
Answers: Manatax
Answers: CC BY-SA 4.0
Answers: 2019-07-26T06:13:21.410Z
Answers: 2019-07-26T06:13:21.410Z
Answers: MLu
Body: <p>I'm writing a few templates to create a stack on demand.
  Because of the concurrent VPC limitations (5 to start), I'm attempting to create all the feature-based dev environments on a single VPC and mostly divide the stacks by subnets. The idea is that every stack will have 2 private and 2 public subnets.
  I know I can get specific CIDRs with something like this (YAML):</p>
  
  <pre><code>!Select [ 0, !Cidr [ !GetAtt MyVpc.CidrBlock, 1, 8 ]]
  </code></pre>
  
  <p>But I need to make sure I'm getting CIDRs that are not being used by some of the other stack.
  Programmatically, I would get all CIDR blocks from the VPC and then filter all the ones that are used by other subnets, to get a final array (or simply return x items from the array).</p>
  
  <p><strong>Is getting a block of free CIDRs or a single free one something I can do with the intrinsic functions?</strong></p>
  
Tags: <amazon-web-services><aws-cloudformation>
Title: Get available CIDRs from existing VPC
UserDisplayName: Manatax
ThreadText: # Get available CIDRs from existing VPC
  
  (Asked by: username_0 on 2019-07-26)
  
  I'm writing a few templates to create a stack on demand.
  Because of the concurrent VPC limitations (5 to start), I'm attempting to create all the feature-based dev environments on a single VPC and mostly divide the stacks by subnets. The idea is that every stack will have 2 private and 2 public subnets.
  I know I can get specific CIDRs with something like this (YAML):
  
  ```
  !Select [ 0, !Cidr [ !GetAtt MyVpc.CidrBlock, 1, 8 ]]
  
  ```
  
  But I need to make sure I'm getting CIDRs that are not being used by some of the other stack.
  Programmatically, I would get all CIDR blocks from the VPC and then filter all the ones that are used by other subnets, to get a final array (or simply return x items from the array).
  
  **Is getting a block of free CIDRs or a single free one something I can do with the intrinsic functions?**
  
  **Tags:** amazon-web-services, aws-cloudformation
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-07-26. Score: 1
  
  Don't worry about putting each stack in its own set of subnets, that's an overkill.
  
  Simply make the resources' **Security Groups** refer to other *SGs* in your stack templates and not to subnet CIDRs.
  
  What that means is for example the RDS SG sg-123456 will permit traffic from App SG sg-9876543 and not from the App subnet 10.20.30.0/24 you'll be fine from the network isolation perspective.
  
  We usually have the VPC infrastructure shared for dev, test and feature stacks. That's perfectly fine. Moreover we also use **[CloudFormation Exports](https://aws.nz/best-practice/cloudformation-exports/)** to simplify the templates.
  
  Hope that helps :)
  
  > **Comments:**
  > **username_0**: It is an interesting approach. I'll see if this is a good alternative for our scenario.  
  > **username_0**: Loved the blog post too. I'll be adding that as well.  
  
  ---
  
  