Amazon EKS 비용 최적화 퀴즈

마지막 업데이트: 2026년 9월 12일

예시는 독립적인 구성 대안이며 실제 실행한 배포나 실측 절감 결과가 아닙니다. 기존 리소스 소유 구성에 변경을 병합하고 같은 워크로드에 모든 예시를 차례로 덮어쓰지 않습니다. 자리표시자 이미지와 애플리케이션 소유 hook을 바꾸고 계정·context·리전·컨트롤러 호환성을 확인한 뒤 운영 전에 동작을 검증합니다.

이 퀴즈는 Amazon EKS 클러스터의 비용을 최적화하기 위한 전략, 도구 및 모범 사례에 대한 이해를 테스트합니다.

퀴즈 개요

컴퓨팅 리소스 최적화
스토리지 비용 최적화
네트워킹 비용 최적화
클러스터 관리 비용 최적화
비용 모니터링 및 분석
비용 최적화 도구 및 모범 사례

객관식 문제

1. Amazon EKS에서 컴퓨팅 비용을 최적화하기 위한 가장 효과적인 전략은 무엇인가요?

A. 항상 가장 큰 인스턴스 유형 사용
B. 모든 워크로드에 온디맨드 인스턴스만 사용
C. 스팟 인스턴스, 적절한 인스턴스 크기 조정 및 자동 스케일링 결합
D. 모든 워크로드를 단일 노드 그룹에 통합

정답 및 설명

정답: C. 스팟 인스턴스, 적절한 인스턴스 크기 조정 및 자동 스케일링 결합

설명: Amazon EKS에서 컴퓨팅 비용을 최적화하기 위한 가장 효과적인 전략은 스팟 인스턴스, 적절한 인스턴스 크기 조정 및 자동 스케일링을 결합하는 것입니다. 중단 허용성과 가용 용량이 허용하는 워크로드에 Spot을 사용하고 SLO에 대조해 절감 결과를 검증합니다. 이 조합이나 광고된 최대 할인율이 비용 절감과 성능 유지를 보장하지는 않습니다.

주요 컴퓨팅 최적화 전략:

스팟 인스턴스 활용:
- 온디맨드 대비 최대 90% 비용 절감
- 내결함성 있는 워크로드에 적합
- 중단 처리 메커니즘 구현
적절한 인스턴스 크기 조정:
- 실제 리소스 사용량에 기반한 인스턴스 선택
- 과도하게 프로비저닝된 리소스 제거
- 리소스 요청 및 제한 최적화
자동 스케일링 구현:
- Cluster Autoscaler 또는 Karpenter를 통한 노드 수준 스케일링
- Horizontal Pod Autoscaler를 통한 파드 수준 스케일링
- 수요에 따른 리소스 조정

NodePool/EC2NodeClass에는 설치된 호환 Karpenter 컨트롤러/CRD, 범위가 제한된 컨트롤러 IAM, 노드 역할, 검색 대상 리소스, 중단 처리 큐가 필요합니다. 현재 호환성 표에서 EKS 1.36은 Karpenter >=1.13이 필요합니다. al2023@latest는 변하는 선택자이므로 실제 AMI를 검토하고 통제된 변경에는 검증한 별칭/AMI를 고정합니다. 인스턴스 목록과 용량 limits는 예시이며 금액 상한이 아닙니다. 관리형 노드 그룹은 자체 중단 경로를 처리하며 Karpenter 노드에 두 번째 처리기를 중복 적용하지 않습니다.

HPA에는 resource metrics와 requests가 필요하고 CPU/메모리 목표 중 가장 큰 희망 복제본 수를 선택합니다. 아래 VPA는 분모를 변경하지 않고 권고만 제공하도록 Off입니다. Auto는 deprecated되어 Recreate 같은 명시적 모드로 대체하며, CPU/메모리 자동 변경은 HPA와 조율해야 합니다. preStop hook도 종료 유예 시간을 소비하며 Spot 기한이나 cleanup 성공을 보장하지 않습니다.

구현 방법:

스팟 인스턴스를 사용한 노드 그룹 생성:

bash

