프로그래밍공부(Programming Study)/DevOps-Cloud Native

AWS EKS에서 팀별 비용 분리하기

Chann._.y 2025. 12. 30.

728x90

컴퓨트부터 트래픽까지, “정산 가능한 구조”로 만드는 방법

하나의 EKS 클러스터를 여러 팀이 함께 쓰기 시작하면, 어느 순간 반드시 이런 질문이 나온다.

“우리 팀이 실제로 얼마나 쓰고 있는 거지?”
“네트워크 비용은 왜 이렇게 많이 나오지?”
“이걸 근거로 비용 정산을 해도 되는 건가?”

EKS는 분명 강력하지만, 비용 관점에서는 기본적으로 ‘팀 단위’를 전혀 모른다.
그래서 비용 분리는 기능 하나로 해결되는 문제가 아니라,
계측 방식 + 구조 설계 + 운영 규칙이 함께 맞물려야 한다.

이 글에서는 AWS가 공식적으로 제공하는 메커니즘을 기준으로,
EKS에서 컴퓨트 + 네트워크 비용을 팀별로 나누는 현실적인 방법을 정리한다.

1. EKS에서 비용이 실제로 발생하는 위치부터 이해하기

EKS 자체는 관리형 컨트롤 플레인 비용만 가진다.
대부분의 비용은 아래 리소스에서 발생한다.

컴퓨트 / 스토리지

EC2 (Managed Node Group)
Fargate
EBS 볼륨

네트워크

Application / Network Load Balancer
NAT Gateway
AZ 간 트래픽
Internet egress
VPC Peering / Transit Gateway

공식 요금 기준:

EC2 데이터 전송 요금
https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer
VPC / NAT Gateway 요금
https://aws.amazon.com/vpc/pricing/

여기서 중요한 전제가 하나 있다.

AWS는 Pod, Namespace, Service 단위로 네트워크 비용을 직접 계산해 주지 않는다.

즉 Kubernetes 개념과 AWS 과금 단위 사이에는 본질적인 간극이 있다.

2. 컴퓨트 비용 분리의 기준선: SCAD + 라벨

EKS 비용 분리의 출발점은 Split Cost Allocation Data(SCAD) 다.

AWS는 SCAD를 통해 Kubernetes 리소스 정보를 CUR(Cost & Usage Report)에 포함할 수 있도록 한다.

공식 문서:

SCAD 개요
https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html
EKS 라벨 기반 비용 추적 가이드
https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring-aws.html

이를 통해 다음 정보들이 CUR에 포함된다.

namespace
pod
Kubernetes label
workload 메타데이터

즉, 라벨 기준으로 비용 집계가 가능해진다.

기본 구성 방식

비용 라벨 정의
예:
cost.team cost.service cost.env
Deployment / StatefulSet에 라벨 강제
- Kyverno 또는 OPA Gatekeeper로 누락 시 배포 차단
Billing 계정에서 SCAD 활성화
- Cost & Usage Report 생성
- Resource ID 포함 옵션 활성화
Cost Allocation Tags에서 라벨 활성화
- cost.team 같은 사용자 태그를 활성화해야 집계 가능

AWS는 Kubernetes 라벨을 사용자 정의 비용 태그로 가져올 수 있도록 명시하고 있다.
(최대 50개 라벨까지 지원됨)
https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html

SCAD 방식의 성격

장점:

AWS 공식 과금 데이터 기반
감사·정산 용도로 신뢰도 높음
자동화 가능

한계:

실시간이 아님 (수 시간~하루 지연)
네트워크 비용은 직접 쪼개지지 않음

그래서 SCAD는 “정산 기준”, 즉 월말 숫자의 기준선 역할에 적합하다.

3. 운영 관점 보완: Kubecost

AWS는 EKS 환경에서 Kubecost 사용을 공식적으로 안내한다.

참고:

https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring-kubecost-bundles.html

Kubecost는 다음을 제공한다.

namespace / label 기준 비용 조회
요청(request) 대비 실제 사용량 분석
네트워크 비용 추정
낭비 리소스 탐지

Kubecost는 AWS 청구 데이터를 그대로 나누는 것이 아니라,
메트릭과 비율 모델을 이용해 비용을 계산한다.

그래서 성격은 다음과 같다.

운영 중 비용 흐름 파악 → 매우 유용
월말 정산의 단일 근거 → 부적합

현업에서는 보통 이렇게 나눈다.

CUR(SCAD): 공식 정산 기준
Kubecost: 운영/튜닝/원인 분석용

