1. 기본 Oracle Cloud Infrastructure Governance 모델 설정
  2. 기준 거버넌스 수명 주기

기준 거버넌스 수명 주기

기술 팀이 처음으로 클라우드에 대해 정의하고 적용하는 기본 보안 정책 및 원칙 세트입니다.

리소스 구성

단일 애플리케이션이나 여러 애플리케이션을 프로비저닝하든 테넌시에서 제어를 유지하는 데 필요한 성장, 유연성 및 책임성에 대한 리소스를 구성해야 합니다.

다음을 기반으로 리소스를 구성합니다.

  • 구획: 조직에 대한 특정 레시피가 있는 구획입니다.
  • 리소스 위치: 대상 오디언스가 있는 위치를 기반으로 하는 영역입니다.
  • 리소스 격리: VCN(가상 클라우드 네트워크) 및 서브넷과 같은 적절한 네트워크 제어

구획 설계

다음 이미지는 특정 결과를 얻기 위해 구획에서 리소스를 구성할 수 있는 방법에 대한 예를 보여줍니다.

다음은 oci-governance-compartment-design.png에 대한 설명입니다.
oci-governance-compartment-design.png 그림에 대한 설명

각 조직은 필요한 결과에 특정한 구획 구조 레시피를 사용할 수 있습니다. 사용 가능한 미리 정의된 템플리트를 기반으로 조직 구조를 작성할 수 있습니다. OCI CIS 랜딩 영역은 네트워크, 보안, 애플리케이션 및 데이터베이스 리소스를 다루는 광범위한 구획 구조 템플리트를 제공합니다. 구획 구조를 확장하여 여러 애플리케이션 또는 서로 다른 라이프사이클 환경(Dev, Test, Prod)에 별도의 하위 구획을 추가할 수 있습니다. 여기서 CIS 랜딩 존 템플릿 이미지를 확인하십시오.

계층적 구획 모델

루트 레벨에서 시작되는 구획 계층의 여러 레벨에서 정의해야 하는 정책을 정의합니다.

루트 수준

IAM 정책 정의

레벨 1

네트워크, 공유 보안, app-dev 및 데이터베이스 정책 정의

레벨 2

프로덕트, 비프로덕트, 프로토타입 정책 정의:

  • 네트워크: 네트워크 제품군
    • Prod and Non: 운용 VCN 및 운용 서브넷
  • 공유 보안: KMS, 로깅, 통지, 저장소
  • App-Dev: OS 버킷, 부트 및 블록 볼륨, FSS
    • 제품: 제품 OAC, OIC, FAW
    • Prototype: 모든 프로토타입 서비스
  • 데이터베이스: 제품 AWD, 비운용 ADW

효과적인 구획 설계를 개발하려면 거버넌스 모델을 작성해야 합니다. 구획 설계는 언제든지 변경하여 조직에서 비즈니스 또는 프로세스 변경을 수행할 수 있습니다. 또한 OCI에서 프로비저닝된 리소스를 한 구획에서 다른 구획으로 이동할 수 있습니다.

자원 지리적 위치

지역 영역에서 자원을 생성하고 대상자의 위치를 기준으로 지역을 선택해야 합니다. 유럽 고객 애플리케이션을 위한 애플리케이션은 유럽 지역의 데이터 센터에 위치해야 합니다. 가용성을 극대화하려면 지역 내의 애플리케이션 리소스를 가용성 도메인과 장애 도메인에 분산해야 합니다. 모든 리소스 또는 작업 로드에 대해 여러 조건에 따라 적절한 영역을 선택해야 합니다.

리소스 네트워크 격리

구획을 사용하여 리소스를 격리할 수 없습니다. 네트워킹 제어를 사용하여 리소스를 격리할 수 있습니다. 리소스를 격리하려면 다른 VCN 및 서브넷에서 리소스를 구성해야 합니다. 동일한 애플리케이션에 속하는 리소스를 동일한 VCN에 포함하고 다른 VCN에 있는 다른 애플리케이션의 리소스를 포함합니다. 두 애플리케이션이 서로 통신해야 하는 경우, VCN을 공유하거나 두 VCN을 페어링할 수 있습니다.

리소스 ID 관리

효과적인 리소스 거버넌스를 위해서는 직원의 ID를 설정하는 것이 중요합니다.

