Amazon SAA-C03: 데이터 전송 및 마이그레이션 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

대역폭과 물리적 배송 사이의 결정

모든 마이그레이션은 계산에서 시작됩니다. 도구를 선택하기 전에 이론적인 전송 시간을 계산해야 합니다.

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

숫자는 냉정합니다. 지속적인 100 Mbps 속도에서 1TB는 약 24시간이 걸리고, 1Gbps에서는 약 2.5시간이 걸립니다. 70% 사용률로 제한된 15Mbps 회선은 하루에 약 113GB만 전송할 수 있으므로, 20TB는 175일 이상이 필요합니다. 150TB를 밤새(100Mbps의 80% 속도로 10시간 동안) 전송하면 하룻밤에 약 360GB, 한 달에 10.5TB를 전송할 수 있어 30일 마감 기한을 맞추기에는 턱없이 부족합니다. 24시간 내내 완전히 포화 상태라도 100Mbps는 하루에 약 1TB만 이동시키므로 150TB는 최소 150일이 필요합니다. 페타바이트 규모에서는 상황이 더 악화됩니다. 실제 효율을 감안한 500Mbps 회선은 이론적으로 하루에 약 5.4TB의 처리량을 제공하는데, 이는 10PB를 전송하는 데 5년 이상의 연속적인 전송이 필요하다는 의미입니다. 이는 대부분의 Direct Connect 회선을 프로비저닝하는 데 걸리는 시간보다 깁니다.

합리적인 경험 법칙은 다음과 같습니다.

마이그레이션 시나리오에서 가장 흔한 오답은 수학적으로 주어진 시간 내에 완료할 수 없는 WAN 전송을 선택하는 것입니다. 여기서 파생되는 함정인 “매일 밤 WAN을 통해 실행하면 되겠지"라는 생각은 단순히 속도가 느린 것 이상의 문제를 야기합니다. 이는 프로덕션 대역폭을 소비하고, 재업로드가 필요한 부분적이거나 손상된 전송의 위험을 초래하며, 대역폭 요금과 엔지니어링 시간을 고려하면 일반적으로 더 많은 비용이 듭니다. Snowball 장치 요금과 배송비는 고정적이고 예측 가능한 비용 항목입니다.

오프라인 대량 전송을 위한 Snow Family

Snowball Edge 디바이스는 두 가지 종류가 있습니다.

Snowcone은 소형 폼팩터(~8TB SSD)로, 견고하고 택배로 배송할 수 있으며, 공간이 제약된 장소에 유용하고 엣지 동기화를 위한 DataSync 에이전트가 사전 로드되어 있습니다. Snowmobile은 최대 100PB를 운송하는 45피트 컨테이너로, 엑사바이트 규모의 데이터 센터 이전을 목표로 했지만, 대부분의 리전에서 병렬 Snowball Edge 플릿을 사용하는 방식이 선호되면서 더 이상 사용되지 않습니다. 페타바이트 미만의 데이터에 Snowmobile을 선택하는 것은 오답을 유도하는 선택지입니다.

Compute Optimized 종류는 단순히 드라이브 용량이 더 큰 것이 아닙니다. 이 장치는 EC2 AMI, Lambda 함수, Greengrass 워크로드를 로컬에서 실행하므로, 데이터를 수집하기 전에 변환, 필터링 또는 개인 식별 정보(PII)를 제거해야 할 때, 수집 후 AWS에서 워크로드를 즉시 재개해야 할 때, 또는 사이트의 연결이 끊겨 있거나 간헐적으로 연결될 때(선박, 원격 광산, 전술적 배포, 원격 연구) 적합한 선택입니다. 장치 내 처리가 필요한 경우에는 Compute Optimized를, 순수한 대량 복사 작업인 경우에는 Storage Optimized를 선택하십시오.

모든 Snow 디바이스는 AWS를 절대 벗어나지 않는 KMS 키를 사용하여 저장된 데이터를 256비트로 암호화합니다. 장치 외부는 E Ink 배송 레이블과 하드웨어 신뢰 플랫폼 모듈(Trusted Platform Module)을 통해 변조 방지 기능이 제공됩니다. 장치 내 데이터는 Snowball 클라이언트, S3 호환 엔드포인트 또는 NFS 마운트를 사용하여 기록되며, 전송 중인 데이터는 수집 및 배송 명세서 교환 과정에서 TLS로 보호됩니다. 장치가 반환되면 콘텐츠는 S3로 수집되고, 장치는 NIST 800-88 표준에 따라 암호화 방식으로 삭제됩니다.

