🔐 AWS에서 멀티 계정으로 전환하면 깨지는 8가지!

[cloudbro-radar]

AWS Organizations로 AWS 멀티 계정으로 전환할 때, 실제로 무너지는 8가지 문제와 원인 그리고 해결 방법들에 대한 정보를 공유합니다.

1. IAM Role, 작동할 줄 알았는데 안 된다 (그리고 아무 말도 안 해준다)

개발(Dev)과 스테이징(Staging)에 똑같은 Role + Policy를 재사용한다. 개발에서는 잘 돌아간다. 그런데 스테이징에서는? 펑. AccessDenied, 로그는 0, 그리고 “똑같이 했는데 왜?”라는 40분의 멘붕.

왜 이런 일이 생길까: Cross-account Trust Policy는 생각보다 훨씬 까다롭다. Principal이 정확히 포함되지 않거나, 다른 계정의 root를 빠뜨리면 그 Role은 사실상 잠겨버린다. 경고도, 힌트도 없다.

고치는 법:

• sts:assume-role로 항상 Role 가정(assumption)을 수동 테스트할 것
• 부트스트랩 단계에서는 Trust Policy를 최소화(제약은 나중에 추가)
• 접근 제어는 과도한 조건 대신 Tag + SCP로 관리할 것 IAM Trust Policy가 사람이라면? 당신 앞에서는 웃다가 뒤에서는 유령처럼 사라질 거다.

---

2. 별것 아니어 보이던 SCP, 모든 걸 망쳐버리다

Dev 환경에서 EC2만 못 쓰게 하려고 SCP를 작성했다. 좋아 보인다. 그런데 갑자기 개발자들이 대시보드를 못 만든다. Lambda도 실행 불가. 심지어 CloudWatch도 열 수 없다.

왜 이런 일이 생길까: SCP는 IAM이 아니다. 상위 레벨의 “거부(veto)”다. 액션 하나를 애매하게 막아버리면, 수십 개 서비스가 연쇄적으로 다운된다.

피하는 방법:

• 항상 Sandbox 계정에서 먼저 테스트
• Access Analyzer로 Policy 영향 시뮬레이션
• 혹시(아니 거의 반드시) 잠그더라도 빠져나올 수 있는 No-SCP “비상 계정” 확보 SCP는 마치 방화벽 규칙을 짠 적 없는 사람이 디버깅도 모른 채 작성한 것과 같다.

---

3. 중앙 로그, 아무 것도 기록하지 않는다

보안 계정에 중앙 로그를 연결했다. 깔끔하고 추적 가능해 보여야 한다. 그런데 프로덕션이 뻗는다. 그런데… 로그는 도착하지 않는다. 이제 당신은 눈을 가린 채 디버깅해야 한다.

왜 이런 일이 생길까: Cross-account 로그 전달은 자동이 아니다. 다음이 필요하다:

• 로그 그룹 권한
• 송신자가 접근할 수 있는 S3 버킷 권한
• 계정 간 퍼블리시가 가능한 IAM Role

고치는 법:

• Firehose를 사용해 로그를 버퍼링 + 계정 간 전달
• logs.amazonaws.com에 S3 버킷 쓰기 권한 부여
• 가짜 로그로 반드시 검증 — 절대 가정하지 말 것 로그가 도착하지 않으면, 그건 Observability가 아니라 그냥 “느낌(vibes)”일 뿐이다.

---

4. Secrets Manager는 여행을 하지 않는다

/prod/db/password에 비밀번호를 저장했다. 다른 계정의 Lambda가 읽으려 한다. 펑. AccessDenied.

왜 이런 일이 생길까: Secrets Manager는 계정 + 리전 단위로 제한된다. 끝. Cross-account 접근? 직접 무대를 만들어야 한다.

살아남는 법:

• 파이프라인이나 자동화로 비밀을 복제 (수동 복사 금지)
• /account/env/service/... 형식으로 키 Prefix 설정 (이름 충돌 방지)
• 리소스 Policy를 사용해 특정 계정에서 읽을 수 있도록 명시 허용 Secrets는 글로벌하지 않다. 하지만 고통은 글로벌하다.

---

5. VPC Peering은 마법의 터널이 아니다

계정 간 VPC Peering을 했다. 이제 통신될 줄 알았다. 그런데 ECS는 여전히 RDS에 연결되지 않는다. 보안 그룹, 라우트, DNS를 전부 확인한다. 그래도 안 된다.

왜 이런 일이 생길까: Peering은 단순히 “연결”일 뿐이다. 실제 통신은 별도 설정이 필요하다:

• DNS 해석 + 호스트네임 활성화
• Cross-account CIDR을 허용하는 SG 규칙
• 양쪽 라우트 테이블 업데이트

해결 방법:

• SG 규칙을 다시 확인하라 — 자동으로 상속되지 않는다
• DNS 설정 검증 (특히 Route 53 Private Zone 사용 시)
• Peering 설정은 문서화하라. 당신의 직업이 그 문서에 달려 있다. AWS Peering은 연애 같다. 연결은 있어도, 소통은 여전히 실패한다.

---

6. 고아 리소스가 조용히 예산을 태운다

잊힌 Sandbox에서 t3.2xlarge가 일주일째 돌아간다. 태그도 없다. 알람도 없다. 재무팀은 원인을 캐묻는다. 이제 당신은 비용 탐정 모드다.

왜 이런 일이 생길까: 멀티 계정은 자유를 준다. 하지만 태깅과 비용 가시성이 없으면 그냥 난장판이다.

돈 새는 걸 막는 법:

• 조직 차원의 태깅 정책 강제 (배포 실패 조건 포함)
• 통합 청구 + 계정별 Cost Explorer
• 정기 감사 실행 (또는 aws-nuke 사용, 단 조심할 것) 클라우드는 저렴하다. 단, 아무도 안 지켜볼 때만.

---

7. 알람은 있는데, 누구에게도 전달되지 않는다

CloudWatch Alarm을 다른 계정의 SNS에 연결했다. 프로덕션이 뻗었다. 그런데 아무도 호출되지 않는다. 알람은 있었는데, 아무도 받지 못했다.

왜 이런 일이 생길까: SNS는 계정 간 퍼블리셔를 명시적으로 허용하지 않으면 싫어한다. EventBridge도 마찬가지다.

고치는 법:

• SNS Access Policy를 작성해 소스 계정에서 허용
• 가짜 이벤트로 반드시 테스트
• 알림 인프라는 중앙 집중화, 서비스가 거기에 구독하도록 구성 누구에게도 전달되지 않은 알람은, 없는 것과 다름없다.

---

8. 신규 개발자는 Role Assumption 지옥에 빠진다

새로운 엔지니어가 합류했다. 접근 권한을 줬다. 그런데 여전히 배포가 안 된다. 한참 디버깅 끝에 알게 된다 — 잘못된 Role을, 잘못된 계정에서 가정하고 있었다.

왜 이런 일이 생길까: 각 계정마다 Role, 권한, MFA 규칙, 이름 체계가 제각각이다. 온보딩 가이드? 아마 오래전에 업데이트 멈췄을 거다.

해결 방법:

• IAM Identity Center(SSO) 사용 — 계정별 Permission Set 할당
• CLI 설정 스크립트화 (aws configure sso 혹은 awsume)

[출처] https://medium.com/towards-aws/8-things-that-break-after-going-multi-account-on-aws-0658a0dd12eb