기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

GAMEOPS02-BP01 여러 게임과 애플리케이션을 자체 계정으로 격리하기 위한 다중 계정 전략 채택

각 환경의 보안, 격리 및 운영 요구 사항을 준수하도록 인프라 배포를 안내하는 계정 구조를 설계합니다. 환경에 대한 액세스를 제한하고 필요한 AWS 서비스만 사용할 수 있도록 허용하여 환경을 격리하는 것이 필수이며, 프로덕션 환경은 잠기고 개발 및 테스트 환경은 실험을 허용할 수 있습니다. 각 환경에서 주요 하위 시스템을 추가로 격리하고 여러 환경에서 자체적으로 AWS 계정 호스팅 및 관리하는 데 사용하는 공통 서비스를 사용하는 것이 좋습니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 높음

구현 지침

다양한 환경(예: 개발, 테스트, 스테이징, 프로덕션 및 공유 서비스)을 개별 환경으로 격리 AWS 하여에서 다중 계정 전략을 채택 AWS 계정하면 인시던트 범위가 줄어듭니다. 의 계층 구조를 중앙에서 관리 AWS 계정 하여 운영을 더욱 간소화하고 계정 수준 및 조직 단위 수준(OU 수준) 정책을 선택적으로 정의 및 적용하는 AWS Organizations 것이 좋습니다. 개발 및 프로덕션 워크플로 요구 사항에 맞는 적절한 OU와 AWS 계정 구조를 설계하면 비용을 최적화하고 확장성을 높일 수 있습니다.

구현 단계

에 배포된 게임 시스템은 적절한 격리를 제공하도록 논리적으로 구성된 여러 계정을 사용해야 AWS 합니다. 이렇게 하면 게임 인프라가 확장될 때 문제의 폭발 반경을 줄이고 작업을 간소화할 수 있습니다. AWS 계정 호스트 게임 인프라는 일반적으로 다음과 같은 논리적 환경으로 그룹화됩니다.

의 게임 인프라의 경우 각 게임 환경(개발 AWS, 테스트, 스테이징 및 프로덕션)과 보안, 로깅 및 중앙 공유 서비스를 위한 계정에 대해 별도의 계정을 생성하는 것이 좋습니다.

일반적으로 제한된 수의 인프라 리소스를 관리하는 소규모 게임 개발 스튜디오, 일반적으로 수백 개 이하의 서버가 이러한 환경(예: 프로덕션 계정 1개, 개발 계정 1개, 스테이징 계정 1개) 각각 AWS 계정 에 대해 하나씩 생성될 수 있습니다. 그러나 시간이 지남에 따라 게임 인프라 또는 팀 크기가 증가함에 따라이 간소화된 모델은 규모가 잘 조정되지 않을 수 있습니다.

이러한 환경을 설정할 때 많은 AWS 서비스가 특정 리전 내의 전체 계정에 대해 리소스 및 API 수준 Service Quotas를 공유한다는 점을 고려하세요. 이는 계정을 논리적으로 구성하는 방법을 결정할 때 고려해야 합니다. 계정에 배포된 서비스 사용에 대한 비용 AWS 계정 만 발생합니다. 따라서 특히 게임이 성장하고 더 많은 개발자가 리소스를 구축하고 관리하기 위해 액세스해야 할 때 리소스 경합과 서비스 할당량을 효과적으로 줄일 수 있는 방법을 제공합니다.

일반적으로 수백 명의 개발자가 리소스에 액세스하는 수천 개의 서버를 운영하는 대규모 게임 개발 스튜디오에서 작업한 경험을 바탕으로 게임을 지원하는 개별 애플리케이션이 자체 개발, 테스트, 스테이징 및 프로덕션 계정을 보유하는 보다 세분화된 계정 구조를 설계하는 것이 좋습니다. 라이브 시스템을 계획하고 마이그레이션하는 복잡성으로 인해 게임을 시작한 후 AWS 다중 계정 전략을 재설계하는 것은 어렵고 시간이 많이 걸리므로 올바른 다중 계정 구조를 결정할 때 향후 규모 조정 요구 사항을 고려하세요. 

