In order to do this, we need the ability to configure the Lambda to run within dedicated subnet(s). This PR enables this, while not changing the behavior by default for others. I've tested this and not suppyling the new security group and subnet values, results in a non-VPC-associated Lambda.
We are currently trying to configure restrictions on the agent token by IP address, re: https://buildkite.com/docs/clusters/manage-clusters#restrict-an-agent-tokens-access-by-ip-address
In order to do this, we need the ability to configure the Lambda to run within dedicated subnet(s). This PR enables this, while not changing the behavior by default for others. I've tested this and not suppyling the new security group and subnet values, results in a non-VPC-associated Lambda.
Note: We are not using the Elastic CI stack. Our use case required us to deploy this Lambda via https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/serverlessapplicationrepository_cloudformation_stack . With that in mind, we likely wouldn't be pursuing a followup PR to enable this for users of Elastic CI stack (i.e. giving folks the ability to thread the subnet IDs and security groups through to the nested stack from this repo)