사이트당 페타바이트 규모의 작업에서는 병렬 처리가 기본 패턴입니다. 1~2Gbps의 회선 용량을 가진 사무실이라도 1PB를 온라인으로 옮기려면 몇 달 동안 회선을 계속 포화 상태로 사용해야 합니다. 반면, 사이트당 약 13개의 Storage Optimized 디바이스(각 80TB) 플릿을 병렬로 배송하면 사무실의 인터넷 회선을 사용하지 않으면서 4주라는 마감 기한을 맞출 수 있습니다. 포화 상태인 100Mbps 회선에서 2주 안에 600TB를 전송해야 하는 작업의 경우, 소규모 병렬 플릿이 유일한 정답입니다. 비용을 무시하더라도 물리적으로 DataSync나 새로운 Direct Connect로는 불가능하기 때문입니다.

온라인, 검증된, 증분 전송을 위한 DataSync

DataSync는 대역폭은 충분하지만 워크로드 특성(수백만 개의 작은 파일, 깊은 디렉터리 트리, 지속적인 증분 동기화, 파일 시스템 간 마이그레이션 등) 때문에 단순한 도구로는 감당하기 어려운 경우에 적합한 도구입니다. aws s3 cp로 4KB 파일 2,000만 개가 있는 디렉터리를 복사하면 처리량이 아닌 왕복 지연 시간(round-trip latency) 때문에 병목 현상이 발생합니다. 각 PutObject 호출은 TLS/HTTP 왕복과 API 요청 비용을 유발합니다. 아카이브로 묶는 방법도 있지만, 파일별 주소 지정 기능을 포기해야 합니다. DataSync 에이전트는 다수의 TCP 스트림을 통해 병렬 처리하고, 메타데이터를 네이티브하게 처리하며, SHA-256을 사용하여 모든 파일을 엔드투엔드로 체크섬 검증하고, 투명하게 재시도하며, CloudWatch로 보고합니다. 이를 통해 에이전트당 최대 약 10Gbps의 속도를 달성하며 예측 가능한 GB당 요금 체계를 제공합니다.

소스 및 대상은 NFS, SMB, HDFS, 자체 관리형 객체 스토리지, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS, FSx for NetApp ONTAP을 포함합니다. 전송 중에는 TLS 1.2를 사용하며, VPC 인터페이스 엔드포인트를 통해 퍼블릭 인터넷을 거치지 않고 전송할 수 있습니다.

중요한 세부 사항: DataSync는 온프레미스 NFS/SMB 소스에 대해 에이전트가 필요합니다. 에이전트는 VMware, Hyper-V, KVM 기반의 VM, EC2 또는 Snowcone에서 실행됩니다. 온프레미스 환경에서 DataSync가 에이전트리스라고 생각하는 것은 흔한 함정입니다. DataSync는 소스와 대상이 모두 AWS 네이티브 서비스일 경우에만 에이전트리스입니다.

최소 배포 구성:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

두 가지 운영 기능이 중요합니다. 대역폭 조절(BytesPerSecond)은 공유 회선이 포화 상태가 되는 것을 방지하여 “다른 부서와 공유하는 1Gbps 회선” 같은 시나리오에 직접적인 해답을 제공합니다. 필터링 및 스케줄링을 사용하면 업무 외 시간에 동기화하고 임시 파일을 제외할 수 있습니다. 사용자가 계속 읽고 쓰는 10Gbps Direct Connect 환경에서 반복 작업을 스케줄링하는 것이 표준적인 패턴입니다. 즉, 초기 전체 스캔으로 대부분의 데이터를 전송하고, 이후 증분 실행으로 변경분(delta)을 처리합니다. 이렇게 하면 부분적인 사용률로도 700TB를 일주일 이내에 충분히 전송할 수 있습니다.

