공유 VPC 네트워크에 연결
조직에서 공유 VPC를 사용하는 경우 서버리스 VPC 액세스를 사용하여 Cloud Run Functions를 공유 VPC 네트워크에 직접 연결할 수 있습니다. 그러면 Cloud Run Functions가 Compute Engine VM 인스턴스, Memorystore 인스턴스, 내부 IP 주소가 있는 기타 리소스 등의 공유 VPC 네트워크의 리소스에 액세스할 수 있습니다.
조직에서 공유 VPC를 사용하지 않는 경우 VPC 네트워크에 연결을 참조하세요.
구성 방법 비교
공유 VPC의 경우 두 가지 방법으로 서버리스 VPC 액세스 커넥터를 구성할 수 있습니다. 네트워크에 액세스해야 하는 Cloud Run Functions 리소스가 있는 서비스 프로젝트마다 커넥터를 설정하거나 호스트 프로젝트에서 공유 커넥터를 설정할 수 있습니다. 각 방법에는 다음과 같은 이점이 있습니다.
서비스 프로젝트
서비스 프로젝트에서 커넥터를 만들 때의 이점은 다음과 같습니다.
- 격리: 각 커넥터는 전용 대역폭을 가지며 다른 서비스 프로젝트에 있는 커넥터의 대역폭 사용에 영향을 받지 않습니다. 이는 트래픽이 급증하는 서비스가 있거나 각 서비스 프로젝트가 다른 서비스 프로젝트의 커넥터 사용에 영향을 받지 않도록 해야 하는 경우에 유용합니다.
- 지불 거절: 커넥터에서 발생한 요금은 커넥터가 포함된 서비스 프로젝트와 연결됩니다. 이를 통해 지불 거절이 더 쉬워집니다.
- 보안: '최소 권한의 원칙'을 따를 수 있습니다. 커넥터는 연결해야 하는 공유 VPC 네트워크의 리소스에 대한 액세스 권한을 부여받아야 합니다. 서비스 프로젝트에서 커넥터를 만들면 방화벽 규칙을 사용하여 프로젝트의 서비스가 액세스할 수 있는 항목을 제한할 수 있습니다.
- 팀 독립성: 호스트 프로젝트 관리자에 대한 종속 항목을 줄입니다.
팀에서 서비스 프로젝트와 연결된 커넥터를 만들고 관리할 수 있습니다. Compute Engine 보안 관리자 역할이나 호스트 프로젝트에 대한
compute.firewalls.create권한이 사용 설정된 커스텀 Identity and Access Management(IAM) 역할이 있는 사용자는 커넥터의 방화벽 규칙을 계속 관리해야 합니다.
서비스 프로젝트에서 커넥터를 설정하려면 서비스 프로젝트에서 커넥터 구성을 참조하세요.
호스트 프로젝트
호스트 프로젝트에서 커넥터를 만들 때의 이점은 다음과 같습니다.
- 중앙 집중식 네트워크 관리: 호스트 프로젝트에서 네트워크 구성 리소스를 중앙 집중화하는 공유 VPC 모델과 일치합니다.
- IP 주소 공간: IP 주소 공간을 더 많이 보존합니다. 커넥터는 인스턴스마다 IP 주소가 필요하므로 커넥터가 적고 각 커넥터의 인스턴스 수가 적을수록 IP 주소가 더 적게 사용됩니다. 이 방법은 IP 주소 부족이 우려되는 경우에 유용합니다.
- 유지보수: 생성한 각 커넥터가 여러 서비스 프로젝트에서 사용될 수 있으므로 유지보수가 줄어듭니다. 이 방식은 유지보수 오버헤드가 우려되는 경우에 유용합니다.
- 유휴 시간 비용: 커넥터 유휴 시간 및 관련 비용을 줄일 수 있습니다. 커넥터는 트래픽을 처리하지 않는 경우에도 비용이 발생합니다(가격 책정 참조). 커넥터 수가 적으면 커넥터 유형 및 인스턴스 수에 따라 트래픽을 제공하지 않을 때 비용을 지불하는 리소스 양이 줄어들 수 있습니다. 이 방법은 많은 서비스가 포함되며 서비스가 자주 사용되지 않는 사용 사례에 비용 효율적입니다.
호스트 프로젝트에서 커넥터를 설정하려면 호스트 프로젝트에서 커넥터 구성을 참조하세요.