다음은 oci-identity-governance.png에 대한 설명입니다.
oci-identity-governance.png 그림에 대한 설명

ID 거버넌스 시나리오

신규입사자가 조직에 합류하면 HR 시스템은 사용자 ID를 생성하고 중앙 집중식 정책 기반 ID 및 해당 자격 세트를 프로비저닝합니다. 새 사용자는 출생 오른쪽 자격 프로비저닝이라는 특정 리소스 및 응용 프로그램에 대한 기본 액세스를 얻습니다. 그러면 사용자의 조직, 그룹 및 역할에 따라 사용자에게 추가 응용 프로그램 및 자격에 대한 액세스 권한이 부여됩니다.

사용자는 승인 프로세스를 거치는 추가 자격 부여를 요청하여 해당 자격 부여에 자신을 지정할 수 있습니다. 사용자가 조직을 폐기하거나 나가면 ID가 프로비전 해제됩니다. 조직에서 동일한 사용자가 재고용되는 경우 사용자는 일반적으로 동일한 ID를 청구할 수 있지만 고용된 그룹 또는 역할에 따라 다른 자격을 가질 수 있습니다.

클라우드에서의 ID

다음은 oci-identity-cloud.png에 대한 설명입니다.
oci-identity-cloud.png 그림에 대한 설명

Oracle은 Oracle Cloud Infrastructure Identity and Access Management(IAM)를 사용하여 IaaS, PaaS 및 SaaS 전반에서 통합 ID를 제공합니다. 모든 OCI IaaS 및 PaaS 서비스를 연결하는 통합 ID에는 OCI IAM과의 기본 통합이 있습니다. 사용자 저장소와 로그인 서비스 모두 OCI IAM을 사용합니다. 그러나 Fusion SaaS 서비스를 비롯한 OCI상의 SaaS 서비스는 SCIM 2.0 및 SAML 표준을 사용하여 OCI IAM과 통합됩니다. 고객은 IAM OAuth을 사용하여 PaaS 서비스와 SaaS를 통합할 수도 있습니다. SCIM 2.0, SAML 및 OIDC 같은 개방형 표준을 사용하여 Oracle Cloud를 온프레미스 또는 타사 클라우드와 통합할 수 있습니다.

통합 ID 서비스는 사용자 온보딩 및 오프보딩 프로세스를 간소화합니다. 유저 계정이 HR 시스템에서 생성되거나 제거되면 OCI IAM은 모든 Oracle 서비스에서 유저 계정을 생성하거나 제거합니다. 또한 OCI IAM 서비스를 사용하면 타사 클라우드 서비스를 손쉽게 유저 계정을 생성하고 제거할 수 있습니다.

OCI IAM은 Oracle Cloud의 ID에 대한 단일 정보 소스를 제공합니다. 고객은 IAM 감사 로그를 활용하여 클라우드 시스템 또는 리소스에 접근 가능한 사용자를 확인할 수 있습니다. 또한 보안 위협 모델링을 실행하여 무단 액세스를 감지하고 수정 조치를 취할 수 있습니다.

리소스 액세스 관리

OCI에는 기본값별 거부 보안 상태가 있습니다. 테넌시가 프로비전될 때 테넌시 관리자 사용자 이외의 사용자가 OCI의 리소스에 액세스할 수 없습니다.

테넌시 관리자는 구획 또는 테넌시 내의 리소스에 대해 사용자 그룹에 권한을 부여하기 위한 정책을 생성할 수 있습니다. 다음은 구획 섹션에서 제안한 구획 구조의 시작점으로 사용할 수 있는 몇 가지 샘플 IAM 정책입니다.

  1. 구획 관리자가 해당 구획의 모든 리소스를 관리할 수 있도록 정책을 생성합니다. 
    • Allow group security_admin to manage all resources in compartment Shared_Security:Prod
Allow group security_admin to manage all resources in compartment Shared_Security:NonProd
Allow group network_admin to manage network-family-resources in compartment Network
Allow group database_admin to manage database-family-resources in compartment Database
Allow group appdev_admin to manage instance-family-resources in compartment App-Dev
  2. 다른 구획의 공유 리소스를 사용할 구획 관리자에 대한 정책을 생성합니다. 
    • Allow group appdev_admin to use network-family-resources in compartment Network
