How do I expose an RDS DB across VPCs? #167
-
We need to expose an RDS DB (Aurora to be specific) to an external VPC without exposing it publicly. What is the best way to do this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
There are two ways to expose an RDS DB across VPCs:
Of the two, the preferred mechanism would be to setup a proxy endpoint. Proxy endpoints can be configured with arbitrary security groups which allows you define fine grained network access rules when exposing it to other VPCs. This has the advantage of being able to configure dedicated access rules on a per endpoint basis, which can be easier to maintain and manage (e.g., you can have a dedicated proxy endpoint for a particular VPC connection that has the context of what SGs and CIDRs should be allowed access, vs maintaining a combined unified list on the DB SG itself). Another advantage of proxy endpoints is that you can limit the cross VPC access to just the Aurora DB. A VPC peer exposes everything in the VPC to the other VPC, so that is something to consider when choosing between the two. That said, Gruntwork modules currently do not support configuring proxy endpoints, so if you want to go down this path, you will have to create a wrapper module that creates the On the other hand, the advantage of VPC peering is that it is much simpler to configure and maintain, since all it is doing is bridging the network between the two VPCs so that it looks like one. This is operationally easier to reason and manage, so is preferable if the security concerns above (fine grained ACL and exposing more resources than the DB) are not an issue. You can configure a VPC peering connection by using the vpc-peering or vpc-peering-external modules, depending on if the target VPC lives in the same account or not. |
Beta Was this translation helpful? Give feedback.
There are two ways to expose an RDS DB across VPCs:
Of the two, the preferred mechanism would be to setup a proxy endpoint. Proxy endpoints can be configured with arbitrary security groups which allows you define fine grained network access rules when exposing it to other VPCs. This has the advantage of being able to configure dedicated access rules on a per endpoint basis, which can be easier to maintain and manage (e.g., you can have a dedicated proxy endpoint for a particular VPC connection that has the context of what SGs and CIDRs should be allowed access, vs maintaining a combined unified list on the DB SG itself).
Another…