AWS Organizations 계정 이전, RAM 공유와 Lake Formation 권한을 잃지 않는 방법

왜 이 이야기가 실무에서 중요한가

AWS Organizations 안에서 계정을 다른 Organizations로 옮기는 일은 M&A, 분사(divestiture), 그룹 재편 등으로 생각보다 자주 발생해요. 문제는 AWS RAM(Resource Access Manager) 리소스 공유가 걸려 있을 때입니다.

조직(Organization)에 묶인 공유(organization-bound share)는 계정이 조직을 떠나는 순간 AWS RAM이 그 연결을 자동으로 제거해요. 데이터 플레인은 살아있는데 컨트롤 플레인만 죽는 기묘한 장애가 여기서 나옵니다. Terraform apply가 갑자기 permission error로 터지는데 트래픽은 멀쩡히 흐르는 상황이죠.

이 글은 글로벌 결제 처리 업체가 382개 계정을 Organizations 간 이동하면서 브릿지 공유(bridge share) 패턴으로 Lake Formation 권한을 보존한 사례를 다뤄요. 단순 요약이 아니라, 왜 이 패턴이 필요한지, 어떤 함정이 있는지 실무 관점으로 풀어볼게요. 자세한 원문 흐름은 근거자료에서 확인할 수 있어요.

핵심 원리: 조직 바운드 공유 vs 외부 공유

AWS RAM은 두 가지 방식으로 principal을 신뢰해요.

1. 조직 멤버십 기반(organization-bound): 같은 Organizations 안에 있으면 자동 신뢰. 계정 ID를 지정해도 조직 멤버십으로 신뢰합니다.
2. 외부 초대 기반(external): Organizations 밖의 principal에게는 초대(invitation)를 보내고, 수락하면 외부 연결로 유지됩니다.

핵심은 외부 연결은 조직 멤버십에 의존하지 않으므로 계정이 이동해도 살아남는다는 점이에요. 브릿지 공유 패턴은 이 성질을 이용합니다.

브릿지 공유 워크플로 (5단계)

# 1) 인벤토리: 리전별로 원본 공유/리소스/principal/권한 매핑
# AWS RAM은 리전 서비스이므로 스코프 내 모든 리전에서 반복해야 합니다.
aws ram list-resource-shares --region ap-northeast-2 --resource-owner SELF

# 2) 브릿지 생성 + 수락 (이전 전에 반드시 수락)
aws ram create-resource-share \
  --name bridge-share-for-migration \
  --resource-arns arn:aws:glue:ap-northeast-2:111122223333:catalog \
  --principals 444455556666 \
  --allow-external-principals \
  --retain-sharing-on-account-leave-organization \
  --region ap-northeast-2

# 소비자 계정에서 초대 수락 (이전 전에 완료)
aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn <invitation-arn> \
  --region ap-northeast-2

# 3) 계정 이동 (Organizations 간 직접 이동 가능, 중간 standalone 불필요)

# 4) 원본 공유에 마이그레이션된 계정 ID를 외부 principal로 재등록
aws ram associate-resource-share \
  --resource-share-arn <original-share-arn> \
  --principals 444455556666 \
  --region ap-northeast-2

# 5) 검증 후 브릿지 삭제 (원본이 완전히 커버할 때만)
aws ram delete-resource-share --resource-share-arn <bridge-share-arn> --region ap-northeast-2

⚠️ allowExternalPrincipals만으로는 부족해요. 2026년 2월에 추가된 retainSharingOnAccountLeaveOrganization 설정도 함께 켜야 합니다. 이 설정은 새로 만든 공유에만 적용되고 기존 공유에는 소급 적용되지 않아요. 그래서 기존 공유는 임시 병렬 공유(브릿지)가 필요한 겁니다.

주의사항: 데이터 플레인이 살아있어도 방심하면 안 됩니다

