Directory Service

이번 글에서는 AWS Directory Service를 파고듭니다.

Directory Service는 AWS 계정 관리 시리즈에서 다소 독특한 위치에 있습니다. IAM이나 STS는 AWS 자체의 자격 증명 시스템인 반면, Directory Service는 기업이 이미 수십 년간 써온 인증 체계 — Active Directory — 를 AWS에 가져오거나 연결하는 다리 역할을 합니다.

이 글에서 다루는 핵심 질문들:

• Active Directory가 정확히 무엇이고, 왜 기업에서 이것을 쓰는가?
• AWS Directory Service의 세 가지 옵션은 언제 무엇을 선택해야 하는가?
• 온프레미스 AD와 AWS를 연동할 때 실제로 어떤 일이 일어나는가?
• EC2 인스턴스를 도메인에 가입(Domain Join)시키면 무엇이 달라지는가?

 

1. Active Directory란 무엇인가? — 기업 인증의 근간

1-1. 디렉터리 서비스의 역할

디렉터리 서비스(Directory Service)는 쉽게 말해 "조직 내 모든 것의 주소록" 입니다.

• 누가 이 조직의 구성원인가? (사용자 계정)
• 어떤 그룹이 있고, 누가 속해 있는가? (그룹 관리)
• 어떤 컴퓨터가 네트워크에 있는가? (컴퓨터 계정)
• 누가 어떤 리소스에 접근할 수 있는가? (접근 제어)
• 어떤 보안 정책이 적용되는가? (GPO - Group Policy Object)

Microsoft의 Active Directory Domain Services(AD DS) 는 1999년 Windows 2000 Server와 함께 출시된 이후, 전 세계 기업 환경에서 사실상 표준이 되었습니다. 오늘날 대다수의 기업이 임직원 인증을 AD로 처리합니다.

1-2. Active Directory의 핵심 프로토콜

AD가 실제로 어떻게 동작하는지 이해하려면 두 가지 핵심 프로토콜을 알아야 합니다.

 

① Kerberos — 현대 AD 인증의 주인공

Kerberos는 AD 환경에서 사용자 인증을 처리하는 티켓 기반 프로토콜입니다. 1980년대 MIT에서 개발됐으며, 비밀번호를 네트워크로 직접 전송하지 않고 암호화된 티켓을 주고받는 방식으로 동작합니다.

Kerberos 인증 흐름을 단순화하면:

1. 사용자가 로그인 시 KDC(Key Distribution Center)에 인증 요청
2. KDC가 TGT(Ticket Granting Ticket) 발급
   → "이 사람은 인증된 사용자입니다"라는 증명서
3. 사용자가 특정 서비스(예: 파일 서버) 접근 시
   TGT를 KDC에 제시하여 서비스 티켓 요청
4. KDC가 서비스 티켓 발급
5. 사용자가 서비스 티켓으로 서버에 직접 접근

이 방식의 핵심 장점은 SSO(Single Sign-On)입니다. 아침에 한 번 로그인하면, 그 티켓으로 모든 AD 연동 서비스에 추가 로그인 없이 접근합니다. 파일 서버, 이메일 서버, ERP 시스템 — 모두 같은 회사 계정으로.

 

② LDAP — AD의 데이터 검색 프로토콜

LDAP(Lightweight Directory Access Protocol)는 디렉터리에서 정보를 읽고 쓰는 프로토콜입니다. 사용자 목록 조회, 그룹 멤버십 확인, 사용자 속성 검색 등에 사용됩니다.

LDAP 쿼리 예시:
"mail 속성이 alice@company.com인 사용자를 찾아라"
→ DC=company,DC=com 하위에서 (mail=alice@company.com) 검색

결과:
cn=Alice Kim
sAMAccountName=alice
memberOf=CN=Developers,OU=Groups,DC=company,DC=com
mail=alice@company.com

많은 애플리케이션(Jenkins, GitLab, Jira, 이메일 서버 등)이 "LDAP 인증"을 지원한다고 할 때, 바로 이 프로토콜로 AD에서 사용자를 조회해 인증을 처리합니다.

