Amazon SAA-C03: 컨테이너 및 오케스트레이션 — 학습 가이드

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

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

ECS와 EKS, 그리고 EC2와 Fargate 사이에서 선택하기

AWS에서 컨테이너 워크로드를 위한 첫 번째 아키텍처 결정은 오케스트레이터와 컴퓨팅 모드를 선택하는 것입니다. Amazon ECS는 AWS 독점 오케스트레이터로 IAM, ALB/NLB, CloudWatch, Service Discovery, VPC 네트워킹과 긴밀하게 통합됩니다. 컨트롤 플레인 비용이 없으며, Kubernetes 관련 특정 도구가 필요 없는 팀에게는 프로덕션까지 가장 빠른 경로입니다. 태스크는 라이프사이클을 공유하는 하나 이상의 컨테이너 단위이며, 서비스는 스케줄러에 의해 관리되는 장기 실행 관리형 태스크 집합입니다. Amazon EKS는 클러스터당 시간당 $0.10의 고정 요금으로 업스트림과 호환되는 Kubernetes를 실행하며, 워크로드의 이식성을 유지해야 하거나, Kubernetes API를 사용해야 하거나, CNCF 생태계(Helm, CRD, Operator)를 활용해야 할 때 올바른 선택입니다. 컨트롤 플레인(API 서버, etcd, 컨트롤러 매니저, 스케줄러)은 AWS에 의해 패치, 백업되고 3개의 가용 영역에 걸쳐 고가용성이 보장됩니다.

두 오케스트레이터 모두 두 가지 컴퓨팅 모드를 지원합니다. AWS Fargate는 각 태스크나 파드를 격리된 Firecracker 마이크로VM에서 실행합니다. 따라서 패치할 AMI도, 튜닝할 Auto Scaling Group 용량 공급자도, 빈 패킹(bin-packing) 결정도, SSH로 접근 가능한 호스트도 없습니다. 태스크의 vCPU-초 및 GB-초당 비용을 지불합니다. EC2 시작 유형 / 관리형 노드 그룹은 인스턴스를 직접 소유하며, 이는 유연성과 운영 부담을 모두 의미합니다.

Fargate는 시나리오가 “서버리스”, “최소한의 운영 오버헤드”, “관리할 인프라 없음"을 강조할 때마다 올바른 기본 선택입니다. 단, 워크로드가 Fargate의 제약 조건(태스크당 최대 16 vCPU / 120GB 메모리, GPU 없음, 특권 컨테이너 없음, DaemonSet 없음, HostPort/HostNetwork 없음, Windows 호스트 수준 사용자 지정 없음)에 맞아야 합니다. GPU, 호스트 접근이 필요한 DaemonSet, 사용자 지정 AMI, GMSA를 사용하는 Windows Server 컨테이너, 초 단위 미만의 빈 패킹 효율성 또는 적극적인 스팟 기반 비용 최적화가 필요한 경우 관리형 노드 그룹 또는 EC2 시작 유형을 선택하십시오.

전형적인 함정은 EC2 노드가 더 저렴하게 ‘느껴지기’ 때문에 선택하는 것입니다. 사용량이 급증하거나 낮은 워크로드의 경우, 유휴 용량과 AMI 패치, 노드 드레이닝, 클러스터 오토스케일러 구성에 드는 엔지니어링 시간을 고려하면 Fargate가 더 저렴한 경우가 많습니다. Fargate는 이 모든 것을 제거합니다.

태스크 정의, 배치 및 용량 공급자

표준적인 ECS Fargate 태스크 정의는 CPU/메모리 크기 조정, 이미지 가져오기 및 로그 작성을 위한 실행 역할, awsvpc 네트워크 모드, CloudWatch Logs 연결과 같은 필수 요소를 포함합니다.

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

EC2를 사용하는 ECS에서 태스크 배치 전략은 태스크가 인스턴스에 어떻게 분산될지 결정합니다. 이 전략들은 순서대로 구성됩니다.

클러스터 쿼리 언어를 사용하는 distinctInstance 또는 memberOf와 같은 배치 제약 조건은 후보를 더욱 제한합니다.

