주, 지방, 교육(SLED) 조직은 다른 기업에 비해 고유한 IT 니즈가 있는 경우가 많습니다. 이 가이드에서는 SLED 조직을 위한 Google Cloud 및 Google Workspace 환경 만들기와 관련된 온보딩 고려사항과 권장사항을 정의합니다. 이 문서는 조직에 Google Cloud, Google Workspace 또는 Google Workspace for Education을 설정하는 관리자를 대상으로 합니다.
ID 개요
Google Cloud 환경을 만들려면 먼저 Google Cloud에서 인증, 승인, 감사를 제공하는 방법을 이해해야 합니다. 다음 세 가지 클라우드 서비스가 인증, 액세스 제어, 감사를 위해 함께 작동합니다.
- Cloud ID는 인증을 제공합니다. 조직에서 Google Workspace 또는 Google Workspace for Education을 사용하는 경우에는 이미 Cloud ID를 사용하고 있습니다.
- Identity and Access Management는 승인을 제공합니다.
- Cloud 감사 로그는 감사를 제공합니다.
Cloud ID
Cloud ID는 Google Cloud, Google Workspace 또는 Google Workspace for Education 리소스에 액세스하는 사용자 및 그룹을 중앙에서 관리할 수 있는 Identity as a Service(IDaaS) 제품입니다. Cloud ID는 무료 또는 유료(프리미엄) 버전으로 제공됩니다. Google Cloud 온보딩 프로세스 중에 Cloud ID는 TXT 레코드를 사용하여 기본 도메인 유효성 검사를 제공합니다. Cloud ID를 사용하면 다음과 같은 이점이 있습니다.
- Google Workspace 관리 콘솔을 사용하여 그룹을 만들고 관리할 수 있습니다.
- 싱글 사인온(SSO) 및 2단계 인증(2FA)을 포함한 계정 보안 제어를 제공합니다.
- 보안 보장 마크업 언어(SAML)와 LDAP를 지원하므로 타사 애플리케이션의 ID 공급업체로 사용할 수 있습니다.
ID 설정
개략적으로 ID를 설정할 때 권장되는 단계는 다음과 같습니다.
아직 Cloud ID, Google Workspace 또는 Google Workspace for Education을 사용하고 있지 않으면 다음 가입 페이지 중 하나에서 시작합니다.
Google Cloud 콘솔의 기반 체크리스트(예시는 엔터프라이즈 온보딩 체크리스트 참조)
관리자 계정을 사용하여 콘솔 내 체크리스트를 탐색합니다.
Cloud ID를 사용하여 도메인을 확인합니다. 도메인을 확인하면 Google Cloud 리소스 계층 구조의 루트 노드 역할을 하는 조직이 자동으로 생성됩니다.
도메인이 이미 소유권 주장이 제기되었다는 오류가 표시되면 도메인 소유권 주장 절차를 완료합니다. 이 절차는 영업일 기준 최대 5일이 걸릴 수 있습니다.
도메인 확인 후에 새로 만든 관리자 계정으로 Google Workspace 관리 콘솔에 로그인합니다.
Google Cloud 콘솔에서 새 Google Cloud 조직을 관리할 조직 관리자를 확인합니다.
직원 ID 제휴를 사용하거나
Cloud ID를 사용하여 사용자를 추가합니다. Cloud ID를 사용하면 다음 방법 중 하나를 사용하여 사용자를 추가할 수 있습니다.
Google Workspace 관리 콘솔 사용(개별적으로 또는 일괄)
Google 계정의 데이터를 Active Directory 또는 LDAP와 동기화하는 Google Cloud 디렉터리 동기화 사용
Azure Active Directory와 같은 서드 파티 동기화 서비스 사용
리소스 관리
이 섹션에서는 SLED 조직에서 리소스 관리에 대한 권장사항을 설명합니다.
Google Cloud 리소스 관리에 대한 중앙 집중식 방법 구현
Google Cloud는 조직, 폴더, 프로젝트로 구성된 계층적 컨테이너 시스템을 제공합니다. 이러한 구조 내에서 Compute Engine 가상 머신(VM), 데이터베이스, Cloud Storage 버킷과 같은 다른 리소스를 구성할 수 있습니다. 이 같은 계층 구조는 여러 리소스에 공통으로 적용되는 액세스 제어와 구성 설정 등을 관리하는 데 도움이 됩니다. Resource Manager를 사용하면 프로그래매틱 방식으로 리소스를 관리할 수 있습니다.
대규모 조직에는 Google Cloud 리소스와 직접 상호작용하는 프로젝트와 사용자가 많은 경우가 많습니다. 기존 IT 거버넌스 및 액세스 제어 전략을 효과적으로 지원하기 위해서는 중앙 집중식 접근 방식으로 Google Cloud 리소스 조직을 구현하는 것이 좋습니다.
조직 노드를 사용하여 리소스 정리
리소스는 루트에서 조직 노드로 정리됩니다. 폴더는 조직 노드 아래에 최대 4개 수준까지 중첩될 수 있습니다. 이러한 폴더에는 프로젝트가 포함될 수 있으며 프로젝트에 다른 리소스가 하위 요소로 포함됩니다. 각 리소스는 단 하나의 상위 요소만 가집니다. 상위 리소스에서 액세스 제어 정책과 구성 설정을 설정하면 하위 리소스가 해당 정책과 설정을 상속합니다.
조직 노드는 사용자가 도메인에 만드는 모든 프로젝트가 최고 관리자에게 표시되도록 합니다. 각 기본 도메인에는 조직 노드 하나가 있습니다. 기본적으로 Google Workspace 최고 관리자에게는 조직 정책을 설정할 수 있는 취소 불가능한 액세스 권한이 있습니다. IT와 클라우드를 따로 관리하는 조직의 경우 Google Workspace 최고 관리자는 조직을 관리할 조직 관리자를 할당해야 합니다. 자세한 내용은 최고 관리자 계정 권장사항을 참조하세요.
조직 노드를 만들기 전에 프로젝트를 만든 경우 관련 없는 프로젝트를 조직 노드로 마이그레이션할 수 있습니다.
Google Cloud를 사용하면 기본 구성에는 단일 조직 노드가 있습니다. 다음 섹션에서는 단일 조직 노드와 여러 조직 노드의 접근 방식을 비교합니다. 이러한 옵션에 대한 자세한 내용은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참조하세요.
옵션 1: 단일 조직 노드
이 옵션에서 단일 조직 노드를 IAM의 정보 소스인 Workspace 도메인에 매핑합니다. 각 폴더에는 별도의 역할 및 기타 정책과 함께 자체 관리자가 있을 수 있습니다. 다음 다이어그램은 교육 기관을 예시로 사용하여 단일 조직 노드를 보여줍니다. 필요에 따라 팀과 환경에 해당하는 하위 폴더를 더 추가할 수 있습니다.
조직의 모든 사용자가 액세스할 수 있는 권한의 폴더에서 교차 프로젝트 네트워킹, 공유 이미지 등의 글로벌 리소스를 호스팅할 수 있습니다.
자세한 내용은 다음을 참조하세요.
옵션 2: 별도의 조직 노드
조직 내의 부서를 중앙 관리가 없는 독립된 항목으로 취급하려면 별도의 조직을 만드는 것이 좋습니다. 다음 다이어그램은 학교를 예시로 사용하여 별도의 조직 노드를 보여줍니다.
이 구성을 구현하려면 school.edu 및 lab3.school.edu를 별도의 기본 Google Workspace 도메인으로 설정해 개별 조직 노드를 만듭니다. 다음 항목이 모두 해당하는 경우에만 이 옵션을 사용합니다.
- 별도의 ID 도메인을 유지하려고 합니다.
- 두 번째 조직의 액세스 제어, 맞춤 역할, 결제, 할당량, 구성 설정을 중앙
school.edu조직 노드와 구분해야 합니다.
조직에서 중앙 집중식 IT 거버넌스를 사용하는 경우 2개의 개별 Google Cloud 환경을 관리하느라 오버헤드가 가중되는 경우가 많습니다. 예를 들어 관리자가 정책을 동기화 상태로 유지하도록 주의하지 않는 한 시간이 경과하면 여러 조직 노드 간의 보안 정책이 달라질 수 있습니다.
이 방법의 영향에 대한 자세한 내용은 단일 조직 노드 사용을 참조하세요.
폴더를 사용하여 리소스 정리
폴더를 사용하면 Google Cloud 리소스를 정리하고 정책을 적용하고 관리자 권한을 위임할 수 있으므로 각 부서와 팀에 더 많은 자율성을 제공할 수 있습니다. 또한 폴더를 사용하면 프로젝트 그룹 정책을 동시에 관리하고 액세스를 제어할 수 있습니다. 한 폴더에 중첩된 폴더, 프로젝트, 리소스는 상위 폴더의 정책을 상속합니다.
다음은 폴더 사용이 적합한 몇 가지 시나리오입니다.
- 조직에는 고유한 사업부가 있으며 각 사업부마다 자체 IT 그룹이 있습니다.
- Microsoft Active Directory 같은 LDAP 디렉터리를 기반으로 설정된 구조에 매핑합니다.
- IT 인프라, 연구 컴퓨팅, 수업, 학습 등 사용 사례별로 프로젝트를 분리하려고 합니다.
자세한 내용은 Google Cloud 리소스 관리를 참조하세요.
프로젝트를 사용하여 리소스를 체계적으로 정리
할당 및 사용하는 모든 Google Cloud 리소스는 하나의 프로젝트에 속해야 합니다. 프로젝트란 빌드 대상의 구성 항목으로 프로젝트는 애플리케이션을 설명하는 설정, 권한, 기타 메타데이터로 이루어집니다. 단일 프로젝트 내 리소스는 내부 네트워크를 통해 통신하여 함께 작동합니다. 각 프로젝트에서 사용하는 리소스는 프로젝트 경계를 넘어 별도로 유지됩니다. 외부 네트워크 연결이나 공유된 Virtual Private Cloud(VPC) 네트워크를 통해서만 리소스를 연결할 수 있습니다.
각 Google Cloud 프로젝트에는 다음 항목이 포함됩니다.
- 사용자가 제공하는 프로젝트 이름
- 사용자가 제공하거나 Google Cloud에서 사용자 대신 제공할 수 있는 프로젝트 ID
- Google Cloud에서 제공하는 프로젝트 번호
프로젝트를 만들 때 다음 사항을 고려하세요.
- 프로젝트 소유권을 결정하고 다른 워크로드 또는 팀에 대해 별도의 프로젝트를 만듭니다.
- 별도의 프로젝트를 사용하여 애플리케이션을 프로덕션 환경과 비프로덕션 환경으로 나눕니다. 이 경우 비프로덕션 환경의 변경사항이 프로덕션 환경에 영향을 미치지 않으며 배포 스크립트를 사용해 변경사항을 승격하거나 반영할 수 있습니다.
- 여러 실험실 간에 또는 한 실험실의 작업에서 컴퓨팅 리소스와 데이터 리소스를 분리합니다. 이 같은 분리로 프로젝트 간에 완전한 자율성을 구현하고 데이터를 분리할 수 있어 한 실험실에서 작업하는 여러 프로젝트의 이해관계자가 경쟁 구도에 있을 경우 유용합니다.
프로젝트를 만들 때는 프로젝트를 결제 계정과 연결해야 합니다. 새 프로젝트를 기존 결제 계정과 연결하려면 대상 결제 계정에 대한 결제 계정 관리자 역할 또는 결제 계정 사용자 역할이 있어야 합니다.
Active Assist를 사용하여 규모에 맞게 리소스 관리
일반적으로 조직이 성장함에 따라 복잡성이 증가합니다. 프로젝트가 사용되지 않고 VM이 유휴 상태가 되며 권한이 부여되었으나 더 이상 필요하지 않게 되어도 삭제되지 않습니다. 복잡성을 줄이기 위해서는 최신 애셋 인벤토리를 유지하고 Active Assist의 권장사항과 통계를 사용하여 검토하는 것이 좋습니다. Active Assist는 유휴 상태 VM 찾기, 초과 IAM 권한 삭제, 사용하지 않는 프로젝트 삭제 또는 회수에 대한 권장사항을 제공합니다.
이러한 권장사항을 사용하면 조직에 상당한 혜택을 가져올 수 있습니다. 이러한 혜택에는 불필요한 지출 감소, 보안 위험 감소, 조직의 성능 관리 및 관리 효율성 증가가 포함됩니다.
모든 Google Cloud 프로젝트 및 관련 리소스의 인벤토리와 기록에 액세스하려면 Cloud 애셋 인벤토리를 사용하면 됩니다. 애셋 기록을 BigQuery 또는 Cloud Storage로 내보낼 수 있습니다.
액세스 제어 관리
이 섹션에서는 Google Cloud 및 Google Workspace 서비스에 대한 액세스를 관리하기 위한 권장사항을 설명합니다.
정책 관리에 그룹 사용
IAM에서는 정책에서 개인 대신 그룹을 사용하는 것이 좋습니다. 팀 구성원이 합류하거나 나가면 그룹 구성원을 조정할 수 있으며 자동으로 올바른 정책 변경사항이 적용됩니다. 이를 구현하려면 프로젝트별 또는 폴더별로 직무에 따른 Google 그룹스를 만듭니다. 그런 다음 각 그룹에 직무별 필요에 따라 다양한 역할을 할당합니다.
최고 관리자나 위임된 관리자가 그룹을 관리하려면 Google Workspace 관리 콘솔을 사용하면 됩니다.
최소 권한을 사용하여 신뢰 경계 만들기
프로젝트 구조를 결정할 때는 기존 IT 거버넌스나 보안 모델을 따르는 IT 신뢰 경계를 고려하세요. 예를 들어 엔지니어링, 비즈니스, 법률 등 서로 간에 신뢰 경계를 유지해야 하는 별도의 부서가 조직에 있는 경우를 고려해 볼 수 있습니다.
최소 권한 보안 권장사항을 적용하면 프로젝트 전체의 사용자 계정과 서비스 계정에 다른 역할을 부여할 수 있습니다. 어떤 사용자가 한 프로젝트에 대해 관리자 수준의 액세스 권한이 있지만 다른 프로젝트에 대해서는 뷰어 권한만 필요한 경우 허용 정책을 사용하여 이러한 역할을 명시적으로 정의할 수 있습니다. 자세한 내용은 최소 권한에 대한 IAM 지침을 참조하세요.
서비스 계정, 역할, 정책을 사용하여 리소스에 대한 액세스 관리
대규모 조직에서는 보안, 네트워크 관리와 같은 운영팀을 다른 부서와 분리하는 경우가 많습니다. 이와 같이 팀을 분리할 경우에는 다른 팀에서 관리하는 리소스를 사용해야 하며 최소 권한의 원칙을 따라야 합니다. IAM 및 서비스 계정을 사용하여 분리를 구성합니다.
IAM을 사용하면 누가 어떤 리소스에 대한 어떤 액세스 수준을 갖는지 정의해 액세스 제어를 관리할 수 있습니다. 허용 정책을 만들어 사용자에게 역할을 부여합니다. 특정 Google Cloud 리소스에 대한 세분화된 액세스 권한을 부여하려면 사전 정의된 역할을 사용하거나 커스텀 역할을 정의합니다.
기본적으로 Google Cloud에서 Google Workspace의 최고 관리자에게 조직 관리자 역할이 할당됩니다. 이 역할은 다른 사용자에게 권한을 부여하는 데 사용되며 최고 관리자 계정에서 삭제될 수 없습니다. 최고 관리자가 부여하는 가장 중요한 역할은 지정된 사용자가 자체 프로젝트를 만들 수 있도록 하는 프로젝트 생성자 역할입니다.
서비스 계정에 대한 자세한 내용은 서비스 계정 이해를 참조하세요.
필요한 경우에만 권한이 있는 계정 만들기
최소 권한의 원칙에 따라 관리자의 일반 계정과 별도의 계정에 최고 관리자 역할을 할당합니다. 예를 들어 일상적인 활동에는 alex@school.edu를 사용하고 Google Workspace 관리자 콘솔 또는 Google Cloud 콘솔을 변경할 때는 alex.admin@school.edu를 사용할 수 있습니다.
워크로드 ID 만들기
Google Cloud에서는 사용자 인증 정보가 직접 포함되지 않도록 서비스 계정을 사용하여 Google API 호출을 호출합니다. 이러한 계정은 다음과 같은 방식으로 ID와 리소스로 취급됩니다.
- 서비스 계정이 ID 역할을 하는 경우 해당 계정이 스토리지 버킷과 같은 리소스에 액세스할 수 있도록 역할을 부여합니다.
- 서비스 계정이 리소스 역할을 하는 경우 BigQuery 데이터 세트에 대한 액세스 권한을 부여할 때와 마찬가지로 해당 계정에 액세스할 수 있는 권한을 사용자에게 부여해야 합니다. 소유자, 편집자, 뷰어 또는 서비스 계정 사용자 역할을 사용자에게 부여할 수 있습니다. 서비스 계정 사용자 역할이 있는 사용자는 서비스 계정에서 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다.
결제 관리
Cloud Billing 계정에는 두 가지 유형, 즉 셀프 서비스(또는 온라인) 계정과 인보이스(또는 오프라인) 계정이 있습니다.
셀프 서비스 계정 기능은 다음과 같습니다.
- 거주 국가나 리전에서 지원되는 경우 신용카드, 체크카드 또는 ACH 자동이체와 같은 결제 수단을 사용하여 결제가 진행됩니다.
- 비용은 Cloud Billing 계정에 연결된 결제 수단으로 자동 청구됩니다.
- Google 도움 없이 셀프 서비스 계정에 가입할 수 있습니다.
- 셀프 서비스 계정에서 생성된 문서에는 명세서, 결제 영수증, 세금 인보이스가 포함됩니다. 콘솔에서 이러한 문서에 액세스할 수 있습니다.
인보이스 계정 기능은 다음과 같습니다.
- 결제는 은행 송금을 통해 이루어집니다.
- 우편이나 전자적인 방식으로 인보이스가 발송됩니다.
- 콘솔에서 인보이스 및 결제 영수증에 액세스할 수 있습니다.
- 인보이스 결제 요건을 충족해야 합니다. 자세한 내용은 인보이스 결제 요건을 참조하세요.
다음 섹션에서는 두 가지 유형의 Cloud Billing 계정에 대한 권장사항을 설명합니다.
분석을 위해 BigQuery로 Cloud Billing 데이터 내보내기
사용량과 비용을 분석하려면 BigQuery 데이터 세트로 결제 데이터를 내보냅니다.
결제 데이터를 BigQuery로 내보내면 설정한 한도를 초과하여 지출한 프로젝트를 찾을 수 있습니다. 요금이 청구되는 서비스의 목록을 쿼리할 수도 있습니다. 예를 들어 다음 쿼리는 이번 달에 $0.10를 초과 지출한 모든 프로젝트를 나열합니다.
SELECT
project.name,
cost
FROM
YOUR_BIGQUERY_TABLE
WHERE
cost > 0.1 AND usage_month IN "YYYY-MM"
ORDER BY
cost DESC
다음을 바꿉니다.
- YOUR_BIGQUERY_TABLE을 테이블 이름으로 바꿉니다.
- YYYY-MM을 이번 달과 날짜로 바꿉니다. 예를 들면
2022-10입니다.
단일 결제 계정을 사용하여 결제 및 예산 관리
Google Cloud 콘솔을 사용하여 Cloud Billing 계정을 관리합니다. Console에서 결제 수단, 관리자 연락처 등 계정 설정을 업데이트할 수 있습니다. 예산 설정, 알림 전송, 결제 내역 보기, 결제 데이터 내보내기 등의 콘솔 구성도 가능합니다.
대부분의 조직에서는 모든 프로젝트에 결제 계정이 하나만 있어도 충분합니다. 조직 전체 할인은 결제 계정과 연결된 모든 프로젝트에 적용됩니다. Google에 한 번만 결제하여 월별 인보이스를 정산하고 내부 IT 지불 거절 프로세스를 사용해 대행사별, 부문별 또는 실험실별 프로젝트 요금을 부과할 수 있습니다.
다음 다이어그램에서는 단일 결제 계정 작동 방식을 보여줍니다.
결제 고려사항은 Google Cloud의 프로젝트 정리 방식과 폴더 정리 방식에도 영향을 줄 수 있습니다. 내부 비용 센터에 따라 다음 다이어그램과 같이 정리를 결정할 수 있습니다.
이 다이어그램에서는 폴더로 비용 센터, 부서, 또는 IT 프로젝트와 관련된 모든 프로젝트 및 애셋이 식별됩니다. 각 프로젝트에 대한 비용이 표시되며 BigQuery로 결제 내보내기에는 프로젝트 ID가 포함됩니다.
비용 센터에서 별도의 인보이스를 결제해야 하거나 조직에 다른 통화로 결제해야 하는 워크로드가 있는 경우 여러 결제 계정을 사용하는 것이 좋습니다. 이 접근 방식에는 각 결제 계정 또는 Google Cloud 리셀러와의 참여에 대해 서명 동의가 필요할 수 있습니다.
결제 계정 역할 할당
결제 계정 역할을 사용하여 결제 계정을 관리할 수 있습니다. 조직 수준에서 특정 사용자에게 다음과 같은 결제 역할을 할당할 수 있습니다.
| 역할 | 설명 |
|---|---|
| 결제 계정 관리자 | 조직의 모든 결제 계정을 관리합니다. |
| 결제 계정 생성자 | 조직의 결제 계정을 만듭니다. |
| 결제 계정 사용자 | 프로젝트를 결제 계정과 연결합니다. |
| 프로젝트 결제 관리자 | 프로젝트의 결제 계정을 할당하거나 프로젝트 결제를 사용 중지하는 액세스 권한을 제공합니다. |
| 결제 계정 비용 관리자 | 결제 계정의 예산 및 뷰를 관리하고 비용 정보를 내보냅니다(가격 책정 정보는 보거나 내보낼 수 없음). |
| 결제 계정 뷰어 | 결제 계정 비용 정보 및 거래를 봅니다. |
사용자가 조직의 모든 결제 계정을 볼 수 있도록 하려면 조직 수준에서 결제 계정 관리자 역할을 부여합니다. 결제 계정을 만들 수 있는 사용자와 그 방법을 제한하려면 결제 계정 생성자 역할로 이 권한을 가진 사용자를 제한합니다. 자세한 내용은 결제 계정 만들기, 수정 또는 닫기 및 결제 액세스 제어 개요를 참조하세요.
프로젝트의 결제 계정을 변경하려면 프로젝트의 결제 계정을 변경하는 방법을 참조하세요.
결제를 모니터링하도록 예산 및 알림 만들기
결제 계정과 개별 프로젝트를 모니터링하려면 예산을 만들고 이메일 알림을 결제 관리자와 결제 권한 사용자에게 보내면 됩니다.
예산에 따른 경고가 제공되지만 프로젝트의 결제가 사용 중지되지는 않습니다. 즉, 예산을 초과해도 프로젝트가 계속 실행됩니다. 프로젝트 실행 시 예산을 초과한 경우 직접 결제를 사용 중지해야 합니다. 또한 예산은 실시간으로 업데이트되지 않으므로 하루 또는 이틀 동안 과다 지출 문제가 발견되지 않을 수 있습니다.
결제 관리자나 결제 권한 사용자가 아닌 사용자에게 예산 알림을 보내려면 Cloud Monitoring 알림 채널을 구성합니다.
라벨을 사용한 리소스 정리
라벨은 Google Cloud 리소스를 구성하는 데 도움이 되는 키-값 쌍입니다. 라벨은 결제 시스템으로 전달되며 BigQuery로 결제 내보내기에 포함됩니다. 라벨을 사용하면 라벨별 청구 요금을 쿼리할 수 있습니다.
부서, 대학, 워크로드 또는 실습별로 리소스에 라벨을 추가하면 새 프로젝트마다 별도의 결제 계정을 만들지 않고도 청구 금액을 올바른 항목에 연결할 수 있습니다. 라벨에 대한 자세한 내용은 라벨 만들기 및 관리를 참조하세요.
할당량 및 한도 모니터링
Google Cloud 내 많은 리소스가 할당량에 따라 제한됩니다. 예를 들어 새로 연결된 결제 계정과 연결된 새 프로젝트는 Compute Engine에서 가상 CPU 8개가 할당량으로 적용됩니다. Google Cloud 콘솔에서 테스트 할당량 사용량을 모니터링할 수 있습니다. 또한 할당량 증가를 요청하여 더 많은 리소스나 새 리소스(예: GPU)에 액세스할 수 있습니다.
네트워크 관리
이 섹션에서는 Google Cloud 네트워크 관리에 대한 권장사항을 설명합니다.
네트워킹 방법 선택
VPC로 클라우드 서비스를 분리합니다. 예를 들어 VPC를 사용하여 모든 프로젝트에 걸쳐 공통 및 비공개 RFC 1918 IP 공간이 포함된 네트워크를 설정합니다. 프로젝트의 인스턴스를 이 네트워크 또는 하위 네트워크에 추가할 수 있습니다. 새 프로젝트마다 기본 VPC 네트워크가 생성됩니다. 이 기본 네트워크는 테스트나 개발에 적합하지만 프로덕션용 커스텀 VPC 네트워크로 바꿔야 합니다.
단일 네트워크에 Cloud VPN을 연결하여 모든 프로젝트나 프로젝트 하위 집합에서 사용할 수도 있습니다. VPN 연결을 사용하여 Google Cloud별 RFC 1918 IP 공간에 연결하거나 온프레미스 네트워크의 RFC 1918 IP 주소 공간을 확장합니다.
다음 표에서는 Google Cloud에서 가장 일반적인 네트워킹 옵션 2개를 설명합니다.
| 네트워킹 옵션 | 설명 |
|---|---|
| 다이렉트 피어링 | 등록된 자율 시스템 번호(ASN)가 있고 공개적으로 라우팅 가능한 IP 프리픽스가 있는 경우 다이렉트 피어링을 사용하여 Google에 연결합니다. 이 옵션은 공개 인터넷과 동일한 상호 연결 모델을 사용합니다. 그러나 공개 인터넷과 달리 서비스 제공업체는 없습니다. 자세한 내용은 Google 에지 네트워크를 참조하세요. |
| 이동통신사 피어링 | 공개 ASN이 없거나 서비스 제공업체를 사용하여 Google에 연결하려면 이동통신사 피어링을 사용합니다. 이동통신사 피어링은 Google의 에지 네트워크에 대한 엔터프라이즈 수준의 연결을 원하는 고객을 위해 설계되었습니다. |
이그레스 트래픽과 관련된 비용을 예측하기가 어려운 경우가 많습니다. Internet2 Higher Education 회원을 지원하기 위해 Google은 정가로 계산된 인터넷 이그레스 수수료를 월간 소비 비용 합계의 최대 15%까지 할인하고 있습니다. 이 혜택은 특정 인터넷 이그레스 SKU에 적용됩니다.
네트워킹 옵션에 대한 자세한 내용은 네트워크 연결 제품 선택을 참조하세요.
도움말 보기
이 섹션에서는 Google의 지원을 받는 권장사항을 설명합니다.
니즈에 맞는 지원 요금제 선택
조직의 니즈에 맞는 지원 요금제를 선택하고 지원 케이스를 만들 수 있는 적절한 권한이 있는 문서를 작성합니다.
베이직 지원은 모든 Google Cloud 사용자에게 무료로 제공됩니다. 베이직에는 결제 지원은 포함되지만 기술 지원은 포함되지 않습니다. 기술 지원을 받으려면 기술 지원 요금제를 구매해야 합니다.
조직 수준에서만 Google Cloud 기술 지원 요금제를 구매할 수 있습니다. 기술 지원 요금은 프로젝트 수준에서 조직의 모든 프로젝트에 청구됩니다.
지원 요금제의 기능 및 비용 비교에 대한 자세한 내용은 Cloud Customer Care를 참조하세요.
적어도 SLED 조직은 스탠더드 지원 요금제를 구매하는 것이 좋습니다. 그러나 조직에서 비즈니스에 중요한 워크로드를 실행 중인 경우 고급 지원 요금제를 구입하는 것이 좋습니다. 고급 지원 요금제를 사용하면 Customer Care에 연중무휴로 액세스하고, Customer Support API를 사용하여 케이스를 만들고, 케이스를 에스컬레이션할 수 있습니다.
조직의 경우 기술계정 관리자가 가이드 온보딩, 케이스 관리, 케이스 에스컬레이션, 월별 운영 상태 검토를 지원할 수 있습니다. 기술계정 관리자가 필요하지만 프리미엄 지원 요금제를 원하지 않는 경우 Technical Account Advisor Service를 사용하는 것이 좋습니다.
Google Cloud 콘솔을 사용하여 스탠더드 지원과 향상된 지원을 구매할 수 있습니다. 프리미엄 지원을 구매하려면 영업팀에 문의하세요.
지원 케이스 만들기 및 에스컬레이션
케이스를 만들려면 Google Cloud 콘솔이나 Cloud Support API(고급 또는 프리미엄 지원 필요)를 사용하면 됩니다. 케이스를 만들 때 적절한 지원 케이스 우선순위를 고려하세요.
케이스에 적절한 케이스 우선순위를 이미 설정했지만 지원 프로세스에서 문제가 발생하면 케이스를 에스컬레이션할 수 있습니다. 케이스를 에스컬레이션할 수 있는 이유 목록은 케이스 에스컬레이션을 참조하세요.
프리미엄 지원 서비스를 사용하는 경우 지역 영업 시간에 기술계정 관리자에게 문의하여 에스컬레이션을 요청할 수도 있습니다.
다음 단계
- 각 Google Cloud 서비스에 대해 자세히 알아보기
- Network Intelligence Center 자세히 알아보기
- Google Cloud 서비스에서 Amazon Web Services(AWS) 또는 Microsoft Azure 서비스에 매핑하는 방법 알아보기
- Google Cloud 교육 기초 강의를 듣거나 인증 취득하기
- Google Cloud 교육 실습 및 과정에 대한 Cloud Skills Boost 살펴보기