1-3. AD의 계층 구조

AD는 조직을 논리적으로 표현하기 위해 계층 구조를 사용합니다.

Forest (포리스트): company.com
└── Tree (트리): company.com
    ├── Domain (도메인): company.com
    │   ├── OU (조직 단위): Employees
    │   │   ├── OU: Engineering
    │   │   │   ├── User: alice (Engineer)
    │   │   │   └── User: bob (Engineer)
    │   │   └── OU: HR
    │   │       └── User: charlie (HR Manager)
    │   ├── OU: Computers
    │   │   ├── Computer: WORKSTATION-01
    │   │   └── Computer: SERVER-PROD-01
    │   └── OU: Groups
    │       ├── Group: Developers
    │       └── Group: Admins
    └── Child Domain: us.company.com (자회사/지역 도메인)

이 구조에서 중요한 개념들:

• Domain(도메인): 인증과 정책의 기본 단위. company.com이 하나의 도메인
• OU(Organizational Unit): 도메인 내의 논리적 컨테이너. 부서/팀 단위로 GPO 적용
• Forest(포리스트): 여러 도메인의 최상위 컨테이너. 보안 경계
• Trust(신뢰 관계): 서로 다른 도메인/포리스트 간 인증을 허용하는 관계

1-4. Group Policy Object (GPO)

GPO는 AD에서 정책을 일괄 적용하는 강력한 도구입니다. 도메인이나 OU에 GPO를 연결하면, 그 범위 안의 모든 컴퓨터와 사용자에게 자동으로 정책이 적용됩니다.

GPO로 할 수 있는 것들:

정책	예시 내용
비밀번호 정책	최소 12자, 대문자+숫자+특수문자 포함
화면 잠금	15분 비활성 시 자동 잠금
소프트웨어 배포	도메인 가입 PC에 Anti-virus 자동 설치
방화벽 규칙	특정 포트 차단 일괄 적용
USB 드라이브 차단	특정 OU 내 PC에서 외장 저장장치 비활성화

EC2 Windows 인스턴스를 AD에 조인(Domain Join)하면 이 GPO가 클라우드 인스턴스에도 자동으로 적용됩니다. 온프레미스 서버와 동일한 보안 정책을 유지할 수 있어, 규정 준수(Compliance) 요건을 충족하기가 훨씬 쉬워집니다.

 

2. AWS Directory Service 세 가지 옵션

AWS는 세 가지 방식으로 디렉터리 서비스를 제공합니다. 이 셋은 목적이 완전히 다르므로, 상황에 따라 올바른 것을 선택해야 합니다.

 

2-1. AWS Managed Microsoft AD

정의: AWS가 완전 관리하는 진짜 Microsoft Active Directory입니다. Windows Server 2019 기반의 실제 AD DS가 AWS 클라우드에서 실행되며, AWS가 도메인 컨트롤러의 패치, 백업, 복구를 담당합니다.

핵심 특성:

• AWS 관리형 Microsoft AD는 클라우드에서 AWS가 관리하는 실제 Microsoft Windows Server Active Directory로 구동됩니다
• 기본적으로 서로 다른 가용 영역(AZ)에 최소 2개의 도메인 컨트롤러를 배포해 고가용성을 보장합니다
• 도메인 컨트롤러에 직접 RDP, SSH, Telnet으로 접근할 수 없습니다. AWS가 관리하는 영역이기 때문입니다
• 온프레미스 AD와 Trust Relationship을 구성해 하이브리드 환경을 만들 수 있습니다

에디션:

에디션	디렉터리 객체 수	주요 대상
Standard	최대 약 30,000개	중소기업
Enterprise	최대 약 500,000개	대기업
Hybrid	기존 온프레미스 AD 확장	하이브리드 인프라

 

지원하는 AWS 서비스:

• Amazon EC2 (도메인 조인, GPO 적용)
• Amazon RDS for SQL Server (Windows 인증)
• Amazon WorkSpaces, AppStream 2.0
• Amazon FSx for Windows File Server
• AWS IAM Identity Center (AD를 자격 증명 소스로)

언제 선택하나:

• 5,000명 이상의 사용자
• 온프레미스 AD와 Trust 관계가 필요할 때
• RDS SQL Server를 AD 인증으로 사용해야 할 때
• AWS에서 완전히 새로운 AD 도메인을 구축할 때

 

2-2. AD Connector

정의: AD Connector는 프록시입니다. 클라우드에 별도 디렉터리를 만들지 않고, 기존 온프레미스 AD를 향해 인증 요청을 중계합니다.

핵심 특성:

• AD Connector는 클라우드에 어떠한 정보도 캐싱하지 않고 디렉터리 요청을 온프레미스 Microsoft Active Directory로 프록시합니다
• 사용자 자격 증명이 AWS에 저장되지 않음 — 온프레미스 AD가 Single Source of Truth
• AD Connector는 RDS SQL Server와 호환되지 않습니다
• 온프레미스 네트워크와의 연결이 끊기면 인증이 불가능합니다 (VPN/Direct Connect 필수)
• 기존 RADIUS 기반 MFA 인프라에 연결해 MFA를 활성화할 수 있습니다

AD Connector의 필수 전제 조건:

온프레미스 DC ← VPN 또는 Direct Connect → AD Connector (VPC 내)

연결이 반드시 있어야 합니다. 연결이 없으면 AD Connector는 아무것도 할 수 없습니다.

언제 선택하나:

• 이미 온프레미스 AD가 있고, 그것을 그대로 사용하고 싶을 때
• AWS에 사용자 데이터를 저장하고 싶지 않을 때 (데이터 주권/규정 준수)
• EC2 Windows 인스턴스를 온프레미스 도메인에 조인하고 싶을 때
• WorkSpaces, WorkDocs, WorkMail 등을 기존 AD로 인증하고 싶을 때

 

2-3. Simple AD

정의: Simple AD는 Samba 4 기반의 독립 실행형 Microsoft Active Directory 호환 디렉터리입니다. 클라우드에서 독립적으로 동작하며, 작고 비용 효율적인 솔루션입니다

핵심 특성:

• Simple AD는 최대 5,000명의 사용자를 지원하는 저비용, 소규모 디렉터리로 기본 Active Directory 호환성을 제공합니다
• 진짜 Microsoft AD가 아닌 Samba 4 구현체이므로 고급 기능이 없습니다
• 지원하지 않는 기능: MFA, Trust 관계, DNS 동적 업데이트, 스키마 확장, LDAPS, FSMO 역할 전달
• RDS SQL Server 미지원

언제 선택하나:

• 소규모 팀(5,000명 이하)
• 기본적인 사용자/그룹 관리, EC2 도메인 조인만 필요
• 비용을 최소화하고 싶을 때
• 온프레미스 AD가 없는 스타트업이나 테스트 환경

 

2-4. 세 가지 비교 표

항목	AWS Managed Microsoft AD	AD Connector	Simple AD
실제 AD 여부	✅ 진짜 MS AD	❌ 프록시	⚠️ Samba 4
사용자 데이터 저장 위치	AWS	온프레미스	AWS
최대 사용자 수	~500,000	제한 없음	~5,000
온프레미스 AD 필요	선택	필수	불필요
Trust 관계	✅	❌	❌
MFA 지원	✅	✅ (RADIUS)	❌
RDS SQL Server	✅	❌	❌
FSx for Windows	✅	❌	❌
VPN/Direct Connect	선택	필수	불필요
비용	높음	중간	낮음

3. Trust Relationship — 두 AD 도메인을 연결하는 신뢰

Trust Relationship은 서로 다른 AD 도메인(또는 포리스트) 간의 인증 신뢰 협약입니다. Trust가 맺어지면, 한쪽 도메인의 사용자가 상대 도메인의 리소스에 접근할 수 있습니다.

3-1. Trust의 방향

단방향 Trust (One-Way Trust):

온프레미스 AD (corp.local) → AWS Managed AD (aws.corp.local)
     신뢰함(Trusts)               신뢰받음(Trusted)

이 경우 aws.corp.local의 사용자가 corp.local의 리소스에 접근할 수 있지만, 반대는 불가합니다.

 