Allow group appdev_admin to use database-family-resources in compartment Database
Allow group database_admin to use network-family-resources in compartment Network
Allow group database_admin to use vaults in compartment Shared_Security
  3. 감사자와 기타 읽기 전용 사용자 그룹에 대한 정책을 생성하여 테넌시의 모든 리소스를 읽습니다. 
    • Allow group auditors to read all resources in tenancy
Allow helpdesk-users to inspect all resources in tenancy
Allow group announcement_readers_group to read announcements in tenancy

태그를 사용하여 IAM 정책을 정의할 수도 있습니다. 조건 및 태그 변수 세트를 사용하여 리소스에 적용된 태그를 기반으로 액세스 범위를 지정하기 위한 정책을 작성할 수 있습니다. 요청 리소스(그룹, 동적 그룹 또는 구획) 또는 요청 대상(리소스 또는 구획)에 있는 태그를 기반으로 접근을 제어할 수 있습니다. 처음 세 개의 샘플 액세스 정책은 요청 리소스 태그를 사용하고 마지막 두 개의 샘플 액세스 정책은 대상 리소스 태그를 사용합니다.

Allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'

온보딩하는 모든 워크로드에 대해 세 개의 상위 레벨 롤로 시작합니다.

  1. 서비스 관리자
  2. 서비스 개발자
  3. 서비스 뷰어

각 역할에 대한 기준 정책을 생성하여 서비스 인스턴스를 관리, 사용, 읽기 및 검사합니다. 정책을 생성하여 공유 리소스에 대한 사용자에게 서비스 관리자에게 권한을 부여할 수 있습니다. 예를 들어, 분석 서비스의 경우 다음 정책을 생성할 수 있습니다.

  1. 서비스 관리자 롤 
    • Allow group Analytics-admin to manage analytics-instances in compartment App-Dev
Allow group Analytics-admin to manage analytics-instance-work-requests in compartment App-Dev
Allow group Analytics-admin to use network-family-resources in compartment Network
Allow group Analytics-admin to use autonomous-databases in compartment Database
  2. 서비스 개발자 롤 
    • Allow group Analytics-developer to use analytics-instances in compartment App-Dev
Allow group Analytics-developer to use analytics-instance-work-requests in compartment App-Dev
  3. 서비스 뷰어 역할 
    • Allow group Analytics-viewer to read analytics-instances in compartment App-Dev
Allow group Analytics-viewer to read analytics-instance-work-requests in compartment App-Dev

이러한 정책이나 유사한 정책으로 프로세스를 시작하고 온보딩한 모든 새 서비스로 정책 모델을 확장할 수 있습니다.

리소스 비용 관리

프로젝트 구현 시 많은 비용이 고정되는 CapEx 모델에서 시스템 사용과 함께 비용 확장 및 축소가 가능한 OpEx 모델로 전환할 때 조직 내에서 이러한 클라우드 비용을 파악, 제어 및 전달하기 위해 비용 관리 툴이 필요한 경우가 많습니다.

Oracle은 조직의 지출을 관리하고 비용을 최적화할 수 있는 툴을 제공합니다.

  • 예측: 클라우드 예산 설정 및 관리
  • 제어: 과도한 지출을 방지합니다.
  • 가시성: 부서 및 프로젝트 전반에 걸쳐 정확한 비용 추적을 보장하고 기간 경과에 따라 클라우드 사용에 영향을 미치는 부서, 서비스 및 프로젝트를 분석할 수 있습니다.
  • 최적화: 송장 조정을 위한 세분화된 사용 세부정보를 확보하고 비용을 최적화할 영역을 식별할 수 있습니다.
  • 확장: 필요한 경우 사용을 확장할 영역을 식별합니다.

원가 관리

이러한 두 가지 방법 중 하나를 사용하여 비용을 제어할 수 있습니다.

  • 모든 팀/자원 그룹에 대한 재무 예산을 생성하고 해당 예산에 대한 사용량을 추적하며 사용량이 예산을 초과하거나 예산을 초과하는 경우 팀 관리자에게 알립니다.
  • 모든 서비스 인스턴스에 대한 제한 또는 할당량을 생성합니다. 팀에서 할당된 할당량보다 많은 인스턴스를 만들려고 하면 요청이 실패합니다.

