5. 온프레미스와 AWS 아키텍처 비교해보기
온프레미스
회사가 직접 서버&장비를 사서 자체 건물(데이터센터)에 설치해 운영
- 클라우드(aws)의 반대말이라고 생각하면 됨
- 서버, 네트워크 장비, 전기, 냉각, 유지보수까지 전부 회사가 직접 관리
- ex: 회사 지하 서버실에 직접 산 델(Dell) 서버 놓고 운영
AWS와 비교
| 구분 | 온프레미스 | AWS(클라우드) |
|---|---|---|
| 초기 비용 | 큼 (서버 구매) | 거의 없음 (쓴 만큼) |
| 확장 속도 | 느림 (서버 주문~설치 몇 주) | 빠름 (몇 분 내 스케일업) |
| 유지보수 | 회사가 직접 (전기, 냉각, 하드웨어 교체) | AWS가 대신 함 |
| 트래픽 변동 대응 | 어려움 (최대치 기준으로 미리 사둬야 함) | 쉬움 (오토스케일링) |
| 고가용성 (HA) | 멂 | 가까움 |
시스템 일부가 고장 나도 서비스 전체는 계속 돌아가게 만드는 설계
AWS에서 HA를 만드는 대표 방법
- 서버(EC2)를 여러 가용 영역(AZ)에 나눠 배치 → 한 AZ가 통째로 죽어도 다른 AZ가 살아있음
- 로드밸런서(ELB)로 여러 서버에 트래픽 분산 → 서버 1대 죽어도 나머지가 처리
- DB도 다중 AZ(Multi-AZ) 배포 → 주 DB 죽으면 자동으로 대기 DB가 이어받음
6. DMS(Database Migration Service) 설명
원본 DB에 있는 데이터를 목적지 DB(RDS)로 복사해서 옮겨주는 서비스
원본 DB 주소/ID/비번, 목적지 DB(RDS) 주소/ID/비번을 입력하면
[온프레미스 원본 DB] → (DMS 인스턴스가 읽어서) → [AWS RDS]DMS가 중간에서 데이터 읽고 옮겨쓰는 복사 역할을 하나 만들어주는 거라고 생각하면 됨 (사람이 직접 데이터를 export/import 안 해도 됨)
- 빠르고 안전하게 DB를 AWS로 마이그레이션하며, 복원성이 좋고 자가 복구 기능을 제공한다.
- 마이그레이션 중에도 원본 DB는 사용 가능
- 동종 (Homogeneous) 마이그레이션: ex. Oracle에서 Oracle로
- 이기종 (Heterogeneous) 마이그레이션: ex. Microsoft SQL Server에서 Aurora로
- CDC(Continuous Data Replication)를 사용한 지속적인 데이터 복제, 마이그레이션하는 동안에도 원본 DB를 계속 운영하면서, 그 사이 바뀐 데이터까지 실시간으로 따라 옮겨주는 기능
- "다운타임 최소화", "무중단 마이그레이션" 같은 문구가 지문에 나오면 → CDC
- DMS를 사용하려면 복제 작업을 수행하기 위해 EC2 인스턴스를 생성해야 함
상황:
온프레미스에서 운영하던 쇼핑몰을 AWS로 그대로 옮기는 중
- 쇼핑몰 코드 → EC2 인스턴스에 배포
- DB 데이터 → RDS로 이전
- 도메인 주소 → AWS 로드밸런서로 연결
7. Route 53과 ACM으로 도메인 연결하기
07. Route 53과 ACM으로 도메인 연결하기
Route 53
도메인 이름을 IP 주소로 바꿔주는 AWS의 DNS 서비스
- 사람은 example.com 같은 이름을 치지만, 컴퓨터끼리는 IP 주소로만 통신함
- 이 둘을 연결(변환)해주는 시스템을 DNS라고 부르고, AWS 서비스 = Route 53
- 직접 DNS 서버를 구축하면 네임서버 설정, 안정성 유지까지 다 회사가 관리해야 해서 복잡함 → Route 53은 AWS가 대신 관리해줌
Route 53의 3가지 주요 기능
| 기능 | 하는 일 |
|---|---|
| 도메인 등록 | Route 53에서 직접 도메인을 사고 관리 |
| 헬스 체크 | 서버가 살아있는지 주기적으로 확인 → 장애 나면 자동으로 다른 정상 리전으로 트래픽 우회 |
| 트래픽 라우팅 | 지리적 위치 / 지연 시간 / 가중치 기반 등 다양한 방식으로 트래픽 분산 |
트래픽 라우팅 → 라우팅 정책 종류
요구사항 키워드 라우팅 정책 사용자와 가장 가까운 서버로 Geoproximity 특정 국가/지역 사용자만 다른 곳으로 Geolocation 응답 속도가 가장 빠른 리전으로 Latency-based 여러 서버에 비율 나눠서(예: 90:10 카나리 배포) Weighted 장애 시 대체 서버로 자동 전환 Failover 여러 IP를 무작위로 반환해 단순 분산 Multivalue Answer
Certificate Manager(ACM)
웹사이트 주소창의 자물쇠, 즉 HTTPS를 가능하게 하는 SSL/TLS 인증서를 발급하고 자동으로 관리해주는 서비스
- HTTPS = 사용자 데이터가 암호화돼서 안전하게 오가는 연결. 그걸 가능하게 하는 게 SSL/TLS 인증서
- 원래는 인증서를 직접 사고, 서버에 설치하고, 만료 전에 갱신까지 다 챙겨야 해서 번거롭고, 깜빡하면 서비스가 갑자기 끊길 위험도 있음
- ACM이 이 전 과정(발급 → 설치 → 갱신)을 자동화해줌
ACM의 4가지 주요 기능
| 기능 | 설명 |
|---|---|
| 무료 발급 | 퍼블릭 도메인용 SSL/TLS 인증서 무료 |
| 자동 갱신 | 만료 걱정 없이 알아서 갱신 |
| 간편 배포 | ELB, CloudFront, API Gateway 등에 클릭 몇 번으로 연결 |
| 프라이빗 인증서 | 내부 서비스 전용 인증서도 발급 가능 |
문제
Q1
한 회사가 온프레미스에서 단일 서버로 웹 애플리케이션을 운영 중이며, 서버 장애 시 서비스가 완전히 중단되는 문제를 겪고 있습니다. AWS로 이전하면서, 한 가용 영역(AZ)에 장애가 발생해도 애플리케이션이 계속 동작하도록 만들고자 합니다. 트래픽 증가에도 자동으로 대응해야 합니다.
A. 하나의 AZ에 대형 EC2 인스턴스 1대를 배치하고 정기적으로 스냅샷을 생성한다.
B. 여러 AZ에 걸친 EC2 인스턴스를 Auto Scaling 그룹으로 구성하고, 앞단에 Application Load Balancer를 둔다.
C. 하나의 AZ에 EC2 인스턴스 2대를 배치하고 그 앞에 ALB를 둔다.
D. EC2 인스턴스 1대에 Elastic IP를 할당하고 장애 시 수동으로 교체한다.
풀이
1. 요구사항 분석
- AZ 장애에도 무중단 → 다중 AZ 분산 필수
- 트래픽 증가 자동 대응 → Auto Scaling
- 서버 앞단에서 트래픽 분산 → 로드 밸런서
2. 관련 AWS 서비스
- Auto Scaling Group: 부하에 따라 인스턴스 수를 자동 조절, 여러 AZ에 분산 배치 가능
- ELB(ALB): 여러 인스턴스로 트래픽 분산 + 비정상 인스턴스 자동 제외
- 가용 영역(AZ): 서로 물리적으로 분리 → 한 AZ 장애가 다른 AZ에 영향 없음
3. 선택지 분석
- A → 단일 AZ + 단일 인스턴스라 SPOF(단일 장애점). 스냅샷은 백업일 뿐 가용성 해결책이 아님
- B → 다중 AZ + ASG + ALB로 고가용성과 자동 확장을 모두 충족
- C → 인스턴스는 2대지만 단일 AZ라 그 AZ 전체 장애에 취약
- D → 여전히 단일 인스턴스 + 수동 복구라 무중단 요건 미충족
Q2
회사의 도메인 이름 레코드를 호스팅하는 DNS 공급자가 AWS에서 실행되는 웹 사이트의 서비스 중단을 초래하는 중단을 겪고 있습니다. 회사는 보다 탄력적인 관리형 DNS 서비스로 마이그레이션해야 하며 해당 서비스가 AWS에서 실행되기를 원합니다.
DNS 호스팅 서비스를 신속하게 마이그레이션하려면 솔루션 설계자가 무엇을 해야 합니까?
A. 도메인 이름에 대한 Amazon Route 53 퍼블릭 호스팅 영역을 생성합니다. 이전 공급자가 호스팅하는 도메인 레코드가 포함된 영역 파일을 가져옵니다.
B. 도메인 이름에 대한 Amazon Route 53 프라이빗 호스팅 영역을 생성합니다. 이전 공급자가 호스팅하는 도메인 레코드가 포함된 영역 파일을 가져옵니다.
C. AWS에서 Simple AD 디렉터리를 생성합니다. 도메인 레코드에 대해 DNS 공급자와 Microsoft Active Directory용 AWS Directory Service 간의 영역 전송을 활성화합니다.
D. VPC에 Amazon Route 53 Resolver 인바운드 엔드포인트를 생성합니다. 공급자의 DNS가 DNS 쿼리를 전달할 IP 주소를 지정합니다. 도메인에 대한 DNS 쿼리를 인바운드 엔드포인트에 지정된 IP 주소로 전달하도록 공급자의 DNS를 구성합니다.
풀이
외부 인터넷 사용자가 접속하는 웹 사이트의 DNS 장애를 해결하고 AWS로 전환하려면, 인터넷 트래픽을 라우팅할 수 있는 Amazon Route 53 퍼블릭 호스팅 영역이 필요합니다. 기존 DNS 공급자로부터 영역 파일(Zone File)을 추출하여 Route 53에 가져오기(Import)하면 레코드를 수동으로 하나씩 생성할 필요 없이 신속하게 마이그레이션을 완료할 수 있습니다.
1. 문제의 요구사항 분석하기
- 외부에서 접속 가능한 웹 사이트의 DNS 서비스 중단 신속 해결.
- 탄력적인 AWS 관리형 DNS 서비스로 마이그레이션.
- 기존 레코드를 빠르게 옮겨 서비스 중단을 최소화.
2. 관련 AWS 서비스 생각하기
- Amazon Route 53 : 가용성과 확장성이 뛰어난 AWS의 클라우드 DNS 웹 서비스로, 퍼블릭 호스팅 영역(인터넷 트래픽 라우팅용)과 프라이빗 호스팅 영역(VPC 내부용) 두 가지 유형을 제공합니다. 또한 BIND 형식의 영역 파일 가져오기(Import Zone File) 기능을 통해 기존 DNS 공급자의 레코드를 한 번에 옮겨 올 수 있어 마이그레이션 시간을 단축할 수 있습니다.
- Amazon Route 53 Resolver : VPC와 온프레미스 네트워크 간 DNS 쿼리를 해석할 수 있도록 하는 하이브리드 DNS 기능으로, 인바운드/아웃바운드 엔드포인트를 제공합니다.
- AWS Directory Service (Simple AD 등) : AWS에서 관리형 디렉터리 서비스를 제공하며, 주로 사용자 인증 및 내부 AD 통합 용도로 활용됩니다.
3. 선택지 분석하기
A. 도메인 이름에 대한 Amazon Route 53 퍼블릭 호스팅 영역을 생성합니다. 이전 공급자가 호스팅하는 도메인 레코드가 포함된 영역 파일을 가져옵니다.
→ 인터넷 사용자를 위한 퍼블릭 호스팅 영역을 생성하고, 영역 파일을 가져와 신속하게 마이그레이션할 수 있는 해결책입니다.
B. 도메인 이름에 대한 Amazon Route 53 프라이빗 호스팅 영역을 생성합니다. 이전 공급자가 호스팅하는 도메인 레코드가 포함된 영역 파일을 가져옵니다.
→ 프라이빗 호스팅 영역은 하나 이상의 특정 VPC 내에서만 내부적으로 트래픽을 라우팅할 때 사용되므로, 퍼블릭 웹 사이트용으로는 적합하지 않습니다.
C. AWS에서 Simple AD 디렉터리를 생성합니다. 도메인 레코드에 대해 DNS 공급자와 Microsoft Active Directory용 AWS Directory Service 간의 영역 전송을 활성화합니다.
→ Simple AD는 내부 디렉터리 서비스 및 인증 용도이며, 일반적인 인터넷 웹 사이트의 글로벌 DNS 호스팅을 위한 서비스가 아닙니다.
D. VPC에 Amazon Route 53 Resolver 인바운드 엔드포인트를 생성합니다. 공급자의 DNS가 DNS 쿼리를 전달할 IP 주소를 지정합니다. 도메인에 대한 DNS 쿼리를 인바운드 엔드포인트에 지정된 IP 주소로 전달하도록 공급자의 DNS를 구성합니다.
→ Route 53 Resolver 인바운드 엔드포인트는 온프레미스 네트워크에서 AWS VPC 내부 리소스의 DNS를 해석할 때 사용하는 하이브리드 구성이므로 퍼블릭 웹 호스팅 목적과 무관합니다.
'aws' 카테고리의 다른 글
| [AWS] AWS Student Community Day 회고 (0) | 2026.07.10 |
|---|---|
| [AWS] CloudTrail을 이용한 AWS 사용자 활동 추적과 로그 분석 (3) | 2026.07.10 |
| [AWS] S3 Presigned URL: 비공개 파일 안전하게 공유하기 (0) | 2026.07.10 |