- 최신
- 최다 투표
- 가장 많은 댓글
My understanding is the reference of VPC1's security group in VPC2 caused a dependency.
One way you can consider, to create encapsulation is to utilize VPC endpoint / AWS PrivateLink. You can expose the VPC2 services through PrivateLink and access the services in VPC1 and other VPCs through interface endpoint.
That way VPC1 and VPC2 would be completely independent and VPC2 has no reference of constructs in VPC1.
Hi Jason_S
Thanks for the answer
Is it better design (and even possible) that in VPC1-stack I change VPC2's security group to allow connection from VPC1's Lambda? That way I break the circular dependency
My VPC2 has an MSK cluster and my client is in VPC1.
One way to think about this is: it makes sense that clients (VPC1 lambda) do the changes to the SG that they need to connect to the service. The service should not know about its clients but the clients should know about the service they need to consume - in terms of responsibility
Another way to think about this is that if we allow clients to amend the SG of the MSK cluster, it probably breaks security? And what if VPC2-stack is rerun, would it remove the ingress rule? perhaps not
Would love to hear your thoughts
Can you break the cycle by moving the Security Group to the same stack as the Lambda function?
Yes, I can do that. I can add ingress rule for lambda SG to the VPC2 SG. That would mean I change the SG of VPC2 from outside of VPC2 Stack - does that not break encapsulation or is it not the right way to think about this