두 번째 접근 방식은 제한적이며 비용 초과를 방지하는 반면, 사용량이 지정된 예산을 초과할 경우 첫 번째 접근 방식에는 수동 개입이 필요합니다. 구획 트리는 예산 및 할당량을 집계하므로, 하위 구획이 상위에 설정된 총 집계 예산 또는 할당량을 공유합니다.

예를 들어 구획 데이터 과학의 예산이 $2000인 경우 DEV 및 TST의 하위 구획이 해당 글로벌 예산을 공유하며, 둘 중 하나가 이 한도를 초과하는 경우 제한됩니다.

비용 추적

비용 추적 태그 또는 구획(루트 구획 포함)을 설정하여 OCI 지출에 대한 부분 제한을 설정하는 예산을 사용할 수 있습니다. 해당 비용 추적 태그 또는 해당 구획과 하위 구획에 대한 모든 지출을 추적할 수 있습니다. 예산이 예산을 초과할 때 관리에 알리기 위해 예산에 대한 경보를 설정할 수도 있습니다. OCI 콘솔에서 모든 예산 및 지출 한도를 확인할 수 있습니다.

시스템에서는 대부분의 지역과 애슈번(IAD)에서 4시간마다 모든 예산 경보를 평가합니다. 예산이 마지막으로 평가된 시간을 보려면 예산에 대한 세부정보를 검토하십시오. 현재 지출, 예측 및 예산이 평가된 기간을 보여주는 [기간 내 지출] 필드를 표시하는 필드가 표시됩니다. 예산 경보가 트리거되면 예산 경보에 구성된 수신자에게 전자메일이 전송됩니다.

자세한 탐색 섹션에 링크된 Oracle Cloud Marketplace에서 OCI Cost Governance and Performance Insights Solution 앱을 설치하고 사용할 수 있습니다.

비용 관리

서비스 제한 및 구획 할당량을 사용하여 생성된 서비스 인스턴스 수를 제한하여 OCI에서 비용을 제어할 수 있습니다.

서비스 제한을 통해 테넌시, 지역, 가용성 도메인 및 구획에서 프로비저닝할 수 있는 최대 리소스 수를 관리할 수 있습니다. 이러한 소프트 제한으로 인해 프로비전 리소스가 정의된 제한을 초과할 수 없습니다. 권한이 부여된 사용자만 이러한 서비스 제한을 늘리거나 줄일 수 있습니다. 서비스 제한을 사용하면 지역, 가용성 도메인 및 구획에서 특정 서비스의 최대 서비스 인스턴스 수를 제한할 수 있습니다.

구획 할당량이란 관리자가 테넌시 및 구획 관리자가 OCI에서 리소스가 소비되는 방식을 더 효과적으로 제어할 수 있도록 함으로써 리소스를 할당할 수 있도록 해주는 정책입니다. Oracle에서 서비스 한도를 설정한 점을 제외하고 구획 할당량은 서비스 한도와 유사합니다. 구획 할당량은 관리자가 높은 수준의 유연성으로 리소스를 할당할 수 있도록 정책을 사용하여 설정합니다.

리소스 관찰 및 모니터링

리소스를 관찰하고 모니터링하여 거버넌스 모델이 조직 목표 달성을 위해 작동하는지 확인해야 합니다.

클라우드 보안 상황 관리

Cloud Guard는 Oracle Cloud에서 강력한 보안 상태를 모니터링하고 유지보수하는 데 도움이 되는 OCI 서비스입니다. Cloud Guard에는 세 가지 필수 요소가 있습니다.

  • 대상은 모니터할 리소스입니다.
  • 감지기 레시피는 문제를 감지하는 레시피입니다.
  • 문제가 감지되면 응답기 레시피가 해당 문제에 응답합니다. 응답은 통지 또는 수정 조치일 수 있습니다.