용량 공급자는 서비스를 원시 Auto Scaling Group에서 분리합니다. FARGATE와 FARGATE_SPOT은 관리형 공급자입니다. 사용자 지정 공급자는 ASG를 래핑하고 관리형 스케일링을 활성화하여 ECS가 프로비저닝된 태스크 수에 따라 ASG의 desired count(원하는 개수)를 조정하도록 합니다. 용량 공급자 전략은 가중치(weight)와 기준(base)에 따라 태스크를 분할합니다. 예를 들어, 2개의 온디맨드 Fargate 태스크를 보장하고, 중단 허용 워크로드를 위해 나머지를 Fargate Spot과 1:4로 분할할 수 있습니다.

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

오토스케일링: 파드, 태스크 및 노드

Fargate는 노드 관리를 제거하지만, 태스크나 파드의 수를 자동으로 스케일링하지는 않습니다. 이 차이점은 Fargate에 대한 가장 흔한 오해 중 하나입니다. 서버리스는 호스트 계층에 적용될 뿐, 서비스의 desired count(원하는 개수)에는 적용되지 않습니다. 서비스 수준의 오토스케일링은 여전히 사용자의 책임입니다.

ECS의 경우 Application Auto Scaling을 사용하십시오. 대상 추적(Target tracking)이 일반적인 기본값인데, 이는 스케일 아웃 및 스케일 인 CloudWatch 경보를 자동으로 생성하고 재사용 대기 시간(cooldown)을 준수하기 때문입니다. 합리적인 지표로는 ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization, ALBRequestCountPerTarget가 있습니다.

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

단계 스케일링 및 예약된 스케일링은 비선형 응답 곡선이나 알려진 트래픽 시간대에 여전히 사용 가능합니다.

EC2 노드 기반 EKS에서 파드 차원은 Horizontal Pod Autoscaler(HPA)에 의해 처리되며, 이는 CPU, 메모리 또는 사용자 지정 지표를 기반으로 복제본(replica) 수를 조정합니다. HPA만으로는 노드를 추가할 수 없습니다. HPA는 클러스터 용량을 초과하여 복제본 수를 늘리게 되고, 그 시점에서 새 파드는 FailedScheduling 이벤트와 함께 Pending 상태가 됩니다. 이것이 EC2에서 HPA를 사용할 때 항상 Kubernetes Cluster Autoscaler 또는 Karpenter와 함께 사용해야 하는 이유입니다. 이 조합을 잊는 것은 빈번한 설계 오류입니다. HPA는 ‘복제본 20개로 스케일링됨’이라고 보고하지만, 그중 절반은 보류(pending) 상태에 머물러 있습니다. 최소한의 Cluster Autoscaler 구성은 ASG 태그를 통해 노드 그룹을 검색합니다.

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Fargate 프로필에서는 이 문제가 사라집니다. 각 파드가 자체 마이크로VM이 되므로 노드 스케일링 차원이 완전히 제거됩니다. 이것이 바로 Fargate가 예측 불가능한 파드 수를 가진 버스트(bursty) 워크로드에 적합한 선택인 이유입니다.

Fargate 프로필과 기능 제한

EKS의 Fargate 프로필은 셀렉터(네임스페이스와 선택적 파드 레이블)이며, EKS가 일치하는 파드를 노드가 아닌 Fargate에서 스케줄링하도록 지시합니다.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

중요한 주의사항은 EKS on Fargate가 Kubernetes의 모든 기능을 지원하지는 않는다는 점입니다.

• DaemonSet은 실행되지 않습니다. 데몬화할 노드가 없으므로, fluentd와 같은 로그 수집기 DaemonSet은 사이드카나 내장된 Fluent Bit 로그 라우터로 대체해야 합니다.
• Privileged 컨테이너, HostPort, HostNetwork는 사용할 수 없습니다.
• 영구 스토리지는 CSI 드라이버를 통한 EFS로 제한됩니다. EBS 볼륨은 특정 EC2 인스턴스에 연결해야 하므로 EBS는 지원되지 않습니다.
• GPU 워크로드는 지원되지 않습니다.
• NodePort 서비스와 privileged init 컨테이너에 의존하는 서비스 메시는 작동하지 않습니다.

기능이 동일하다고 가정하면 EBS가 필요한 StatefulSet, hostPort를 사용하는 인그레스 컨트롤러, 또는 GPU 추론 워크로드의 마이그레이션이 실패하게 됩니다.

인그레스: AWS Load Balancer Controller를 통한 ALB 대 NLB

