빠른참조 · 4

서비스 선택 결정 트리

요구사항에서 출발해 질문 → 분기 → 결론으로 내려가면 서비스가 나옵니다. 서비스를 하나씩 아는 것과 요구사항에서 서비스를 뽑아내는 것은 다른 능력이고, 시험이 요구하는 것은 후자입니다.

갈래는 여섯입니다 — 스토리지 · 데이터베이스 · 컴퓨팅 · 네트워크 연결 · 데이터 전송 · 재해 복구.

이 페이지 쓰는 법

먼저 갈래를 정합니다

시나리오 문항은 대개 첫 두 문장에서 갈래가 드러납니다. "파일을 여러 서버가 공유해야 한다"는 스토리지, "온프레미스 데이터센터와 연결해야 한다"는 네트워크 연결, "리전 장애에 대비해야 한다"는 재해 복구입니다. 갈래를 틀리게 잡으면 아무리 세부 지식이 있어도 답이 나오지 않습니다.

문제문의 표현과 갈래의 대응
문제문에 이런 표현이 있으면 이 갈래로
"파일을 저장", "공유 스토리지", "아카이브", "백업 보관" 스토리지
"질의가 느리다", "스키마", "트랜잭션", "키로 조회" 데이터베이스
"애플리케이션을 실행", "컨테이너", "이벤트에 반응", "인스턴스 비용" 컴퓨팅
"인터넷을 거치면 안 된다", "온프레미스와 연결", "여러 VPC" 네트워크 연결
"데이터를 옮긴다", "마이그레이션", "테라바이트를 업로드" 데이터 전송
"리전 장애", "RTO", "RPO", "재해 복구" 재해 복구

스토리지