4. 네트워크 비용이 특히 어려운 이유

네트워크 비용은 Kubernetes 레벨에서 계측되지 않는다.

AWS가 실제로 과금하는 단위는 다음과 같다.

Load Balancer
NAT Gateway
ENI
AZ 간 데이터 전송
VPC 단위 트래픽

즉 이런 질문에는 AWS가 바로 답해주지 않는다.

“이 Pod가 발생시킨 트래픽 비용은 얼마인가?”

그래서 네트워크 비용은 구조적으로 분리하지 않으면 정확한 팀 귀속이 불가능하다.

5. 인바운드 트래픽 분리: Load Balancer 기준

ALB / NLB는 리소스 단위로 비용이 집계된다.

공식 문서:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html

구조 예시

팀 A → ALB A
팀 B → ALB B

Ingress Controller 또는 IngressClass를 팀별로 분리한다.

장점

비용 귀속이 명확함
CUR에서 바로 팀별 집계 가능
설명이 쉽다

단점

Load Balancer 개수 증가
관리 및 비용 증가 가능

6. 아웃바운드 트래픽 분리: NAT Gateway 기준

대부분의 인터넷 아웃바운드는 NAT Gateway를 통과한다.

NAT Gateway는 다음 기준으로 과금된다.

시간당 요금
처리한 데이터(GB)

공식 문서:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html

구조

팀별 Subnet
팀별 Route Table
팀별 NAT Gateway

이렇게 구성하면:

NAT A → 팀 A
NAT B → 팀 B

로 비용 귀속이 매우 명확해진다.

장점

아웃바운드 트래픽 분리 정확도 높음
CUR 기준 집계 가능

단점

NAT Gateway 수 증가 → 고정 비용 증가
네트워크 설계 복잡도 상승

7. NodeGroup 기반 간접 분리 (현실적인 절충안)

팀별 NodeGroup을 만들고, 각 NodeGroup이 서로 다른 Subnet을 사용하게 하면 트래픽 경로가 자연스럽게 분리된다.

흐름은 다음과 같다.

Pod → Node(팀별) → Subnet → NAT

정확도는 중간 수준이지만 장점이 많다.

컴퓨트 비용과 함께 묶어서 관리 가능
EKS 운영 패턴과 잘 맞음
구조가 단순함

Managed Node Group에 taint를 적용해 팀 간 혼재를 막는 것도 AWS 공식 문서로 지원된다.
https://docs.aws.amazon.com/eks/latest/userguide/node-taints-managed-node-groups.html

8. 로그 기반 접근(VPC Flow Logs)은 언제 쓰나

VPC Flow Logs는 다음 정보를 제공한다.

source / destination
bytes
subnet
AZ

공식 문서:
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

이를 이용하면 다음 매핑이 가능하다.

ENI → Node → Pod → team label

기술적으로는 팀별 트래픽 추정이 가능하지만,

파이프라인 복잡도 높음
Athena/Glue/S3 운영 필요
정산 기준으로 쓰기엔 부담 큼

그래서 보통 분석·조사 목적으로만 사용된다.

9. 많이 쓰는 조합

패턴 A (가장 흔함)

컴퓨트: SCAD + 라벨
인바운드: Load Balancer 분리
아웃바운드: NAT Gateway 분리
공용 비용: 비율 배분

패턴 B (단순화된 구조)

팀별 NodeGroup
Subnet + NAT 분리
CUR 기준 집계

패턴 C (운영 중심)

Kubecost로 실시간 가시화
CUR은 월말 정산 기준으로만 사용

마무리

EKS 비용 분리는 단순히 “툴을 하나 붙이는 문제”가 아니다.

컴퓨트는 SCAD + 라벨로 해결 가능하다.
네트워크는 구조를 바꾸지 않으면 정확히 나눌 수 없다.
Load Balancer / NAT 같은 과금 단위를 기준으로 설계해야 한다.
Kubecost는 운영용, CUR은 정산용이라는 역할 분리가 필요하다.

결국 중요한 건 완벽한 정밀도가 아니라,
조직이 합의할 수 있고 반복 가능한 기준을 만드는 것이다.

마무리 생각거리

지금 클러스터에서 가장 큰 비용은 컴퓨트일까, 네트워크일까?
그 비용을 “팀 귀속”으로 만들기 위해 구조를 어디까지 바꿀 수 있을까?
기술적으로 가능한 것과, 조직이 감당할 수 있는 복잡도 사이의 균형점은 어디일까?

이 질문에 대한 답이 정리되면, EKS 비용 분리는 훨씬 수월해진다.