# eksctl을 사용한 스팟 인스턴스 노드 그룹 생성
eksctl create nodegroup \
  --cluster my-cluster \
  --region us-west-2 \
  --managed \
  --name spot-ng \
  --node-type m5.large \
  --nodes-min 2 \
  --nodes-max 10 \
  --spot

Karpenter 배포 및 구성:

yaml

# Karpenter NodePool
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "kubernetes.io/os"
          operator: In
          values: ["linux"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large", "m5a.large", "m5d.large", "m5ad.large", "m4.large"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
---
# Karpenter NodeClass
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  role: KarpenterNodeRole
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
  tags:
    karpenter.sh/discovery: my-cluster

Horizontal Pod Autoscaler 구성:

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Vertical Pod Autoscaler 구성:

yaml

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 100Mi
      maxAllowed:
        cpu: 1
        memory: 1Gi
      controlledResources: ["cpu", "memory"]

워크로드 유형별 최적화 전략:

상태 비저장(Stateless) 애플리케이션:
- 스팟 인스턴스 우선 사용
- 수평적 확장 구현
- 다중 가용 영역 배포
상태 저장(Stateful) 애플리케이션:
- 온디맨드 인스턴스와 스팟 인스턴스 혼합
- 적절한 인스턴스 유형 선택
- 스토리지 성능과 비용 균형
배치 작업:
- 스팟 인스턴스 최대한 활용
- 작업 재시도 메커니즘 구현
- 작업 기한/가용 용량에 맞춰 예약하며 일반 온디맨드 시간대 할인을 가정하지 않음

모범 사례:

리소스 요청 및 제한 최적화:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: web-app
        image: web-app:1.0
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi
    metadata:
      labels:
        app: web-app
  selector:
    matchLabels:
      app: web-app

노드 선호도 및 파드 분배 최적화:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: node.kubernetes.io/instance-type
                operator: In
                values:
                - m5.large
                - m5a.large
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-app
              topologyKey: kubernetes.io/hostname
      containers:
      - name: web-app
        image: registry.example.com/team/web-app:REVIEWED_TAG
    metadata:
      labels:
        app: web-app
  selector:
    matchLabels:
      app: web-app

스팟 인스턴스 중단 처리:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: web-app
        image: web-app:1.0
        lifecycle:
          preStop:
            exec:
              command:
              - /bin/sh
              - -c
              - sleep 10; /app/cleanup.sh
    metadata:
      labels:
        app: web-app
  selector:
    matchLabels:
      app: web-app

기존 구성에 적용하는 추가 예시:

비용 효율적인 노드 그룹 구성: 기존 클러스터에 노드 그룹을 추가하는 구성 fragment입니다. 소유자의 private subnet, 노드 IAM 정책, 기존 그룹/ASG 태그를 확인한 뒤 사용하며, 클러스터 전체를 새로 만드는 독립 예제로 취급하지 않습니다.

yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: us-west-2
managedNodeGroups:
- name: system-ng
  instanceType: m5.large
  desiredCapacity: 2
  minSize: 2
  maxSize: 4
  labels:
    workload-type: system
  privateNetworking: true
- name: app-spot-ng
  instanceTypes:
  - m5.large
  - m5a.large
  - m5d.large
  - m4.large
  spot: true
  desiredCapacity: 3
  minSize: 1
  maxSize: 10
  labels:
    workload-type: application
  privateNetworking: true

Terraform을 사용한 비용 최적화 인프라 구성:

hcl

# 스팟 인스턴스 노드 그룹
resource "aws_eks_node_group" "spot" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "spot-ng"
  node_role_arn   = aws_iam_role.node_role.arn
  subnet_ids      = var.private_subnet_ids

  capacity_type  = "SPOT"
  instance_types = ["m5.large", "m5a.large", "m5d.large", "m4.large"]

  scaling_config {
    desired_size = 3
    min_size     = 1
    max_size     = 10
  }

  labels = {
    "workload-type" = "application"
  }

  tags = {
    Team        = "platform"
    Environment = "development"
  }
}

