AWS Landing Zone 확장

AWS가 글로벌 인프라를 확장함에 따라 조직은 클라우드 존재를 새 리전으로 확장하기 위한 구조화된 접근 방식이 필요합니다. AWS가 새 리전을 출시함에 따라 조직들은 자신의 풋프린트를 확장하려 합니다. 이 지침은 AWS Organization 또는 Landing Zone을 확장하기 위한 주요 고려 사항과 모범 사례를 설명합니다.

기반 구축

포괄적인 거버넌스 제어와 함께 강력한 클라우드 기반을 설정하는 것은 단순한 모범 사례가 아닌 오늘날의 동적인 클라우드 환경에서 필수적입니다. 처음부터 강력한 거버넌스 프레임워크를 수립하는 데 시간을 투자하는 조직은 성장함에 따라 확장, 적응 및 보안을 유지하는 데 더 유리한 위치에 있습니다. 집을 짓는 것에 비유하면: 견고한 기반 없이는 추가나 수정이 점점 더 위험하고 복잡해집니다. Service Control Policies(SCP), 가드레일, 규정 준수 프레임워크를 포함한 클라우드 거버넌스 제어는 클라우드 인프라가 안전하고, 규정을 준수하며, 관리 가능한 상태를 유지하도록 보장하는 건축 청사진과 건축 규정 역할을 합니다. 새 리전으로 확장할 때 이러한 제어가 적용되어 있으면 확장 프로세스가 더 간소화되고 안전해집니다. 조직들은 사후에 거버넌스 제어를 적용하는 것이 초기 설정 중에 구현하는 것보다 훨씬 더 어렵고 리소스 집약적이라는 것을 종종 발견합니다.

Organization 우선 접근 방식 vs. Control Tower: 주요 차이점

새 리전으로 확장할 때 고객은 기존 설정에 따라 두 가지 주요 경로를 가집니다. AWS Organizations는 구현 세부 사항에 대한 세밀한 제어를 허용하는 수동이지만 매우 유연한 접근 방식을 제공합니다. 이 경로는 각 서비스의 직접 구성과 Service Control Policies의 사용자 정의 구현이 필요하지만 특정 요구 사항에 대한 최대 유연성을 제공합니다. 반면 AWS Control Tower는 사전 구축된 거버넌스 제어 및 표준화된 가드레일과 함께 Account Factory를 통한 더 간소화되고 자동화된 접근 방식을 제공합니다. Control Tower는 멀티 계정 설정 프로세스를 크게 간소화하지만 순수 Organizations 접근 방식보다 유연성이 떨어질 수 있습니다.

거버넌스 및 보안 제어

새 AWS 리전으로 확장할 때 한 가지 좋은 점은 CloudTrail 및 AWS Billing과 같은 특정 기반 서비스가 새 리전을 기존 구성에 자동으로 통합한다는 것입니다. 모든 리전에 대해 구성된 CloudTrail은 계정에서 사용 가능하게 되는 새 리전에서 API 활동을 자동으로 로깅하기 시작하며 추가 설정이 필요하지 않습니다. 마찬가지로 AWS Billing은 모든 활성 리전의 비용을 자동으로 통합하여 AWS Cost Explorer와 AWS Bills를 통한 통합 비용 관리 및 보고를 제공합니다.

그러나 이러한 서비스가 자동으로 적응하는 반면, Service Control Policies, GuardDuty, Security Hub, AWS Config와 같은 다른 보안 및 운영 서비스는 확장된 풋프린트의 포괄적인 커버리지를 보장하기 위해 명시적인 리전 활성화가 필요하다는 점에 유의해야 합니다.

접근 제어