더 미묘한 함정은 메타데이터 충실도와 관련이 있습니다. DataSync는 선별된 POSIX 또는 SMB 속성 집합(NFS의 경우 UID/GID/모드/타임스탬프, SMB의 경우 소유권 및 DACL)을 보존하지만, 모든 독점적인 NAS 속성을 캡처하지는 않습니다. 벤더별 ACL, 프로토콜이 노출하는 범위를 넘어서는 확장 속성, 스냅샷, 중복 제거 메타데이터 등은 DataSync의 처리 범위를 벗어납니다. 규정 준수를 위해 벤더 기능을 포함한 정확한 NAS 복제본이 필요한 경우 DataSync만으로는 부족하며, SnapMirror를 사용하는 FSx for ONTAP이나 Storage Gateway를 통한 리프트 앤 시프트 같은 NetApp을 인식하는 경로가 필요합니다.

DataSync는 Snowball을 보완하기도 합니다. Snowball로 초기 150TB를 옮긴 후, DataSync로 매주 발생하는 500GB 워킹셋의 증분 데이터를 처리할 수 있습니다.

Storage Gateway: 마이그레이션이 아닌 하이브리드 프레젠테이션

Storage Gateway는 마이그레이션 도구가 아니라 하이브리드 프레젠테이션 계층입니다. 온프레미스 애플리케이션은 계속해서 NFS, SMB, iSCSI, iSCSI-VTL 프로토콜을 사용하고 데이터는 S3, S3 Glacier 또는 EBS 스냅샷에 저장됩니다. Storage Gateway를 DataSync와 혼동하는 것은 흔한 실수입니다. File Gateway는 70TB의 데이터를 빠르게 옮기도록 설계되지 않았으며, DataSync는 온프레미스 클라이언트에 영구적인 공유를 제공하지 않습니다.

File Gateway가 핵심적인 역할을 합니다. \\gateway\share\reports\2024\report.pdf에 파일을 쓰면 s3://bucket/reports/2024/report.pdf가 생성되어 Athena, Lambda, EMR 또는 모든 S3 클라이언트에서 네이티브하게 사용할 수 있습니다. 이러한 일대일 파일-객체 매핑은 내부를 알 수 없는(black-box) 백업 대상에 비해 큰 장점입니다. 로컬 캐싱 덕분에 자주 사용하는 파일은 LAN 속도로 반환되고, 자주 사용하지 않는 파일은 필요할 때 S3에서 스트리밍됩니다.

어플라이언스의 핵심은 캐시입니다. 자주 사용하는 데이터에 대한 읽기는 로컬에서 처리되고, 쓰기는 먼저 로컬 디스크에 저장된 후 비동기적으로 업로드됩니다. S3 기반이라고 해서 모든 읽기 작업에 인터넷 왕복 지연 시간이 발생한다고 가정하는 것은 흔한 설계 실수입니다. 워킹셋이 캐시에 맞는다면 그렇지 않습니다. 반대로 캐시를 너무 작게 설정하면 지속적인 캐시 미스가 발생하여 워크로드가 “느리게” 보입니다. 일반적인 원칙은 다음과 같습니다. 캐시 크기 = 전체 데이터셋의 20% 또는 자주 사용하는 워킹셋의 100% 중 더 큰 값.

캐시 모드와 저장 모드의 함정은 특별히 주의해야 합니다. 캐시 모드는 주 복사본을 S3에 두고 자주 사용하는 블록만 로컬에 유지합니다. 저렴하고 탄력적이지만 캐시 미스가 발생하면 WAN 왕복이 필요합니다. 저장 모드는 주 복사본을 로컬 디스크에 두고 S3에 EBS 스냅샷 형태로 비동기 스냅샷을 저장합니다. 모든 읽기 작업이 로컬에서 저지연으로 처리되지만, 전체 데이터셋이 온프레미스에 들어갈 수 있어야 합니다. “AWS에 백업되는 동안 모든 데이터에 로컬로 액세스"해야 한다는 백업 대체 요구사항에는 저장 모드가 맞습니다. 캐시 모드는 이 요구사항을 위반합니다. 전체 데이터셋에 대한 저지연 액세스가 필요한 워크로드에 캐시 모드를 선택하는 것은 설계 목적에 어긋나며, 사이트에서 전체 데이터셋을 호스팅할 수 없을 때 저장 모드를 선택하는 것은 정의상 불가능합니다.

