AWS EKS 팀별 비용 배부: 태그부터 Showback·Chargeback까지

여러 팀이 하나의 Amazon EKS cluster를 공유하면 AWS 청구서만으로 “A팀이 얼마를 썼는가”를 바로 답하기 어렵다. EC2 node, load balancer, NAT Gateway, EBS와 shared observability 비용은 Pod 경계와 정확히 일치하지 않기 때문이다.

팀별 비용 분리는 기술 기능 하나가 아니라 귀속 가능한 비용, 공유 비용, 미분류 비용을 어떤 규칙으로 배부할지 합의하는 FinOps 모델이다.

공유 EKS 클러스터의 팀별 비용을 분리하는 구조

먼저 비용을 세 묶음으로 나눈다

묶음	예시	배부 방식
직접 귀속	전용 load balancer, 팀 전용 EBS, namespace workload	resource tag·Pod label로 직접 귀속
공유 비용	node idle, control plane, observability, shared ingress	합의한 driver로 배부
미분류	label 누락, mapping 실패, 공용 network 경로	unallocated로 남겨 개선

모든 비용을 억지로 팀에 나누면 숫자는 100%가 되지만 신뢰는 떨어진다. 분류되지 않은 비용을 별도 bucket으로 보이는 편이 metadata 품질과 배부 규칙을 개선하기 쉽다.

EKS 비용은 Pod CPU·memory만이 아니다

대표적인 비용 항목은 다음과 같다.

• EKS cluster의 standard 또는 extended support 요금
• EC2 managed node group, self-managed node, Karpenter node
• Fargate compute
• EBS·EFS와 snapshot
• Application·Network Load Balancer
• NAT Gateway 시간·data processing
• inter-AZ·internet·VPC 연결 data transfer
• CloudWatch log·metric, tracing과 third-party observability
• container registry와 image pull
• backup·security·support 도구

가격과 support lifecycle은 바뀔 수 있으므로 글에 고정 금액을 적기보다 Amazon EKS 공식 가격을 기준으로 현재 account·region을 확인한다.

1단계: label 계약부터 고정한다

비용 tool보다 먼저 workload owner를 식별할 metadata가 필요하다. Kubernetes recommended label과 조직용 label을 섞어 최소 계약을 만든다.

metadata:
  labels:
    app.kubernetes.io/name: checkout-api
    app.kubernetes.io/part-of: commerce
    cost.example.com/team: payments
    cost.example.com/environment: production
    cost.example.com/cost-center: cc-042

실제 domain과 값은 조직 표준에 맞춘다. label value에 개인 이름이나 email을 넣지 않고 stable team·cost-center ID를 사용한다.

계약에는 다음을 포함한다.

• 필수 label key와 허용 value
• namespace·Deployment·Pod 중 적용 위치
• admission policy 또는 CI 검증
• 팀 이동·조직 개편 시 변경 절차
• 누락 workload의 owner와 unallocated 처리

AWS Split Cost Allocation Data는 EKS Pod label을 cost allocation tag로 가져올 수 있다. 다만 management account에서 기능과 tag를 활성화해야 하고, 반영 지연과 label 수·문자 제한이 있다. 현재 문서는 Pod당 alphabet 순으로 최대 50개 label을 지원하므로, 비용 key를 무작정 늘리기보다 핵심 dimension을 정한다.

2단계: AWS Split Cost Allocation Data로 청구 비용을 나눈다

Split Cost Allocation Data, SCAD는 AWS Cost and Usage Report 또는 Data Exports에서 shared EC2 compute 비용을 Pod 단위 record로 나눈다. CPU와 memory의 reservation·actual usage 비율, instance의 amortized cost 등을 이용해 split cost column을 만든다.

여기서 중요한 경계가 있다.

1. AWS billing data에 기반하므로 account 총비용과 reconciliation하기 좋다.
2. 그렇다고 각 Pod가 “정확히 유발한 물리적 원가”를 측정한 것은 아니다.
3. idle·unused·shared 비용을 어떤 driver로 나눌지는 여전히 정책이다.
4. report record 수와 저장·query 비용이 늘어난다.
5. data는 실시간 alert가 아니라 billing 분석 흐름에 가깝다.

SCAD Containers Cost Allocation Dashboard는 Pod, namespace, controller와 custom label로 drill-down하고 showback·chargeback view를 만드는 데 도움을 준다. dashboard가 배부 정책을 대신 결정해 주지는 않는다.

3단계: Kubecost는 운영 관측에 사용한다

Kubecost는 Kubernetes metric과 cloud price 정보를 바탕으로 namespace, workload, label별 cost와 efficiency를 보여 준다. rightsizing, idle cost와 daily trend를 빠르게 보는 데 유용하다.

다만 Kubecost의 실시간 추정치와 AWS의 최종 청구 data가 언제나 같지는 않다.

• Savings Plans·Reserved Instance·enterprise discount 반영
• shared service 배부 방식
• network·support·tax 등 포함 범위
• metric 유실과 sampling
• amortization과 billing period

따라서 역할을 나눈다.

• Kubecost: 운영 중 추세, anomaly, rightsizing 후보
• AWS billing data·SCAD: 월별 reconciliation과 공식 showback basis

두 숫자가 다르면 어느 쪽이 틀렸다고 바로 판단하지 말고 scope와 allocation rule부터 맞춘다.

shared compute를 어떻게 배부할까

request 기준

CPU·memory request 비율로 node 비용을 나눈다. team이 예약한 capacity 책임을 보여 주기 좋고, workload가 idle이어도 request만큼 비용을 부담한다.