AWS Identity and Access Management(IAM)는 전체 AWS 풋프린트에서 작동하는 글로벌 서비스입니다. 리전으로 확장할 때 기존 IAM 사용자, 역할 및 정책은 이미 준비되어 있으며 추가 구성이 필요하지 않습니다. 기존 IAM 보안 주체는 자동으로 다른 리전과 동일한 권한을 가집니다(정책에 리전별 제한이 포함되지 않는 한). IAM의 이 글로벌 특성은 시간을 크게 절약하고 성장하는 AWS 환경에서 일관된 접근 제어를 유지하는 데 도움이 됩니다. 단, IAM은 글로벌이지만 일부 리소스 기반 정책과 서비스 연결 역할은 리전별 고려가 필요할 수 있으므로 확장 체크리스트에 포함하세요.

Service Control Policies

AWS Control Tower를 사용하는 경우 좋은 소식이 있습니다 - 기본 가드레일과 관련 Service Control Policies(SCP)는 Control Tower에서 활성화되면 새 리전으로 자동으로 보호를 확장합니다. 그러나 사용자 정의 SCP(Control Tower 또는 AWS Organizations에서)를 사용하는 경우 새 리전을 포함하도록 해당 정책을 수동으로 업데이트해야 합니다. 이는 리전별 제어 또는 허용 리전 문을 사용하는 정책에 특히 중요합니다. 예를 들어, 허용된 리전을 명시적으로 나열하는 SCP가 있는 경우 해당 목록에 새 리전을 추가해야 합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedRegions",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:RequestedRegion": [
                        "ap-southeast-2",
                        "ap-southeast-4"  // Asia Pacific (Melbourne) 리전 추가
                    ]
                }
            }
        }
    ]
}

이러한 변경 없이는 팀이 리소스를 시작할 수 없는 이유를 궁금해할 수 있습니다. 프로덕션 환경이 아닌 환경에서 먼저 이러한 정책 업데이트를 테스트하세요 - 항상 고객 영향을 최소화해야 합니다.

AWS Config

Service Control Policies와 마찬가지로 AWS Control Tower를 사용하는 경우 AWS Config는 Control Tower에서 지원하면 새 리전에서 자동으로 활성화되고 구성됩니다. 규칙, 집계기 및 레코더가 자동으로 나타납니다. 그러나 Control Tower 없이 Organizations를 통해 AWS Config를 실행하는 경우 수동으로 작업해야 합니다. 이는 새 리전에서 Config를 활성화하고, 규칙(사용자 정의 규칙도 포함)을 배포하고, 사용하는 경우 집계기를 설정하는 것을 의미합니다. 많은 고객이 CloudFormation StackSets를 사용하여 이 프로세스를 자동화합니다.

추가 보안 서비스

새 리전으로 확장할 때 AWS 보안 서비스에 대해 알아야 할 사항을 살펴보겠습니다. 글로벌 범위의 IAM과 달리, 대부분의 AWS 보안 서비스는 리전별 배포 전략이 필요합니다.

먼저 보안 서비스 팀인 GuardDuty, Security Hub, Macie, Detective에 대해 이야기해 보겠습니다. 이러한 각 서비스는 새 리전에서 명시적으로 활성화해야 합니다. 그러나 Organizations에서 흥미로운 점은 위임된 관리자 계정 설정이 실제로 글로벌이라는 것입니다. 보안 서비스의 위임된 관리자로 계정을 지정하면 해당 계정은 모든 리전에서 특별한 권한을 유지합니다.

그러나 여전히 해야 할 작업이 있습니다. 위임된 관리자 계정이 있더라도 새 리전에서 각 보안 서비스를 활성화해야 합니다. 예를 들어 Security Hub의 경우 위임된 관리자 계정은 새 리전에서 서비스를 활성화한 다음 멤버 계정의 결과 집계를 구성해야 합니다.

프로 팁: 많은 빌더들이 AWS CloudFormation StackSets 또는 기타 도구를 사용하여 이 리전별 활성화 프로세스를 자동화합니다. 필요한 모든 보안 서비스를 활성화하고 구성하는 "새 리전 보안 부트스트랩" 템플릿을 만드는 것을 고려하세요!

가시성 확보