AWS Load Balancer Controller는 Ingress 및 Service 객체를 실제 ALB와 NLB로 변환하는 Kubernetes 컨트롤러입니다. 경로 또는 호스트 기반 라우팅을 사용하는 HTTP/HTTPS 마이크로서비스의 경우, 클래스가 alb인 단일 Ingress를 생성합니다. 여러 서비스 앞에 하나의 ALB를 두는 것(alb.ingress.kubernetes.io/group.name 사용)은 서비스당 하나의 ALB를 사용하는 것보다 훨씬 저렴하며, 표준적인 비용 효율적 패턴입니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

TCP, UDP, TLS сквозной(pass-through), 고정 IP 요구사항 또는 극도의 Layer 4 처리량이 필요한 경우에는 NLB(LoadBalancer 타입의 서비스에 service.beta.kubernetes.io/aws-load-balancer-type: external 및 대상 타입 nlb-ip 설정)를 사용하십시오. HTTP/2 기반 gRPC나 일반 TCP 데이터베이스 프록시를 ALB 뒤에 두는 것은 gRPC의 경우에만 괜찮습니다(ALB는 HTTP/2와 gRPC를 지원함). ALB는 임의의 TCP나 UDP를 종료할 수 없습니다. ALB를 통해 UDP 게임 트래픽을 서비스하려고 시도하는 것은 설계 시에 발견해야 할 프로토콜 불일치입니다.

IRSA를 이용한 파드 수준 IAM

**IAM Roles for Service Accounts (IRSA)**는 개별 파드에 AWS API 권한을 부여하는 올바른 메커니즘입니다. 파드에 S3 접근 권한을 주기 위해 노드의 인스턴스 프로필을 연결하는 것은 잘못된 방법입니다. 왜냐하면 노드 위의 모든 파드가 해당 권한을 상속받아 최소 권한 원칙을 위반하기 때문입니다. IRSA는 클러스터의 OIDC 공급자를 IAM과 연동하여 작동합니다. OIDC 공급자를 한 번 생성한 다음, 특정 namespace:serviceaccount 주체에 대해 해당 공급자를 신뢰하는 신뢰 정책을 가진 IAM 역할을 생성합니다.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

서비스 계정에는 eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role 어노테이션이 추가되고, 이를 마운트하는 파드는 프로젝션된 토큰을 통해 단기 STS 자격 증명을 받습니다. OIDC 공급자 연결을 건너뛰거나 어노테이션을 생략하면 조용히 노드 역할로 대체(fallback)됩니다. 이는 검토 시 놓치기 쉬운 미묘한 보안 저하입니다.

VPC CNI 플러그인은 각 파드에 VPC 서브넷 내에서 라우팅 가능한 ENI/IP 주소를 할당하여 이를 보완합니다. 그러면 파드는 보안 그룹을 사용하여 RDS, ElastiCache 또는 VPC 엔드포인트와 직접 통신할 수 있으며, CloudTrail은 감사 목적으로 파드의 실제 IP를 볼 수 있습니다.

영구 및 임시 스토리지

스토리지 선택은 액세스 모드, 내구성 및 시작 유형에 따라 달라집니다.

EBS(EKS에서는 EBS CSI 드라이버를 통해, ECS에서는 태스크에 연결된 EBS를 통해)는 Postgres 프라이머리와 같은 단일 파드 상태 저장 워크로드를 위한 ReadWriteOnce 블록 볼륨을 제공합니다. EFS는 지역적이고, 다중 AZ이며, 여러 파드에서 동시에 마운트할 수 있는 ReadWriteMany NFS 스토리지를 제공합니다. 이는 “고가용성, 내결함성, 여러 컨테이너 간 공유” 또는 공유 ML 아티팩트와 같은 요구사항이 있을 때 올바른 선택입니다. FSx for Lustre는 고성능 컴퓨팅(HPC)을 처리하고, FSx for NetApp ONTAP 및 FSx for Windows File Server는 엔터프라이즈 NFS/SMB를 처리합니다.

Fargate 태스크는 기본적으로 20GB의 임시 스토리지를 받으며, 플랫폼 1.4.0 이상에서는 ephemeralStorage.sizeInGiB를 통해 최대 200GB까지 구성할 수 있습니다. Fargate에 항상 “충분한 스크래치 공간"이 있다고 가정하는 것은 함정입니다. 50GB의 중간 파일을 쓰는 벤더 컨테이너는 확장된 임시 스토리지에 맞을 수 있지만, 요구사항이 태스크 재시작 간 또는 여러 태스크 간에 50GB의 공유 또는 영구 스토리지라면 임시 스토리지는 잘못된 선택입니다. 임시 스토리지는 태스크 중지 시 파괴되고 절대 공유되지 않기 때문입니다. Fargate는 EBS를 지원하지 않습니다. Fargate 워크로드에 영구 또는 공유 스토리지가 필요한 경우, EFS가 사실상 유일하게 지원되는 옵션입니다.