Tape Gateway는 매우 구체적인 요구사항을 해결합니다. 즉, iSCSI를 통해 VTL(가상 테이프 라이브러리)을 제공하여 Veeam, NetBackup, Commvault 워크플로를 그대로 유지하면서 물리적 테이프 라이브러리를 교체하는 것입니다. 데이터는 S3에서 Glacier 또는 Deep Archive로 수명 주기에 따라 관리됩니다. 규제상 보존 기간이 테이프 미디어 기준으로 정의되어 있고 기존 백업 소프트웨어를 변경할 수 없는 경우에 매우 유용합니다.

AWS Transfer Family

Transfer Family는 S3 또는 EFS를 백엔드로 사용하는 완전 관리형 SFTP, FTPS, FTP 및 AS2 엔드포인트를 제공합니다. 핵심 가치는 파트너와 약속된 프로토콜 계약을 그대로 유지할 수 있다는 점입니다. SFTP로만 파일을 전송하는 벤더 시스템은 변경 없이 그대로 사용하면서, 수신 측은 네이티브 S3가 되어 수명 주기 정책, Lambda 트리거, 분석 통합 등의 이점을 누릴 수 있습니다.

여기서 빠지기 쉬운 함정은 레거시 벤더가 ‘그냥 S3 API로 전환하면 된다’고 가정하는 것입니다. 많은 벤더 시스템은 어플라이언스, 병원 HL7 피드, 은행 배치 시스템, 또는 B2B EDI 파이프라인 등이며, 이들의 SFTP 클라이언트는 펌웨어나 서명된 바이너리에 내장되어 있는 경우가 많습니다. 이러한 시스템을 변경하는 데 드는 변경 관리, 보안 검토, 재인증 비용은 전체 AWS 마이그레이션 비용을 초과하는 경우가 많습니다. Transfer Family는 이 문제를 완전히 우회합니다. 또한 AS2 지원을 통해 MDN 영수증, 메시지 서명/암호화를 사용하는 EDI 워크로드를 처리할 수 있어 B2B 규정 준수 요구사항을 충족합니다.

인증은 서비스 관리형 사용자, AWS Directory Service(Managed Microsoft AD 또는 온프레미스 AD용 AD Connector), 또는 API Gateway/Lambda를 통한 사용자 지정 자격 증명 공급자를 지원합니다. 이를 통해 기존 회사 자격 증명을 신뢰할 수 있는 단일 소스(source of truth)로 계속 사용할 수 있습니다. Lambda 권한 부여자는 사용자별 IAM 역할, 홈 디렉터리 매핑, 세션 정책을 반환할 수 있어, 벤더별 인프라 없이도 벤더별 격리를 구현할 수 있습니다.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow는 SaaS에서 AWS로 데이터를 이동하기 위한 관리형 통합 계층입니다. Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk 등 수십 개의 다른 서비스에서 S3, Redshift 또는 Snowflake로 데이터를 가져옵니다. 수동으로 ETL 작업을 만들 필요 없이 페이지네이션, 증분 추출, 필드 매핑, 필터링, 마스킹, 유효성 검사를 처리합니다.

보안상 매우 중요한 기능은 지원되는 커넥터(특히 Salesforce)에 대한 PrivateLink 통합입니다. SaaS 테넌트에 도달하기 위해 퍼블릭 인터넷으로 나갔다가 AWS로 돌아오는 대신, 흐름이 프라이빗 VPC 엔드포인트를 통해 이루어집니다. 이를 통해 추출 페이로드의 퍼블릭 인터넷 노출을 제거하고 의료, 금융, 개인 식별 정보(PII) 워크로드에 대한 감사 절차를 간소화합니다. 흐름은 예약 실행, SaaS 레코드 변경에 따른 이벤트 기반 트리거, 또는 온디맨드 실행이 가능하며, 흐름 실행당 최대 100GB를 지원합니다.

AppFlow는 DataSync나 Storage Gateway보다 상위 계층에서 작동합니다. 소스가 파일 시스템이나 데이터베이스가 아닌 API 기반 SaaS일 때 적합한 도구입니다.

데이터베이스 마이그레이션: DMS와 SCT

AWS Database Migration Service는 소스 데이터베이스를 완전히 운영 상태로 유지하면서 소스와 대상 데이터베이스 간에 데이터를 복제합니다. 동종(MySQL → RDS MySQL, Oracle → RDS Oracle) 및 이기종(Oracle → Aurora PostgreSQL, SQL Server → MySQL) 마이그레이션을 모두 지원하며, 대상은 RDS를 넘어 Aurora, Redshift, S3, DynamoDB, Kinesis까지 확장됩니다. 소스에는 Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, Db2 등이 포함됩니다.

