1. 그림 전체 한 줄 요약
온프레미스 AD(회사 AD)와 AWS Managed Microsoft AD 를
AWS Organizations의 Management Account(관리 계정) 안에 두고
둘 사이를 one-way 또는 two-way trust 로 묶은 하이브리드 AD 구조
2. Corporate data center (온프레미스 AD)
- Computers – 도메인에 join된 사내 PC, 노트북
- Users and groups – 직원 계정, 보안 그룹(개발팀, 재무팀 등)
- Servers – 파일 서버, 애플리케이션 서버, 도메인 컨트롤러(DC) 등
- Active Directory – 이 모든 계정/정책을 관리하는 회사 AD
여기서 하는 일 간단 정리
- 사용자가 로그인하면 Kerberos 티켓 발급해서 “이 사람 진짜 맞음” 인증
- 이 사람이 어떤 그룹에 속해 있는지(예:
Dev-Team,HR-Team) 저장 - 그룹 정책(GPO)로 PC/서버에 보안 설정 배포
→ “회사 사람인지, 어떤 팀인지, 어디 들어갈 수 있는지”를 여기서 결정.
3. Org Management account + AWS Managed Microsoft AD
3-1. Org Management account란?
AWS Organizations 쓸 때:
-
Management account:
- 조직 전체를 컨트롤하는 “최상위 계정”
- 멤버 계정 생성, SCP(서비스 제어 정책) 설정, 결제 통합 등
- 권한이 너무 강해서 일반 워크로드를 올리지 말라 고 권장함
보통 실제 현업 환경에서는:
Management account– 조직 관리, 결제Log Archive account– 모든 계정 CloudTrail/Config 로그 모음Security account– Security Hub, GuardDuty 등Shared Services account– AD, VPN, 프록시 같은 공통 인프라
이렇게 역할을 나누는 게 베스트 프랙티스.
4. AWS Managed Microsoft AD
- AD 도메인 컨트롤러를 AWS가 대신 관리 (패치/백업/모니터링)
- Windows 서버, FSx for Windows, RDS for SQL Server 같은 것들이
이 AD에 조인해서 도메인 기능 활용 - 클라우드 안의 워크로드에게 “AD 기반 인증/권한” 을 제공
즉, AWS 쪽 “리소스 포리스트(resource forest)” 역할을 해.
5. One-way or two-way trust
5-1. One-way trust 예시
-
방향: 온프 AD → AWS Managed AD
-
효과:
- 온프 AD 유저는 AWS 리소스(Managed AD에 join된 서버)에 들어갈 수 있음
- 반대로 AWS Managed AD 유저는 온프 서버로 못 감
“회사 AD에서 인증된 사람만,
클라우드 리소스에 추가로 접근할 수 있게 하겠다”
라는 구조에 적합.
5-2. Two-way trust 예시
- 양쪽이 서로를 신뢰
- AWS Managed AD 에서 만든 서비스 계정 또는 리소스가
온프 쪽 리소스에 접근할 수도 있고, 반대도 가능
온프 ↔ 클라우드가 꽤 깊게 엮여 있고,
앱이 서로의 리소스를 많이 호출하는 복잡한 환경에서 사용.
6. 이 그림과 이전 “Shared Services account 버전”의 차이 정리
| 항목 | 이전 그림 | 이번 그림 |
|---|---|---|
| 오른쪽 계정 이름 | Shared Services account | Org Management account |
| 의미 | AD, VPN, 프록시 등 공용 인프라를 모아두는 전용 계정 | Organizations의 최상위 관리 계정 |
| 실무 권장 | ✅ AD 두기 좋은 곳 | ⚠️ 보통은 워크로드/AD를 넣지 말라고 권장 |
| 나머지(Managed AD, trust, 온프 AD) | 구조/역할 동일 | 구조/역할 동일 |
7. 최종 정리
이 그림을 기준으로, 아주 구체적인 흐름 하나만 잡아보면:
- 사용자는 회사 노트북에서 온프 AD 계정으로 로그인
→ 온프 AD가 Kerberos 티켓(TGT)을 발급 - 사용자가 VPN/Direct Connect 통해 AWS VPC에 있는 Windows 서버로 RDP 시도
→ 그 서버는 AWS Managed AD 도메인에 join - 서버는 “이 사용자 corp 도메인 유저인데, trust 있으니 corp AD에 인증 맡겨야지”
→ Kerberos를 통해 온프 AD에서 인증 결과 확인 - 인증/그룹 확인이 끝나면, 서버는 ACL에 따라 접근 허용
즉:
- 계정/그룹/정책: 온프 AD
- 클라우드 리소스 도메인 가입: AWS Managed AD
- 두 세계를 잇는 다리: one-way / two-way trust