양방향 Trust (Two-Way Trust):

온프레미스 AD (corp.local) ↔ AWS Managed AD (aws.corp.local)
     서로 신뢰함

양쪽 도메인 사용자 모두 상대방 리소스에 접근 가능합니다.

3-2. Trust의 종류

External Trust (외부 신뢰):

• 두 도메인 간의 직접 1:1 신뢰
• 비전이적(Non-transitive): A↔B, B↔C 신뢰가 있어도 A→C 자동 허용 없음
• NTLM 인증 사용 (Kerberos 부분 가능)

Forest Trust (포리스트 신뢰):

• 두 포리스트 전체 간의 신뢰
• Forest Trust는 두 포리스트 간의 리소스 공유에 사용되며, Kerberos와 완전히 호환되는 선호하는 트러스트 모델입니다
• 전이적(Transitive): A↔B Forest Trust가 있으면 A 내 모든 도메인이 B 내 모든 도메인과 신뢰

실무 권장: 가능하면 Forest Trust를 사용하세요. Kerberos SSO가 완전히 동작하며, External Trust보다 관리가 단순합니다.

3-3. AWS Managed AD와 온프레미스 AD Trust 구성 흐름

1. AWS Managed Microsoft AD 생성
2. 온프레미스 AD와 AWS 간 네트워크 연결 (VPN 또는 Direct Connect)
3. DNS 포워딩 설정
   - 온프레미스 DNS → AWS 도메인(aws.corp.local) 쿼리를 AWS로 포워딩
   - AWS Route 53 Resolver → 온프레미스 도메인(corp.local) 쿼리를 온프레미스로 포워딩
4. 온프레미스 AD에서 Trust 생성 (먼저 생성해야 함)
5. AWS Managed AD에서 Trust 생성
6. Trust 검증

중요: Trust를 생성할 때 온프레미스 도메인에서 먼저 Trust를 생성한 다음, AWS Managed Microsoft AD에서 Trust를 생성해야 합니다.

 

4. Domain Join — EC2 인스턴스를 AD에 연결하기

4-1. Domain Join이란?

EC2 Windows 인스턴스를 AD 도메인에 가입(Join)시키면, 그 인스턴스는 AD의 구성원이 됩니다. 이후부터:

• AD 사용자 계정으로 RDP 로그인 가능 (로컬 계정 불필요)
• GPO 자동 적용 (보안 정책, 소프트웨어 배포 등)
• AD 그룹 기반 접근 제어 가능
• Kerberos SSO 지원

기업 환경에서 "EC2에서 Windows 서버를 운영한다"면, 대부분 도메인에 조인해서 중앙 집중적으로 관리합니다.

4-2. 도메인 조인 방법 비교

방법 1: 콘솔 / 수동 조인 EC2 시작 시 또는 이미 실행 중인 인스턴스에 RDP 접속 후 Windows의 "도메인 가입" 기능을 직접 사용합니다. 소규모 환경이나 테스트 용도에 적합합니다.

 

방법 2: EC2 Launch Wizard (자동 조인) EC2 인스턴스를 시작할 때 "도메인 조인 디렉터리"를 선택하면, 인스턴스가 부팅되면서 자동으로 도메인에 가입됩니다. AWS Systems Manager SSM Agent가 이 과정을 처리합니다.

EC2 콘솔 → 인스턴스 시작 → 고급 세부 정보
→ 도메인 조인 디렉터리: [생성한 Directory ID 선택]
→ IAM 인스턴스 프로파일: [SSM 권한이 있는 Role 선택]

 

방법 3: SSM Automation (대규모 자동화) AWS Systems Manager의 AWS-JoinDirectoryServiceDomain 자동화 문서를 사용하면 기존 인스턴스를 도메인에 대량으로 조인할 수 있습니다.

aws ssm start-automation-execution \
  --document-name "AWS-JoinDirectoryServiceDomain" \
  --parameters \
    directoryId=d-xxxxxxxx,\
    directoryName=corp.example.com,\
    instanceIds=i-1234567890abcdef0

4-3. Domain Join 후 실제 변화