스토리지 선택 결정 트리 데이터에 어떻게 접근하는가라는 하나의 질문에서 시작해 네 갈래로 갈라지는 위에서 아래로 내려가는 결정 트리입니다. 첫째 갈래는 인스턴스 한 대가 디스크로 붙여 쓰는 경우입니다. 데이터가 사라져도 되고 최고 성능이 필요하면 EC2 인스턴스 스토어이고, 인스턴스와 무관하게 유지되어야 하면 Amazon EBS 입니다. EBS 안에서 볼륨 타입은 IOPS 와 스루풋 요구로 다시 가릅니다. 둘째 갈래는 여러 서버가 동시에 파일 시스템으로 쓰는 경우입니다. 프로토콜이 NFS 면 Amazon EFS, Windows SMB 면 FSx for Windows File Server, HPC 용 Lustre 면 FSx for Lustre 입니다. 셋째 갈래는 HTTP 로 객체를 통째로 읽고 쓰는 경우이며 Amazon S3 입니다. 접근 빈도로 클래스를 가릅니다. 자주 읽으면 Standard, 패턴이 불규칙하면 Intelligent-Tiering, 거의 읽지 않으면 Glacier 계열입니다. 넷째 갈래는 온프레미스 애플리케이션이 기존 프로토콜을 그대로 쓰는 경우이며 AWS Storage Gateway 입니다. 파일 공유면 파일 게이트웨이, 블록이면 볼륨 게이트웨이, 백업 소프트웨어면 테이프 게이트웨이를 씁니다. 시험 시나리오의 첫 문장에 나오는 접근 방식만 읽어도 후보가 네 갈래 중 하나로 좁혀진다는 것이 이 트리의 쓸모입니다. 데이터에 어떻게 접근하는가 인스턴스 한 대가 디스크로 붙여서 사라져도 되는가 사라져도 된다 인스턴스 스토어 유지되어야 한다 Amazon EBS 볼륨 타입은 IOPS · 스루풋 요구로 가릅니다 여러 서버가 동시에 파일 시스템으로 어떤 프로토콜인가 NFS Amazon EFS Windows SMB FSx for Windows HPC · Lustre FSx for Lustre HTTP 로 객체를 통째로 읽고 쓴다 Amazon S3 · 접근 빈도 자주 읽는다 S3 Standard 패턴이 불규칙하다 Intelligent-Tiering 거의 읽지 않는다 Glacier 계열 온프레미스 앱이 기존 프로토콜로 AWS Storage Gateway 파일 공유 파일 게이트웨이 블록 볼륨 볼륨 게이트웨이 백업 소프트웨어 테이프 게이트웨이 시나리오 첫 문장의 접근 방식만 읽어도 후보가 네 갈래 중 하나로 좁혀집니다
스토리지 선택 결정 트리 — 접근 방식(블록 · 파일 · 객체)에서 시작해 공유 여부, 지속성 요구, 프로토콜, 접근 빈도로 갈라져 Amazon EBS · 인스턴스 스토어 · Amazon EFS · Amazon FSx · Amazon S3 스토리지 클래스로 수렴합니다
스토리지 선택 — 질문, 분기, 결론
단계 질문 분기 결론
S1 데이터에 어떻게 접근하는가 인스턴스 한 대가 디스크로 붙여서 S2로
S1 데이터에 어떻게 접근하는가 여러 서버가 동시에 파일 시스템으로 S4로
S1 데이터에 어떻게 접근하는가 HTTP로 객체를 통째로 읽고 쓴다 S5로
S1 데이터에 어떻게 접근하는가 온프레미스 애플리케이션이 기존 프로토콜로 AWS Storage Gateway — 파일 공유면 파일 게이트웨이, 블록이면 볼륨 게이트웨이, 백업 소프트웨어면 테이프 게이트웨이
S2 데이터가 사라져도 되는가 사라져도 되고 최고 성능이 필요하다 EC2 인스턴스 스토어 — 인스턴스를 중지하면 소실됩니다
S2 데이터가 사라져도 되는가 인스턴스와 무관하게 유지되어야 한다 S3로
S3 어떤 EBS 볼륨 타입인가 대용량을 순차로 읽고 쓴다 (로그, 빅데이터) st1 — 부트 볼륨으로는 쓸 수 없습니다
S3 어떤 EBS 볼륨 타입인가 거의 읽지 않는 대용량을 가장 싸게 sc1 — 부트 볼륨으로는 쓸 수 없습니다
S3 어떤 EBS 볼륨 타입인가 매우 높은 IOPS와 높은 내구성이 요구된다 io2 — 최대 256,000 IOPS
S3 어떤 EBS 볼륨 타입인가 그 밖의 일반적인 경우 gp3 — 크기와 무관하게 성능을 따로 지정합니다
S4 어떤 프로토콜과 생태계가 필요한가 리눅스, NFS, 용량 자동 확장 Amazon EFS
S4 어떤 프로토콜과 생태계가 필요한가 Windows, SMB, Active Directory Amazon FSx for Windows File Server
S4 어떤 프로토콜과 생태계가 필요한가 고성능 컴퓨팅, 기계 학습 학습, S3 데이터셋 연동 Amazon FSx for Lustre
S4 어떤 프로토콜과 생태계가 필요한가 NFS와 SMB를 한 스토리지에서, 기존 NetApp 운영 유지 Amazon FSx for NetApp ONTAP
S4 어떤 프로토콜과 생태계가 필요한가 리눅스 NFS를 ZFS 스냅샷 기능과 함께 Amazon FSx for OpenZFS
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 자주 읽는다 S3 Standard
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 접근 패턴을 모른다 S3 Intelligent-Tiering — 이 분기의 유일한 답입니다
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 드물게 읽지만 즉시 접근해야 한다 S3 Standard-IA — 다시 만들 수 있는 데이터면 S3 One Zone-IA
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 아카이브인데 밀리초 접근이 필요하다 S3 Glacier Instant Retrieval
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 아카이브이고 분에서 시간 단위 복원을 감수할 수 있다 S3 Glacier Flexible Retrieval
S5 얼마나 자주 읽고, 읽어야 할 때 얼마나 빨리 필요한가 수년 보존이고 거의 읽지 않는다 S3 Glacier Deep Archive

데이터베이스