Cloud Guard는 OCI 리소스의 보안 구성 문제를 감지합니다. 문제의 가능한 영향을 기반으로 위험 점수를 문제에 지정합니다. Cloud Guard 대시보드에서 테넌시의 집계된 위험 점수를 모니터할 수 있습니다. 다음은 Cloud Guard를 사용하기 위한 권장 사항입니다.

  • Cloud Guard는 무료 서비스이며 모든 구획에 대해 Cloud Guard를 활성화하는 것이 가장 좋습니다.
  • Cloud Guard 레시피를 사용자정의하여 감지된 문제에 대한 사용자정의 위험 점수 및 응답 작업을 정의합니다.
  • 일부 구획이 특정 다른 구획에서 리소스를 제공하지 않도록 제외하도록 선택합니다. 예를 들어 개발 구획을 제외할 경우 운용 구획에서 허용되지 않는 리소스를 생성할 수 있는 유연성을 제공할 수 있습니다.

Cloud Guard는 Cloud Guard 정책에 대한 예외 목록인 허용 목록을 지원합니다. 예를 들어, Cloud Guard 정책이 공용 객체 저장소 버킷을 거부하도록 설정된 경우입니다. 적절한 사용 사례에 따라 퍼블릭 버킷을 생성해야 하는 경우 퍼블릭 버킷의 OCID를 허용 목록에 명시적으로 추가할 수 있습니다.

보안 로깅

모든 클라우드 리소스에 대한 모든 작업을 중앙 집중식으로 기록하고 클라우드 에코시스템에서 감사할 수 있어 성공적인 클라우드 구현을 보장합니다. 또한 네트워크 플로우 로그 및 일부 응용 프로그램 로그를 사용하여 변형 동작을 감지할 수 있습니다. 보안 및 규제준수 팀은 원치 않는 모든 사고에 대한 통지 또는 수정 조치를 자동화할 수 있습니다. 빠른 조치를 허용하면 모든 침해와 위협을 완화할 수 있습니다.

데이터 모니터링, 감사 및 로깅을 기반으로 하는 대시보드와 보고서는 팀이 재해가 발생하기 전에 문제를 업데이트하고 해결하는 데 중점을 둘 수 있습니다. 보안 로깅을 설정하여 다음을 수행할 수 있습니다.

  • 집계 감사 로그(OCI에서 기본적으로 설정됨)는 Logging Analytics를 사용하여 로그 그룹을 모니터할 수 있습니다.
  • 의심스러운 네트워크 작업을 감지하기 위해 네트워크 플로우 로그를 사용으로 설정합니다.
  • 서비스 로그를 지원하는 모든 서비스에 대해 서비스 로그를 사용으로 설정합니다. 서비스 로그를 사용으로 설정하는 동안 적절한 로그 그룹을 선택해야 합니다.
  • Logging Analytics의 대화식 시각화를 사용하여 데이터를 분석합니다. 클러스터 기능을 사용하여 수백만 개의 로그 항목을 작은 일련의 흥미로운 로그 서명으로 줄여 손쉽게 로그를 검토할 수 있습니다.
  • 로깅 분석의 링크 기능을 사용하여 트랜잭션의 로그를 분석하고 그룹화된 뷰를 사용하여 변형 패턴을 식별합니다.

타사 SIEM 솔루션을 사용하는 경우 OCI 스트리밍 서비스 및 서비스 커넥터를 사용하여 OCI와 통합할 수 있습니다.

기준 거버넌스 구현

Oracle은 보안 랜딩 영역을 사용하여 리소스 조직(구획 구조) 및 리소스 액세스 거버넌스를 구현할 것을 권장합니다.

기준 요소 관리를 통해 테넌시 구조 및 액세스 정책을 생성할 뿐 아니라 Cloud Guard, 감사 및 로깅과 같은 기타 보안 기능도 사용할 수 있어야 합니다.

또한 다음 절에서 권장하는 대로 태깅 구조 및 비용 거버넌스 구조를 생성해야 합니다.

태그 지정

다음 표의 태그 네임스페이스는 Cost-Management입니다.

태그 키 샘플 키-값 설명
이름 - -
CostCenterID ERP-U, ERP-Uk 프로젝트 코드 이름

다음 표의 태그 네임스페이스는 Operations입니다.

태그 키 샘플 키-값 설명
환경 운용, 비운용 수명 주기 환경
AppName 재무, HR 비즈니스 단위
AppCI - -
OProjectName 재무-EBS, 재무-ERP -
업무 소유자 ABC.someone@example.com -
SystemCustodian ABC.someone@example.com -
여기 SupportGrp ABC.someone@example.com -
OS 린, 윈 -
유지 관리 Group1, Group2, Group3 -
영향 낮음, 중간, 높음 조직 내 폭발 반경