AWS Organizations를 사용하여 계층 구조 및 그룹화를 설정하고 AWS 계정조직 단위(OUs)를 정의하여 서비스 제어 정책(SCPs)을 통해 공통 OU 수준 정책을 적용할 수 있습니다.는 리소스를 확장하고 확장함에 따라 환경을 AWS Organizations 중앙에서 관리하고 관리합니다. 프로그래밍 방식으로 새 계정을 생성하고 리소스를 할당하며, 계정을 그룹화하여 워크플로를 구성하고, 거버넌스를 위해 계정 또는 그룹에 정책을 적용하고, 계정에 대한 단일 결제 방법을 사용하여 결제를 간소화할 수 있습니다. 또한 Organizations는 다른 서비스와 통합되어 조직의 계정 간에 중앙 구성, 보안 메커니즘, 감사 요구 사항 및 리소스 공유를 정의할 수 있습니다.

AWS Control Tower는 랜딩 존이라고 하는 안전한 다중 계정 환경을 설정하고 관리하는 간단한 방법을 제공합니다. Control Tower는를 사용하여 AWS Organizations랜딩 존을 생성하여 수천 명의 고객이 클라우드로 이동할 때 작업한 AWS경험을 기반으로 지속적인 계정 관리 및 거버넌스와 구현 모범 사례를 제공합니다. AWS Config , AWS Trusted Advisor, AWS Security Hub CSPM는 계정의 위생을 집계하거나 중앙 집중식으로 볼 수 있는 서비스입니다.

이 격리는 각 게임 환경에 대한 사용자 지정 또는 개별 권한과 가드레일을 설정하는 데 도움이 됩니다. 프로덕션 계정에는 필요한 가드레일, 액세스 제한, 모니터링 및 알림, 보안 도구가 있어야 하지만 비프로덕션 계정에는 동일한 수준의 가드레일 및 권한이 필요하지 않을 수 있습니다. 비프로덕션 환경을 자동화하여 몇 시간 후에 리소스를 종료하고 비용을 절감할 수 있습니다. 이러한 세분화 수준에서 계정을 분리하면 게임을 지원하는 각 환경의 인프라 비용을 쉽게 모니터링할 수 있습니다.

다음은 AWS Organizations 및 조직 단위(OUs)를 사용하여 논리적으로 별도의 환경과 스튜디오 AWS 계정 로 그룹화하는 게임 회사의 다중 계정 구조의 예입니다. 이 예제에서는 OUs 사용하여 환경을 기반으로 계정을 그룹화한 다음 환경을 운영하는 스튜디오를 기반으로 계정을 그룹화합니다. 이는 중첩 계층 구조를 생성하여 별도의 애플리케이션과 게임을 환경 내 자체 계정에 배포할 수 있도록 하는 방법(OUs)을 보여줍니다. 이는 여러 게임을 개발하고 운영할 때 유용할 수 있습니다. 다중 계정 전략을 구성하는 데 고려할 수 있는 추가 전략에 대해 알아보려면이 원칙의 리소스 섹션에 제공된 설명서 및 백서를 참조하세요.

위의 논의를 기반으로 아래 샘플 다이어그램은 4단계(개발, 테스트, 스테이징 및 프로덕션)로 구성된 개발 파이프라인이 있는 게임 스튜디오(조직)를 가정합니다. 특정 게임(game1)의 경우 각 환경(OU)에는 게임 서비스, 전용 게임 서버, 소셜 서비스 및 웹 서버에 AWS 계정 대한 개별가 있습니다. 각에서 실행되는 리소스는 해당 하위 시스템과 AWS 계정 관련이 있습니다. 일반적으로 이러한 종류의 개발 파이프라인을 사용하는 모든 개별 게임은이 파이프라인 또는 유사한 구조를 복제합니다 AWS 계정.

이러한 게임 중심 환경 OUs 외에도 공유 서비스 OU 및 보안 OU도 있습니다. 이러한 OUs는 각 개별 게임이 아닌 조직 전체여야 합니다. 이렇게 하면 게임은이 예제와 같이 개발 도구, 데이터 및 분석에 공유 서비스를 사용합니다. 그런 다음 애플리케이션 및 시스템 로그를 보안 OU의 로그 AWS 계정 설정으로 전송합니다.