# Cluster Autoscaler IAM 정책
resource "aws_iam_policy" "cluster_autoscaler" {
  name        = "EKSClusterAutoscalerPolicy"
  description = "Policy for Cluster Autoscaler"

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "autoscaling:DescribeAutoScalingGroups",
          "autoscaling:DescribeAutoScalingInstances",
          "autoscaling:DescribeLaunchConfigurations",
          "autoscaling:DescribeTags",
          "autoscaling:DescribeScalingActivities",
          "ec2:DescribeImages",
          "ec2:DescribeInstanceTypes",
          "ec2:GetInstanceTypesFromInstanceRequirements",
          "eks:DescribeNodegroup",
          "ec2:DescribeLaunchTemplateVersions"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "autoscaling:SetDesiredCapacity",
          "autoscaling:TerminateInstanceInAutoScalingGroup"
        ],
        Resource = "*",
        Condition = {
          StringEquals = {
            "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled"                      = "true",
            "aws:ResourceTag/k8s.io/cluster-autoscaler/${aws_eks_cluster.main.name}" = "owned"
          }
        }
      }
    ]
  })
}

추가 예시는 기존 Terraform 모듈의 fragment로 aws_eks_cluster.main, 노드 역할/정책, private subnet 변수와 provider가 이미 정의되었다고 가정하며 독립 실행 파일이 아닙니다. autoscaler와 desired_size 소유권도 조율합니다. 노드 그룹 태그는 실제 ASG 검색 태그를 대체하지 않으므로 ASG와 기존 태그 소유자를 조회해 확인합니다. 정책은 노드 역할이 아닌 전용 컨트롤러 identity에 연결합니다. 쓰기 동작 두 개는 enabled/cluster 태그 조건으로 제한하고 조회 권한과 분리합니다. 전체 IAM/검색 설정은 공식 EKS 가이드를 따릅니다. system/application 레이블만으로 격리되지는 않으며 bootstrap 컨트롤러가 실행되기 전에 유일한 온디맨드 노드를 taint하지 않습니다.

다른 옵션들의 문제점:

A. 항상 가장 큰 인스턴스 유형 사용: 이는 과도한 프로비저닝으로 이어져 불필요한 비용이 발생하며, 워크로드 요구 사항에 맞지 않을 수 있습니다.
B. 모든 워크로드에 온디맨드 인스턴스만 사용: 온디맨드 인스턴스는 스팟 인스턴스보다 비용이 더 높으며, 많은 워크로드가 스팟 인스턴스에서 효과적으로 실행될 수 있습니다.
D. 모든 워크로드를 단일 노드 그룹에 통합: 다양한 워크로드 요구 사항을 충족하기 어렵고, 리소스 격리가 부족하며, 비용 할당 및 최적화가 어려워집니다.

### 2. Amazon EKS에서 스토리지 비용을 최적화하기 위한 가장 효과적인 접근 방식은 무엇인가요?

A. 모든 워크로드에 대해 가장 저렴한 스토리지 유형 사용
B. 모든 데이터를 S3로 마이그레이션
C. 워크로드 요구 사항에 맞는 스토리지 유형 선택 및 수명 주기 관리 구현
D. 모든 볼륨 크기를 최소화

정답 및 설명

정답: C. 워크로드 요구 사항에 맞는 스토리지 유형 선택 및 수명 주기 관리 구현

설명: Amazon EKS에서 스토리지 비용을 최적화하기 위한 가장 효과적인 접근 방식은 워크로드 요구 사항에 맞는 스토리지 유형을 선택하고 수명 주기 관리를 구현하는 것입니다. 이 접근 방식은 성능 요구 사항을 충족하면서 비용을 최소화하고, 데이터의 가치와 액세스 패턴에 따라 적절한 스토리지 계층을 활용합니다.

주요 스토리지 최적화 전략:

워크로드에 적합한 스토리지 유형 선택:
- 고성능 필요: io2, gp3 (EBS)
- 공유 액세스 필요: EFS
- 대용량 데이터 처리: FSx for Lustre
- 아카이브 데이터: S3, S3 Glacier
스토리지 수명 주기 관리:
- 자주 액세스하는 데이터: 고성능 스토리지
- 가끔 액세스하는 데이터: 표준 스토리지
- 거의 액세스하지 않는 데이터: 저비용 아카이브 스토리지
효율적인 볼륨 관리:
- 적절한 볼륨 크기 설정
- 사용하지 않는 볼륨 식별 및 제거
- 스냅샷 수명 주기 관리