이 사례에서 가장 위험했던 지점은 비프로덕션 테스트로는 절대 재현되지 않는다는 사실이었어요. 비프로덕션 계정은 이미 별도 Organizations에 있어서 프로덕션에서 깨지는 신뢰 경계를 넘지 않았거든요. 14번의 클린 웨이브가 프로세스는 검증했지만 프로덕션 고유 조건은 못 잡았습니다.

리소스 타입별 영향 정리

추가로 깨지는 것들

• AWS Firewall Manager 정책: 리소스 정리 설정에 따라 Network Firewall 룰이 제거될 수 있어 재배포 필요
• CloudFormation StackSets(조직 통합형): retain 설정 안 하면 스택이 삭제됨
• SCP: 마이그레이션 윈도우 동안 ram:AcceptResourceShareInvitation을 막는 SCP가 있으면 임시 조정 필요

왜 원본 공유를 반드시 복원해야 하나

브릿지는 마이그레이션 전용 임시 복사본이에요. Lake Formation이 만든 원본 공유가 durable한 권한 객체입니다. 마이그레이션 윈도우 중에 추가된 grant는 원본 공유에만 붙고 브릿지에는 자동 반영되지 않아요. 둘 다 남겨두면 권한 상태가 두 갈래로 갈라지고(drift), 감사(audit)가 꼬이고, 어느 쪽이 진짜인지 알 수 없게 됩니다. 그래서 자동화는 원본 공유가 브릿지의 리소스/principal/권한을 완전히 커버하고 모든 association이 ASSOCIATED 상태일 때만 브릿지를 삭제하도록 설계돼요.

💡 국내 SI/금융권 환경에서는 SCP와 감사 로그(CloudTrail) 요건이 엄격해서, 브릿지 공유를 만드는 순간부터 변경 이력이 남도록 태깅 전략을 미리 잡아두시는 걸 권합니다. ram:ResourceShareInvitationArn 이벤트를 EventBridge로 받아 슬랙 알림을 걸어두면 stale share를 조기에 잡을 수 있어요.

정리: 실무 적용을 위한 체크리스트

이 사례에서 뽑아낼 수 있는 교훈은 세 가지예요.

1. 검증 경계를 프로덕션과 일치시켜라. 테스트 Organizations가 프로덕션과 같은 신뢰 경계를 넘지 않으면 이 실패는 절대 재현되지 않습니다. 첫 웨이브 전에 각 프로덕션 리스크를 재현 가능한 환경에 매핑하세요.
2. 컨트롤 플레인 변화를 모니터링하라. AWS RAM은 리소스 공유 상태 변경 이벤트를 EventBridge로 직접 내보내고, CloudTrail이 DisassociateResourceShare API 호출을 기록합니다. 주간 post-migration sweep으로 stale share를 정리하는 습관이 큰 사고를 막아요.
3. 의존성과 목적지 가드레일을 동시에 인벤토리화하라. Account Assessment for AWS Organizations 툴로 RAM 의존성을 미리 뽑고, 목적지 Organizations의 SCP도 같은 시점에 검토하세요.

브릿지 공유는 임시라는 점이 핵심입니다. 원본 공유를 복원해야 Lake Formation 권한이 향후 grant와 정렬되고, 권한 상태가 두 개로 갈라지는 상황을 피할 수 있어요.

다음 단계 학습 방향

• aws-samples/sample-aws-ram-org-migration 스크립트를 dry-run 모드로 먼저 돌려보세요. 리전별, 계정별 검증이 필수입니다.
• Glue Data Catalog나 Lake Formation이 스코프에 들어오면 AWS account team을 조기에 불러주세요. 2주 만에 패턴이 검증된 것도 이 협업 덕분이었습니다.

함께 보면 좋은 글

• PMTUD 블랙홀, 이제 Cloudflare One이 실시간으로 해결합니다 — 네트워크 경로 문제를 실시간으로 잡는 접근법이 궁금하다면.
• CSS Grid로 지그재그(폭포수) 레이아웃 만들기 translateY(%)의 숨은 마법 — 프론트엔드 레이아웃 쪽으로 잠깐 눈 돌리고 싶을 때.