데이터베이스 선택 결정 트리 관계형 데이터인가라는 질문에서 시작해 왼쪽 관계형 갈래와 오른쪽 비관계형 갈래로 나뉘는 위에서 아래로 내려가는 결정 트리입니다. 관계형 갈래에서는 먼저 운영 부담을 얼마나 줄여야 하는지를 묻습니다. 최소로 줄여야 하면 Amazon Aurora 이고, 표준 관리형으로 충분하면 Amazon RDS 입니다. 그다음 읽기 확장과 가용성 가운데 무엇이 요구인지를 묻습니다. 읽기 확장이면 읽기 전용 복제본이고 가용성이면 Multi-AZ 배포입니다. 둘은 서로 다른 문제이므로 처방도 다릅니다. 비관계형 갈래에서는 데이터 모델을 묻습니다. 키-값이고 대규모 처리량이면 Amazon DynamoDB, MongoDB 호환 문서면 Amazon DocumentDB, 관계를 탐색하는 그래프면 Amazon Neptune, 시계열이면 Amazon Timestream, 인메모리 캐시나 초저지연 저장소면 Amazon ElastiCache 와 MemoryDB 입니다. 문제문에 LEAST operational overhead 라는 한정어가 보이면 관리형과 서버리스 쪽으로 꺾는 신호입니다. 관계형 데이터인가 예 — 관계형 운영 부담을 얼마나 줄여야 하는가 최소로 줄인다 Amazon Aurora 표준으로 충분 Amazon RDS 읽기 확장과 가용성 중 무엇이 요구인가 읽기 확장 읽기 전용 복제본 가용성 Multi-AZ 배포 읽기 확장과 가용성은 서로 다른 문제입니다 아니오 — 비관계형 어떤 데이터 모델인가 키-값 · 대규모 처리량 Amazon DynamoDB 문서 (MongoDB 호환) Amazon DocumentDB 그래프 · 관계 탐색 Amazon Neptune 시계열 Amazon Timestream 인메모리 · 초저지연 ElastiCache · MemoryDB LEAST operational overhead 한정어는 관리형과 서버리스 쪽으로 꺾는 신호입니다 읽기 확장과 가용성은 서로 다른 요구이므로 처방도 다릅니다
데이터베이스 선택 결정 트리 — 관계형 여부에서 시작해 운영 부담, 읽기 확장과 가용성 중 무엇이 요구인지, 비관계형이면 어떤 데이터 모델인지로 갈라져 Amazon RDS · Amazon Aurora · Amazon DynamoDB · 목적별 데이터베이스로 수렴합니다
데이터베이스 선택 — 질문, 분기, 결론
단계 질문 분기 결론
D1 관계형 데이터와 SQL이 필요한가 필요하다 D2로
D1 관계형 데이터와 SQL이 필요한가 필요 없다 D4로
D1 관계형 데이터와 SQL이 필요한가 이미 S3에 있는 데이터에 가끔 SQL을 던지고 싶다 Amazon Athena — 인프라를 두지 않습니다
D2 엔진과 운영 요구가 무엇인가 특정 엔진과 버전을 그대로 써야 한다 Amazon RDS
D2 엔진과 운영 요구가 무엇인가 MySQL 또는 PostgreSQL 호환이면 되고 읽기 확장과 빠른 장애 조치가 필요하다 Amazon Aurora
D2 엔진과 운영 요구가 무엇인가 부하가 간헐적이고 용량을 고정하기 어렵다 Amazon Aurora Serverless v2
D2 엔진과 운영 요구가 무엇인가 대량 데이터에 복잡한 분석 질의를 반복한다 Amazon Redshift — 트랜잭션 데이터베이스가 아닙니다
D3 관계형 데이터베이스가 이미 있는데 무엇이 문제인가 가용 영역 장애를 견뎌야 한다 Multi-AZ 배포
D3 관계형 데이터베이스가 이미 있는데 무엇이 문제인가 읽기 질의가 많아 느리다 읽기 전용 복제본
D3 관계형 데이터베이스가 이미 있는데 무엇이 문제인가 같은 질의가 반복되고 애플리케이션을 고칠 수 있다 Amazon ElastiCache
D3 관계형 데이터베이스가 이미 있는데 무엇이 문제인가 연결 수가 고갈된다 (서버리스 클라이언트) Amazon RDS Proxy
D3 관계형 데이터베이스가 이미 있는데 무엇이 문제인가 가용성과 읽기 확장이 둘 다 요구된다 Multi-AZ 배포와 읽기 전용 복제본을 함께 구성합니다
D4 어떤 데이터 모델인가 키로 조회하고 예측 가능한 지연이 필요하다 Amazon DynamoDB
D4 어떤 데이터 모델인가 문서 데이터베이스이고 MongoDB 호환이 필요하다 Amazon DocumentDB
D4 어떤 데이터 모델인가 개체 사이의 관계를 탐색한다 Amazon Neptune
D4 어떤 데이터 모델인가 Apache Cassandra 호환이 필요하다 Amazon Keyspaces
D4 어떤 데이터 모델인가 시간축으로 쌓이는 측정값이다 Amazon Timestream
D4 어떤 데이터 모델인가 인메모리 속도가 필요하고 사라져도 된다 Amazon ElastiCache
D4 어떤 데이터 모델인가 인메모리 속도가 필요하고 사라지면 안 된다 Amazon MemoryDB
D5 DynamoDB를 골랐는데 읽기가 느리다 코드 변경을 최소화해야 한다 Amazon DynamoDB Accelerator (DAX)
D5 DynamoDB를 골랐는데 새 조회 패턴이 필요하다 이미 운영 중인 테이블이다 GSI — LSI는 테이블 생성 후에 만들 수 없습니다