StorageClass 예시에는 설치된 CSI 드라이버와 올바른 IAM/KMS·토폴로지 설정이 필요합니다. WaitForFirstConsumer는 EBS 프로비저닝을 스케줄링과 맞추며 Retain으로 남은 볼륨은 소유자가 처리할 때까지 과금됩니다. 바인딩된 PVC의 클래스 변경이나 제자리 축소는 불가능합니다. 스냅샷/복원 또는 지원되는 볼륨 유형 변경은 소유자가 검토한 이전 절차와 복원 테스트가 필요합니다. Auto Mode의 EBS provisioner는 다르므로 표준 CSI 예시에 조용히 대입하지 않습니다.

create-file-system에는 --lifecycle-policies 옵션이 없습니다. 아래처럼 기존 파일 시스템의 전체 원하는 정책 배열을 보존하며 put-lifecycle-configuration을 사용합니다. S3 전환도 최소 기간/크기, 요청 비용, 버전 관리, 복구 지연을 검토하고 lifecycle 전체 교체 시 관련 없는 규칙을 보존해야 합니다.

구현 방법:

EBS 볼륨 최적화:

yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: '3000'
  throughput: '125'
  encrypted: 'true'
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain

EFS 수명 주기 관리:

bash

set -euo pipefail
: "${AWS_REGION:?Set the reviewed Region}"
: "${FILE_SYSTEM_ID:?Set the existing reviewed EFS filesystem ID}"
aws efs describe-lifecycle-configuration --region "$AWS_REGION" \
  --file-system-id "$FILE_SYSTEM_ID" --query LifecyclePolicies --output json \
  > efs-lifecycle-policies.json
# Edit the exported array; an IA entry is {"TransitionToIA":"AFTER_30_DAYS"}.
# Preserve required Archive/return-to-primary entries before submitting the whole policy.
aws efs put-lifecycle-configuration --region "$AWS_REGION" \
  --file-system-id "$FILE_SYSTEM_ID" \
  --lifecycle-policies file://efs-lifecycle-policies.json

S3 수명 주기 정책:

json

{
  "Rules": [
    {
      "ID": "Move to IA after 30 days, Glacier after 90 days",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      },
      "Filter": {
        "Prefix": "eks-backups/"
      }
    }
  ]
}

EBS 스냅샷 수명 주기 관리:

yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot
driver: ebs.csi.aws.com
deletionPolicy: Delete

아래 스냅샷 일정은 소유자가 기존 team-a/database-data PVC, 표준 EBS CSI 드라이버, snapshot controller/CRD, ebs-snapshot 클래스를 확인할 때까지 suspend 상태입니다. 마운트한 template은 고정 이름 충돌을 피하도록 generateName을 사용합니다. Role은 이 namespace의 스냅샷 생성을 허용하며 source PVC 필드까지 제한하지는 않습니다. 애플리케이션 일관성/quiescing과 복원 검증은 별도 책임입니다. Job 성공은 API 생성 성공이며 snapshot 준비 완료가 아니므로 readyToUse와 오류를 별도로 감시합니다. Job 이력 제한은 VolumeSnapshot/EBS snapshot을 만료시키지 않습니다. 일정 활성화 전에 보존·복구 소유자를 정해야 하며 deletionPolicy: Delete이면 Kubernetes snapshot 삭제 시 원본 EBS snapshot도 삭제됩니다.

yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: snapshot-creator
  namespace: team-a
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: snapshot-creator
  namespace: team-a
rules:
- apiGroups: ["snapshot.storage.k8s.io"]
  resources: ["volumesnapshots"]
  verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: snapshot-creator
  namespace: team-a
subjects:
- kind: ServiceAccount
  name: snapshot-creator
  namespace: team-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: snapshot-creator
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: snapshot-templates
  namespace: team-a
data:
  snapshot.yaml: |
    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      generateName: database-data-
      namespace: team-a
    spec:
      volumeSnapshotClassName: ebs-snapshot
      source:
        persistentVolumeClaimName: database-data
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: volume-snapshot
  namespace: team-a
