VPC Bridge Lambda Resource

[ericzbeard]

A limitation of resource types is that they cannot talk to a VPC, since the handler is not running in the same account as the deployed resources. I'd like to explore the idea of a resource design where we install a Lambda "locally" in the same account to act as a bridge to VPC resources. This would require an RPC mechanism to allow the handler to communicate with the local VPC lambda.

[benbridts]

The "invent-and-simplify" way to do this, is by having an ENI in each customers account (which might need big changes on the AWS side).

Either way this is solved, we should try to avoid creating a (lambda) bridge for every resource or stack (this re-introduces some lambda-backed custom resource problems). Maybe the bridge is create before out of band?

Other things beside lambda that can attach to a VPC:

• Step Functions
• CodeBuild
• Maybe VPC Lattice (but this also has an hourly price)

[ericzbeard]

If we do this out of band, having a single bridge that could be used by many resources, how would we implement that in a generic way? One use case is a resource that allows you to create a database schema from a template, without relying on the data API. It would need to connect to an RDS instance using the native connector, which would need to be installed as part of the bridge.

Agree on the ENI solution, but that's a design change that will take significant time, so an interim workaround here might benefit customers who don't want to wait.

[benbridts]

If we do this out of band, having a single bridge that could be used by many resources, how would we implement that in a generic way? One use case is a resource that allows you to create a database schema from a template, without relying on the data API. It would need to connect to an RDS instance using the native connector, which would need to be installed as part of the bridge.

I would do it like this:

• Create a template bridge.yaml that you can deploy one or multiple times (and turn it into a SAR app?)
• Each bridge stack can export a BridgeArn (under ${AWS::StackName}-Bridge-Arn) and can be connected to one or more DBs (depending on how the bridge works this might be an input to the bridge stack, or a SG you give access in your DB stack(s)).
• When you use the Community::MySQL::Schema resource, you specify the bridge-arn as a property.

When you need to create a schema, you have the option to:

• create one bridge that can access all your DBs
• create a bridge per DB (maybe putting them in your DB stack)
• create a bridge inside the stack that creates the schema.