컴퓨팅

컴퓨팅 선택 — 질문, 분기, 결론
단계 질문 분기 결론
C1 무엇을 실행하는가 이벤트에 반응하는 짧은 처리 AWS Lambda — 한 번 실행이 900초를 넘으면 다른 선택지로
C1 무엇을 실행하는가 컨테이너 이미지 C2로
C1 무엇을 실행하는가 운영체제 수준의 제어가 필요한 애플리케이션 C3으로
C1 무엇을 실행하는가 대량의 독립 배치 작업 AWS Batch — 스팟 용량과 잘 맞습니다
C1 무엇을 실행하는가 여러 단계를 순서와 재시도로 엮어야 한다 AWS Step Functions로 단계를 조율합니다
C2 Kubernetes API가 요구되는가 요구된다 (기존 클러스터, 표준 도구) Amazon EKS
C2 Kubernetes API가 요구되는가 요구되지 않는다 Amazon ECS
C2 인스턴스를 우리가 관리해야 하는가 관리하고 싶지 않다 (운영 부담 최소) 시작 유형을 AWS Fargate로 — ECS와 EKS 모두에서 고를 수 있습니다
C2 인스턴스를 우리가 관리해야 하는가 GPU나 특수 인스턴스 타입이 필요하다 EC2 시작 유형
C3 EC2를 어떤 구매 옵션으로 사는가 중단되어도 되고 재시작할 수 있다 스팟 인스턴스
C3 EC2를 어떤 구매 옵션으로 사는가 1년 또는 3년간 상시 가동하는 기저 부하다 Savings Plans 또는 예약 인스턴스
C3 EC2를 어떤 구매 옵션으로 사는가 기간과 규모를 예측할 수 없고 짧게 쓴다 온디맨드
C3 EC2를 어떤 구매 옵션으로 사는가 물리 서버 단위 라이선스나 규정 요구가 있다 전용 호스트
C4 용량이 부족하다 — 어떻게 늘리는가 부하가 변하고 장애도 견뎌야 한다 수평 확장 — 여러 가용 영역에 걸친 Auto Scaling 그룹
C4 용량이 부족하다 — 어떻게 늘리는가 단일 프로세스가 메모리나 CPU를 더 필요로 한다 수직 확장 — 인스턴스 타입 변경. 탄력성은 얻지 못합니다
C4 스케일아웃이 트래픽 급증을 따라가지 못한다 요청을 즉시 처리하지 않아도 된다 Amazon SQS로 완충하고 큐 길이로 스케일링합니다

네트워크 연결