spec:
  suspend: true
  schedule: "0 1 * * *"
  timeZone: Etc/UTC
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 1800
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 2
  jobTemplate:
    spec:
      backoffLimit: 0
      activeDeadlineSeconds: 120
      template:
        spec:
          serviceAccountName: snapshot-creator
          restartPolicy: Never
          securityContext:
            runAsNonRoot: true
            runAsUser: 65532
            seccompProfile:
              type: RuntimeDefault
          containers:
          - name: snapshot-creator
            image: registry.k8s.io/kubectl:v1.36.2
            command: ["kubectl"]
            args: ["create", "-f", "/snapshots/snapshot.yaml", "--namespace=team-a"]
            env:
            - name: HOME
              value: /tmp
            securityContext:
              allowPrivilegeEscalation: false
              readOnlyRootFilesystem: true
              capabilities:
                drop: ["ALL"]
            resources:
              requests:
                cpu: 10m
                memory: 32Mi
              limits:
                memory: 128Mi
            volumeMounts:
            - name: snapshots
              mountPath: /snapshots
              readOnly: true
            - name: tmp
              mountPath: /tmp
          volumes:
          - name: snapshots
            configMap:
              name: snapshot-templates
          - name: tmp
            emptyDir: {}

워크로드 유형별 스토리지 최적화:

데이터베이스 워크로드:
- 성능 요구 사항: 높은 IOPS 및 처리량
- 권장 스토리지: EBS io2 또는 gp3
- 최적화 전략: 적절한 IOPS 및 처리량 설정, 정기적인 스냅샷
웹 애플리케이션:
- 성능 요구 사항: 중간 IOPS, 공유 액세스
- 권장 스토리지: EFS 또는 EBS gp3
- 최적화 전략: 캐싱, 정적 콘텐츠 분리
로그 및 분석 데이터:
- 성능 요구 사항: 높은 처리량, 대용량
- 권장 스토리지: S3, EFS
- 최적화 전략: 수명 주기 정책, 압축
AI/ML 워크로드:
- 성능 요구 사항: 매우 높은 처리량
- 권장 스토리지: FSx for Lustre, EBS gp3
- 최적화 전략: 임시 데이터와 영구 데이터 분리

모범 사례:

데이터 계층화 구현:

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hot-data
  namespace: team-a
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: ebs-gp3
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: warm-data
  namespace: team-a
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: efs-standard
  resources:
    requests:
      storage: 100Gi

스토리지 사용량 모니터링 및 최적화:

bash

set -euo pipefail
: "${KUBE_CONTEXT:?Select the reviewed cluster context}"
: "${KUBE_NAMESPACE:?Select the reviewed namespace}"
kubectl --context "$KUBE_CONTEXT" --namespace "$KUBE_NAMESPACE" \
  get pvc --chunk-size=500 -o json > pvcs.json
kubectl --context "$KUBE_CONTEXT" --namespace "$KUBE_NAMESPACE" \
  get pods --chunk-size=500 -o json > pods.json
python3 unreferenced_pvcs.py

데이터 압축 및 중복 제거:
- 로그 및 백업 데이터 압축
- 중복 데이터 제거 기술 활용
- 효율적인 데이터 형식 사용

비용 할당 및 태깅:

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-data
  labels:
    app: database
    environment: production
    cost-center: cc-123
  namespace: team-a
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: ebs-io2
  resources:
    requests:
      storage: 100Gi

추가 구성과 읽기 전용 분석 예시:

스토리지 비용 최적화 아키텍처:

+-------------------+    +-------------------+    +-------------------+
|                   |    |                   |    |                   |
|  Hot Data         |    |  Warm Data        |    |  Cold Data        |
|  (EBS gp3)        |    |  (EFS)            |    |  (S3)             |
+-------------------+    +-------------------+    +-------------------+
        |                        |                        |
        v                        v                        v