ECS의 경우, 태스크 정의에서 EFS를 직접 마운트합니다. 액세스 포인트는 태스크별로 POSIX UID/GID 및 루트 디렉토리를 강제하여 단일 파일 시스템에서 안전한 멀티테넌시를 제공하고, IAM 권한 부여는 elasticfilesystem:ClientMount 범위를 지정합니다.

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

EKS의 경우, StorageClass를 통해 EFS를 연결합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

반복되는 함정: 상태 저장 워크로드를 위해 Fargate를 선택하면서 EFS CSI 드라이버와 StorageClass 설치를 잊는 경우입니다. 파드는 시작되지만 PersistentVolumeClaims는 영원히 Pending 상태로 남아있게 됩니다. 반대로, 요구사항이 공유 다중 쓰기(multi-writer) 스토리지인데도 단지 EBS를 연결하기 위해 EC2 노드를 선택하는 것도 잘못입니다. 하나의 노드에 연결된 EBS io2는 여러 AZ에 걸쳐 공유될 수 없습니다.

ECR 이미지 스캔 및 수명 주기

Amazon ECR은 두 가지 스캔 모드를 제공합니다. 기본 스캔은 오픈 소스 Clair 데이터베이스를 사용하며, 푸시 시(또는 온디맨드) 무료로 실행됩니다. 고급 스캔은 Amazon Inspector와 통합되어 OS 및 언어 패키지 CVE를 지속적으로 모니터링하고, 결과를 Security Hub에 보고합니다. “CVE 스캔, 새 이미지 생성 시 스캔, 워크로드 변경 최소화"라는 요구사항에 대한 올바른 조치는 리포지토리 수준에서 푸시 시 스캔을 활성화하는 것입니다. 푸시 이벤트가 스캔을 트리거하므로 파이프라인 변경이 필요 없습니다.

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

그 다음 CI/CD는 describe-image-scan-findings를 호출하고 CRITICAL 또는 HIGH 개수에 따라 빌드를 실패시킵니다. 스캔을 건너뛰는 것은 패치되지 않은 Log4j, OpenSSL 또는 glibc CVE가 프로덕션에서 실행된다는 것을 의미합니다. 스캔을 하지 않음으로써 발생하는 완화 비용은 스캔을 활성화하는 거의 0에 가까운 비용보다 훨씬 큽니다.

수명 주기 정책은 스토리지 비용을 제한하고 태그 위생을 강제합니다.

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Kubernetes + MongoDB 워크로드 마이그레이션

“애플리케이션 코드 변경 없음"과 “최소한의 운영 오버헤드"라는 제약 조건 하에서 자체 호스팅 Kubernetes + MongoDB 스택을 AWS로 리프트 앤 시프트할 때 두 가지 결정이 중요합니다. 첫째, 컴퓨팅 계층은 EKS로 이전합니다. Kubernetes API 호환성 덕분에 매니페스트와 Helm 차트를 변경 없이 이식할 수 있기 때문입니다. 스테이트리스 서비스에는 Fargate 프로필을 사용하여 노드 관리 부담을 없앱니다.

둘째, MongoDB 자체를 직접 관리하는 EC2나 StatefulSet에 다시 호스팅해서는 안 됩니다. 이는 백업, 샤딩, 장애 조치, 패치 적용과 같은 운영 부담을 다시 발생시킵니다. 대신 **Amazon DocumentDB(MongoDB 호환)**를 사용해야 합니다. 이 서비스는 MongoDB 3.6/4.0/5.0 와이어 프로토콜을 사용하므로 기존 드라이버와 연결 문자열을 최소한의 변경으로 사용할 수 있습니다.

호환성과 관련된 주의 사항이 중요합니다. DocumentDB는 MongoDB API를 에뮬레이션하지만 MongoDB 자체는 아닙니다. 특정 집계 연산자, 특정 인덱스 유형, 변경 스트림 시맨틱, 그리고 최신 MongoDB 버전에 도입된 기능들은 실패할 수 있습니다. 마이그레이션 전 올바른 단계는 DocumentDB 호환성 도구(compat.py)를 애플리케이션에 실행하여 모든 작업이 지원되는지 확인하는 것입니다. 대신 DynamoDB를 선택하면 데이터 모델을 다시 작성해야 하고, RDS를 선택하면 문서 모델이 완전히 깨집니다. 두 가지 모두 ‘코드 변경 없음’ 제약 조건을 위반합니다.