새 리전으로 확장할 때 간과하기 쉽지만 매우 중요한 서비스에 대해 이야기해 보겠습니다. Resource Explorer는 모든 AWS 리소스의 통합된 뷰를 유지하려면 집계기 설정에 새 리전을 추가해야 합니다. 마찬가지로 IAM Access Analyzer는 포괄적인 권한 인사이트를 유지하기 위해 새 리전에서 활성화하고 집계 구성에 추가해야 합니다. CloudWatch Logs도 잊지 마세요! 교차 계정, 교차 리전 중앙 집중식 로깅을 사용하는 경우 새 리전을 포함하도록 로그 라우팅 및 복제 설정을 업데이트해야 합니다.

무엇이 빠져있나요?

새 리전에 뛰어들기 전에 AWS 서비스 인벤토리에 대해 이야기해 보겠습니다. 성공적인 리전 확장에서 역방향으로 작업하면서 AWS 서비스 풋프린트에 대한 포괄적인 평가를 만들고 싶을 것입니다. 명확한 서비스를 넘어 생각하세요 - 조직 서비스, 보안 및 규정 준수 도구, 모니터링 및 로깅 구성, EC2와 S3에 대해 다루었습니다. 하지만 몇 달 전에 설정한 Route 53 상태 확인, AWS Backup 계획 또는 AWS Private Certificate Authorities는 어떻습니까? AWS Resource Explorer 또는 AWS Config를 사용하여 현재 사용 중인 모든 서비스를 검색하세요.

Landing Zone에 대하여

AWS Landing Zone과 홈 리전의 중요한 역할에 대해 알아보겠습니다.

AWS Landing Zone을 클라우드 본부로, 홈 리전을 메인 오피스로 생각하세요. AWS Control Tower를 처음 설정하거나 사용자 정의 Landing Zone 솔루션을 구현할 때 홈 리전을 선택하며, 이 결정은 많은 사람들이 생각하는 것보다 더 중요합니다.

홈 리전에서는 Control Tower 및 관리 구성 요소와 같은 중요한 서비스가 설치됩니다. Landing Zone을 새 리전으로 확장하면 원래 홈 리전에 본부를 유지하면서 기본적으로 지사를 여는 것입니다. 새 리전은 거버넌스 제어를 상속받고 완전히 활용할 수 있지만, 기본 구성 및 관리 구성 요소는 홈 리전에 유지됩니다.

Landing Zone의 홈 리전을 이동하는 것은 기본 AWS Console 리전을 변경하는 것과 다릅니다. 비즈니스를 원활하게 운영하면서 회사 본부를 새 도시로 옮기는 것에 가깝습니다. 핵심 서비스를 해체하고 재배포하고, 로깅 집계를 재구성하고, 조직 구성을 재구조화하고, 잠재적으로 자동화 파이프라인을 재구축해야 합니다.

이것이 홈 리전 선택이 "두 번 재고 한 번 자르기" 결정인 이유입니다. 장기적인 지리적 전략 및 규정 준수 요구 사항에 맞는 홈 리전을 선택하는 것을 권장합니다. 새 리전으로 확장하는 것은 간단하지만, Landing Zone의 홈을 이동하는 것은 신중한 계획과 실행이 필요한 중대한 작업입니다.

결론

결론적으로, AWS Landing Zone 또는 Organization을 리전으로 확장하려면 신중한 계획과 AWS 서비스의 리전별 동작에 대한 포괄적인 이해가 필요합니다. 기반 거버넌스 제어 및 보안 서비스부터 운영 가시성 도구 및 Landing Zone 고려 사항까지 중요한 측면을 다루었습니다. IAM과 CloudTrail과 같은 일부 서비스는 자동으로 새 리전을 수용하지만, 다른 서비스는 명시적인 활성화와 구성이 필요합니다. 확장 여정은 잘 문서화된 서비스 인벤토리와 Landing Zone의 홈 리전 영향에 대한 명확한 이해를 바탕으로 해야 합니다. 이러한 모범 사례와 고려 사항을 따르면 확장되는 AWS 풋프린트 전체에서 일관된 보안, 규정 준수 및 운영 우수성을 유지할 수 있습니다.