[reinvent 2025] 대규모 AWS 계정의 원활한 이동
Summary
최근 기업의 인수합병(M&A) 속도가 빨라지고 조직 구조가 복잡해짐에 따라, 수많은 AWS 계정을 보안 공백이나 운영 중단 없이 안전하게 이동시켜야 하는 과제에 대한 방법론과 최신 업데이트된 기능, 그리고 실무자가 놓치기 쉬운 핵심 체크리스트를 공유해 드립니다.
리인벤트 2025 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
이번 세션을 신청한 이유는 M&A와 조직 통합이 가속화되는 상황에서 AWS 계정을 효과적으로 이동하고 통합하는 방법을 배우고 싶었기 때문입니다. 특히 여러 조직에 산재된 계정들을 하나로 통합할 때 놓치기 쉬운 함정들과 실질적인 해결 방안을 알고 싶었습니다. 이 세션에서 주목할 내용은 5단계 프레임워크와 최신 업데이트된 ‘직접 전송(Direct Transfer)’ 기능을 공유해 드리고자 합니다.
성공적인 계정 이동을 위한 5단계 프레임워크와 ‘Assess’의 중요성
이번 세션의 핵심은 막무가내로 계정을 옮기는 것이 아니라, 계획(Plan) – 평가(Assess) – 준비(Prepare) – 이동(Migrate) – 통합(Integrate)이라는 5단계 프레임워크를 따르는 것입니다. 특히 연사 Paul Bayer는 단순 기술적 이동뿐만 아니라 재무적 종속성의 중요성을 강조했습니다.
RI나 Savings Plans 혜택은 Payer 계정 또는 해당 조직의 관리 위임 계정에 의해 조직 수준에서 공유되므로, 조직 이동 시 기존 조직의 혜택을 더 이상 받지 못하게 됩니다. 따라서, 계정 이동 시 재무적인 영향을 반드시 미리 파악해야 합니다. 또한, ‘평가 단계’에서는 RAM(Resource Access Manager) 공유 상태와 리소스 정책 내의 Org ID 조건(Conditionals)을 찾아내는 것이 필수적입니다. 계정이 이동하여 Org ID가 바뀌면, 하드코딩된 조건으로 인해 S3 버킷 접근이 갑자기 차단될 수 있기 때문입니다.
놓치기 쉬운 기술적 함정: 신뢰 정책과 네트워크 종속성
계정을 이동할 때 가장 빈번하게 발생하는 사고는 권한과 네트워크 연결의 단절입니다. 세션에서는 두 가지 치명적인 시나리오를 경고했습니다.
첫째, 신뢰 정책(Trust Policy)의 갱신입니다. 새 계정 생성 시 기본적으로 만들어지는 OrganizationAccountAccessRole은 기존 Payer 계정을 신뢰하도록 설정되어 있습니다. 계정을 새 조직으로 옮겨도 이 설정은 자동으로 바뀌지 않으므로, 스크립트를 통해 수동으로 업데이트하지 않으면 이전 조직의 관리자가 여전히 내 계정에 접근할 수 있는 보안 구멍이 생깁니다.
둘째, RAM 공유 갱신입니다. TGW(Transit Gateway) 등을 RAM으로 공유 중일 때, 리소스를 공유하지 않은 상태로 계정을 먼저 옮기면 네트워크 연결이 즉시 끊길 수 있습니다. 따라서 이동 전후로 반드시 RAM 공유 상태를 새로고침(Refresh)하여 확인해야 합니다.
최신 기능 ‘직접 전송(Direct Transfer)’
이번 세션의 하이라이트 중 하나는 AWS Organizations의 신규 기능인 ‘직접 전송(Direct Transfer)’ 소개였습니다. 과거에는 계정을 조직에서 내보내 ‘독립형(Standalone)’으로 만든 뒤 다시 새 조직으로 초대해야 하는 번거로움이 있었고, 이 과정에서 임시 결제 수단을 등록해야 하는 불편함이 있었습니다. 하지만 이제는 기존 조직 멤버 상태에서 바로 새 조직으로 초대와 수락이 가능해져 프로세스가 훨씬 간소화되었습니다.
무중단 컷오버 전략
네트워크 중단을 막기 위한 컷오버 실무 팁으로 ‘네트워크 선(先) 컷오버’ 전략이 제시되었습니다.
- 계정을 구 조직에 둔 상태에서, 네트워크 컷오버를 먼저 진행합니다.
- TGW를 공유하고 라우팅 테이블을 변경해서, 구 조직에 있는 계정이 ‘새 조직’의 네트워크를 통해 트래픽을 받도록 만듭니다.
- 트래픽이 새 네트워크를 타는 것을 확인합니다. (구 조직은 네트워크로부터는 격리됨)
- 이렇게 모든 네트워크 변경을 마친 뒤, 계정을 이동시키면 네트워크 변경 없이 AWS 컨트롤 플레인상의 논리적 변경만 발생하게 됩니다.
이 방식을 사용하면 실제 계정 이동 시점에는 네트워크 변경이 발생하지 않아 장애 가능성을 최소화할 수 있습니다.
결론
이번세션은 단순히 AWS 계정을 ‘옮기는 법’을 넘어, M&A나 대규모 조직 개편 시 엔지니어가 고려해야 할 보안, 네트워크 등 복합적인 문제를 해결하는 인사이트를 제공했습니다. 가장 인상 깊었던 점은 “프로덕션 조직과 똑같이 생긴 ‘보조(Secondary) 테스트 조직’을 반드시 운영하라”는 조언이었습니다. 계정 이동이나 Control Tower 업그레이드 같은 되돌릴 수 없는 작업을 수행하기 전, 안전한 샌드박스 환경에서의 검증이 얼마나 중요한지 다시금 깨닫게 되었습니다.
글 │메가존클라우드, Specialty Service Unit, Modernization SA 1팀, 박혜진 SA
게시물 주소가 복사되었습니다.