태스크는 세 가지 모드 중 하나로 작동합니다.

다운타임을 최소화하는 전환의 핵심 엔진은 **변경 데이터 캡처(Change Data Capture)**입니다. 전체 로드 + CDC 동안 DMS는 소스 트랜잭션 로그(Oracle redo, MySQL binlog, SQL Server MS-CDC 또는 MS-Replication)를 마이닝하면서 기존 행을 대량 복사합니다. 전체 로드가 완료되면 CDC는 대기 중인 변경 사항을 적용하고 애플리케이션이 전환될 때까지 대상을 지속적으로 최신 상태로 유지합니다. 애플리케이션을 쓰기 가능한 상태로 유지해야 할 때 CDC를 활성화하지 않는 것은 일반적인 아키텍처 오류입니다. 전체 로드만 수행하면 로드가 완료되는 순간 대상이 오래된 데이터가 됩니다.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

이기종 작업의 경우, AWS Schema Conversion Tool(또는 클라우드 버전인 DMS Schema Conversion)이 DDL, 저장 프로시저, 뷰, 함수를 변환하고 수동 재작성이 필요한 항목을 표시합니다. DMS는 데이터를 이동하고, SCT는 스키마를 변환합니다. SCT 평가 보고서를 건너뛰는 것은 전환 3일 전에 마이그레이션이 실패하는 지름길입니다.

엔진별 전제 조건과 제한 사항을 무시하면 큰 문제가 발생할 수 있습니다. 64KB를 초과하는 Oracle LOB는 고정된 최댓값을 갖는 **제한된 LOB 모드(limited LOB mode)**가 필요하며, LONG RAW에는 주의 사항이 있습니다. PostgreSQL은 wal_level=logical 설정과 복제 역할이 필요합니다. MySQL은 ROW 형식의 바이너리 로깅, 충분한 binlog_row_image 설정, 그리고 승격된 CDC 권한(REPLICATION CLIENT, REPLICATION SLAVE)이 필요합니다. Oracle Spatial, RAC 관련 동작, SQL Server CLR 어셈블리는 일반적으로 지원되지 않습니다. 복제 인스턴스와 엔드포인트 간에는 TLS가 강제되며, SSL 모드는 require, verify-ca, 또는 verify-full을 사용합니다.

DMS Serverless는 워크로드 프로필이 예측 불가능하거나 폭증하는 경우에 올바른 선택입니다. 예를 들어, 낮에는 사용량이 급증하고 밤에는 조용한 온프레미스 Oracle 시스템 같은 경우입니다. DCU(DMS Capacity Units) 단위로 MinCapacityUnits와 MaxCapacityUnits를 정의하면, DMS는 CPU 및 메모리 압력에 따라 복제 용량을 확장합니다:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

자주 빠지는 함정은 프로비저닝된 DMS 인스턴스(예: dms.c5.4xlarge)가 자동으로 확장될 것이라고 가정하는 것입니다. 그렇지 않습니다. 프로비저닝된 인스턴스는 고정된 크기의 EC2 호스트입니다. 처리량이 용량을 초과하면 복제 지연이 증가하며, 수동으로 인스턴스 클래스를 수정하고 작업을 다시 시작해야 합니다. 프로비저닝된 DMS는 처리량이 알려진 안정적인 상태의 마이그레이션에 적합하고, Serverless는 예측 불가능한 마이그레이션에 적합합니다.

2주간의 기간과 짧은 다운타임이 요구되는 20TB MySQL 마이그레이션의 경우, DMS를 사용하여 Aurora MySQL 또는 RDS MySQL로 전체 로드 + CDC를 수행하는 것이 비용 효율적인 방법입니다. 네이티브 mysqldump/mysqlpump 복원은 허용할 수 없는 다운타임을 유발하며, Snowball은 배송 지연과 오프라인 공백을 추가합니다.

DMS Fleet Advisor는 온프레미스 데이터베이스 인벤토리를 검색하여 단계별 마이그레이션 계획(wave planning)에 유용합니다.

서버 마이그레이션: AWS Application Migration Service (MGN)