도메인 조인 전후를 비교하면:

[조인 전]
- 로컬 계정(Administrator)으로만 RDP 로그인 가능
- 보안 정책을 인스턴스마다 개별 설정
- 중앙 집중 관리 불가

[조인 후]
- AD 사용자 계정(CORP\alice)으로 RDP 로그인 가능
- GPO 자동 적용 (비밀번호 정책, 화면 잠금, 방화벽 등)
- AD 그룹(CORP\Admins)을 로컬 Administrators 그룹에 추가해 권한 위임 가능
- RSAT 도구로 중앙에서 관리 가능

 

5. AWS Managed Microsoft AD와 IAM Identity Center 연동

AWS Managed Microsoft AD의 가장 강력한 활용은 IAM Identity Center와 연동하는 것입니다.

이 조합이 갖추어지면:

직원 → 회사 AD 계정으로 로그인
     → IAM Identity Center가 AD를 자격 증명 소스로 사용
     → Permission Set(IAM Role 묶음) 매핑
     → 여러 AWS 계정에 SSO 접근

즉, 직원이 회사 LDAP/AD 계정 하나로 모든 AWS 계정에 SSO 접근합니다. AD 계정이 비활성화되면 자동으로 AWS 접근도 차단됩니다. 

 

6. 실습: AWS Managed Microsoft AD 생성 및 EC2 Domain Join

이 실습은 AWS Managed Microsoft AD를 생성하고, EC2 Windows 인스턴스를 도메인에 가입시켜 AD 계정으로 RDP 로그인하는 것까지 구현합니다.

 

비용 주의: AWS Managed Microsoft AD는 시간당 과금됩니다. Standard Edition 기준 약 $0.05/도메인컨트롤러/시간 (최소 2개 DC). 실습 후 반드시 삭제하세요. 30일 무료 체험(1,500 DC 시간)을 활용할 수 있습니다.

실습 환경 구성

[실습 구성]
VPC: 10.0.0.0/16
  ├── 퍼블릭 서브넷 1 (ap-northeast-2a): 10.0.1.0/24 → EC2 인스턴스
  ├── 프라이빗 서브넷 1 (ap-northeast-2a): 10.0.10.0/24 → AD DC
  └── 프라이빗 서브넷 2 (ap-northeast-2c): 10.0.20.0/24 → AD DC (이중화)

Step 1: VPC 및 서브넷 준비

실습용 VPC가 없다면 먼저 생성합니다:

VPC 콘솔 → VPC 생성
→ VPC 설정: VPC 및 기타 (VPC + 서브넷 자동 생성)
→ IPv4 CIDR: 10.0.0.0/16
→ 가용 영역 수: 2
→ 퍼블릭 서브넷 수: 2 (EC2 접근용)
→ 프라이빗 서브넷 수: 2 (AD DC용)

Step 2: AWS Managed Microsoft AD 생성

Directory Service 콘솔 → 디렉터리 설정 → 디렉터리 유형 선택
→ AWS Managed Microsoft AD 선택 → 다음

[디렉터리 정보]
에디션: Standard
DNS 이름: corp.example.com        ← 조직에 맞게 설정
NetBIOS 이름: CORP
관리자 비밀번호: [복잡한 비밀번호 설정]  ← 반드시 기록해두기

[네트워킹]
VPC: [위에서 만든 VPC 선택]
서브넷: [프라이빗 서브넷 2개 선택 — 서로 다른 AZ]

→ 검토 및 생성

 

 

 

생성 완료 후 확인해야 할 것들:

# Directory ID 확인 (d-xxxxxxxxxx 형태)
aws ds describe-directories --query 'DirectoryDescriptions[*].{ID:DirectoryId,Name:Name,Status:Stage}'

# DNS 주소 확인 (두 개의 IP)
aws ds describe-directories \
  --directory-ids d-xxxxxxxxxx \
  --query 'DirectoryDescriptions[0].DnsIpAddrs'

Step 3: EC2 Domain Join용 IAM Role 생성

도메인 조인 자동화를 위해 EC2에 연결할 IAM Role이 필요합니다:

IAM 콘솔 → Roles → Create role
→ EC2 서비스 선택
→ 정책 추가:
   - AmazonSSMManagedInstanceCore (SSM 에이전트 통신)
   - AmazonSSMDirectoryServiceAccess (도메인 조인 자동화)
→ Role name: EC2-DomainJoin-Role
→ Create role

Step 4: AD 사용자 생성 (관리 EC2 인스턴스 사용)

AWS Managed Microsoft AD를 관리하는 방법은 두 가지입니다.

방법 A (최신 방식): Directory Service Data API 직접 사용

# 사용자 생성
aws ds-data create-user \
  --directory-id d-xxxxxxxxxx \
  --sam-account-name testuser \
  --given-name Test \
  --surname User \
  --password "TestP@ssw0rd!"

# 그룹 생성
aws ds-data create-group \
  --directory-id d-xxxxxxxxxx \
  --sam-account-name Developers

# 그룹에 사용자 추가
aws ds-data add-group-member \
  --directory-id d-xxxxxxxxxx \
  --group-sam-account-name Developers \
  --member-sam-account-name testuser

 

방법 B (전통적 방식): RSAT 도구 사용

AD 도메인에 조인된 Windows EC2 인스턴스에 RSAT(Remote Server Administration Tools)를 설치하고, Active Directory Users and Computers(ADUC) GUI로 관리합니다.

# Windows EC2에서 RSAT 설치
Install-WindowsFeature -Name RSAT-AD-Tools

# AD Users and Computers 열기
dsa.msc

Step 5: EC2 Windows 인스턴스 생성 및 도메인 조인

EC2 콘솔 → 인스턴스 시작

[AMI 선택]
Windows Server 2022 Base 선택

[인스턴스 유형]
t3.medium (Windows는 최소 이 크기 권장)

[고급 세부 정보]
IAM 인스턴스 프로파일: EC2-DomainJoin-Role
도메인 조인 디렉터리: corp.example.com [생성한 디렉터리 선택]

[보안 그룹]
RDP (3389): 내 IP에서만 허용

인스턴스가 시작되면서 자동으로 도메인에 조인됩니다. 약 5~10분 소요됩니다.

Step 6: AD 계정으로 RDP 로그인 확인

1. EC2 콘솔 → 인스턴스 선택 → 연결 → RDP 클라이언트
2. 비밀번호 가져오기 (키 페어 사용)
3. RDP 로그인 화면에서:
   사용자 이름: CORP\testuser  ← 도메인\사용자 형식
   비밀번호: TestP@ssw0rd!
4. 로그인 성공 확인

로그인 성공 후 PowerShell에서 확인:

# 도메인 가입 여부 확인
(Get-WmiObject Win32_ComputerSystem).Domain
# 출력: corp.example.com

# 현재 로그인 사용자 확인
whoami
# 출력: corp\testuser

# AD 그룹 멤버십 확인
whoami /groups | findstr CORP

 

7. 실습: AD Connector 설정 (개념 실습)

AD Connector는 온프레미스 AD가 있어야 하므로, 이 실습에서는 실제 온프레미스 AD 대신 EC2에 Self-managed AD를 구성하여 연결하는 시나리오로 진행합니다.

 

AD Connector의 필수 전제 조건

1. 온프레미스(또는 EC2 Self-managed) AD가 준비되어 있어야 함
2. VPN 또는 Direct Connect로 AWS VPC와 연결되어 있어야 함
3. AD Connector 서비스 계정 (비관리자 계정, 특정 권한만 부여)
   - Users, Groups, Computers 읽기 권한
   - 컴퓨터 도메인 가입 권한
4. 방화벽 규칙 (AD Connector → 온프레미스 DC):
   - TCP/UDP 88  (Kerberos)
   - TCP/UDP 389 (LDAP)
   - TCP 636     (LDAPS)
   - TCP/UDP 445 (SMB)
   - TCP/UDP 464 (Kerberos Password Change)

AD Connector 생성

Directory Service 콘솔 → 디렉터리 설정
→ AD Connector 선택 → 다음