다음 표의 태그 네임스페이스는 Govn-Security입니다.

태그 키 샘플 키-값 설명
InfoClass 공개, 내부, 민감 -
NetTrustLevel 기업(3)/공급업체 DMZ(2)/인터넷 DMZ(1)/방화벽 -
중요도 T1, T2, T3, T4
  • 계층 1: 가장 중요
  • 계층 2: 중요
  • 계층 3: 중요하지 않은 업무 작업 로드
  • 계층 4: 중요하지 않은 IT 업무

비용 거버넌스

OCI 콘솔에서 Governance 아래의 Tag Namespaces UI를 사용하고 다음을 수행합니다.

  1. 이름이 CostManagement.CostCenterID인 태그 키를 정의하고 비용 추적에 대해 사용으로 설정합니다.
  2. 재무 비용 부서 CostManagement.CostCenterID = "Finance"에 대한 키 태그 값 Finance를 특정 리소스에 지정합니다.
  3. IT 비용 부서 "IT" (CostManagement.CostCenterID = "IT")에 대한 IT의 키 태그 값을 다른 리소스에 지정합니다.

테넌시 아래의 예산 생성 UI를 사용하여 예산 생성

  1. CostManagement.CostCenterID = Finance 태그가 지정된 리소스에 대한 예산을 생성합니다.
  2. CostManagement.CostCenterID = IT 태그 지정된 리소스에 대해 다른 예산을 생성합니다.
  3. 비용이 사전 정의된 예산을 초과하거나 예측이 설정된 임계값을 초과하는 경우 전자메일을 사용하여 수신자에게 통지하도록 알림을 구성합니다.

태그 값 관련 구획에 대한 예산을 생성할 수 있습니다. 예를 들어, 월별 예산 $500이 Cost-Management/Finance 태그 네임스페이스 및 CostCenterID 태그 키에서 태그 키 값이 IT인 프로젝트의 모든 리소스에 할당됩니다. 비즈니스 요구 사항에 맞게 월의 특정일에 시작하도록 예산을 구성할 수도 있습니다. 그러면 실제 지출 금액이 $500 예산의 80%에 도달할 때 ABC.someone@company.com로 경고를 보내도록 구성할 수 있습니다.

모든 OCI 서비스에는 기본 서비스 제한이 적용됩니다. 워크로드에 따라 제한, 할당량 및 사용량 UI를 사용하여 기본 서비스 제한을 업데이트할 수 있습니다. 이러한 제한은 해당 그룹에 필요한 필요에 따라 승인된 경계 또는 예산에 맞게 설정할 수 있습니다.

통제 비용

OCI의 모든 구획에 대한 구획 할당량을 생성합니다. 다음 예에서는 구획 할당량을 생성하는 방법을 보여줍니다.

  1. 다음 예에서는 미국 서부(피닉스) 지역의 App-Dev 구획에서 각 AD의 VM.Standard2 and BM.Standard2 컴퓨트 시리즈에 대한 쿼터를 240 OCPU(코어)로 설정합니다.
    set compute-core quota standard2-core-count to 240 in compartment App-Dev where request.region = us-phoenix-1
  2. 다음 예에서는 허용 목록을 만들고 패밀리의 모든 쿼터를 0으로 설정한 다음 명시적으로 리소스를 할당하는 방법을 보여줍니다.
    zero compute-core quotas in tenancy set compute-core quota standard2-core-count to 240 in tenancy
  3. 이 예에서는 고밀도 I/O 컴퓨트 리소스 생성을 하나의 영역으로만 제한하는 방법을 보여줍니다.
    zero compute-core quotas /*dense-io*/ in tenancy set compute-core quota /*dense-io*/ to 48 in tenancy where request.region = us-phoenix-1
  4. 리소스에 대한 할당량을 제거하는 unset 문을 사용하여 할당량을 지울 수 있습니다. 이제 이 리소스에 대한 제한이 서비스 제한 집합을 사용하여 적용됩니다.
    zero compute-core quotas in tenancy unset compute-core quota standard2-core-count in tenancy

비용 분석 및 보고