+-------------------+    +-------------------+    +-------------------+
|                   |    |                   |    |                   |
|  Active           |    |  Recent           |    |  Archive          |
|  Applications     |    |  Applications     |    |  Data             |
|                   |    |                   |    |                   |
+-------------------+    +-------------------+    +-------------------+
                                  |
                                  v
                         +-------------------+
                         |                   |
                         |  Lifecycle        |
                         |  Management       |
                         |                   |
                         +-------------------+

Terraform을 사용한 스토리지 최적화 인프라 구성:

hcl

# EBS gp3 스토리지 클래스
resource "kubernetes_storage_class_v1" "ebs_gp3" {
  metadata {
    name = "ebs-gp3"
  }
  storage_provisioner = "ebs.csi.aws.com"
  parameters = {
    type       = "gp3"
    iops       = "3000"
    throughput = "125"
    encrypted  = "true"
  }
  allow_volume_expansion = true
  volume_binding_mode    = "WaitForFirstConsumer"
  reclaim_policy         = "Retain"
}

# EFS 파일 시스템
resource "aws_efs_file_system" "eks_efs" {
  creation_token = "eks-efs"
  encrypted      = true

  lifecycle_policy {
    transition_to_ia = "AFTER_30_DAYS"
  }

  tags = {
    Name = "eks-efs"
  }
}