하이브리드 옵션: ECS Anywhere 및 EKS Anywhere

ECS Anywhere는 온프레미스 서버(또는 다른 클라우드의 VM)를 외부 인스턴스로 ECS 클러스터에 등록합니다. 컨트롤 플레인은 AWS에 유지되고, 외부 인스턴스의 SSM Agent와 ECS Agent가 아웃바운드로 연결합니다. 하나의 배포 파이프라인, 하나의 작업 정의, 하나의 IAM 역할 세트로 클라우드와 온프레미스 워크로드를 모두 처리할 수 있습니다.

EKS Anywhere는 사용자의 하드웨어(일반적으로 vSphere 또는 베어메탈)에 표준 Kubernetes 배포판을 설치하며, 선택적으로 EKS Connector를 통해 AWS 콘솔에서 가시성을 확보할 수 있습니다. 경량의 작업 정의 기반 하이브리드 환경에는 ECS Anywhere를 선택하고, 규제 또는 지연 시간 제약으로 인해 클라우드의 EKS와 동일한 도구 세트를 사용하여 로컬 환경에 Kubernetes가 필요한 경우에는 EKS Anywhere를 선택하세요. 두 가지 모두 오케스트레이션을 일관되게 유지합니다. 핵심 가치는 팀이 두 개의 CI/CD 시스템이나 두 개의 사고 모델을 유지할 필요가 없다는 것입니다.

EKS Connector를 사용한 멀티 클러스터 가시성

조직은 EKS 클러스터, EC2에서 직접 관리하는 Kubernetes, 온프레미스 클러스터를 혼합하여 운영하는 경우가 많습니다. Amazon EKS Connector는 모든 표준 Kubernetes 클러스터를 EKS 콘솔에 등록하여 노드, 워크로드, 클러스터 메타데이터에 대한 단일 창(single pane of glass)을 제공합니다. 이것은 본질적으로 경량 에이전트와 SSM 채널의 조합으로, ‘모든 클러스터의 중앙 집중식 뷰’에 대한 오버헤드가 적은 해답입니다. 직접 호스팅하는 Rancher, Anthos 또는 맞춤형 Prometheus/Grafana 연동으로 동등한 가시성을 구축하는 것도 가능하지만, 운영 비용이 훨씬 많이 들고 IAM이나 콘솔 기반 액세스와 통합되지 않습니다.

EKS Connector는 엄격히 가시성 계층입니다. 원격 클러스터를 관리하거나 업그레이드하지 않으며, 이는 ‘최소한의 오버헤드로 중앙 집중식 뷰 확보’라는 의미와 정확히 일치합니다.

패턴 종합하기

로드 밸런싱되는 프런트엔드, 컨테이너화된 미들 티어, 관계형 스토어를 갖춘 이커머스 워크로드에서 ‘수동 개입을 최소화’하는 것이 기준일 때, 표준적인 스택은 ALB → ECS on Fargate → Aurora Serverless v2입니다. 모든 계층에서 인스턴스 수준의 관리 부담을 제거합니다. ALB는 완전 관리형이고, Fargate는 호스트를 제거하며, Aurora Serverless v2는 인스턴스 크기 조정 없이 ACU 단위로 확장됩니다.

팀이 ‘추가 인프라를 관리할 수 없는’ 마이크로서비스 플랫폼의 경우, 올바른 조합은 ECS 또는 EKS 와 Fargate, 그리고 완전 관리형 데이터 서비스입니다. EC2 시작 유형이나 직접 관리하는 노드 그룹을 선택하는 것은 기술적으로 워크로드가 실행될 수는 있지만, 해당 제약 조건에 위배됩니다.

Kubernetes + MongoDB의 리프트 앤 시프트의 경우, 해답은 EKS + DocumentDB로 수렴됩니다. Kubernetes API는 배포 방법을 보존하고, DocumentDB는 드라이버 호환성을 보존하며, Fargate 프로필은 최소한의 운영을 보장합니다. 단, 워크로드의 Kubernetes 기능 사용량과 MongoDB 명령어 범위가 위에서 설명한 지원 범위 내에 속해야 합니다.

← 컴퓨팅 · 모든 도메인 · 서버리스 및 이벤트 기반 아키텍처 →

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

Amazon 찾아보기 →