AWS 클라우드 따라잡기 19장

이번 장은 인증과 멀티계정 거버넌스를 다룬다.

조직이 커지면 계정 하나로는 부족하다. 팀·환경별로 계정을 나누고 일관되게 통제해야 한다.

또한 서비스 사용자(고객)의 로그인도 다뤄야 한다.

이 장의 목표는 다음과 같다.

• 앱 사용자 인증(Cognito)을 이해한다.
• 멀티계정 전략과 통제 수단을 안다.

1. Cognito — 앱 사용자 인증

2장의 IAM은 AWS를 다루는 관리자·서비스용이었다.

반면 Cognito는 내 애플리케이션을 쓰는 최종 사용자(고객)의 인증을 담당한다.

• 사용자 풀(User Pool): 회원 가입·로그인·비밀번호 관리를 제공한다.
• 구글·애플 같은 소셜 로그인, MFA를 붙일 수 있다.
• 자격 증명 풀(Identity Pool): 로그인한 사용자에게 임시 AWS 권한을 부여한다.

로그인 기능을 직접 만들지 않고 Cognito에 맡기는 것이다.

2. 왜 계정을 나누나

계정 하나에 모든 것을 두면 위험하다.

• 운영과 개발이 섞여 실수가 운영에 영향을 준다.
• 권한·비용을 팀별로 나누기 어렵다.

그래서 환경(운영/스테이징/개발)이나 팀별로 계정을 분리한다.

3. Organizations와 SCP

Organizations는 여러 AWS 계정을 묶어 중앙에서 관리한다.

• 계정을 OU(조직 단위)로 그룹화한다.
• 결제를 통합(consolidated billing)해 볼륨 할인을 받는다.

SCP(서비스 제어 정책)는 조직·OU 단위의 권한 상한선이다.

• 개별 계정이 무엇을 허용하든, SCP가 막으면 못 한다.
• 예: "특정 리전만 사용", "루트 사용자 특정 작업 금지"를 조직 전체에 강제.

IAM이 "무엇을 허용"이라면, SCP는 "무엇을 절대 못 하게"의 울타리다.

4. Control Tower와 Identity Center

• Control Tower: 멀티계정 환경을 모범 사례대로 자동 구성한다(랜딩 존).
• IAM Identity Center: 여러 계정에 대한 싱글 사인온(SSO)을 제공한다. 계정마다 사용자를 만들 필요가 없다.

정리

• Cognito는 앱 고객의 로그인을, IAM은 AWS 운영 주체를 담당한다.
• 환경·팀별로 계정을 분리해 격리와 관리 편의를 얻는다.
• Organizations로 묶고 SCP로 조직 차원의 금지선을 강제한다.
• Control Tower·Identity Center로 멀티계정을 표준화·SSO한다.

다음 장에서는 이 환경을 지키는 보안 운영과 위협 탐지를 다룬다.