# S3 버킷 및 수명 주기 정책
resource "aws_s3_bucket" "eks_data" {
  bucket = "eks-data-${data.aws_caller_identity.current.account_id}"

  tags = {
    Name = "eks-data"
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "eks_data_lifecycle" {
  bucket = aws_s3_bucket.eks_data.id

  rule {
    id     = "archive-rule"
    status = "Enabled"

    filter {
      prefix = "eks-backups/"
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER"
    }

    expiration {
      days = 365
    }
  }
}

스토리지 비용 모니터링 및 최적화 스크립트:

python

import json
from pathlib import Path


def unreferenced_claims(claims, pods):
    referenced = set()
    for pod in pods["items"]:
        namespace = pod["metadata"]["namespace"]
        for volume in pod.get("spec", {}).get("volumes") or []:
            claim = volume.get("persistentVolumeClaim")
            if claim:
                referenced.add((namespace, claim["claimName"]))
    result = []
    for claim in claims["items"]:
        metadata = claim["metadata"]
        identity = (metadata["namespace"], metadata["name"])
        if claim.get("status", {}).get("phase") != "Bound" or identity in referenced:
            continue
        spec = claim.get("spec", {})
        result.append({
            "namespace": identity[0],
            "name": identity[1],
            "storageClass": spec.get("storageClassName"),
            "requested": ((spec.get("resources") or {}).get("requests") or {}).get("storage"),
            "meaning": "not referenced by the supplied current Pod snapshot; review required",
        })
    return result


if __name__ == "__main__":
    claims = json.loads(Path("pvcs.json").read_text())
    pods = json.loads(Path("pods.json").read_text())
    print(json.dumps(unreferenced_claims(claims, pods), indent=2))

위 Python을 unreferenced_pvcs.py로 저장하고 앞의 읽기 전용 명령과 사용합니다. 현재 Pod snapshot에서 참조되지 않는 Bound PVC 후보만 출력합니다. (namespace, name)으로 비교하고 PVC가 아닌 볼륨의 persistentVolumeClaim: null도 처리합니다. 기본 Kubernetes에는 pv_used 어노테이션이 없으며 이를 미사용 판정으로 사용하지 않습니다. 서로 다른 시점의 목록, 축소된 StatefulSet, 대기 작업, 컨트롤러 template, 백업/복구 요구는 이 목록으로 확인되지 않습니다. 삭제를 자동화하지 마세요. EBS available도 미사용을 의미하지 않으며, EKS06 비용 문항의 계정·태그 범위 조회를 사용합니다.

hot/warm/cold 도식은 접근 패턴별 선택 예시이며 EBS→EFS→S3 자동 이전 파이프라인이 아닙니다. efs-standard/ebs-io2 클래스는 별도로 준비해야 하고, EFS PVC의 100Gi 요청은 파일 시스템 사용량 quota나 선결제 용량을 설정하지 않습니다. PVC 레이블도 AWS 청구 태그로 자동 전달되지 않습니다. Terraform은 기존 provider·caller identity 등을 요구하는 구성 fragment로, 기존 StorageClass 소유권과 파일 시스템 mount target/접근 권한, 백업·보존 요구를 별도 구성해야 합니다.

다른 옵션들의 문제점:

A. 모든 워크로드에 대해 가장 저렴한 스토리지 유형 사용: 가장 저렴한 스토리지는 성능 요구 사항을 충족하지 못할 수 있으며, 이로 인해 애플리케이션 성능 저하 및 비즈니스 영향이 발생할 수 있습니다.
B. 모든 데이터를 S3로 마이그레이션: S3는 일부 데이터 유형에 적합하지만, 지연 시간에 민감한 워크로드나 블록 스토리지가 필요한 애플리케이션에는 적합하지 않습니다.
D. 모든 볼륨 크기를 최소화: 볼륨 크기를 과도하게 최소화하면 공간 부족 문제가 발생할 수 있으며, 일부 볼륨 유형(예: gp2)은 크기에 따라 성능이 결정됩니다.

### 3. Amazon EKS에서 네트워킹 비용을 최적화하기 위한 가장 효과적인 전략은 무엇인가요?

A. 모든 트래픽에 대해 가장 비싼 네트워크 대역폭 사용
B. 모든 서비스를 단일 가용 영역에 배치
C. 트래픽 패턴 최적화, 데이터 전송 비용 최소화 및 VPC 엔드포인트 활용
D. 모든 네트워크 트래픽 차단

정답 및 설명

정답: C. 트래픽 패턴 최적화, 데이터 전송 비용 최소화 및 VPC 엔드포인트 활용

설명: Amazon EKS에서 네트워킹 비용을 최적화하기 위한 가장 효과적인 전략은 트래픽 패턴을 최적화하고, 데이터 전송 비용을 최소화하며, VPC 엔드포인트를 활용하는 것입니다. 이 접근 방식은 네트워크 트래픽의 효율성을 높이고, AWS 네트워크 비용 모델을 고려하여 불필요한 비용을 줄입니다.

주요 네트워킹 비용 최적화 전략:

트래픽 패턴 최적화:
- 가용 영역 간 트래픽 최소화
- 리전 간 트래픽 최소화
- 로컬리티 인식 라우팅 구현
데이터 전송 비용 최소화:
- 압축 및 효율적인 데이터 형식 사용
- 캐싱 전략 구현
- 불필요한 데이터 전송 제거
VPC 엔드포인트 활용:
- AWS 서비스에 대한 프라이빗 연결
- 인터넷 게이트웨이 우회
- 데이터 전송 비용 절감

Topology spread는 배치를 제어하며 Service 트래픽의 엔드포인트를 선택하지 않습니다. spec.topologyKeys는 제거되었습니다. 예시는 Kubernetes 1.35+에서 stable인 trafficDistribution: PreferSameZone을 사용하며 fallback이 가능하므로 AZ 간 트래픽 0을 보장하지 않습니다. 실제 proxy/CNI 동작과 가용성 제약을 검증합니다.

S3/DynamoDB gateway endpoint와 interface endpoint의 가격 모델은 다릅니다. ECR 이미지 pull에는 ecr.api, ecr.dkr, S3 연결과 private DNS, 대상 노드/Pod에서 endpoint로의 TCP 443 보안 그룹 규칙이 필요합니다. CLI는 interface endpoint 하나를 보여주며 아래 Terraform처럼 DKR 상대 endpoint도 준비합니다. endpoint policy와 실제 리전 트래픽/비용을 검토해야 하며 프라이빗 연결이 무료를 의미하지는 않습니다.

구현 방법:

가용 영역 인식 파드 배치:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-app
      containers:
      - name: web-app
        image: registry.example.com/team/web-app:REVIEWED_TAG
    metadata:
      labels:
        app: web-app
  selector:
    matchLabels:
      app: web-app

Private Pod in AZ-a -> S3/DynamoDB gateway endpoint route -> regional service -> private DNS -> interface endpoint ENI:443 -> ECR API/DKR (ECR layer downloads also require S3 access) -> zonal NAT in AZ-a public subnet -> internet gateway -> external API