AWS Application Migration Service는 주요 리프트 앤 시프트(“리호스트”) 서비스이며, 대부분의 사용 사례에서 CloudEndure Migration 및 Server Migration Service를 대체했습니다. MGN은 각 소스 서버(물리, VMware, Hyper-V 또는 다른 클라우드)에 경량 AWS Replication Agent를 설치합니다. 이 에이전트는 대상 VPC의 저비용 스테이징 영역(연결된 EBS 볼륨이 있는 소규모 T3 인스턴스)으로 초기 블록 레벨 스냅샷을 수행한 다음, 블록 레벨 변경 사항을 비동기적으로 지속적으로 복제합니다. 복제가 블록 레벨이고 지속적이므로 컷오버는 몇 분 안에 완료됩니다. MGN은 컷오버 시점에 스테이징 볼륨을 대상 인스턴스 유형의 프로덕션 EC2 인스턴스로 변환합니다.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

테스트 시작은 필수적이지만 종종 건너뜁니다. MGN은 진행 중인 복제를 중단하지 않고 현재 복제 상태에서 격리된 테스트 인스턴스를 시작합니다. 애플리케이션 동작을 검증하고, 테스트를 폐기하고, 반복한 후, 테스트가 통과될 때만 컷오버를 시작합니다. 컷오버는 복제를 중지하고, 최종 인스턴스를 시작하며, 웨이브를 완료로 표시합니다.

잘못된 접근 방식은 VM을 OVF로 수동으로 내보내고, aws ec2 import-image를 통해 업로드하고, 새로 프로비저닝된 EC2 인스턴스에 애플리케이션을 다시 설치하는 것입니다. 이 방식은 느리고, 오류가 발생하기 쉬우며, 내보내기 시간과 동일한 VM별 다운타임이 필요하고, 델타 복제를 제공하지 않으며, 무중단 테스트를 제공하지 않습니다. MGN은 이 모든 것을 제거합니다. 소스는 최종 컷오버 순간까지 계속 실행되며, 소스와 대상 간의 차이(drift)는 거의 0에 가깝습니다.

일반적인 포트폴리오 가이드는 먼저 리호스트한 다음, 반복 비용이 더 낮은 리전 내에서 리플랫포밍 또는 리팩터링하는 것입니다. 리팩터링과 마이그레이션을 동시에 수행하면 상응하는 이점 없이 위험만 배가됩니다.

하이브리드 연결: Direct Connect 및 VPN

AWS Direct Connect는 온프레미스 라우터에서 Direct Connect 로케이션까지의 전용 Layer 2 회선을 제공하여 일관된 대역폭(전용 1, 10, 100Gbps, 파트너 호스팅 연결을 통해 1Gbps 미만)과 예측 가능한 지연 시간을 제공합니다. 가상 인터페이스(Virtual Interface)는 회선을 분할합니다.

• 프라이빗 VIF — Virtual Private Gateway를 통해 단일 VPC에 액세스합니다.
• 전송 VIF — Transit Gateway에 연결된 Direct Connect Gateway를 통해 여러 VPC에 액세스합니다. 이는 대규모 다중 VPC, 다중 사이트 환경의 표준 패턴입니다.
• 퍼블릭 VIF — 인터넷을 거치지 않고 AWS 퍼블릭 서비스 엔드포인트(S3, DynamoDB)에 액세스합니다.

DX는 그 자체로 고가용성을 보장하지 않습니다. 단일 DX 로케이션의 단일 회선은 단일 광섬유 경로에 의존합니다. 두 가지 복원력 패턴이 중요합니다.

1. 인터넷을 통한 DX + Site-to-Site VPN 백업은 최소한의 실행 가능한 HA 구성입니다. BGP는 AS-path prepending, MED 또는 local-pref를 사용하여 정상 상태에서 DX를 선호하도록 자동 장애 조치를 처리합니다.
2. 별도의 DX 로케이션에 이중 DX 회선을 구성하는 것은 최대 복원력 패턴이며 미션 크리티컬 워크로드에 필요하고 DX SLA에도 요구됩니다.

백업 경로를 전혀 프로비저닝하지 않는 것은 잘 알려진 함정입니다. DX 장애 시 VPN이 없으면 하이브리드 앱, DataSync 작업, Storage Gateway 업로드가 모두 통신사 수리 기간 동안 중단됩니다. 순수 VPN은 처리량이 낮은 워크로드나 몇 주가 걸릴 수 있는 DX 프로비저닝 기간 동안의 임시 방편으로 사용할 수 있습니다.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