[디렉터리 정보]
DNS 이름: corp.onprem.local
NetBIOS 이름: CORP

[연결 정보]
VPC: [선택]
서브넷: [두 개의 서브넷 선택]
DNS IP 주소:
  10.0.100.10  ← 온프레미스 DC 1의 IP
  10.0.100.11  ← 온프레미스 DC 2의 IP (이중화)
서비스 계정 사용자 이름: svc-ad-connector
서비스 계정 암호: [서비스 계정 비밀번호]

 

8. 아키텍처 패턴: 언제 무엇을 선택할까

패턴 1: 스타트업 / 클라우드 네이티브

AD가 없는 신규 조직이라면 대부분 AWS Managed Microsoft AD는 불필요합니다. 대신 IAM + IAM Identity Center로 충분합니다. Windows 워크로드가 많아지면 그때 Simple AD나 Managed AD를 검토하세요.

추천: IAM Identity Center (IdP 없이) + IAM User/Role
이유: 복잡성 최소화, 비용 절감

패턴 2: 기업 — 온프레미스 AD 있음, 클라우드로 일부 이전

기존 AD를 유지하면서 AWS를 사용하는 가장 일반적인 엔터프라이즈 패턴입니다.

추천: AD Connector
이유:
  - 온프레미스 AD가 Single Source of Truth 유지
  - 사용자 자격 증명이 AWS에 저장되지 않음
  - 이미 있는 인프라를 최대 활용
  - 단, VPN/Direct Connect 연결 필수, RDS SQL Server 불가

패턴 3: 기업 — 온프레미스 AD와 AWS를 독립적으로 운영하되 신뢰 관계 필요

AWS에서 새로운 AD 도메인을 운영하면서, 온프레미스 AD 사용자도 AWS 리소스에 접근이 가능해야 하는 경우입니다.

추천: AWS Managed Microsoft AD + Trust Relationship
이유:
  - AWS AD가 독립적으로 운영 (온프레미스 연결 단절 시에도 동작)
  - Trust로 온프레미스 사용자 접근 허용
  - RDS SQL Server, FSx 등 모든 AWS 서비스 지원
  - 단, 비용이 가장 높음

패턴 4: 대규모 기업 — 완전한 하이브리드 ID

추천: AWS Managed Microsoft AD (Hybrid Edition) + IAM Identity Center
이유:
  - AWS Managed AD가 온프레미스 AD 포리스트의 일부로 편입
  - IAM Identity Center를 통해 수십 개의 AWS 계정에 SSO
  - 전사적 단일 자격 증명 체계

 

Active Directory의 본질:

• LDAP(디렉터리 검색) + Kerberos(인증) + GPO(정책)의 조합
• 기업 환경에서 인증의 Single Source of Truth
• OU 계층 구조로 조직을 논리적으로 표현

AWS Directory Service 선택 기준:

• 온프레미스 AD 없음 + 소규모 → Simple AD (또는 IAM만으로 충분)
• 온프레미스 AD 있음 + 그대로 활용 → AD Connector (VPN/DX 필수)
• 클라우드 AD 독립 운영 + 풀 기능 → AWS Managed Microsoft AD

Trust Relationship:

• 서로 다른 AD 도메인/포리스트 간 인증 허용
• Forest Trust가 External Trust보다 선호됨 (Kerberos 완전 지원)
• 온프레미스 AD에서 먼저 Trust 생성 후 AWS 측에서 생성

Domain Join:

• EC2 인스턴스를 AD에 연결해 중앙 집중적 관리
• 콘솔 자동 조인, SSM Automation, 수동 조인 세 가지 방법

 

참고 자료

• AWS 공식 문서: AWS Directory Service란?
• AWS 공식 문서: Simple AD 모범 사례
• AWS 공식 문서: AD Connector 모범 사례
• AWS 공식 문서: 온프레미스 AD와 신뢰 관계 생성
• AWS 블로그: Trust with AWS Managed Microsoft AD에 대해 알고 싶은 모든 것
• AWS 공식 문서: AWS Directory Service 기능
• Tutorials Dojo: AWS Directory Service Cheat Sheet