Describe the bug
Share within an OU

To Reproduce
Any VPC with an ou shared with

  dev:
    style: workloadIsolated
    vpcCidr: 10.0.0.0/16
    subnets:
      workload:
        cidrMask: 18
        sharedWith:
          - ou-abcd-efg

Expected behavior
RAM Share works

Additional context
CloudFormation returns 'OperationNotPermittedException;'

Describe the bug
RAM Share names for VPCs are not descriptive

To Reproduce
RAM Share multiple VPCs. They will all be named 'share-workload'.

Expected behavior
Name of the RAM share should at minimum describe the VPC being shared.

Is your feature request related to a problem? Please describe.
For use-cases where the Transit Gateway is associated with a Direct Connect Transit Gateway a model should exist that permits including the DX Gateway attachment as a destination for a routesTo: in supported Routes.

Describe the solution you'd like
A model for a DX Gateway in the configuration file. The required configuration items would be imported as existing (route table and attachment identifiers) similar to how an existing TGW or existing VPN is imported today.

CloudFormation currently has no support (aws-cloudformation/cloudformation-coverage-roadmap#876) for creating the Direct Connect Gateway itself, but we can model it by importing required attributes to support routesTo: within the Transit Gateway Route tables.

When a routesTo: destination is the modeled Direct Connect Gateway - static routes, dynamic routes and/or default routes would be configured in the same way they are today for VPC and VPN connections.

Is your feature request related to a problem? Please describe.
When a peer transit gateway is created you must manage the VPC routes to that Transit Gateway manually.

Describe the solution you'd like
Ability to model a Transit Gateway Peer Attachment in the configuration file and be able to use it in the 'routes' section as a destination.

Describe alternatives you've considered
None

Additional context
None

Could you submit a PR to implement this feature?
Yes

Describe the bug
When a newline or newlines are inserted into endpoint configuration files ie: sample-complex-endpoints-us-east-1.txt synthesis will fail with a message Error: Interface Endpoint named not found in discovery files.

To Reproduce
Add a newline to sample-complex-endpoints-us-east-1.txt then attempt to synthesize the sample-complex example.

Expected behavior
Newlines should be ignored

The usage of the Discovery tooling is not present in the readme. Multi-region instructions are missing from the readme.

RAM shared resources do not have parent resource tags. I believe this is a known RAM issue however would be nice to include a fix for this so parent and child resource such as subnets have synchronized tags at creation time.

Is your feature request related to a problem? Please describe.
Today when configuring a black hole route you need to specify a CIDR address.

Describe the solution you'd like
Often the Black Hole Route is for a VPC That is already defined in the same configuration file (ie: the CIDR is known). It is safer and more convenient to reefer to the VPC by-name instead of needing to copy and paste it's CIDR address.

Support specifying a VPC by-name in the Black Hole Route section. This should functionally work the same as providing a CIDR address, but the resolution of the CIDR address is handled by the definition in the configuration file under the vpcs: block.

Trying to get vpc builder running in a different region is not that straight forward. Tried to stand-up in us-west-2 with global: global:

** Replace with overall organizational ID **

Uncomment below if you'd like to use RAM Sharing

organizationId: o-hjw5j8o5mo
stackNamePrefix: sample-complex
ssmPrefix: /sample-complex/network
region: us-west-2
availabilityZones:
- us-west-2a
- us-west-2b

This leads to error with:
Endpoint vpc-endpoints: Service interface file sample-complex-endpoints-us-west-2.txt not found in the config directory

After creating the interface endpoint file it was looking for based on the us-east-1.txt reference and updating to us-west-2 values I'm still getting endpoint erorrs:
Error: Interface Endpoint named not found in discovery files
at VpcInterfaceEndpointsStack.lookupPrivateDnsName (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/vpc-interface-endpoints-stack.ts:198:13)
at /Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/vpc-interface-endpoints-stack.ts:105:43
at Array.forEach ()
at new VpcInterfaceEndpointsStack (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/vpc-interface-endpoints-stack.ts:75:25)
at StackMapper.providerEndpointStacks (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/stack-mapper.ts:151:26)
at StackBuilderClass.createEndpointServiceInterfaceStack (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/stack-builder.ts:365:37)
at StackBuilderClass.buildEndpointStacks (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/stack-builder.ts:334:20)
at StackBuilderClass.build (/Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/lib/stack-builder.ts:128:18)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at /Users/kennschr/IAC/CDK/aws-vpc-builder-cdk/bin/vpc-builder.ts:15:7

Immediate first step after deploying VPC builder was to launch a basic instance with SSM connectivity. Would be nice to bootstrap the IAM Role for EC2 SSM Access and launch a bastion in each VPC as part of initial deploy.