Feature: Conditionally Enable Ingress to spoke-vpc via org-vpc-share #28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #, if available: #27
Description of changes:
The current solution does not easily enable Ingress to spoke accounts. Although it is possible by creating additional TF stacks to deploy - for example - ALBs in the Network-Hub account which forward to IP-based Target Groups in a Spoke account, I feel this makes IaC management & organization more difficult.
It is my opinion that this solution should also be responsible for allowing Ingress to Spoke accounts, via a single example-spoke-vpc deployment, which I feel is helpful when provisioning new sub-accounts.
This PR does just that, by creating a RAM resource share
org-vpc-sharefrom the Network-Hub account that shares the inspection_vpc's public subnets. New spoke-vpc deployments have the option of joining thisorg-vpc-shareby enabling an Input Flagenable_ingress. If enabled, the spoke-vpc module joins the VPC share, seamlessly allowing spoke-account resources like an ALB to deploy into the public subnets shared by theorg-vpc-share.For me, it just makes sense to have this feature managed by these network-hub and network-spoke modules, rather than having to deploy additional cross-account stacks with cross-account dependencies. This is a one-time action managed by the same deployment responsible for provisioning spoke-vpcs.
This feature is backwards-compatible with the current version. While now the
org-vpc-shareis created by default, new subaccounts / spoke-vpc's do not join the resource share by default unless theenable_ingressinput is explicitly set totrue.Please let me know your thoughts on this, and feel free to suggest changes (especially to the new names used).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.