usage 기준

실제 CPU·memory 사용 비율로 나눈다. 소비량과 가까워 보이지만 metric 품질과 sampling에 의존하고, burst나 memory resident 특성을 어떻게 반영할지 정해야 한다.

혼합 기준

base는 request, variable cost는 usage로 배부하거나 idle을 별도 pool로 둔다. 설명 가능성과 최적화 유인을 함께 만들 수 있지만 규칙이 복잡해진다.

어떤 방식을 쓰든 계산식, 기간, rounding과 shared bucket을 문서화한다. 비용 dashboard 숫자가 달라졌을 때 계산 근거를 재현할 수 있어야 한다.

network 비용은 Pod label 하나로 끝나지 않는다

network cost에는 load balancer, NAT Gateway, inter-AZ와 internet data transfer가 섞인다. packet의 source Pod를 알아도 최종 AWS charge와 항상 1:1로 연결되지 않는다.

Load Balancer

team 전용 load balancer는 tag와 resource ownership으로 비교적 직접 귀속하기 쉽다. 하지만 팀마다 하나씩 만들면 hourly fixed cost와 운영 object 수가 늘어난다. shared ingress는 host·route·byte·request 중 어떤 driver로 나눌지 정해야 한다.

NAT Gateway

NAT Gateway에는 시간과 처리 data 비용이 있고, AZ를 가로질러 접근하면 inter-AZ transfer도 생길 수 있다. AWS는 resilience와 cross-AZ 비용 회피를 위해 AZ별 NAT Gateway를 설명하지만, gateway 수가 늘면 시간 비용도 증가한다.

따라서 “팀마다 NAT Gateway”를 기본값으로 두기보다 다음을 비교한다.

• AZ별 shared NAT와 team별 route visibility
• S3·DynamoDB Gateway Endpoint
• 필요한 AWS service의 Interface Endpoint
• direct internet egress가 필요한 destination
• egress proxy·firewall의 shared cost

VPC Flow Logs

Flow Logs는 interface, source·destination address, byte 등을 분석해 egress 후보를 찾는 데 유용하다. 그러나 그 자체가 비용 invoice는 아니다.

Pod IP와 ENI mapping은 시간에 따라 바뀌고 IP가 재사용될 수 있다. log window와 cluster inventory를 시간 기준으로 맞춰야 하며, capture되지 않는 traffic과 aggregation delay도 고려한다. 이를 “Pod별 정확한 network 청구서”로 표현하면 안 된다.

team별 node group과 network를 분리할 시점

방식	장점	비용·운영 trade-off
shared node	bin packing과 효율이 좋음	idle·DaemonSet·system Pod 배부 필요
team node group	EC2 cost 귀속과 quota가 명확	작은 team의 idle, node 수 증가
team account·cluster	billing·security boundary가 가장 명확	control plane·platform 중복, 운영 복잡도
shared ingress·egress	fixed cost 절감	route·traffic driver 합의 필요
dedicated network resource	직접 귀속·isolation	hourly cost와 관리 object 증가

비용 분리만을 위해 infrastructure를 지나치게 쪼개면 전체 비용이 더 커질 수 있다. compliance, blast radius, quota와 team autonomy까지 함께 이유가 있을 때 물리적 분리를 선택한다.

node group을 나눠도 shared DaemonSet, cluster add-on, cross-AZ traffic과 공용 control plane은 남는다. “node label이 곧 완전한 팀별 청구”는 아니다.

Showback에서 Chargeback으로 가는 순서

1. Showback

실제 내부 청구 없이 팀별 비용과 배부 규칙을 보여 준다. 최소 두세 billing cycle 동안 누락 label, 조직 이동과 shared cost 이견을 고친다.

2. 책임 지표 연결

• request 대비 usage
• idle 비율
• unallocated 비율
• team owner가 없는 resource
• 전월 대비 변화와 설명

비용만 보여 주고 workload SLO를 함께 보지 않으면 무리한 절감으로 reliability가 떨어질 수 있다.

3. Chargeback

정책 owner, 이의 제기, 월말 freeze와 retroactive correction 규칙을 정한 뒤 내부 청구에 연결한다. allocation model을 version으로 관리하고 변경 전후 영향을 공개한다.

구현 점검표

• account·region별 현재 가격과 discount 범위를 확인했는가?
• 필수 Kubernetes label을 admission·CI에서 검증하는가?
• SCAD·Data Exports와 cost allocation tag가 활성화됐는가?
• direct, shared, unallocated 비용을 분리했는가?
• Kubecost 추정과 AWS bill의 scope를 설명할 수 있는가?
• node idle·DaemonSet·control plane 배부 규칙이 있는가?
• load balancer·NAT·inter-AZ·observability 비용을 포함했는가?
• network attribution의 시간 mapping과 누락 한계를 기록했는가?
• showback 검증 기간을 거친 뒤 chargeback하는가?
• 비용 절감과 SLO·security trade-off를 함께 보는가?

Kubernetes request·limit과 QoS는 compute 배부 기준을 이해하는 데 도움이 된다. EKS conntrack·Pod NAT 흐름과 NLB 동작 정리는 network cost의 실제 경로를 따라가는 배경이 된다.

참고 자료

• Amazon EKS pricing
• AWS EKS split cost allocation data
• AWS Data Exports: split cost allocation data
• AWS Data Exports: Kubernetes labels for EKS cost allocation
• AWS SCAD Containers Cost Allocation Dashboard
• Amazon EKS cost optimization: networking
• Amazon VPC NAT Gateway pricing guidance
• Amazon VPC Flow Logs