비용 분석 및 보고는 비용을 모니터링하고 비용 제어 측정이 작동하는지 검증하는 데 사용할 수 있는 두 가지 서비스입니다.

비용 분석 툴을 사용하면 Oracle Cloud 크레딧의 사용 현황과 사용 현황을 약정 금액과 비교하는 방법을 분석할 수 있습니다. 대시보드를 사용하여 구획 또는 비용 추적 태그 및 추세선을 사용하여 서비스 또는 부서별 지출을 볼 수 있습니다. 이를 통해 지출 패턴이 어떻게 변화하고 있는지 파악하며 비용을 절감하는 데 집중할 수 있습니다. 예산과 유사한 특정 태그 키에 대해 비용 분석을 수행할 수 있습니다.

특정 기간 및 요소에 대해 실행할 특정 보고서 유형을 선택할 수 있습니다. 또한 구획, 태깅 또는 기타 그룹 값을 기반으로 이러한 보고서를 그룹화하면 과금 또는 분석을 위한 세분화된 보고가 가능합니다.

사용량 및 원가 보고서

사용량 보고서를 통해 청구에 대한 통찰력을 얻거나 사용자정의 청구 애플리케이션을 생성할 수 있습니다. 보고서에는 리소스당 하나의 레코드가 포함됩니다. 예를 들어 메타데이터와 태그를 사용한 시간당 인스턴스, DB 시스템 또는 오브젝트 스토리지 버킷입니다.

비용 보고서는 사용량 보고서와 유사한 CSV(콤마로 구분된 값) 파일로, 비용 열을 포함합니다. 이 보고서는 자원 레벨 세분성에서 송장 라인 항목의 분석을 가져오는 데 사용할 수 있습니다. 따라서 OCI 지출을 최적화하고 보다 정확한 정보를 토대로 클라우드 지출 결정을 내릴 수 있습니다.

사용량 보고서는 소비되는 수량을 나타냅니다. 원가 보고서는 자원 소비의 원가를 나타냅니다. 요율 카드와 결합할 때 사용 보고서에 따라 다음과 같은 시나리오가 결정됩니다.

  • 송장 조정
  • 사용자정의 보고
  • 상호 비용 청구
  • 비용 최적화
  • 자원 재고

새 청구 시나리오를 사용으로 설정하는 것 외에도 사용 보고서는 청구 시스템의 작동 방식에 대한 투명성을 제공합니다. 사용 보고서는 사용 보고서 내에서 반올림이 발생하는 방법 및 위치와 1시간 이내에 존재하는 리소스가 청구되는 방법을 나타낼 수 있습니다.

배치

이 솔루션의 Terraform 코드는 GitHub에서 사용할 수 있습니다. 한 번의 클릭으로 코드를 Oracle Cloud Infrastructure Resource Manager로 풀링하고 스택을 생성한 다음 배포할 수 있습니다. 또는 Terraform CLI를 사용하여 GitHub의 코드를 컴퓨터로 다운로드하고 코드를 커스터마이즈한 다음 구조를 배치합니다.

  • Oracle Cloud Infrastructure Resource Manager를 사용하여 배치합니다.
    1. Oracle Cloud에 배치을 누릅니다.

      아직 사인인하지 않은 경우 테넌시 및 사용자 인증서를 입력합니다.

    2. 조건 및 조항을 검토하고 수락합니다.
    3. 스택을 배치할 영역을 선택합니다.
    4. 화면의 프롬프트와 지침에 따라 스택을 생성합니다.
    5. 스택을 생성한 후 Terraform 작업을 누르고 계획을 선택합니다.
    6. 작업이 완료될 때까지 기다린 후 계획을 검토합니다.

      내용을 변경하려면 [스택 세부정보] 페이지로 돌아가서 스택 편집을 누르고 필요에 따라 변경합니다. 그런 다음 계획 작업을 다시 실행합니다.

    7. 추가 변경이 필요하지 않은 경우 스택 세부정보 페이지로 돌아가서 Terraform 작업을 누르고 적용을 선택합니다.
  • Terraform CLI를 사용하여 배치합니다.
    1. GitHub로 이동하십시오.
    2. 로컬 컴퓨터에 코드를 다운로드하거나 복제합니다.
    3. README의 지침을 따릅니다.