네트워크 연결 선택 — 질문, 분기, 결론
단계 질문 분기 결론
N1 무엇과 무엇을 잇는가 VPC와 VPC N2로
N1 무엇과 무엇을 잇는가 VPC와 온프레미스 N3으로
N1 무엇과 무엇을 잇는가 VPC와 AWS 서비스 N4로
N1 무엇과 무엇을 잇는가 프라이빗 서브넷과 인터넷 (나가기만) NAT 게이트웨이 — 가용 영역마다 하나씩 둡니다
N2 연결할 VPC가 몇 개이고 전이 라우팅이 필요한가 소수이고 전이 라우팅이 필요 없다 VPC 피어링
N2 연결할 VPC가 몇 개이고 전이 라우팅이 필요한가 다수이거나 전이 라우팅이 필요하다 AWS Transit Gateway
N2 연결할 VPC가 몇 개이고 전이 라우팅이 필요한가 네트워크 전체가 아니라 서비스 하나만 노출하면 된다 AWS PrivateLink — 인터페이스 엔드포인트로 연결합니다
N2 연결할 VPC가 몇 개이고 전이 라우팅이 필요한가 CIDR이 겹친다 피어링과 Transit Gateway 모두 불가 — 주소 설계를 바꿔야 합니다
N3 온프레미스 연결에 무엇이 요구되는가 빠르게 연결해야 하고 비용을 낮게 AWS Site-to-Site VPN
N3 온프레미스 연결에 무엇이 요구되는가 일관된 지연과 대역폭, 인터넷 비경유 AWS Direct Connect — 구축에 시간이 걸립니다
N3 온프레미스 연결에 무엇이 요구되는가 전용 회선을 쓰지만 끊기면 안 된다 Direct Connect에 Site-to-Site VPN을 백업으로 붙입니다
N3 온프레미스 연결에 무엇이 요구되는가 사무실이 아니라 개별 사용자 단말이다 AWS Client VPN
N4 어떤 AWS 서비스에 비공개로 접근하는가 Amazon S3 또는 Amazon DynamoDB이고 VPC 안에서만 쓴다 게이트웨이 엔드포인트 — 추가 요금이 없습니다
N4 어떤 AWS 서비스에 비공개로 접근하는가 그 밖의 서비스이거나, 온프레미스·피어링 상대에서도 접근해야 한다 인터페이스 엔드포인트
N5 전 세계 사용자에게 빠르게 전달해야 한다 캐시할 수 있는 HTTP 콘텐츠다 Amazon CloudFront
N5 전 세계 사용자에게 빠르게 전달해야 한다 TCP·UDP이거나 고정 IP가 필요하다 AWS Global Accelerator

데이터 전송

이 갈래의 첫 계산은 언제나 같습니다 — 전송량을 가용 대역폭으로 나눠 소요 기간을 구합니다. 그 기간이 요구를 만족하면 네트워크 전송이고, 만족하지 못하면 물리 전송입니다. 장비 모델을 외우는 것이 아니라 이 계산이 판단입니다.

데이터 전송 수단 선택 — 질문, 분기, 결론
단계 질문 분기 결론
T1 일회성인가 상시인가 한 번 옮기고 끝난다 T2로
T1 일회성인가 상시인가 주기적으로 동기화한다 AWS DataSync
T1 일회성인가 상시인가 온프레미스 애플리케이션이 계속 접근한다 AWS Storage Gateway — 이전이 아니라 연장입니다
T1 일회성인가 상시인가 외부 상대가 SFTP 같은 기존 프로토콜을 바꿀 수 없다 AWS Transfer Family
T2 전송량 ÷ 가용 대역폭 = 기간. 이 기간이 요구를 만족하는가 만족한다 AWS DataSync — 회선이 부족하면 AWS Direct Connect를 함께 검토합니다
T2 전송량 ÷ 가용 대역폭 = 기간. 이 기간이 요구를 만족하는가 만족하지 못한다 (몇 달이 걸린다) AWS Snow Family — 물리 배송으로 옮깁니다
T3 무엇을 옮기는가 데이터베이스이고 다운타임을 최소화해야 한다 AWS Database Migration Service — 엔진이 다르면 스키마 변환을 함께 씁니다
T3 무엇을 옮기는가 서버를 고치지 않고 그대로 옮긴다 AWS Application Migration Service (MGN)
T3 무엇을 옮기는가 무엇을 옮길지부터 파악해야 한다 AWS Application Discovery Service로 자산과 의존 관계를 수집합니다

재해 복구

재해 복구 문항은 RTO와 RPO 요구에서 전략이 결정되고, 전략이 정해지면 데이터 복제 수단과 전환 수단이 따라옵니다. 비용은 언제나 복구 시간과 교환됩니다 — 빠를수록 상시 가동해야 하는 구성 요소가 늘어납니다.