물리 계층 암호화가 필수인 경우, MACsec 지원 DX 연결을 선택하십시오. 대역폭을 위한 DX, 오케스트레이션을 위한 DataSync, 지속적인 로컬 액세스를 위한 Storage Gateway를 결합하는 것은 다운타임 창을 허용할 수 없는 대규모 라이브 데이터 세트를 위한 표준 하이브리드 패턴입니다.

온프레미스 AWS 인프라를 위한 AWS Outposts

Outposts는 완전 관리형 랙(또는 1U/2U Outposts 서버) 형태로 AWS 인프라를 고객 시설로 확장합니다. 상위 리전과 동일한 API를 사용하여 선별된 서비스 세트(EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR)를 로컬에서 실행합니다. 제어 플레인 작업은 이중화된 암호화 터널의 서비스 링크를 통해 상위 리전으로 다시 전달됩니다. WAN 중단은 일시적으로 새 인스턴스 시작을 막지만 실행 중인 워크로드를 중지시키지는 않습니다.

공동 책임 모델의 분할 지점은 운영자가 빠지기 쉬운 함정입니다. AWS는 하드웨어, 하이퍼바이저, 관리형 서비스를 제공하고 유지 관리합니다. 고객은 다음에 대한 책임이 있습니다.

• Outposts 사양을 충족하는 물리적 공간, 전원, 냉각 및 네트워킹(이중화된 전원 공급 장치, 업스트림 스위치, 적절한 PDU).
• 시설의 물리적 보안.
• 로컬 네트워크 구성 — 온프레미스 트래픽을 위한 로컬 게이트웨이(LGW) 및 서비스 링크 업링크.
• 리전 내에서와 똑같이 워크로드의 OS 및 애플리케이션 관련 사항.
• 상위 리전으로의 적절한 WAN 연결.

Outposts는 운영을 없애는 것이 아니라 추상화의 수준을 바꾸는 것입니다. AWS가 데이터센터 전원이나 업스트림 네트워크를 책임진다고 가정하는 것은 근본적인 오해입니다. 또한 “온프레미스에서 모든 AWS 서비스 실행"도 아닙니다. 지원되는 목록은 한정되어 있으며 Route 53이나 IAM과 같은 서비스는 리전 기반으로 유지됩니다.

규제상의 이유로 데이터가 온프레미스에 머물러야 하는 Hadoop/Spark 현대화의 경우, EMR on Outposts가 올바른 패턴입니다. 이는 리전 내 도구와 로컬 데이터 상주성을 갖춘 관리형 탄력적 Spark 클러스터입니다. Storage Gateway나 DataSync는 상주성 요구 사항을 충족하지 못하며, 리전 내 EMR로의 리프트 앤 시프트는 규정 준수에 실패합니다.

엣지 플릿에 콘텐츠 배포

Outposts 서버, 리테일 스토어 또는 엣지 디바이스가 매일 밤의 소프트웨어 릴리스와 같은 동일한 대용량 페이로드를 반복적으로 가져올 때, 단일 리전의 S3 버킷에서 직접 가져오면 업링크가 포화 상태가 되고 배포 시간이 늘어납니다. 올바른 패턴은 S3 오리진과 서명된 URL을 사용하는 CloudFront입니다:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

한 리전의 첫 번째 디바이스가 엣지 캐시를 워밍업(warming up)하면, 이후의 모든 디바이스는 엣지 지연 시간으로 데이터를 가져옵니다. 서명된 URL은 디바이스별 IAM 자격 증명 없이 무단 다운로드를 방지하며, 관리해야 할 리전별 복제본 플릿도 없습니다.

피해야 할 두 가지 안티패턴은 다음과 같습니다: 릴리스를 단일 EC2 웹 서버에서 호스팅하는 것(확장성 및 지연 시간 재앙)과, 단지 다운로드 지연 시간을 줄이기 위해 Cross-Region Replication을 통해 모든 리전에 S3 버킷을 복제하는 것(CloudFront 캐싱으로 무료로 해결할 수 있는 불필요한 스토리지 비용과 운영 복잡성 발생)입니다.

결정 요약

← 스토리지 및 데이터 수명 주기 · 모든 도메인 · 네트워킹 및 연결성 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →