Hi,

This looks like something I could really make use of but your example success template returns "An invalid subnet size was specified: 24, 25, 26". I tried some other valid combinations but nothing works.

I checked the code and subnet size check looks ok to me. (I am not a python expert though!)

# Check the sizes are valid
if any(size < 16 or size > 28 for size in sizes):
    return send_response(event, context, "FAILED", reason="An invalid subnet size was specified: {}".format(", ".join(sizes)))

You may want to consider updating the role so the function can send logs to cloudwatch.

Thanks!

Followed all instructions and cannot get this code to cooperate. Everytime that I create a new stack, it sits there then eventually fails. After reviewing the CloudWatch logs I find:

Unable to import module 'cidr_findr': No module named 'cidr_findr'

Help!

Hello guys. Trying pretty hard to get this working on our account, and whenever I call this using a custom resource in subsequent cfn templates, we're getting this output from the Lambda Function:

Not enough information to determine IP range: Exception
Traceback (most recent call last):
File "/var/task/lambda.py", line 78, in lambda_handler
result = find_next_subnet(vpc_cidr, subnet_cidrs, sizes)
File "/var/task/cidr_findr.py", line 86, in find_next_subnet
attempt = Range(base=vpc.base, size=req)
File "/var/task/cidr_findr.py", line 64, in __init__
raise Exception("Not enough information to determine IP range")
Exception: Not enough information to determine IP range

Pretty sure we're passing everything in correctly, here's the corresponding custom resource:

  CidrFindr:
    Type: Custom::CidrFindr
    Properties:
      ServiceToken: !ImportValue CidrFindr
      VpcId: !Ref myVpc
      Sizes: [27,27,27]

For what it's worth, I also created a custom test request using the AWS console (using the CloudFormation request format) and still get the same thing. I'm not super great at Python so really banging my head trying to understand where it's failing.

It worked the first time. But now when using in a new stack it returns a cidr that is either identical or within the range from the results provided to the first stack that used it.

`
The CIDR '10.10.16.0/24' conflicts with another subnet

`

Please add support for VPCs that have multiple CIDR blocks associated.

Desired behaviour - when looking for an available subnet slot, keep searching through all associated CIDR blocks in order until slot is found, or the search has reached the end.