재해 복구 전략과 수단 선택 — 질문, 분기, 결론
단계 질문 분기 결론
R1 요구되는 복구 시간과 데이터 손실 허용 범위는 시간에서 일 단위 복구를 감수할 수 있고 상시 비용을 최소화해야 한다 백업 및 복원 — 평상시에는 데이터만 대상 리전에 둡니다
R1 요구되는 복구 시간과 데이터 손실 허용 범위는 수십 분 안에 복구해야 한다 파일럿 라이트 — 데이터베이스 등 최소 코어만 상시 가동합니다
R1 요구되는 복구 시간과 데이터 손실 허용 범위는 분 단위로 복구해야 하고 축소 규모로라도 서비스가 살아 있어야 한다 웜 스탠바이 — 축소된 전체 스택이 상시 가동됩니다
R1 요구되는 복구 시간과 데이터 손실 허용 범위는 사실상 중단이 없어야 한다 다중 사이트 액티브-액티브 — 가장 비쌉니다
R2 데이터를 어떻게 대상 리전으로 옮기는가 Amazon S3의 객체 교차 리전 복제(CRR)
R2 데이터를 어떻게 대상 리전으로 옮기는가 Amazon RDS 데이터베이스 교차 리전 읽기 전용 복제본 또는 스냅샷 복사
R2 데이터를 어떻게 대상 리전으로 옮기는가 Amazon DynamoDB 테이블 글로벌 테이블 — 여러 리전에서 읽고 씁니다
R2 데이터를 어떻게 대상 리전으로 옮기는가 여러 서비스의 백업을 한 정책으로 AWS Backup의 교차 리전 복사
R2 데이터를 어떻게 대상 리전으로 옮기는가 서버 단위로 지속 복제해 두었다가 기동 AWS Elastic Disaster Recovery
R3 트래픽을 어떻게 대상 리전으로 넘기는가 DNS 수준에서 전환한다 Amazon Route 53 장애 조치 라우팅 + 상태 확인
R3 트래픽을 어떻게 대상 리전으로 넘기는가 DNS 캐시를 기다릴 수 없고 고정 IP가 필요하다 AWS Global Accelerator
R4 가용 영역 하나가 사라져도 되는 구성인가 단일 NAT 게이트웨이, 단일 인스턴스, 단일 서브넷이 있다 재해 복구 이전에 단일 장애점부터 제거합니다
R4 가용 영역 하나가 사라져도 되는 구성인가 이미 다중 가용 영역이다 R1로 — 리전 단위 재해를 다룹니다

한정어가 분기를 바꾸는 지점

같은 요구사항이라도 마지막 문장의 한정어가 분기를 옮깁니다. 아래는 위 여섯 갈래에서 한정어가 실제로 결론을 바꾸는 자리입니다.

한정어별로 분기가 바뀌는 지점
한정어 어느 단계에서 어느 쪽으로 꺾이는가
LEAST operational overhead (운영 부담 최소) C2 · D2 AWS Fargate, AWS Lambda, Amazon Aurora Serverless v2, Amazon DynamoDB 쪽으로
MOST cost-effective (가장 비용 효율적) C3 · S5 스팟 인스턴스와 약정, 그리고 더 차가운 스토리지 클래스 쪽으로. 단 제약을 위반하면 오답입니다
MOST highly available (가장 가용성 높은) D3 · R4 Multi-AZ 배포와 여러 가용 영역에 걸친 Auto Scaling 쪽으로
LOWEST latency (가장 낮은 지연) D3 · N5 캐시(ElastiCache · DAX)와 엣지(CloudFront · Global Accelerator) 쪽으로
without changing application code (코드 변경 없이) D3 · S4 Amazon RDS Proxy, DAX, Amazon EFS 쪽으로. 애플리케이션 수정을 요구하는 선택지는 소거합니다
must not traverse the internet (인터넷을 거치면 안 됨) N4 VPC 엔드포인트와 AWS PrivateLink, AWS Direct Connect 쪽으로
real-time (실시간) 데이터 수집 Amazon Kinesis Data Streams 쪽으로. 버퍼링과 배치 도구는 소거합니다
minimal downtime (다운타임 최소) T3 AWS Database Migration Service와 AWS Application Migration Service 쪽으로

한정어 전체 목록과 각각이 가리키는 서비스군은 한정어 키워드 사전에 정리되어 있습니다.

이어서 볼 곳

공식 문서 출처