전체 글

총 618개의 글

EKS Pod IP 할당이 안 될 때 서브넷 여유 IP·ENI·Prefix Delegation 점검하기

AWS EKS · 네트워크 오류 해결EKS Pod IP 할당이 안 될 때서브넷 여유 IP·ENI·Prefix Delegation 점검하기Pod 이벤트에서 실패 단계를 구분한 뒤 실제 Pod 서브넷, 노드 한도, Prefix 공간과 CNI 권한을 확인하세요.VPC CNI 진단조회 명령증상별 판단표2026.09.09 확인EKS Pod IP 할당 실패를 Pod 이벤트부터 서브넷 여유 IP, ENI 한도, Prefix Delegation 순서로 점검합니다. InsufficientCidrBlocks, Warm Pool, CNI 권한 오류를 구분하는 조회 명령과 진단표를 확인하세요.목차Pod IP 할당 실패인지 먼저 확인하기VPC CNI가 Pod IP를 할당하는 구조첫 점검: 해당 노드의 aws-node와 로그 확..

AWS Guides

EKS에서 Calico가 필요한 경우: VPC CNI 정책 기능과 CNI 교체 판단 기준

AWS EKS · 네트워크 선택 기준EKS에서 Calico가 필요한 경우VPC CNI 정책 기능과 CNI 교체 판단 기준기본 통신 제어는 VPC CNI부터 검토하세요. Calico 정책이 필요한지, Pod 네트워크 자체를 바꿔야 하는지 나누면 도입 범위를 정하기 쉽습니다.VPC CNICalico 도입 판단구성 비교2026.09.09 확인EKS에서 Calico가 필요한 상황을 VPC CNI 유지, Calico 정책 추가, CNI 교체로 나눠 비교합니다. NetworkPolicy 지원 조건과 Pod IP 부족 대안, AWS 지원 범위 및 운영 전환 점검 기준을 확인하세요.목차EKS에서 Calico가 꼭 필요할까? 먼저 보는 선택 기준VPC CNI와 Calico의 역할: 정책 추가와 네트워킹 교체VPC CNI..

Codex·Claude Code·Google Antigravity 비교이용률·장점·요금과 결제 선택 가이드

AI 코딩 도구 · 선택과 비용Codex·Claude Code·Google Antigravity 비교이용률·장점·요금과 결제 선택 가이드이미 쓰는 구독과 개발 환경부터 확인하고, 실제 작업의 검토 부담과 추가 비용으로 선택하세요.업무용 이용률도구별 장점구독과 추가 과금2026.09.08 확인Codex·Claude Code·Google Antigravity의 업무용 이용률, 장점, 무료·유료 요금과 추가 과금 조건을 비교합니다. 구독료와 API 비용의 차이, 해지 시 확인할 점을 정리해 개인 개발자와 팀의 선택을 돕습니다.목차Codex·Claude Code·Google Antigravity, 어떤 도구를 선택할까AI 코딩 도구 점유율 비교: 이용률 통계는 어떻게 읽어야 할까Codex의 장점과 선택 전 확인..

Kubernetes Guides

쿠버네티스 PVC 용량 확장이 반영되지 않을 때: 요청 용량·CSI·파일시스템 점검하기

Kubernetes · 스토리지 장애 점검 쿠버네티스 PVC 용량 확장이 반영되지 않을 때요청 용량·CSI·파일시스템 점검하기 PVC 요청값, PV 용량, 컨테이너의 실제 파일시스템을 비교하면 확장이 멈춘 단계를 좁힐 수 있습니다. PVC 확장CSI 진단샘플 YAML2026.09.09 확인쿠버네티스 PVC 용량을 늘렸는데 반영되지 않을 때 요청값, PV 용량, CSI 이벤트와 파일시스템을 점검하는 순서를 정리합니다. EKS EBS CSI 샘플 YAML과 확장 명령, 완료 확인 및 데이터 보호 기준을 함께 확인하세요. 목차 PVC 용량 확장이 안 될 때 먼저 비교할 세 가지 확장 전제 조건: StorageClass와 드라이버부터 확인하기 샘플 YAML: 확장 가능한 테스트 볼륨 ..

GPT-6 Astra 사용법: ChatGPT Work에서 시작하는 새 모델 활용 가이드

GPT-6 Astra · Getting Started GPT-6 Astra 사용법ChatGPT Work에서 시작하기 새 모델의 특징부터 선택 방법, 첫 요청과 결과 검증까지 정리합니다. AstraChatGPT WorkCodexValidationGPT-6 Astra의 특징과 ChatGPT Work에서 시작하는 방법을 정리합니다. 모델 선택과 계정별 제공 여부, 첫 요청 예시, 결과 검증, 사용 한도와 API 요금의 차이를 확인하고 업무에 맞게 활용하세요. 목차 GPT-6 Astra란 무엇인가 무엇이 달라졌나: 긴 작업과 도구 활용에 초점 ChatGPT·ChatGPT Work·Codex·API는 어떻게 다른가 ChatGPT Work에서 Astra를 선택하고 시작하기 첫 ..

AWS Guides

AWS LiteLLM과 Amazon Bedrock 연동 구조: IAM 인증·배포·비용 관리

AWS · LLM Gateway AWS LiteLLM과 Amazon Bedrock연동 구조와 운영 기준 모델 호출 흐름부터 IAM 인증, 배포 환경 선택과 팀별 사용량 관리까지 설계 기준을 정리합니다. LiteLLMAmazon BedrockIAM Role비용 관리LiteLLM Proxy는 애플리케이션과 Amazon Bedrock 사이에서 모델 호출과 접근 정책을 관리하는 LLM Gateway입니다. AWS 배포 방식, IAM 인증, 팀별 비용 관리와 도입 판단 기준을 설명합니다. 목차 LiteLLM이란 무엇인가 Amazon Bedrock 앞에 LiteLLM을 두는 이유 AWS에서 전체 요청 흐름 이해하기 AWS 배포 방식 선택하기 인증 구조 이해하기: 사용자 키와 I..

AWS Guides

AWS Network Firewall 구성 방식 총정리 단일 NFW 중앙 Inspection VPC 이중 방화벽 설계 비교

AWS Network SecurityAWS Network Firewall 구성 방식 총정리: 단일 NFW, 중앙 Inspection VPC, 이중 방화벽 설계 비교AWS Network Firewall을 어디에 배치하고 어떤 라우팅으로 통과시킬지, 대표 구성별 장점과 주의점을 정리합니다.NFWInspection VPCTGWRoutingAWS Network Firewall은 VPC 트래픽을 검사하는 관리형 방화벽입니다. 이 글은 단일 VPC 구성, Distributed 구성, 중앙 Inspection VPC, 중앙 Egress, Ingress 앞단, 앞단·뒷단 이중 방화벽, Combined 구성, TGW-attached 구성을 공식 문서 기준으로 설명합니다.목차AWS Network Firewall 설계의 핵..

AWS Guides

AWS Control Tower 설계 기준 정리: Landing Zone, OU 구조, Control 정책, 초기 배포 방식

AWS Multi-Account GovernanceAWS Control Tower 설계 기준 정리: Landing Zone, OU 구조, Control 정책, 초기 배포 방식AWS Control Tower를 도입할 때 필요한 Landing Zone 구조, OU별 정책 차이, 초기 배포 방식, 보안 기준을 정리합니다.Landing ZoneOUControlsAccount FactoryAWS Control Tower는 멀티 계정 환경을 표준화하고 지속적으로 거버넌스를 적용하기 위한 서비스입니다. 이 글은 처음 설계할 때 확인해야 할 구조, 정책, 보안 설정, Terraform과 CloudFormation 기반 초기 배포 예시를 설명합니다.목차AWS Control Tower가 필요한 이유기본 설계 방식OU 구조..

AWS Guides

EKS에서 mTLS를 적용하는 방식: Service Mesh와 Gateway 기준

Kubernetes SecurityEKS에서 mTLS를 적용하는 방식: Service Mesh와 Gateway 기준EKS에서 mTLS가 어떤 문제를 해결하는지, Service Mesh와 Gateway 기준으로 어디에 적용하는지 간단히 정리합니다.mTLSEKSIstioGateway이 글은 EKS에서 mTLS를 이해할 때 필요한 TLS와 mTLS의 차이, Pod 간 통신 보호, Ingress Gateway의 클라이언트 인증, 인증서 관리, 운영 주의점을 공식 문서 기준으로 설명합니다.목차mTLS란 무엇인가EKS에서 mTLS가 직접 기능이 아닌 이유Service Mesh에서 Pod 간 통신을 보호하는 방식Istio에서 STRICT와 PERMISSIVE를 구분하는 이유Gateway에서 외부 클라이언트를 인증하는..

AWS Guides

AWS Load Balancer Controller Deep Dive: EKS에서 ALB와 NLB가 생성되는 원리

EKS NetworkingAWS Load Balancer Controller Deep Dive: EKS에서 ALB와 NLB가 생성되는 원리AWS Load Balancer Controller가 EKS 리소스를 감시해 ALB, NLB, TargetGroupBinding을 만드는 흐름을 개념적으로 정리합니다.ALBNLBTargetGroupBindingReconcile이 글은 EKS에서 AWS Load Balancer Controller를 사용할 때 Ingress, Service, IngressClass, loadBalancerClass, TargetGroupBinding이 어떻게 연결되는지 설명합니다.목차AWS Load Balancer Controller란 무엇인가EKS에서 LB Controller를 사용할 ..

EKS Pod IP 할당이 안 될 때 서브넷 여유 IP·ENI·Prefix Delegation 점검하기

2026. 9. 9. 17:05

AWS EKS · 네트워크 오류 해결

EKS Pod IP 할당이 안 될 때
서브넷 여유 IP·ENI·Prefix Delegation 점검하기

Pod 이벤트에서 실패 단계를 구분한 뒤 실제 Pod 서브넷, 노드 한도, Prefix 공간과 CNI 권한을 확인하세요.

VPC CNI 진단조회 명령증상별 판단표2026.09.09 확인

EKS Pod IP 할당 실패를 Pod 이벤트부터 서브넷 여유 IP, ENI 한도, Prefix Delegation 순서로 점검합니다. InsufficientCidrBlocks, Warm Pool, CNI 권한 오류를 구분하는 조회 명령과 진단표를 확인하세요.

Pod IP 할당 실패인지 먼저 확인하기

EKS에서 Pod가 생성되지 않는다면 먼저 노드에 배치됐는지 확인하세요. 배치 전 FailedScheduling과 배치 후 네트워크 준비 실패는 진단 대상이 다릅니다. IP 할당 관련 메시지가 확인되면 실제 Pod용 서브넷의 주소, 노드 한도, Prefix 공간, CNI의 AWS API 호출 상태를 순서대로 좁혀갑니다.

이 글은 Amazon VPC CNI를 사용하는 일반 EKS EC2 Linux·IPv4 환경을 대상으로 합니다. Fargate, Auto Mode, Windows, IPv6 및 Calico 네트워킹 교체 환경에는 아래 명령과 판단을 그대로 적용하지 않습니다. Security Groups for Pods와 다중 인터페이스 사용 시에는 추가 인터페이스 구조도 확인해야 합니다.

ContainerCreating은 kubectl이 보여주는 상태이며 이것만으로 IP 부족을 뜻하지 않습니다. FailedCreatePodSandBox도 여러 원인으로 발생하므로 이벤트 본문에서 IP 할당 관련 오류를 확인해야 합니다. Kubernetes Pod 상태와 이벤트 진단

공식 문서 확인일은 2026년 9월 9일입니다. 아래는 Bash 계열 셸에서 사용하는 진단용 조회 명령 예시입니다. kubectl context와 AWS CLI 계정·리전을 먼저 맞추고 읽기 권한을 준비하세요. YOUR_로 시작하는 값은 자신의 확인 대상 값으로 교체합니다. PowerShell에서는 특히 JSONPath 인용부호 처리를 사용하는 버전에 맞춰 조정해야 합니다.

관찰	확인 대상
노드 미배치 + FailedScheduling	자원·taint·Pod 수 제한
노드 배치 + IP 할당 오류	해당 노드 CNI와 Pod 서브넷
IP 존재 + 통신 실패	DNS·경로·정책·보안 그룹

kubectl config current-context kubectl get pod YOUR_POD -n YOUR_NAMESPACE -o wide kubectl describe pod YOUR_POD -n YOUR_NAMESPACE kubectl get events -n YOUR_NAMESPACE --field-selector involvedObject.name=YOUR_POD --sort-by=.metadata.creationTimestamp

VPC CNI가 Pod IP를 할당하는 구조

기본 VPC CNI 구성에서는 노드에 연결한 ENI의 VPC 주소를 Pod에 사용합니다. 개별 보조 IP 모드와 Prefix 모드는 주소를 확보하는 단위가 다릅니다.

서브넷 주소 공간 → 노드 ENI → 개별 보조 IP 또는 Prefix → Pod IP. 이 흐름에서 ipamd가 주소 풀을 관리합니다. 이 구조는 기본 단일 인터페이스 구성의 이해를 위한 요약입니다. Amazon VPC CNI 주소 관리

서브넷이 충분해도 노드 한도에 걸릴 수 있고, Prefix 공간이 있어도 API 호출이 실패할 수 있습니다. 어느 단계가 막혔는지 나누어야 같은 Pending 상태에서도 맞는 조치를 선택할 수 있습니다.

첫 점검: 해당 노드의 aws-node와 로그 확인

문제 Pod의 NODE 값을 확인한 뒤 같은 노드에서 실행되는 aws-node를 찾습니다. 클러스터 전체 로그보다 장애 노드와 발생 시점을 맞추어 확인하세요. YOUR_AWS_NODE_POD는 첫 조회 결과의 Pod 이름으로 교체합니다.

describe 결과에서 이미지 버전, Ready 상태, 재시작과 환경변수를 확인합니다. --previous는 컨테이너가 재시작했고 이전 로그가 남아 있을 때만 사용할 수 있습니다.

kubectl logs에 IPAM 로그가 모두 나오는 것은 아닙니다. AWS_VPC_K8S_CNI_LOG_FILE이 파일 출력이면 설정된 수집 경로나 노드의 /var/log/aws-routed-eni/ipamd.log를 확인하세요. 컨테이너 내부 기본 경로는 /host/var/log/aws-routed-eni/ipamd.log입니다. IPAM 로그 저장 위치

조회 결과를 공유할 때는 계정·리소스 식별자를 제거하세요. 이 글은 실제 운영 로그를 사용하지 않습니다.

kubectl get pods -n kube-system -l k8s-app=aws-node --field-selector spec.nodeName=YOUR_NODE -o wide kubectl describe pod YOUR_AWS_NODE_POD -n kube-system kubectl logs YOUR_AWS_NODE_POD -n kube-system -c aws-node --since=30m --tail=200 kubectl logs YOUR_AWS_NODE_POD -n kube-system -c aws-node --previous --tail=200 kubectl describe daemonset aws-node -n kube-system

서브넷에 사용할 IP가 충분한가?

노드의 providerID에서 EC2 인스턴스를 식별하고 연결 ENI의 서브넷을 조회하세요. custom networking을 사용하면 Pod용 ENI가 노드의 기본 서브넷과 다른 서브넷에 있을 수 있습니다.

custom networking은 ENIConfig로 Pod용 서브넷 등을 지정합니다. 기능이 켜져 있다면 ENIConfig와 노드의 연결 설정도 대조하세요. ENIConfig 리소스 종류를 찾지 못하면 기능 사용 여부부터 확인합니다. Pod용 서브넷 선택

AvailableIpAddressCount는 사용할 수 있는 IPv4 주소 개수이며 연속된 /28 블록 수가 아닙니다. ENI나 Prefix로 이미 확보한 주소는 Pod에 배정하기 전이어도 서브넷의 가용 주소와 별도로 봐야 합니다. 서브넷 조회 필드

ENI 결과의 Subnet을 YOUR_SUBNET_ID로 넣어 각각 조회합니다. Prefix 목록과 개별 IP 배열도 구분하세요. ENI 조회 필터와 Prefix 필드

kubectl get node YOUR_NODE -o jsonpath='{.spec.providerID}' aws ec2 describe-network-interfaces --region YOUR_REGION --filters "Name=attachment.instance-id,Values=YOUR_INSTANCE_ID" --query 'NetworkInterfaces[].{ENI:NetworkInterfaceId,Subnet:SubnetId,Device:Attachment.DeviceIndex,PrivateIPCount:length(PrivateIpAddresses),Prefixes:Ipv4Prefixes}' --output json aws ec2 describe-subnets --region YOUR_REGION --subnet-ids YOUR_SUBNET_ID --query 'Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,AvailableIPv4:AvailableIpAddressCount}' --output table kubectl get eniconfigs.crd.k8s.amazonaws.com -o yaml kubectl describe node YOUR_NODE

ENI·주소 한도와 maxPods 구분하기

Too many pods가 나오면 스케줄러가 보는 Pod 수 한도를 확인합니다. 반면 노드 배치 후 IP 할당 실패는 주소 확보 경로를 확인해야 합니다. CPU·메모리 부족으로 인한 배치 실패도 별도 원인입니다.

YOUR_INSTANCE_TYPE은 노드 조회 결과의 유형으로 교체하세요. AWS 조회는 유형의 기본 네트워크 한도를 보여줍니다. 실제 ENI와 Prefix는 앞 절 결과와 대조합니다. PrivateIpAddresses 배열 길이가 Prefix 안의 모든 Pod 주소를 포함한다고 가정하면 안 됩니다.

Prefix 모드는 주소 슬롯 사용 방식을 바꾸며 ENI 최대 수 자체를 늘리지는 않습니다. 관리형 노드 그룹의 AMI 지정 여부 등에 따라 maxPods 설정 방법이 다릅니다. 임의로 숫자만 높이지 말고 allocatable 값과 지원 조건을 확인하세요. Prefix와 최대 Pod 수 설정

노드 추가는 서브넷에 충분한 주소가 있는지 확인한 뒤 선택해야 합니다. 주소가 부족한 같은 서브넷에 노드를 더 만들면 해결이 되지 않을 수 있습니다.

kubectl get node YOUR_NODE -L node.kubernetes.io/instance-type kubectl get node YOUR_NODE -o jsonpath='{.status.capacity.pods}{" / "}{.status.allocatable.pods}{"\n"}' kubectl get pods -A --field-selector spec.nodeName=YOUR_NODE -o wide aws ec2 describe-instance-types --region YOUR_REGION --instance-types YOUR_INSTANCE_TYPE --query 'InstanceTypes[].{Type:InstanceType,MaxENI:NetworkInfo.MaximumNetworkInterfaces,IPv4PerENI:NetworkInfo.Ipv4AddressesPerInterface}' --output table

Prefix Delegation을 켰는데도 실패하는 이유

IPv4 Prefix 할당에는 연속된 /28 공간이 필요합니다. 가상의 서브넷에 40개 여유 IP가 있어도 주소가 흩어져 있다면 필요한 블록을 확보하지 못할 수 있습니다. 이 숫자는 원리를 설명하기 위한 가정입니다.

InsufficientCidrBlocks가 보이면 연속 공간 부족을 검토하세요. 새 서브넷이나 Prefix용 CIDR 예약이 선택지입니다. 예약은 기존 사용 중 주소를 즉시 이동시켜 빈 블록을 만드는 기능은 아닙니다. Prefix 전제와 주소 단편화

Linux IPv4 Prefix는 VPC CNI 1.9.0 이상, Nitro 기반 노드 등의 조건을 확인해야 합니다. 최소 기능 버전이 현재 클러스터의 권장 버전을 의미하지는 않습니다. ENABLE_PREFIX_DELEGATION 설정과 실제 노드 조건을 함께 확인하세요.

아래 set env 명령은 --list를 붙인 조회입니다. 값 할당을 추가하지 말고 조회용으로 사용하세요. 실제 Pod 환경변수는 describe pod 결과와도 비교합니다.

kubectl set env daemonset/aws-node -n kube-system --list aws ec2 get-subnet-cidr-reservations --region YOUR_REGION --subnet-id YOUR_SUBNET_ID --output json

Warm Pool 설정이 IP 사용량에 미치는 영향

CNI는 새 Pod를 위해 여유 주소를 준비하므로 실행 중 Pod 수와 확보 주소 수가 다를 수 있습니다. 노드당 평상시 Pod 수와 한 번에 늘어나는 Pod 수를 함께 보고 조정하는 것이 좋습니다.

Prefix 모드에서는 WARM_IP_TARGET 또는 MINIMUM_IP_TARGET을 지정하면 WARM_PREFIX_TARGET보다 우선합니다. 확보 단위 때문에 실제 여유 주소가 IP 목표와 딱 맞지는 않을 수 있습니다. Prefix Warm Pool 설정

MINIMUM_IP_TARGET은 전체 확보 주소의 하한입니다. 이를 지정하고 WARM_IP_TARGET을 생략하면 추가 할당에 영향을 줄 수 있으므로 버전별 안내를 확인하세요. 최소 확보 주소 설정

큰 여유 값은 서브넷 소모를 늘리고 너무 작은 값은 급격한 확장 때 추가 요청을 늘릴 수 있습니다. 정답 숫자를 고정하기보다 실제 Pod 증가량과 API 오류·주소 사용량으로 판단하세요.

설정	의미
WARM_PREFIX_TARGET	미사용 Prefix 여유 목표
WARM_IP_TARGET	즉시 배정 가능한 여유 IP 목표
MINIMUM_IP_TARGET	전체 확보 IP의 하한 목표

IP 여유가 있어도 실패할 때: 권한·API·CNI 상태

같은 시각의 CNI 로그에서 UnauthorizedOperation·AccessDenied는 권한 경로, throttling·RequestLimitExceeded는 호출 제한, timeout은 DNS·연결 경로 등을 점검하는 단서입니다. 한 줄만으로 원인을 확정하지는 않습니다.

CNI의 IAM 역할은 애플리케이션이나 조회 명령 실행자의 역할과 다를 수 있습니다. IRSA·Pod Identity·노드 역할 중 실제 사용 방식을 확인하세요. 관리형 Add-on이 없다는 조회 오류가 나더라도 자체 관리 방식의 aws-node가 설치되어 있을 수 있습니다.

인터넷 접근을 제한한 환경에서는 EC2 API를 위한 Endpoint·보안 그룹·DNS를 확인합니다. 자격증명 방식에 따라 STS 또는 EKS Auth 접근도 필요할 수 있습니다. Private EKS 서비스별 Endpoint

aws-node 자체가 Ready가 아니면 이미지 다운로드·초기화 이벤트부터 확인하세요. 주소가 충분해도 CNI가 정상 기동하지 않으면 주소 할당이 진행되지 않을 수 있습니다.

Pod Identity 연결 목록에는 실제 IAM 역할이 생략됩니다. 연결이 있으면 associationId를 YOUR_ASSOCIATION_ID로 바꿔 상세 조회하세요. Pod Identity 연결 조회의 반환 범위

aws eks describe-addon --region YOUR_REGION --cluster-name YOUR_CLUSTER --addon-name vpc-cni --output json kubectl get serviceaccount aws-node -n kube-system -o yaml aws eks list-pod-identity-associations --region YOUR_REGION --cluster-name YOUR_CLUSTER --namespace kube-system --service-account aws-node --output json kubectl get daemonset aws-node -n kube-system aws eks describe-pod-identity-association --region YOUR_REGION --cluster-name YOUR_CLUSTER --association-id YOUR_ASSOCIATION_ID --output json

증상별 진단표와 조치 선택

아래 표는 관찰값을 연결하는 진단 제안입니다. 변경 전 오류 시각, 노드·서브넷, CNI 설정과 한도를 기록하세요. 재시작만으로 주소 고갈·단편화·권한 부족이 해결된다고 가정하지 마세요.

Prefix 전환은 새 노드 그룹을 준비해 검증하는 방안을 비교하세요. AWS도 새 노드 그룹과 기존 워크로드의 안전한 이동을 권장합니다. Prefix 전환 시 노드 교체

변경 후 새 Pod가 IP를 받고 Ready가 되는지 확인합니다. 이어서 필요한 DNS·서비스·외부 연결을 점검하세요. IP 확보와 애플리케이션 통신은 별도의 완료 조건입니다.

증상	다음 확인	조치 방향
FailedScheduling / Too many pods	allocatable·배치된 Pod 수	노드 용량·maxPods 설계
Pod용 서브넷 가용 IP 부족	실제 ENI 서브넷·여유 풀	주소 공간·Pod 배치 검토
InsufficientCidrBlocks	연속 /28 공간·예약	새 서브넷·Prefix 공간 계획
노드 ENI·주소 한도 도달	유형 한도·실제 확보 상태	Prefix·노드 설계 검토
UnauthorizedOperation / AccessDenied	CNI 역할·실패 API	필요한 권한 확인·수정
API 제한·timeout	호출량·Endpoint·DNS	호출·연결 원인 해소
IP 확보 후 통신 실패	DNS·경로·정책	통신 진단으로 전환

재발 방지와 다른 네트워크 구성의 검토 시점

서브넷별 가용 주소, 노드별 Pod 증가량, CNI 주소 할당 오류를 같은 시간축으로 보세요. 총 여유 IP 알람만으로 단편화를 탐지할 수 없으므로 Prefix 할당 오류도 함께 관찰하는 것을 권합니다.

여유 기준에는 배포 시 추가 복제본, 노드 교체와 자동 확장의 동시 용량을 포함하세요. 피크 수치를 확인하지 않고 절감률이나 권장 여유량을 고정하지 않는 것이 좋습니다.

IPv4 주소 계획 자체가 제약이라면 custom networking과 IPv6를 비교할 수 있습니다. CNI 교체 전에 기존 구성의 주소 설계 대안을 검토하세요. 주소 부족 시 custom networking 검토

Calico 정책만 추가하면 Pod 주소 할당 방식은 바뀌지 않습니다. 최근 Calico 도입 판단 글이 도구 선택을 다룬다면, 이번 글은 VPC CNI를 유지한 상태에서 장애 원인을 좁히는 데 집중합니다.

핵심 요약

단계

노드 미배치와 배치 후 IP 할당 실패를 먼저 나눕니다.

주소

실제 Pod용 서브넷과 노드의 ENI·Prefix를 함께 확인합니다.

Prefix

여유 IP 총량은 연속된 /28 공간을 보장하지 않습니다.

완료

새 Pod의 IP 확보와 필요한 통신을 각각 확인합니다.

FAQ

Pending이면 서브넷 IP 부족인가요?

아닙니다. 노드 배치 여부와 이벤트를 먼저 확인해야 합니다. 자원, taint, Pod 수 제한 또는 배치 후 초기화 문제일 수 있습니다.

Prefix Delegation을 켜면 서브넷 주소가 늘어나나요?

아닙니다. ENI에 주소를 확보하는 단위가 바뀝니다. 주소 공간을 늘리려면 별도 서브넷·CIDR 등 주소 설계가 필요합니다.

여유 IP가 많은데 InsufficientCidrBlocks가 나오는 이유는 무엇인가요?

IPv4 Prefix에 필요한 연속된 /28 공간이 없을 수 있습니다. 가용 주소 개수와 주소 블록의 연속성을 구분하세요.

aws-node 로그가 조용하면 CNI는 정상인가요?

그렇게 단정할 수 없습니다. IPAM 로그의 저장 위치를 확인하세요. 파일 출력으로 설정되어 있으면 kubectl logs에 해당 내용이 나오지 않을 수 있습니다.

CONCLUSION

Pod 이벤트에서 시작해 실제 Pod용 서브넷과 노드의 주소 확보 상태로 원인을 좁혀가세요. Prefix 공간과 권한·API 문제까지 확인하면 불필요한 CNI 교체나 노드 추가를 줄일 수 있습니다. 변경은 관찰한 원인에 맞춰 선택하고 새 Pod의 IP 확보와 통신까지 확인하세요.

...

Trace allocation failures from the Pod to the subnet and node.

EKS Pod IP 할당 실패 시 서브넷 여유 IP, ENI 한도, Prefix 연속 공간을 점검

저작자표시 동일조건 (새창열림)

'AWS Guides' 카테고리의 다른 글

EKS에서 Calico가 필요한 경우: VPC CNI 정책 기능과 CNI 교체 판단 기준 (0)	2026.09.09
AWS LiteLLM과 Amazon Bedrock 연동 구조: IAM 인증·배포·비용 관리 (0)	2026.09.06
AWS Network Firewall 구성 방식 총정리 단일 NFW 중앙 Inspection VPC 이중 방화벽 설계 비교 (0)	2026.09.03
AWS Control Tower 설계 기준 정리: Landing Zone, OU 구조, Control 정책, 초기 배포 방식 (0)	2026.09.03
EKS에서 mTLS를 적용하는 방식: Service Mesh와 Gateway 기준 (0)	2026.09.03

EKS에서 Calico가 필요한 경우: VPC CNI 정책 기능과 CNI 교체 판단 기준

2026. 9. 9. 17:04

AWS EKS · 네트워크 선택 기준

EKS에서 Calico가 필요한 경우
VPC CNI 정책 기능과 CNI 교체 판단 기준

기본 통신 제어는 VPC CNI부터 검토하세요. Calico 정책이 필요한지, Pod 네트워크 자체를 바꿔야 하는지 나누면 도입 범위를 정하기 쉽습니다.

VPC CNICalico 도입 판단구성 비교2026.09.09 확인

EKS에서 Calico가 필요한 상황을 VPC CNI 유지, Calico 정책 추가, CNI 교체로 나눠 비교합니다. NetworkPolicy 지원 조건과 Pod IP 부족 대안, AWS 지원 범위 및 운영 전환 점검 기준을 확인하세요.

EKS에서 Calico가 꼭 필요할까? 먼저 보는 선택 기준

일반적인 EKS EC2 환경에서 Calico는 필수 구성 요소가 아닙니다. 필요한 통신 제어를 VPC CNI 정책으로 구현할 수 있다면 이를 우선 검토하고, 기존 Calico 정책 활용이나 별도 Pod 주소 공간이 필요한 경우에 도입 범위를 넓히는 것이 이 글의 권장 순서입니다.

이 글은 EKS 도입·운영 담당자가 네트워크 도구를 선택하는 데 필요한 판단 기준을 다룹니다. 설치 완료를 보여주는 실습이 아니라 구성 선택과 검증 계획을 위한 초안이며, 공식 문서 확인일은 2026년 9월 9일입니다. Calico의 기본 개념을 반복하기보다 EKS에서 달라지는 지원 조건과 운영 부담에 집중합니다.

선택	우선 검토할 상황	바뀌는 범위
VPC CNI 유지	기본 통신 제어와 AWS 연동 중심	기존 네트워크에 정책 설정
Calico 정책 추가	Calico 정책 API·운영 체계 활용	정책 엔진
Calico 네트워킹 사용	VPC와 분리된 Pod 주소 설계 필요	IP 할당·통신 경로·정책

VPC CNI와 Calico의 역할: 정책 추가와 네트워킹 교체

CNI는 Pod가 네트워크에 연결되는 구성을 담당하고, IPAM은 사용할 IP 주소를 관리합니다. 정책 엔진은 그 통신을 허용하거나 차단합니다. Calico를 설치했다는 사실만으로 이 세 역할이 모두 Calico로 바뀌었다고 판단할 수 없습니다.

VPC CNI와 Calico 정책을 함께 쓰면 Pod 주소 할당과 VPC 연결은 AWS 구성을 유지합니다. Calico 네트워킹을 선택하면 별도 IPAM과 오버레이를 사용하는 구성이 가능합니다. 아래 비교도는 역할 구분을 위한 개념도이며 패킷이 처리되는 정확한 순서를 나타내지는 않습니다. Calico EKS 구성 안내

기본 정책 개념은 Calico NetworkPolicy와 네트워크 보안 구조에서 확인하세요. 이번 글에서는 해당 개념을 EKS 구성 선택에 적용합니다.

세 가지 구성 비교: IP 할당과 정책 담당

① VPC CNI 유지

Pod

VPC CNI
VPC IP 할당·연결

VPC CNI 정책
필요한 통신 제어

② Calico 정책 추가

Pod

VPC CNI
VPC IP 할당·연결

Calico 정책
VPC CNI 정책 기능 비활성화

③ Calico 네트워킹

Pod

Calico IPAM·네트워킹
별도 Pod IP·오버레이

Calico 정책
외부 접근 경로 별도 검토

역할 구분을 위한 개념도입니다. ②는 VPC IP 사용량을 줄이지 않으며, ③도 노드 등 VPC 리소스의 IP 사용은 남습니다.

VPC CNI의 NetworkPolicy로 충분한 경우

가상의 예약 서비스에서 프런트엔드는 예약 API에만 접근하고, 다른 업무의 Pod는 API에 접근하지 못하게 하려는 요구를 생각해 보세요. 필요한 제어가 Pod·네임스페이스 선택과 IP·포트 범위에 해당한다면 표준 NetworkPolicy를 먼저 검토할 수 있습니다.

현재 AWS 문서에는 표준 NetworkPolicy뿐 아니라 클러스터 범위의 ClusterNetworkPolicy도 안내되어 있습니다. 따라서 중앙 정책이나 클러스터 전체 차단이 필요하다는 이유만으로 Calico가 유일한 선택이라고 볼 수 없습니다. AWS의 ClusterNetworkPolicy는 networking.k8s.aws API를 사용하므로 표준 NetworkPolicy와 이식성도 구분하세요.

확인한 AWS 문서는 표준·관리자 정책을 함께 사용하는 조건으로 VPC CNI 1.21.0 이상을 제시합니다. 이는 표준 NetworkPolicy가 해당 버전에서 처음 등장했다는 뜻이 아닙니다. EC2 Linux 노드 등 적용 조건과 설치 버전의 기능을 함께 확인하세요. VPC CNI 정책 종류와 지원 조건

정책 객체를 생성하는 것과 정책 엔진을 활성화하는 것은 다릅니다. 또한 시작 시 기본 허용하는 standard 모드와 기본 차단하는 strict 모드의 차이를 검토해야 합니다. strict 모드는 DNS 등 필수 통신을 허용하는 준비가 필요합니다. VPC CNI 정책 활성화와 시작 모드

VPC CNI를 유지하면서 Calico 정책을 추가하는 경우

이미 온프레미스에서 Calico 정책을 관리하고 있고 EKS에서도 같은 정책 API와 검토 절차를 유지하려는 팀이라면 정책만 추가하는 방식을 검토할 수 있습니다. 이것은 도입 판단 예시이며 서로 다른 환경에서 정책 파일이 수정 없이 동작한다는 보장은 아닙니다.

Calico의 GlobalNetworkPolicy는 네임스페이스에 한정되지 않는 정책 리소스이며 order, selector, Allow·Deny 등의 필드로 동작을 정의합니다. 필요한 필드를 현재 VPC CNI 기능과 항목별로 비교하세요. 이름이 비슷한 정책도 평가 순서와 적용 대상이 같다고 가정하지 않는 것이 좋습니다. Calico GlobalNetworkPolicy 정의

도입 검토표에는 필요한 기능 이름, 오픈소스 또는 상용 제품 여부, 지원 버전, 담당자를 함께 기록하는 것을 권합니다. 특정 보안·관측 기능이 Calico 전체 제품에서 동일하게 제공된다고 가정하면 비용과 구현 범위를 잘못 산정할 수 있습니다.

Pod IP 부족 때문에 Calico로 교체해야 할까?

IP 부족은 서브넷에 주소가 없는 상황과 노드가 더 이상 Pod IP를 확보하지 못하는 상황을 나누어 보아야 합니다. 가령 서브넷에는 공간이 있지만 노드별 밀도에 막힌 상황과, 서브넷 주소 자체가 소진된 상황은 같은 해결책으로 다루기 어렵습니다.

Prefix Delegation은 ENI에 주소 묶음을 할당해 노드당 Pod 밀도를 높이는 방식입니다. IPv4에서는 연속된 /28 공간이 필요하므로 빈 주소 총량이 있어도 단편화로 실패할 수 있습니다. 서브넷의 전체 주소 공간을 늘리는 기능은 아닙니다. Prefix Delegation과 주소 단편화

custom networking은 Pod에 사용할 별도 서브넷과 주소 공간을 구성하는 VPC CNI의 선택지입니다. IPv4 부족이라면 이 방식과 IPv6 설계를 먼저 비교할 수 있습니다. AWS는 아직 IPv6를 사용할 수 없는 IPv4 부족 상황에서 custom networking을 검토하도록 안내합니다. custom networking 선택 기준

Calico 정책만 추가하면 IP 할당 방식은 그대로입니다. 별도 Pod 주소 대역을 통한 VPC 주소 소모 완화는 Calico 네트워킹을 선택할 때 검토할 수 있는 효과입니다. Calico 네트워킹 선택 기준

관찰한 문제	먼저 비교할 항목	판단 시 주의점
노드별 Pod 밀도 제한	Prefix Delegation·노드 설정	CPU·메모리와 maxPods도 확인
서브넷 주소 부족	주소 공간 추가·custom networking·IPv6	주소 계획과 외부 연결 영향 확인
VPC 주소와 Pod 주소 분리 필요	Calico 오버레이	클러스터 외부에서 Pod 접근 방식 변경
통신 차단 규칙만 필요	VPC CNI 정책 또는 Calico 정책	정책 추가는 IP 부족 해결책이 아님

Calico 네트워킹으로 교체하면 달라지는 통신 구조

Calico 오버레이를 선택하면 Pod 주소가 VPC에서 직접 라우팅되는 기존 구조와 달라집니다. 외부 서비스가 Pod IP를 직접 목적지로 쓰는지 먼저 조사하세요. 클러스터 밖에서 도달하지 못하는 주소를 로드밸런서 대상으로 등록하면 정상 연결을 기대하기 어렵습니다. AWS에서 Calico 오버레이를 선택할 때의 외부 접근 제한

Tigera의 EKS 안내는 제어 평면이 Calico Pod로 연결을 시작할 수 없는 제약을 설명합니다. Admission webhook처럼 제어 평면에서 접근해야 하는 구성은 별도 설계가 필요합니다. 문서의 hostNetwork 우회 방안도 신뢰 가능한 구성 요소에 대한 선택지이므로 일괄 적용하지 말고 노드 포트와 정책 경계를 검토하세요. Calico EKS 제어 평면 연결 주의사항

실무 검증에서는 로드밸런서 대상 유형과 헬스 체크, 외부 API로 나가는 NAT 경로, 반환 트래픽, DNS, MTU를 하나의 통신 목록으로 묶는 것을 권합니다. 짧은 요청뿐 아니라 큰 응답과 장시간 연결도 시험 항목에 포함하면 경로 변경의 영향을 확인하기 쉽습니다.

EKS 실행 환경과 AWS 지원 범위 확인하기

설치 가능한 구성과 AWS가 지원하는 구성은 구분해야 합니다. 아래는 확인일 기준 AWS 안내를 요약한 표입니다. 일반 EC2 노드에서 대체 CNI를 선택한다면 공급업체 지원 또는 내부 장애 대응 역량을 확보하는 것이 필요합니다. EKS 대체 CNI 지원 범위

실행 환경	확인한 지원 조건	도입 판단
일반 EC2 노드	AWS 지원 CNI는 VPC CNI, 호환 대체 CNI 설치 가능	Calico 장애 대응 주체를 별도 확보
Fargate	VPC CNI만 사용 가능	Calico CNI 교체 대상에서 제외
EKS Auto Mode	대체 CNI·네트워크 정책 플러그인 미지원	일반 EC2 구성의 절차를 적용하지 않음
Hybrid Nodes	Calico·Cilium 핵심 기능 별도 지원	일반 EC2와 구분해 해당 지원 범위 확인

정책 충돌과 적용 예외: 설치 전에 확인할 사항

Calico를 정책 엔진으로 선택할 때 VPC CNI의 정책 기능을 동시에 켜지 않도록 구성해야 합니다. Tigera는 두 정책 엔진의 충돌을 명시합니다. 같은 트래픽을 두 엔진이 관리하면 허용·차단 원인을 구분하기도 어려워집니다.

VPC CNI와 Calico 정책을 조합하는 설치 안내에는 ANNOTATE_POD_IP=true와 aws-node의 Pod patch 권한 요구가 있습니다. IPv6 Pod에서 ENABLE_V4_EGRESS=true인 경우의 Calico 정책 적용 제한도 확인해야 합니다. Calico 정책 구성의 권한·IPv6 조건

또한 AWS는 Pod에 보안 그룹이 연결된 경우 해당 트래픽이 Calico 정책 집행 대상에 포함되지 않는다고 안내합니다. Security Groups for Pods와 Calico를 조합할 때 모든 트래픽에 두 통제가 중첩된다고 가정하면 안 됩니다. Calico와 Pod 보안 그룹 주의사항

가상의 예약 서비스 검증에서는 허용된 프런트엔드 접근, 다른 업무 Pod의 차단, DNS 조회, 외부 결제 연동용 더미 API 접근을 각각 구분하는 것을 권합니다. 기대 결과를 먼저 적고 허용과 차단을 모두 확인해야 정책의 목적을 판단할 수 있습니다.

운영 전환 전에 검증할 통신과 복구 기준

아래 표는 신규 검증 환경에서 사용할 제안입니다. 실제 운영 전환 절차는 현재 설치 방식과 버전에 맞춰 별도로 작성해야 합니다. 특히 CNI 교체를 기존 aws-node 삭제 한 단계로 취급하지 마세요. 새 환경에서 경로를 확인한 뒤 워크로드를 옮기는 방안을 우선 비교하는 것이 좋습니다.

검증 결과에는 연결 성공 여부 외에도 지연, 오류율, 노드 자원 사용량과 정책 로그를 남기세요. 전환 전후의 요청 크기와 부하 조건을 맞춰야 성능 비교가 의미를 갖습니다. Calico 도입만으로 속도 향상이나 비용 절감을 단정할 수 없습니다.

검증 영역	시험 내용	완료 판단 예시
정책	허용·비허용 Pod에서 동일 목적지 접근	의도한 허용과 차단 모두 재현
운영 연결	DNS·웹훅·로드밸런서·외부 API	모든 필수 경로가 정상 동작
노드 수명주기	노드 추가·교체와 Pod 재생성	새 노드에서도 정책과 경로 유지
업그레이드	Kubernetes·CNI·운영자 버전 조합	지원 조건 및 회귀 점검 통과
복구	기존 환경으로 트래픽을 되돌리는 과정	담당자·시간 기준·중단 조건 명시
비용	추가 컴퓨팅·관측 저장·지원·운영 시간	실제 견적과 측정값으로 비교

최종 도입 판단표: 필요한 범위만 선택하기

도입 결정은 도구 이름보다 현재 해결하지 못하는 요구사항을 중심으로 내리는 것이 좋습니다. 아래 표는 앞서 확인한 기능과 지원 조건을 바탕으로 정리한 설계 제안입니다. 정책 요구와 주소 설계 요구가 함께 있으면 두 항목을 따로 평가하세요.

우리 팀의 요구	우선 검토할 선택	다음 확인
Pod·네임스페이스 간 기본 통신 통제	VPC CNI 정책	지원 환경·버전·필수 허용 규칙
중앙에서 클러스터 정책 관리	VPC CNI와 Calico 정책 기능 비교	필요한 API·평가 순서·이식성
기존 Calico 정책 운영 체계 활용	VPC CNI + Calico 정책	정책 충돌·적용 예외
VPC IP 부족 해결	VPC CNI 주소 설계 대안부터 비교	서브넷 고갈인지 노드 밀도인지 확인
Pod IP를 VPC와 분리	Calico 네트워킹 검토	외부 접근·웹훅·복구 경로
AWS 관리 범위 중심의 단순한 운영	VPC CNI 유지	기본 기능으로 요구 충족 가능한지 확인

핵심 요약

구분

Calico 정책 추가와 CNI 교체는 변경 범위가 다릅니다.

기능

VPC CNI도 정책을 지원하므로 필요한 API와 적용 조건을 비교합니다.

정책 엔진 변경만으로 VPC IP 부족이 해결되지는 않습니다.

운영

교체 전에는 외부 접근과 제어 평면 연결, 지원·복구 범위를 확인합니다.

FAQ

Calico를 설치하면 VPC CNI를 삭제해야 하나요?

정책만 추가하는 구성에서는 VPC CNI를 유지합니다. Calico 네트워킹을 사용하는 경우에만 별도 전환 설계를 검토합니다. 운영 클러스터에서 설치 모드를 확인하지 않고 aws-node를 삭제하지 마세요.

클러스터 전체 정책을 쓰려면 Calico가 필수인가요?

아닙니다. 현재 AWS 문서에도 ClusterNetworkPolicy가 안내되어 있습니다. 필요한 기능과 API, 설치 버전 및 지원 조건을 비교해 선택하세요.

Calico를 쓰면 Pod IP 부족과 성능 문제가 함께 해결되나요?

정책만 추가하면 주소 할당 방식은 바뀌지 않습니다. 오버레이는 주소 설계 대안이 될 수 있지만 성능은 경로·부하·노드 조건을 맞춰 측정해야 합니다.

Calico 오픈소스에는 운영 비용이 없나요?

라이선스 구매 여부와 별개로 추가 구성 요소의 자원, 관측 데이터 저장, 업그레이드·장애 대응 시간이 필요합니다. 상용 지원이나 기능을 선택하면 해당 견적도 포함하세요.

CONCLUSION

먼저 VPC CNI로 해결되지 않는 요구사항을 한 문장으로 적어보세요. Calico 정책이 필요하면 정책 추가를, 별도 Pod 주소 설계가 필요하면 네트워킹 변경을 검토하면 됩니다. 외부 통신과 복구 경로를 검증하고 운영 담당자가 지원 범위를 감당할 수 있을 때 도입을 결정하는 것이 좋습니다.

...

Choose the required policy and networking scope.

VPC CNI 유지, Calico 정책 추가, CNI 교체의 세 가지 선택

저작자표시 동일조건 (새창열림)

'AWS Guides' 카테고리의 다른 글

EKS Pod IP 할당이 안 될 때 서브넷 여유 IP·ENI·Prefix Delegation 점검하기 (0)	2026.09.09
AWS LiteLLM과 Amazon Bedrock 연동 구조: IAM 인증·배포·비용 관리 (0)	2026.09.06
AWS Network Firewall 구성 방식 총정리 단일 NFW 중앙 Inspection VPC 이중 방화벽 설계 비교 (0)	2026.09.03
AWS Control Tower 설계 기준 정리: Landing Zone, OU 구조, Control 정책, 초기 배포 방식 (0)	2026.09.03
EKS에서 mTLS를 적용하는 방식: Service Mesh와 Gateway 기준 (0)	2026.09.03

Codex·Claude Code·Google Antigravity 비교이용률·장점·요금과 결제 선택 가이드

2026. 9. 9. 17:02

AI 코딩 도구 · 선택과 비용

Codex·Claude Code·Google Antigravity 비교
이용률·장점·요금과 결제 선택 가이드

이미 쓰는 구독과 개발 환경부터 확인하고, 실제 작업의 검토 부담과 추가 비용으로 선택하세요.

업무용 이용률도구별 장점구독과 추가 과금2026.09.08 확인

Codex·Claude Code·Google Antigravity의 업무용 이용률, 장점, 무료·유료 요금과 추가 과금 조건을 비교합니다. 구독료와 API 비용의 차이, 해지 시 확인할 점을 정리해 개인 개발자와 팀의 선택을 돕습니다.

Codex·Claude Code·Google Antigravity, 어떤 도구를 선택할까

AI 코딩 도구를 처음 선택한다면 이미 보유한 구독과 익숙한 개발 환경부터 확인하세요. 그다음 실제로 반복하는 오류 수정이나 기능 추가 작업을 맡겨 보고, 결과를 검토하는 시간과 추가 비용을 비교하는 것이 좋습니다. 이용률이 높다는 이유만으로 자신의 프로젝트에도 가장 적합하다고 판단할 수는 없습니다.

이 글은 유료 도입을 고민하는 개인 개발자와 소규모 팀을 위한 선택 가이드입니다. 공식 문서 확인일은 2026년 9월 8일이며, 요금은 미국 달러 표시 기준입니다. 한국 계정의 원화 결제 금액·세금·할인 적용 여부는 확인하지 않았습니다. 기능 설명과 별도로 제시한 평가 방법은 작성자의 제안이며, 세 도구를 직접 실행해 성능을 측정한 후기는 아닙니다.

먼저 확인할 조건	검토할 후보	결정 전에 볼 항목
기존 ChatGPT 구독과 개발 작업을 함께 활용	Codex	현재 구독의 포함 범위와 남은 한도
터미널과 편집기를 오가며 코드 수정	Claude Code	기존 작업 흐름과 인증·과금 방식
Google 계정 기반의 에이전트 작업 환경	Google Antigravity	무료 한도, 개발 환경 연동과 구독 혜택

선택표의 의미

위 표는 처음 평가할 후보를 좁히는 제안입니다. 특정 작업을 한 도구만 할 수 있다는 뜻은 아닙니다. 공통 기능이 많으므로 실제 프로젝트에서 검토 가능한 결과가 나오는지 확인해야 합니다.

AI 코딩 도구 점유율 비교: 이용률 통계는 어떻게 읽어야 할까

JetBrains의 Developer Ecosystem Survey 2026에 따르면 업무용 이용률은 Claude Code 39%, Codex 16%, Google Antigravity 6%입니다. 조사 기간은 2026년 5~7월이며 전체 조사에는 전 세계 전문 개발자 15,000명 이상이 참여했습니다. JetBrains 업무용 이용률 조사

이 수치는 전체 시장의 매출이나 유료 구독자 비중이 아닙니다. 여러 도구를 함께 사용하는 상황을 배제한 점유율로 해석하거나, 세 수치를 합쳐 100%로 다시 계산하면 안 됩니다. 비교 대상 세 도구의 순서이며 시장 전체의 상위 3개 순위도 아닙니다.

조사에는 지역·고용 상태·프로그래밍 언어·JetBrains 제품 친숙도에 대한 통계 보정이 적용됐습니다. 다만 해당 문항의 정확한 유효 응답자 수와 복수 응답 설정은 이번 확인 범위에서 확인하지 못했습니다. Google 수치는 Gemini CLI가 아닌 Antigravity이며, 9월의 실시간 이용률을 뜻하지 않습니다.

도구	업무용 이용률	동일한 비교 조건
Claude Code	39%	2026년 5~7월 전문 개발자 조사
OpenAI Codex	16%	동일 조사
Google Antigravity	6%	동일 조사

Codex의 장점과 선택 전 확인할 점

Codex는 CLI와 IDE 확장, 웹 기반 작업 등 여러 환경에서 사용할 수 있습니다. 구독 방식에서는 클라우드 코드 리뷰 같은 연동도 제공되며, API 키 방식은 사용 가능한 기능 범위가 다릅니다. Codex 환경별 기능과 요금

선택 관점에서 볼 장점은 이미 쓰고 있는 ChatGPT 구독의 포함 기능을 개발 작업에도 활용할 수 있다는 점입니다. 추가 결제 전에 현재 계정으로 작은 수정 작업을 진행할 수 있는지 확인하면 도입 판단이 쉬워집니다.

예를 들어 코드 변경 요청에는 수정할 범위, 유지할 동작, 실행할 테스트를 함께 적어 보세요. 결과를 받을 때는 변경 파일과 실패한 검사, 직접 확인하지 못한 부분을 분리해 달라고 요청하는 편이 검토에 도움이 됩니다. 이는 이 글에서 제안하는 활용 방식이며 정확성이나 시간 절감을 실측한 결과는 아닙니다.

팀에서는 도구의 명령 실행 범위, 저장소 접근 권한과 검토 절차가 기존 개발 규칙에 맞는지 평가하세요. 요청이 완료됐다는 설명만으로 병합을 결정하지 말고 실제 변경 내용과 테스트 결과를 확인해야 합니다.

Claude Code의 장점과 선택 전 확인할 점

Claude Code는 코드베이스 읽기, 파일 수정, 명령 실행을 개발 도구와 연결하는 코딩 에이전트입니다. 터미널 외에도 IDE, 데스크톱 앱과 웹에서 사용할 수 있어 CLI 전용 도구로만 설명하면 범위가 좁아집니다. Claude Code 공식 기능 소개

터미널을 자주 사용하는 개발자라면 기존 명령 실행과 코드 탐색 흐름에 자연어 요청을 추가하는 방식부터 평가할 수 있습니다. 익숙한 편집기에서 변경 내용을 확인하고 필요한 부분만 직접 조정할 수 있는지가 중요한 선택 기준입니다.

비용 측면에서는 로그인 방식이 중요합니다. ANTHROPIC_API_KEY가 설정된 환경은 구독 대신 API 인증과 과금이 적용될 수 있습니다. 구독을 결제했다는 사실과 지금 실행 중인 세션이 구독 한도를 사용한다는 사실을 구분하세요. Claude Code 구독 연결과 API 과금 구분

이 글의 평가 예제에서는 오류 원인을 설명하는 능력뿐 아니라 수정 범위를 지키는지, 테스트 실패를 숨기지 않는지, 재요청 없이 검토할 수 있는 결과를 주는지를 함께 기록하도록 제안합니다.

Google Antigravity의 장점과 선택 전 확인할 점

Google Antigravity는 독립형 앱을 중심으로 에이전트 작업을 관리하며 IDE 확장도 제공합니다. Google의 2026년 8월 안내에는 VS Code, Visual Studio, JetBrains, Zed, Xcode 연동이 소개되어 있습니다. 일부 환경은 미리보기이므로 지원 버전과 조직 계정 사용 조건을 함께 확인해야 합니다. Antigravity 앱과 IDE 확장 안내

개발자가 평가할 지점은 작업을 맡기는 화면과 변경 내용을 직접 살펴보는 편집기가 얼마나 편리하게 연결되는가입니다. 독립형 앱으로 전체 작업을 관리하고 익숙한 IDE에서 세부 코드를 검토하는 방식을 선호한다면 후보에 넣을 수 있습니다.

이 글에서 비교하는 제품은 Google Antigravity입니다. Google은 별도로 Antigravity CLI도 소개하고 있으며 Gemini CLI 사용자에게 이전을 안내합니다. 예전 Gemini CLI의 요청 한도나 가격을 Antigravity 통계·요금에 그대로 적용하면 안 됩니다. Google 개발 도구 구분과 이전 안내

계정에서 선택할 수 있는 모델은 별도로 확인하세요. 이번 확인에서는 Antigravity 가격 소개와 상세 플랜 문서의 외부 모델 제공 설명이 일치하지 않아, 특정 외부 모델을 무료로 쓸 수 있다고 단정하지 않았습니다.

같은 개발 작업으로 비교하는 실전 선택 기준

비교 예제로 가상의 동아리 장비 대여 앱을 생각해 보겠습니다. 반납 날짜가 대여 날짜보다 빠른데도 신청이 저장되는 문제가 있다고 가정합니다. 세 도구에 같은 시작 코드와 요구사항을 제공하고 날짜 검증과 테스트를 추가하게 합니다. 실제 서비스나 고객 정보를 사용하지 않는 새 더미 상황이며 이 예제를 실행해 얻은 측정값은 없습니다.

공통 요청은 다음처럼 작성할 수 있습니다. ‘날짜 검증 오류를 재현하고 필요한 부분만 수정해 주세요. 기존 정상 신청은 유지하고, 반납일이 빠른 경우와 날짜가 비어 있는 경우를 확인해 주세요. 실행한 테스트와 실행하지 못한 검사를 구분해 설명해 주세요.’ 프로젝트별 테스트 명령과 동작 조건은 자신의 환경에 맞춰 바꿔야 합니다.

각 도구는 같은 코드 상태에서 새 작업을 시작하고 같은 시간·비용 예산을 적용하세요. 선택 모델, 버전, 실행 권한도 기록합니다. 제공 모델이 서로 다르면 같은 모델의 성능 실험이 아니라 각 제품 구성을 비교한 결과로 표시해야 합니다.

최초 답변 속도보다 검토 가능한 수정이 나오기까지의 전체 시간을 보세요. 빠르게 답해도 누락과 재수정이 많으면 실제 작업 비용은 커질 수 있습니다.

평가 항목	기록할 내용
오류 재현	기존 코드에서 문제가 나타나는 조건을 확인했는가
수정 정확성	잘못된 신청을 막고 정상 신청을 유지했는가
변경 범위	관계없는 파일과 기능까지 바꾸지 않았는가
검증 근거	실제 실행 결과와 미실행 항목을 구분했는가
검토 부담	사람이 읽고 수정한 시간과 추가 요청 횟수
비용	사용량 변화, 별도 과금과 작업 완료 수

무료·유료 요금제 비교: 결제하면 무엇이 달라질까

아래는 개인용 중심의 미국 달러 비교표입니다. 월간 결제와 연간 선결제를 구분했으며, 무료 체험 가격은 일반 요금에 섞지 않았습니다. 한국 결제 화면의 통화·세금·할인이 반영된 청구액은 별도 확인해야 합니다.

Codex 가격은 OpenAI 공식 가격 안내, Claude 가격은 Claude 개인 요금제 안내를 기준으로 정리했습니다. Claude Code는 유료 플랜에 포함되며 무료 Claude 채팅과 같은 조건으로 이해하면 안 됩니다. Claude Code 포함 범위

Antigravity 무료 플랜은 공식 가격 안내, Google AI Pro의 미국 월 요금은 2026년 8월 Google 공식 안내의 갱신 가격, Ultra는 2026년 5월 Google 공식 요금 개편에서 확인했습니다. Google One 가격 페이지에서 금액이 추출되지 않아 날짜가 명시된 공식 안내로 보완했습니다.

같은 5배·20배라는 이름도 회사마다 기준이 다릅니다. 가격이 같거나 배수가 같다고 실제 작업 횟수까지 같아지는 것은 아닙니다. 자주 쓰는 작업이 어느 한도에서 막히는지를 기록한 뒤 상위 구독의 필요성을 판단하세요.

도구·구독	미국 달러 가격	결제와 선택 기준
Codex · ChatGPT Free / Go	무료 / 월 $8	가벼운 작업부터 평가
Codex · ChatGPT Plus	월 $20	현재 구독 포함 범위 확인
Codex · ChatGPT Pro	월 $100 / $200	5배 / 20배 한도 옵션, 무제한 작업 아님
Claude Code · Pro	월 $20 또는 연 $200	연간은 $200 선결제, 월 환산 약 $16.67
Claude Code · Max	월 $100 / $200	5배 / 20배 옵션, 월간 구독
Antigravity · Individual	무료	기본 주간 한도
Antigravity · Google AI Pro	월 $19.99	미국 공식 갱신 가격 기준
Antigravity · Google AI Ultra	월 $100 / $200	2026년 5월 공식 발표 가격 기준

구독료와 API 비용은 어떻게 다를까

구독은 정해진 기간에 포함된 기능과 사용 범위를 구매하는 방식입니다. API 사용량 과금은 실제 요청에서 소비한 사용량에 따라 비용이 달라지는 방식입니다. 유료 구독을 보유했다고 개발 환경의 모든 API 호출이 포함되는 것은 아닙니다.

Codex의 API 키 사용은 API 요금을 따릅니다. Plus·Pro의 포함 한도를 넘긴 뒤 추가 크레딧을 구매하는 경로도 있습니다. Codex 추가 사용과 API 결제

Claude의 구독 사용과 Console의 API 비용은 분리됩니다. API 크레딧 자동 충전을 켜 둔 경우 잔액이 낮아질 때 추가 구매가 발생할 수 있습니다. Claude 구독·Console 결제 구분

Antigravity는 Pro·Ultra에서 기본 한도를 넘긴 사용에 AI 크레딧을 사용할 수 있습니다. AI Credit Overages의 Never는 자동 크레딧 사용을 막고, Always는 기본 한도 소진 후 크레딧을 사용하도록 하는 설정입니다. Antigravity 초과 사용 설정

예산은 ‘구독 고정비 + 추가 사용료 + 별도 API 비용 + 필요한 실행 환경 비용’으로 나누어 기록하면 됩니다. 같은 사용분을 추가 크레딧 비용과 API 비용에 중복 계산하지 않도록 청구 경로별로 정리하세요. 사람의 검토 시간은 현금 청구액과 별도 지표로 기록하는 것이 비교하기 쉽습니다.

직접 만든 계산 예시

가상의 월 구독료 $20에 별도 사용료 $12가 발생했다면 세금·환전 수수료를 제외한 합계는 $32입니다. 이는 계산 방식 예시이며 세 서비스의 평균 비용이나 예상 청구액이 아닙니다.

결제 전 확인할 사용 한도·추가 과금·해지 조건

결제 직전에는 결제 주기, 첫 청구 금액, 다음 갱신일, 추가 크레딧 사용 여부를 확인하세요. 월 환산 가격으로 표시된 연간 구독은 매달 그 금액만 결제하는 방식과 다릅니다. 체험 할인도 종료 후 요금과 함께 비교해야 합니다.

Claude는 해지 후 현재 결제 기간까지 이용할 수 있으며 다음 결제를 피하려면 갱신 최소 24시간 전에 취소하도록 안내합니다. 일반적으로 환불은 제한되지만 예외가 있고, 앱스토어 결제는 처리 경로가 달라집니다. Claude 해지·환불 안내

Google One은 구독 취소와 환불을 별도로 안내하며 국가·구매 경로에 따라 조건이 달라집니다. AI 크레딧 자동 충전도 별도 설정이므로 확인해야 합니다. Antigravity의 ‘보유 크레딧 사용’과 Google One의 ‘새 크레딧 자동 구매’는 다른 동작입니다. Google One 구독 취소와 환불 · AI 크레딧 자동 충전 관리

Codex를 이용하는 ChatGPT 구독의 해지·환불 세부 조건은 이번에 확인한 공식 가격 문서만으로 확정하지 못했습니다. 따라서 다른 서비스의 취소 기한을 동일하게 적용하지 않았습니다. 결제한 계정의 구독 관리 화면에서 다음 청구일·취소 적용 시점·환불 안내를 확인해야 합니다.

요청 횟수만으로 세 서비스의 한도를 비교하기도 어렵습니다. 모델과 작업 복잡도에 따라 소비가 달라지므로 남은 한도, 갱신 시각과 실제 작업 결과를 함께 기록하세요.

확인할 항목	독자가 확인할 질문
결제 단위	월간 청구인가, 연간 선결제인가
실제 금액	표시 통화, 세금과 할인 종료 후 금액은 무엇인가
초과 사용	한도 이후 멈추는가, 보유 크레딧을 사용하는가
자동 충전	잔액 부족 시 새 결제가 발생하도록 설정했는가
해지	취소 적용일과 다음 갱신일을 확인했는가
환불	결제 경로와 거주 지역에 적용되는 안내를 확인했는가

입문자·개인 개발자·팀별 추천 선택 기준

입문자는 현재 이용 가능한 무료 범위나 이미 결제한 구독에서 작은 작업부터 시작하는 편이 좋습니다. 결과를 이해하고 잘못된 수정을 찾아낼 수 있는지 확인한 뒤 사용량을 늘리세요. 처음부터 세 도구를 모두 구독할 필요는 없습니다.

개인 개발자는 반복 업무 하나를 정해 비교하세요. 오류 수정이 대부분이라면 재현과 회귀 테스트를, 화면 개발이 많다면 변경 내용을 확인하고 수정하는 흐름을 중요하게 보면 됩니다. 한도 부족이 실제 작업을 자주 중단시키는지 기록하면 상위 구독과 추가 사용 중 무엇을 검토할지 판단하기 쉽습니다.

팀은 개인용 구독료만으로 총비용을 계산하지 않아야 합니다. 좌석 수, 관리 기능, 저장소 접근 범위, 코드 보관 정책, 퇴사자 접근 회수와 실제 사용료를 확인해야 합니다. 조직용 제공 방식은 각 공급자의 현재 계약 조건에 따라 별도로 비교하세요.

두 도구를 함께 쓰려면 역할이 나뉘는지부터 보세요. 하나는 변경 초안 작성에, 다른 하나는 검토 보조에 쓰는 설계를 검토할 수 있습니다. 다만 두 AI가 같은 결론을 냈다는 사실만으로 정확성을 보장할 수 없으며 테스트와 사람의 검토는 계속 필요합니다.

상황	첫 선택 방법	확대할 조건
입문자	무료 또는 보유 구독에서 작은 과제	결과를 이해하고 검토할 수 있을 때
개인 개발자	자주 하는 작업으로 후보 평가	추가 비용보다 작업상 이점이 확인될 때
소규모 팀	제한된 프로젝트와 인원으로 평가	권한·검토·비용 관리가 가능할 때
여러 도구 병행	도구별 역할과 비용 분리	중복 구독을 유지할 이유가 기록될 때

SUMMARY

통계

39%·16%·6%는 동일 조사의 업무용 이용률이며 매출 점유율이 아닙니다.

비용

구독료, 추가 크레딧, 별도 API 청구를 구분해 비교하세요.

선택

같은 과제의 수정 정확성, 검토 시간과 실제 비용으로 판단하세요.

FAQ

이용률이 높은 도구를 선택하면 되나요?

이용률은 후보를 이해하는 참고 지표입니다. 자신이 쓰는 언어와 개발 환경, 검토 부담과 비용에 맞는지는 별도 평가해야 합니다.

유료 구독만 있으면 추가 비용이 없나요?

사용 중인 인증 방식과 초과 사용 설정에 따라 다릅니다. API 키, 보유 크레딧 사용, 자동 충전을 각각 확인하세요.

세 도구의 5배·20배 요금제는 같은 사용량인가요?

회사마다 기준 구독과 사용량 계산 방식이 달라 동일한 작업 횟수를 뜻하지 않습니다.

Google AI Pro 가격은 한국에서도 $19.99인가요?

본문은 미국 공식 안내 가격입니다. 한국 계정의 통화와 세금, 할인 및 결제 경로를 반영한 실제 금액은 확인하지 않았습니다.

이 글의 실전 비교는 직접 실행한 결과인가요?

아닙니다. 같은 조건으로 평가할 수 있도록 만든 더미 예제이며 실행 속도나 수정 정확성의 실측 순위는 제공하지 않습니다.

CONCLUSION

이미 가진 구독과 개발 환경에서 후보 하나를 골라 시작하세요. 가상의 작은 과제로 수정 정확성과 검토 시간을 확인하고, 한도가 부족할 때 추가 비용과 상위 구독을 비교하면 됩니다. 현재 작업을 더 쉽게 검토하고 완료하게 만드는지가 도입 판단의 기준입니다.

...

Choose by verified results, review effort, and total cost.

Codex·Claude Code·Google Antigravity의 이용률·장점·요금과 결제 선택 기준

저작자표시 동일조건 (새창열림)

'AI' 카테고리의 다른 글

GPT-6 Astra 사용법: ChatGPT Work에서 시작하는 새 모델 활용 가이드 (0)	2026.09.09
GPU 서버 자원 모니터링 방법: nvidia-smi, DCGM Exporter, Prometheus, Grafana로 AI 인프라 상태를 확인하는 기준 (0)	2026.06.28
GPU 서버와 일반 서버의 차이: AI 모델 실행을 위한 CUDA, NVIDIA 드라이버, 라이브러리 설치 주의사항 (0)	2026.06.28
OpenAI gpt-oss란 무엇인가: 무료 오픈 웨이트 LLM을 Ollama, LM Studio, Hugging Face로 로컬에서 사용하는 방법 (0)	2026.06.28
OpenAI Codex on Amazon Bedrock이 의미하는 것: AWS가 멀티 모델 AI 개발 플랫폼을 강화하는 이유 (0)	2026.06.28

쿠버네티스 PVC 용량 확장이 반영되지 않을 때: 요청 용량·CSI·파일시스템 점검하기

2026. 9. 9. 16:50

Kubernetes · 스토리지 장애 점검

쿠버네티스 PVC 용량 확장이 반영되지 않을 때
요청 용량·CSI·파일시스템 점검하기

PVC 요청값, PV 용량, 컨테이너의 실제 파일시스템을 비교하면 확장이 멈춘 단계를 좁힐 수 있습니다.

PVC 확장CSI 진단샘플 YAML2026.09.09 확인

쿠버네티스 PVC 용량을 늘렸는데 반영되지 않을 때 요청값, PV 용량, CSI 이벤트와 파일시스템을 점검하는 순서를 정리합니다. EKS EBS CSI 샘플 YAML과 확장 명령, 완료 확인 및 데이터 보호 기준을 함께 확인하세요.

PVC 용량 확장이 안 될 때 먼저 비교할 세 가지

PVC의 요청 용량을 늘렸다면 PVC spec의 요청값, 연결된 PV의 용량, 애플리케이션이 사용하는 파일시스템 용량을 차례로 비교하세요. 요청이 저장된 것과 볼륨·파일시스템 확장이 끝난 것은 서로 다른 상태입니다. kubectl get pvc의 CAPACITY 열만으로 요청 반영 여부를 판단하지 않는 것이 좋습니다.

이 글은 기존 볼륨이 Bound 상태이고, 용량 증설을 요청한 뒤 반영되지 않는 상황을 다룹니다. 새 PVC가 처음부터 Pending인 경우의 일반적인 생성 장애와 구분합니다. 공식 문서 확인일은 2026년 9월 9일입니다. 아래는 직접 만든 가상 보관용 볼륨 예제입니다.

확인 대상	필드·명령	확인할 의미
요청 용량	PVC spec.resources.requests.storage	원하는 크기가 API에 저장됐는가
볼륨 용량	PV spec.capacity.storage	Kubernetes가 인식하는 볼륨 크기는 얼마인가
PVC 상태	PVC status.capacity·conditions·이벤트	진행 단계나 실패 사유가 있는가
파일시스템	Pod 안에서 df -h /archive	실제 마운트 경로에 늘어난 공간이 보이는가

확장 전제 조건: StorageClass와 드라이버부터 확인하기

StorageClass의 allowVolumeExpansion이 true인지 확인하세요. 이 설정만으로 모든 스토리지가 확장되는 것은 아니며 드라이버와 파일시스템도 지원해야 합니다. PVC 확장은 용량 증가를 위한 기능으로, 이미 할당된 볼륨 축소에 사용하지 않습니다. StorageClass 확장 조건

이 글의 YAML은 일반 EKS EC2 워커 노드에서 표준 Amazon EBS CSI Driver를 사용하는 테스트 환경을 전제로 합니다. 드라이버 설치, 필요한 IAM 권한, 노드 배치 조건과 이미지 다운로드 경로가 준비되어야 합니다.

EKS Auto Mode는 provisioner가 ebs.csi.eks.amazonaws.com으로 다르며, 이 예제의 ebs.csi.aws.com과 구분해야 합니다. EBS 볼륨을 Fargate Pod에 마운트하는 예제로도 사용할 수 없습니다. EKS EBS CSI 사용 조건

실제 데이터가 있는 환경은 복구 가능한 백업과 변경 시간을 먼저 정하세요. 이 글의 명령은 자신의 namespace·PVC·Pod 이름으로 바꿔야 하며, 샘플을 기존 운영 PVC에 그대로 적용하지 마세요.

kubectl get pvc -n pvc-expand-demo archive-data -o yaml
kubectl get storageclass demo-expand-gp3 -o yaml
kubectl get resourcequota -n pvc-expand-demo

샘플 YAML: 확장 가능한 테스트 볼륨 만들기

가상의 보관 앱에서 3Gi 볼륨을 7Gi로 늘리는 상황입니다. 아래 파일을 pvc-expand-demo.yaml로 저장하세요. 실제 EBS 볼륨을 생성하므로 실행하면 스토리지 비용이 발생할 수 있습니다.

Namespace, StorageClass, PVC와 확인용 Pod를 함께 구성합니다. 이름이 같은 리소스가 이미 있으면 다른 테스트 이름을 사용하세요. 이미지 태그도 자신의 테스트 환경에서 사용 가능한 버전인지 확인해야 합니다.

WaitForFirstConsumer는 소비 Pod의 배치 조건을 고려해 볼륨 생성을 진행하는 설정입니다. PVC만 만들고 기다리는 경우와 구분하세요. Retain은 PVC 삭제 시 볼륨이 자동 삭제되는 위험을 줄이기 위한 예제 선택이며, 남은 볼륨은 별도 정리가 필요합니다.

StorageClass와 PVC의 연결 원리는 기존 CSI·PersistentVolume 구조 글에서 확인할 수 있습니다. 여기서는 생성 이후의 확장 점검에 집중합니다.

apiVersion: v1
kind: Namespace
metadata:
  name: pvc-expand-demo
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: demo-expand-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  csi.storage.k8s.io/fstype: ext4
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: archive-data
  namespace: pvc-expand-demo
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  storageClassName: demo-expand-gp3
  resources:
    requests:
      storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: archive-check
  namespace: pvc-expand-demo
spec:
  containers:
    - name: checker
      image: busybox:1.37.0
      command: ["sh", "-c", "sleep 86400"]
      resources:
        requests:
          cpu: 10m
          memory: 16Mi
        limits:
          memory: 64Mi
      volumeMounts:
        - name: archive
          mountPath: /archive
  volumes:
    - name: archive
      persistentVolumeClaim:
        claimName: archive-data

초기 상태 확인 후 PVC 요청 용량만 변경하기

먼저 다음 명령으로 예제를 적용하고 Pod가 준비되는지 확인합니다. 대기 시간이 끝났다고 곧바로 확장 장애로 판단하지 마세요. 이미지 다운로드·노드 배치·볼륨 연결 문제가 없는지 describe의 이벤트를 먼저 읽어야 합니다.

초기 PVC가 Bound이고 /archive에 볼륨이 마운트된 다음에 증설을 요청합니다. 초기 용량이 보이는 상태를 기록해 두면 확장 전후 비교가 쉽습니다.

kubectl apply -f pvc-expand-demo.yaml
kubectl wait --for=condition=Ready pod/archive-check -n pvc-expand-demo --timeout=180s
kubectl get pvc -n pvc-expand-demo archive-data
kubectl describe pod -n pvc-expand-demo archive-check
kubectl exec -n pvc-expand-demo archive-check -c checker -- df -h /archive

확장용 YAML과 적용 명령: 3Gi에서 7Gi로

아래 내용은 독립적으로 생성하는 Kubernetes 리소스가 아니라 PVC에 적용할 merge patch입니다. pvc-expand-to-7gi.yaml로 저장한 뒤 다음 섹션의 patch 명령에 사용하세요.

필드 하나만 바꿔 실제 PVC의 요청 용량을 증가시키는 방식입니다. Git이나 Helm에서 PVC를 관리한다면 선언 원본에도 같은 요청값을 반영해 상태가 어긋나지 않게 하세요.

PV의 capacity를 먼저 수동 변경하지 마세요. Kubernetes가 이미 용량을 맞춘 것으로 판단해 필요한 자동 확장 처리가 진행되지 않을 수 있습니다. PVC를 통한 확장과 PV 직접 수정 주의사항

spec:
  resources:
    requests:
      storage: 7Gi

요청이 저장됐는지 확인하고 이벤트 읽기

patch 명령이 성공해도 확장이 완료된 것은 아닙니다. 아래 조회에서 REQUEST가 7Gi인지 먼저 보고 CAPACITY와 조건을 비교하세요. API 요청이 거부됐다면 권한, ResourceQuota, 정책 또는 확장 허용 설정부터 확인합니다.

이벤트의 시각과 메시지를 함께 읽으세요. Resizing·FileSystemResizePending 등의 표시 여부와 문구는 버전·드라이버·진행 시점에 따라 다를 수 있습니다. 조건이 비어 있다는 이유만으로 성공이나 실패를 확정하지 마세요.

PV 이름은 PVC의 spec.volumeName에서 확인한 실제 값으로 다음 명령의 <pv-name>을 교체하세요. 실제 PV 이름이나 오류 로그를 외부에 공유할 때는 운영 식별자를 제거해야 합니다.

kubectl patch pvc archive-data -n pvc-expand-demo --type=merge --patch-file=pvc-expand-to-7gi.yaml
kubectl get pvc archive-data -n pvc-expand-demo -o custom-columns=NAME:.metadata.name,REQUEST:.spec.resources.requests.storage,CAPACITY:.status.capacity.storage
kubectl describe pvc archive-data -n pvc-expand-demo
kubectl get events -n pvc-expand-demo --field-selector involvedObject.kind=PersistentVolumeClaim,involvedObject.name=archive-data --sort-by=.metadata.creationTimestamp
kubectl get pvc archive-data -n pvc-expand-demo -o jsonpath='{.spec.volumeName}'
kubectl get pv <pv-name> -o yaml

CSI 단계에서 멈췄다면 컨트롤러와 스토리지 오류 확인하기

요청은 커졌는데 PV 용량이 그대로라면 볼륨 확장 처리 구간을 조사하세요. 단, PV 표시만으로 공급자 측 처리 상태를 확정하지 말고 CSI 로그와 실제 스토리지 상태도 대조합니다.

표준 EBS CSI 설치에서는 컨트롤러의 csi-resizer와 ebs-plugin 로그가 점검 대상입니다. 아래 리소스·컨테이너 이름은 일반적인 설치 예시이므로 실제 Pod 목록과 컨테이너 이름부터 확인하세요. 다른 CSI 드라이버는 해당 배포의 이름으로 바꿔야 합니다.

권한 오류라면 CSI 컨트롤러가 사용하는 자격 증명을 확인하고, 용량 제한이나 볼륨 변경 중이라는 오류라면 해당 스토리지의 제한과 현재 변경 상태를 확인합니다. 애플리케이션 Pod에 더 강한 IAM 권한을 주는 방식으로 해결하려 하지 마세요.

EBS CSI는 PVC의 새 크기에 따른 볼륨 확장을 지원합니다. 구체적인 오류는 설치된 드라이버 버전과 구성에 맞춰 확인하세요. EBS CSI 기능 및 문서

kubectl get pods -n kube-system -o wide
kubectl get deployment ebs-csi-controller -n kube-system -o jsonpath='{.spec.template.spec.containers[*].name}'
kubectl logs -n kube-system deployment/ebs-csi-controller -c csi-resizer --since=15m
kubectl logs -n kube-system deployment/ebs-csi-controller -c ebs-plugin --since=15m

로그 해석 기준

컨트롤러 복제본이 여러 개라면 한 Pod의 로그만으로 오류가 없다고 판단하지 마세요. 해당 시간에 처리를 담당한 복제본의 로그를 확인합니다.

볼륨은 커졌는데 df가 그대로라면 파일시스템 점검하기

Filesystem 볼륨은 저장 장치 확장 이후 파일시스템 반영 단계가 필요할 수 있습니다. 실행 중 확장과 재마운트 필요 여부는 드라이버·파일시스템 조건에 따라 판단해야 하며, 무조건 Pod부터 삭제하는 방식은 피하세요. 파일시스템 확장 조건

먼저 올바른 Pod와 컨테이너에서 PVC가 연결된 경로를 보고 있는지 확인합니다. 루트 경로의 df 결과는 컨테이너의 임시 파일시스템일 수 있습니다. 샘플에서는 /archive를 지정합니다.

PV는 커졌지만 FileSystemResizePending이 지속된다면 Pod가 배치된 노드의 CSI node plugin과 kubelet 관련 오류를 조사하세요. 재마운트가 필요하다는 근거가 확인된 뒤 워크로드 복제본·데이터 일관성·중단 영향을 검토하고 재시작 여부를 결정합니다.

Raw Block 볼륨은 df로 확인하는 파일시스템 예제와 다릅니다. 또한 파일시스템 용량은 단위와 메타데이터 때문에 요청 숫자와 화면 표시가 정확히 일치하지 않을 수 있습니다. 애플리케이션의 별도 저장 한도도 구분해서 확인하세요.

kubectl get pod archive-check -n pvc-expand-demo -o wide
kubectl get pod archive-check -n pvc-expand-demo -o yaml
kubectl exec -n pvc-expand-demo archive-check -c checker -- df -h /archive
kubectl describe pod archive-check -n pvc-expand-demo

증상별 판단과 완료 확인·정리 기준

완료 판단은 요청값 하나로 끝내지 않습니다. 요청한 크기와 PV·PVC 상태를 확인하고, 실제 마운트 경로의 용량과 애플리케이션의 읽기·쓰기가 정상인지 검증하세요. 아래 표는 진단 방향이며 확정 원인을 뜻하지 않습니다.

테스트가 끝나면 Pod·PVC·Namespace와 테스트 StorageClass의 사용 여부를 확인해 정리하세요. 예제의 Retain 정책에서는 PVC 삭제 후에도 PV와 실제 EBS 볼륨이 남을 수 있으므로 연결 해제·데이터 보존 필요성을 확인한 뒤 각각 정리해야 합니다. 리소스를 자동 삭제하는 정리 명령은 포함하지 않았습니다.

확장 실패를 이유로 운영 PVC를 삭제하거나 finalizer를 제거하지 마세요. 현재 할당된 용량보다 줄이는 변경을 일반적인 복구 방법으로 사용해서도 안 됩니다.

관찰한 상태	우선 점검할 곳
요청값 자체가 이전 크기	patch 결과, namespace·PVC 이름, 권한·정책
요청은 증가, PV는 이전 크기	확장 허용, CSI 컨트롤러, 공급자 오류
PV는 증가, 파일시스템은 이전 크기	실제 마운트 경로, 노드 확장 단계
용량은 증가, 앱만 저장 실패	앱 제한, 쓰기 권한, inode·실제 사용량
명령이 성공했지만 근거 부족	조건·이벤트·PV·파일시스템을 함께 재확인

SUMMARY

요청

PVC spec의 요청값과 CAPACITY 표시를 구분합니다.

진단

볼륨 확장과 파일시스템 반영을 나누어 점검합니다.

보호

PV 숫자 수정이나 PVC 삭제를 첫 해결책으로 사용하지 않습니다.

FAQ

StorageClass에 allowVolumeExpansion만 추가하면 끝인가요?

아닙니다. 사용하는 드라이버와 파일시스템의 확장 지원, 권한과 용량 제한도 확인해야 합니다.

Pod를 반드시 재시작해야 하나요?

일률적으로 판단할 수 없습니다. 실행 중 확장 지원과 노드 단계의 이벤트를 확인하고 재마운트가 필요한 경우에만 중단 영향을 검토해 진행하세요.

StatefulSet에서도 이 YAML을 그대로 쓰면 되나요?

이 예제는 독립 PVC와 확인용 Pod를 사용합니다. StatefulSet에서는 실제 생성된 PVC를 식별하고 선언 템플릿 변경 가능 여부와 기존 PVC 반영 방식을 별도로 확인해야 합니다.

CONCLUSION

먼저 PVC에 원하는 크기가 저장됐는지 확인하고, 다음으로 CSI가 볼륨을 늘렸는지, 마지막으로 애플리케이션의 파일시스템에 공간이 반영됐는지 확인하세요. 각 단계의 관찰 결과를 남기면 불필요한 재시작과 데이터 삭제 없이 다음 조치를 선택하기 쉽습니다.

...

Verify the request, the volume, and the mounted filesystem.

저작자표시 동일조건 (새창열림)

'Kubernetes Guides' 카테고리의 다른 글

Kubernetes 트래픽 진입 구조 이해하기: ALB Controller, NGINX Ingress, Gateway, Istio 차이 (0)	2026.08.31
eBPF Observability란 무엇인가: Kubernetes 네트워크와 보안을 커널 수준에서 관찰하는 방법 (0)	2026.06.20
컨테이너는 어떻게 격리되는가: cgroup, namespace, overlay filesystem, 네트워크 구조로 이해하는 Docker와 Kubernetes 이미지 실행 원리 (0)	2026.06.18
Open Source Summit 2026 전망: 오픈소스 공급망 보안과 CNCF가 중요한 이유 (0)	2026.06.13
Fluent Bit을 왜 사용할까: Kubernetes 로그 수집, 필터링, 전송 구조를 이해하는 방법 (0)	2026.06.13

관심 항목	독자가 확인할 점
여러 단계의 업무	읽기·작성·검토까지 목표를 명확히 지정
작업 중 변경	수정할 범위와 유지할 조건을 함께 전달
도구 활용	현재 환경에 필요한 도구와 권한이 있는지 확인
이전 모델과 비교	같은 입력으로 정확성·수정 횟수·소요 시간 비교

시험 작업	완료 기준	기록할 결과
메모 정리	원문 항목 누락·허위 추가 없음	누락과 추가 내용
문서 비교	차이와 근거 위치가 일치	잘못된 비교 항목
결과물 제작	파일이 열리고 요구 형식 유지	형식 오류와 수정 횟수
코드 수정	요구 동작과 필요한 검증 충족	변경 범위와 검사 결과

Codex·Claude Code·Google Antigravity 비교이용률·장점·요금과 결제 선택 가이드 (0)	2026.09.09
GPU 서버 자원 모니터링 방법: nvidia-smi, DCGM Exporter, Prometheus, Grafana로 AI 인프라 상태를 확인하는 기준 (0)	2026.06.28
GPU 서버와 일반 서버의 차이: AI 모델 실행을 위한 CUDA, NVIDIA 드라이버, 라이브러리 설치 주의사항 (0)	2026.06.28
OpenAI gpt-oss란 무엇인가: 무료 오픈 웨이트 LLM을 Ollama, LM Studio, Hugging Face로 로컬에서 사용하는 방법 (0)	2026.06.28
OpenAI Codex on Amazon Bedrock이 의미하는 것: AWS가 멀티 모델 AI 개발 플랫폼을 강화하는 이유 (0)	2026.06.28

비교 항목	Bedrock 직접 호출	LiteLLM Proxy 경유
호출 경로	애플리케이션에서 Bedrock으로 전달	애플리케이션에서 Proxy를 거쳐 전달
정책 적용 위치	각 애플리케이션과 AWS 권한 체계	Proxy 정책과 AWS 권한 체계를 함께 설계
운영 범위	애플리케이션과 AWS 연동 관리	Proxy의 가용성·배포·상태 저장소 관리 추가

배포 방식	검토할 상황	운영 시 확인할 내용
EC2	서버에서 직접 설치와 동작을 확인하는 경우	운영체제 업데이트, 프로세스 복구, 증설
ECS	기존 ECS 기반으로 컨테이너를 운영하는 경우	Task Role, 서비스 배포, 로드 밸런서 연결
EKS	기존 Kubernetes 운영 기반을 활용하는 경우	Pod 권한, 배포 정책, 클러스터 관리 부담

확인 구간	주요 점검 내용
클라이언트 → Proxy	주소, TLS, 접근 경로, 클라이언트 인증
Proxy 내부	모델 별칭, 허용 모델, 설정 로딩, 데이터베이스 상태
Proxy → AWS 인증	실행 환경의 역할, 자격 증명 취득, IAM 권한
Bedrock 모델 호출	리전, 모델 또는 Inference Profile 식별자, 접근 조건, 호출 한도
응답 전달	클라이언트 제한 시간, 스트리밍 처리, 중간 연결 종료

판단 항목	도입 검토 상황	직접 호출로 시작할 상황
사용 범위	여러 팀·애플리케이션의 공통 정책 필요	단일 애플리케이션 중심
제공자 연동	다른 제공자까지 공통 호출 방식 필요	Bedrock 연동으로 요구 충족
사용량 통제	키별 사용량·접근 모델을 중앙에서 관리	애플리케이션별 관리로 충분
운영 여건	Gateway 배포·복구 담당자 확보	추가 서비스 운영 여력이 제한적

AWS Network Security

AWS Network Firewall 구성 방식 총정리: 단일 NFW, 중앙 Inspection VPC, 이중 방화벽 설계 비교

AWS Network Firewall을 어디에 배치하고 어떤 라우팅으로 통과시킬지, 대표 구성별 장점과 주의점을 정리합니다.

NFWInspection VPCTGWRouting

AWS Network Firewall은 VPC 트래픽을 검사하는 관리형 방화벽입니다. 이 글은 단일 VPC 구성, Distributed 구성, 중앙 Inspection VPC, 중앙 Egress, Ingress 앞단, 앞단·뒷단 이중 방화벽, Combined 구성, TGW-attached 구성을 공식 문서 기준으로 설명합니다.

AWS Network Firewall 설계의 핵심

AWS Network Firewall은 VPC 안에 Firewall Endpoint를 만들고, Route Table을 통해 트래픽을 그 Endpoint로 보내는 방식으로 동작합니다. 방화벽을 만들었다고 모든 트래픽이 자동으로 검사되는 것은 아닙니다.

따라서 설계의 핵심은 “방화벽을 몇 개 만들 것인가”보다 “어떤 서브넷의 어떤 경로를 Firewall Endpoint로 보낼 것인가”입니다. 인터넷으로 나가는 트래픽, 인터넷에서 들어오는 트래픽, VPC 간 트래픽, 온프레미스와 오가는 트래픽마다 라우팅 경로가 달라집니다.

공식 문서 기준으로 Firewall Endpoint는 전용 Firewall Subnet에 배치해야 하며, 고가용성을 위해 사용 중인 AZ마다 Endpoint를 두는 구성이 일반적입니다. 또한 상태 기반 검사를 하므로 요청과 응답이 같은 방화벽 경로를 지나도록 대칭 라우팅을 맞춰야 합니다.

설계 핵심
1. 보호할 트래픽 방향을 정합니다.
2. Firewall Subnet을 전용으로 분리합니다.
3. Workload Subnet Route Table을 Firewall Endpoint로 보냅니다.
4. IGW, NAT Gateway, TGW 쪽 Route Table도 return path를 맞춥니다.
5. AZ별 경로가 같은 AZ의 Firewall Endpoint를 지나도록 설계합니다.

섹션 공식문서

How AWS Network Firewall works, Example architectures with routing 문서를 기준으로 확인하면 됩니다.

단일 VPC에서 NFW 하나를 사용하는 구성

가장 기본적인 방식은 하나의 VPC 안에 Firewall Subnet과 Workload Subnet을 나누고, Workload Subnet의 트래픽을 Network Firewall Endpoint로 보내는 구성입니다.

인터넷 outbound를 검사하려면 Workload Subnet의 기본 경로를 Firewall Endpoint로 보내고, Firewall Subnet 이후에 NAT Gateway 또는 Internet Gateway로 나가도록 구성합니다. 인터넷 inbound를 검사하려면 VPC Ingress Routing을 사용해 Internet Gateway에서 들어온 트래픽을 먼저 Firewall Endpoint로 보낸 뒤 workload나 Load Balancer로 전달합니다.

이 구성은 단순하고 이해하기 쉽습니다. 단일 VPC만 보호하면 되는 환경, 특정 서비스만 별도 보안 검사가 필요한 환경, 또는 Network Firewall을 처음 도입하는 환경에 적합합니다.

장점	주의점
Transit Gateway 없이 구성 가능	VPC마다 별도 구성이 필요함
라우팅 범위가 작아 이해하기 쉬움	AZ별 Endpoint 경로를 맞춰야 함
장애 영향 범위가 해당 VPC로 제한됨	여러 VPC로 확장하면 관리 포인트 증가

VPC별로 NFW를 각각 두는 Distributed 구성

Distributed 구성은 각 VPC에 Network Firewall을 배치하는 방식입니다. 중앙으로 트래픽을 모으지 않고, 각 VPC 내부에서 로컬로 검사합니다.

이 방식은 VPC별 보안 요구사항이 다를 때 유리합니다. 예를 들어 외부 연동 VPC, 내부 업무 VPC, 데이터 처리 VPC가 서로 다른 정책을 가져야 한다면 각각의 Firewall Policy를 분리할 수 있습니다.

또한 고트래픽 VPC가 중앙 방화벽을 왕복하지 않아도 되므로 지연시간과 중앙 경로 의존도를 줄일 수 있습니다. 다만 VPC 수가 많아질수록 Firewall Endpoint 수와 운영 관리 포인트가 증가합니다.

Distributed 구성 개념
VPC A: Firewall Endpoint + Workload Subnet
VPC B: Firewall Endpoint + Workload Subnet
VPC C: Firewall Endpoint + Workload Subnet
각 VPC가 자체 Route Table로 로컬 검사 경로를 구성합니다.

중앙 Inspection VPC 구성

중앙 Inspection VPC 구성은 여러 Spoke VPC의 트래픽을 Transit Gateway를 통해 중앙 검사 VPC로 보내는 방식입니다. 멀티 계정, 다수 VPC 환경에서 가장 자주 검토되는 구조입니다.

이 구성에서는 Transit Gateway가 허브 역할을 하고, Inspection VPC에는 TGW Attachment Subnet과 Firewall Subnet을 분리해서 둡니다. Spoke VPC에서 다른 VPC, 온프레미스, 인터넷 방향으로 나가는 트래픽을 중앙 방화벽으로 보내 정책을 일관되게 적용할 수 있습니다.

장점은 정책 중앙화입니다. 보안팀이 하나의 Firewall Policy와 공통 룰셋을 관리할 수 있고, 여러 VPC에 동일한 검사 기준을 적용하기 쉽습니다. 단점은 TGW Route Table, VPC Route Table, Firewall Endpoint Route Table이 함께 맞아야 하므로 라우팅 설계가 복잡해진다는 점입니다.

중앙 Inspection VPC 흐름
Spoke VPC
→ Transit Gateway
→ Inspection VPC TGW Attachment Subnet
→ Network Firewall Endpoint
→ Transit Gateway
→ 대상 VPC 또는 외부 경로

섹션 공식문서

Deployment models for AWS Network Firewall 문서형 블로그는 중앙 Inspection VPC 모델과 East-West 검사 흐름을 설명합니다.

중앙 Egress VPC 구성

중앙 Egress VPC 구성은 여러 VPC의 인터넷 outbound 트래픽을 한 곳으로 모아 검사하고, NAT Gateway를 통해 인터넷으로 내보내는 방식입니다.

일반적으로 Spoke VPC의 private subnet 기본 경로는 Transit Gateway로 향하고, Transit Gateway는 해당 트래픽을 Egress VPC 또는 Inspection VPC로 전달합니다. Network Firewall이 트래픽을 검사한 뒤 NAT Gateway와 Internet Gateway를 통해 외부로 나갑니다.

이 구성의 장점은 인터넷 outbound 정책을 중앙에서 관리할 수 있다는 점입니다. 도메인 기반 차단, Suricata compatible rule, 침입 탐지·차단, 로깅 정책을 한 곳에 모을 수 있습니다.

주의할 점은 NAT Gateway와 Firewall Endpoint의 AZ 정합성입니다. 한 AZ에서 들어온 트래픽이 다른 AZ의 NAT Gateway나 Firewall Endpoint로 이동하면 비용과 장애 영향이 커질 수 있습니다.

Ingress 앞단에 NFW를 두는 구성

Ingress 앞단 구성은 인터넷에서 들어오는 트래픽이 애플리케이션이나 Load Balancer에 도달하기 전에 Network Firewall을 지나게 만드는 방식입니다.

이 구조는 외부에서 들어오는 비정상 포트, 악성 IP, 알려진 공격 패턴, 허용되지 않은 프로토콜을 네트워크 계층에서 먼저 걸러내고 싶을 때 사용합니다. 보통 Internet Gateway, Firewall Endpoint, ALB 또는 NLB, Workload Subnet 순서로 흐름을 설계합니다.

다만 HTTP와 HTTPS 애플리케이션 공격을 세밀하게 다루는 목적이라면 AWS WAF가 더 적합한 경우가 많습니다. WAF 앞단 설계는 CloudFront + AWS WAF 보안 구성 베스트 프랙티스를 함께 보면 이해하기 쉽습니다. Network Firewall은 네트워크 방화벽과 IDS/IPS 성격이 강하고, WAF는 웹 요청의 URI, header, body, bot, managed rule 같은 애플리케이션 계층 보호에 강합니다.

구분	Network Firewall	AWS WAF
주요 계층	네트워크와 전송 계층 중심, 일부 애플리케이션 프로토콜 검사	HTTP/HTTPS 웹 요청 중심
주요 대상	VPC 라우팅 경로의 트래픽	CloudFront, ALB, API Gateway 등 웹 진입점
대표 용도	네트워크 정책, IPS, 도메인 필터링, egress 통제	SQL injection, XSS, bot, 웹 규칙 기반 차단

섹션 공식문서

Network Firewall architectures, What is AWS WAF 문서를 함께 보면 역할 차이를 구분할 수 있습니다.

앞단·뒷단 이중 NFW 구성

앞단·뒷단 이중 NFW 구성은 외부 진입 구간에서 1차 검사하고, Load Balancer 뒤 또는 내부 서비스 앞에서 2차 검사하는 방식입니다.

예를 들어 앞단 NFW는 인터넷에서 들어오는 트래픽을 넓은 기준으로 차단하고, 뒷단 NFW는 애플리케이션 내부 구간으로 들어가는 트래픽을 더 세밀한 정책으로 검사할 수 있습니다. 보안 구역을 DMZ와 내부 서비스 영역으로 강하게 분리해야 하는 경우 설명하기 좋은 구조입니다.

장점은 역할 분리입니다. 앞단은 외부 위협 완화, 뒷단은 내부 서비스 보호로 목적을 나눌 수 있습니다. 또한 로그도 진입 전과 진입 후로 분리되어 보안 분석에 도움이 됩니다.

단점은 비용과 복잡도입니다. 방화벽 Endpoint 수가 늘고, Route Table도 늘어납니다. 특히 stateful 검사에서는 양방향 트래픽이 같은 방화벽 계층을 지나야 하므로 비대칭 라우팅을 더 엄격하게 관리해야 합니다.

앞단·뒷단 이중 검사 예시
Internet Gateway
→ Front Network Firewall
→ Load Balancer
→ Back Network Firewall
→ Workload Subnet
응답 트래픽도 반대 방향으로 같은 검사 계층을 지나야 합니다.

Ingress용 NFW와 Egress용 NFW를 분리하는 구성

NFW를 두 개 사용한다는 말은 보통 ingress용과 egress용을 분리한다는 의미일 수 있습니다. 외부에서 들어오는 정책과 외부로 나가는 정책은 목적이 다르기 때문입니다.

Ingress용 NFW는 외부 출발 트래픽을 애플리케이션 도달 전에 검사합니다. 반면 Egress용 NFW는 내부 workload가 인터넷이나 외부 서비스로 나가는 경로를 검사합니다.

분리의 장점은 정책 책임을 나누기 쉽다는 점입니다. Ingress 룰셋은 공개 서비스 보호에 집중하고, Egress 룰셋은 외부 도메인 접근, 데이터 유출 방지, 악성 목적지 차단에 집중할 수 있습니다.

하나로 충분한 경우도 있습니다. 트래픽 규모가 작고, 정책 소유자가 같고, 라우팅이 단순한 환경이라면 굳이 두 개로 나누지 않아도 됩니다. 반대로 규제, 감사, 운영 책임, 로그 분석 기준이 분리되어야 한다면 ingress와 egress 분리를 검토할 수 있습니다.

Combined 구성

Combined 구성은 중앙 Inspection VPC를 사용하면서 일부 VPC에는 전용 Network Firewall을 추가로 두는 혼합 모델입니다.

예를 들어 대부분의 VPC 간 통신과 공통 outbound는 중앙 Inspection VPC에서 검사하고, 인터넷에 직접 노출되는 특정 VPC만 로컬 Network Firewall을 둬서 별도 ingress 정책을 적용할 수 있습니다.

이 방식은 중앙 관리와 개별 최적화를 동시에 가져갈 수 있습니다. 공통 보안 정책은 중앙에서 관리하고, 특수한 VPC만 별도 룰셋이나 별도 로그 체계를 둘 수 있습니다.

하지만 출발점으로는 복잡할 수 있습니다. 중앙 모델과 분산 모델의 라우팅, 비용, 정책 관리를 모두 이해해야 하므로 처음부터 Combined로 시작하기보다 요구사항이 명확할 때 선택하는 편이 좋습니다.

TGW-attached Network Firewall 구성

TGW-attached Network Firewall은 Transit Gateway 중심 환경에서 Network Firewall을 네트워크 기능 attachment처럼 사용하는 구성입니다. 기존 중앙 Inspection VPC 방식처럼 고객이 직접 Inspection VPC의 세부 라우팅을 많이 관리하는 구조와는 접근이 다릅니다.

이 방식의 장점은 운영 단순화입니다. Transit Gateway 중심으로 여러 VPC, VPN, Direct Connect 경로를 연결하는 환경에서 방화벽 연결과 대칭 경로 관리를 더 단순하게 가져갈 수 있습니다.

다만 모든 ingress 요구사항에 맞는 것은 아닙니다. 특히 중앙 ingress에서 source IP 보존이나 애플리케이션 계층 제어가 중요한 경우에는 CloudFront, AWS WAF, ALB, 전용 ingress VPC 같은 선택지도 함께 검토해야 합니다.

섹션 공식문서

Deployment models for AWS Network Firewall: Transit Gateway attachment and multiple VPC endpoints에서 TGW-attached 모델과 multiple VPC endpoint association 모델을 확인할 수 있습니다.

구성별 선택 기준 비교

Network Firewall 구성은 정답 하나로 고정되지 않습니다. VPC 수, 트래픽 방향, 중앙 관리 필요성, 비용, 장애 범위, 라우팅 복잡도를 함께 보고 선택해야 합니다.

구성	적합한 상황	장점
단일 VPC NFW	작은 환경, 특정 VPC 보호	단순하고 빠르게 적용 가능
Distributed	VPC별 정책이 다름	독립성 높고 장애 범위가 작음
중앙 Inspection VPC	멀티 계정, 다수 VPC	정책 중앙화와 공통 검사에 유리
중앙 Egress VPC	인터넷 outbound 통제	NAT와 보안 로그를 중앙화 가능
Ingress 앞단	외부 진입 트래픽 검사	애플리케이션 도달 전 네트워크 검사
앞단·뒷단 이중 NFW	강한 보안 구역 분리	진입 전과 내부 진입 후 정책 분리
Ingress/Egress 분리	정책 소유자와 로그 목적이 다름	룰셋과 운영 책임 분리
Combined	공통 정책과 예외 VPC가 공존	중앙화와 개별 최적화 절충
TGW-attached	TGW 중심 대규모 환경	중앙 방화벽 운영 복잡도 감소

설계 시 반드시 확인할 항목

첫 번째는 대칭 라우팅입니다. Network Firewall은 상태 기반 검사를 수행하므로 요청과 응답이 서로 다른 방화벽 경로를 지나면 예상하지 못한 차단이나 연결 실패가 발생할 수 있습니다.

두 번째는 AZ 정합성입니다. Workload가 있는 AZ, Firewall Endpoint가 있는 AZ, NAT Gateway 또는 TGW Attachment가 있는 AZ의 경로를 맞춰야 장애와 비용을 줄일 수 있습니다.

세 번째는 우회 경로입니다. Route Table에 기본 경로는 방화벽으로 보내면서도 특정 prefix는 바로 TGW, NAT, IGW로 빠지게 만들면 검사되지 않는 트래픽이 생길 수 있습니다.

네 번째는 지원되지 않는 검사 경로입니다. 공식 문서에서는 VPC Peering, AWS Global Accelerator 트래픽, AmazonProvidedDNS 트래픽 등 일부 아키텍처와 트래픽은 Network Firewall 검사 대상으로 지원되지 않는다고 설명합니다.

설계 점검 목록
1. Firewall Subnet은 전용으로 분리했는가
2. Workload Subnet의 기본 경로가 Firewall Endpoint를 향하는가
3. Return path도 같은 검사 경로를 지나가는가
4. AZ별 Firewall Endpoint와 NAT Gateway 경로가 맞는가
5. TGW Route Table association과 propagation이 의도대로 분리됐는가
6. 방화벽을 우회하는 static route가 없는가
7. Stateful rule과 stateless rule 평가 순서를 이해했는가
8. Flow log와 alert log를 수집하고 있는가

섹션 공식문서

Example architectures with routing 문서의 unsupported architectures와 avoiding asymmetric routing 항목을 확인해야 합니다.

참고 공식문서

아래 문서는 글 전체를 검증할 때 참고한 대표 공식문서입니다. 섹션마다 모두 넣지 않고, 전체 구조를 다시 확인할 때 사용할 수 있도록 마지막에 모았습니다.

공식 문서 목록

AWS Network Firewall example architectures with routing

How AWS Network Firewall works

AWS Network Firewall deployment architecture best practices

Deployment models for AWS Network Firewall

Transit Gateway attachment and multiple VPC endpoints

What is AWS WAF

SUMMARY

핵심

Network Firewall은 Route Table로 트래픽을 Firewall Endpoint에 보내야 동작합니다.

단일 구성

단일 VPC 보호에 적합하고 구조가 가장 단순합니다.

중앙 구성

멀티 계정과 다수 VPC에서 정책 중앙화에 유리하지만 TGW 라우팅 설계가 중요합니다.

이중 구성

앞단과 뒷단을 나눠 강한 보안 경계를 만들 수 있지만 비용과 복잡도가 증가합니다.

검토 기준

대칭 라우팅, AZ 정합성, 우회 경로, 전용 Firewall Subnet, 로그 수집을 반드시 확인해야 합니다.

FAQ

Network Firewall을 만들면 VPC 트래픽이 자동으로 검사되나요?

아닙니다. Route Table에서 검사할 트래픽을 Firewall Endpoint로 보내야 합니다.

NFW 하나와 두 개 구성 중 무엇이 더 좋은가요?

정답은 없습니다. 트래픽 방향, 정책 소유자, 로그 분리, 비용, 라우팅 복잡도를 기준으로 결정해야 합니다.

웹 애플리케이션 앞에는 Network Firewall만 두면 되나요?

웹 공격 방어가 목적이라면 AWS WAF도 함께 검토해야 합니다. Network Firewall과 WAF는 보호 계층과 역할이 다릅니다.

CONCLUSION

AWS Network Firewall 설계는 방화벽 개수보다 트래픽 경로 설계가 중요합니다. 단일 VPC, 중앙 Inspection VPC, Distributed, Combined, TGW-attached, 앞단·뒷단 이중 구성은 모두 사용할 수 있지만 목적이 다릅니다. 실제 설계에서는 Route Table, AZ 정합성, 대칭 라우팅, Firewall Subnet 분리, 로그 수집을 먼저 확인해야 합니다.

...

Design the route path first, then choose the firewall deployment model.

AWS Network Firewall 구성 방식 총정리 단일 NFW 중앙 Inspection VPC 이중 방화벽 설계 비교

저작자표시 동일조건 (새창열림)

'AWS Guides' 카테고리의 다른 글

EKS에서 Calico가 필요한 경우: VPC CNI 정책 기능과 CNI 교체 판단 기준 (0)	2026.09.09
AWS LiteLLM과 Amazon Bedrock 연동 구조: IAM 인증·배포·비용 관리 (0)	2026.09.06
AWS Control Tower 설계 기준 정리: Landing Zone, OU 구조, Control 정책, 초기 배포 방식 (0)	2026.09.03
EKS에서 mTLS를 적용하는 방식: Service Mesh와 Gateway 기준 (0)	2026.09.03
AWS Load Balancer Controller Deep Dive: EKS에서 ALB와 NLB가 생성되는 원리 (0)	2026.08.31

OU	주요 목적	정책 방향
Security	로그와 감사	변경 제한, 중앙 보안 접근
Workloads-Prod	운영 서비스	강한 변경 통제, 리전 제한, 보안 필수화
Workloads-NonProd	개발과 검증	운영보다 완화된 정책, 기본 보안 기준 유지
Sandbox	실험	비용 제한, 위험 서비스 제한, 데이터 반입 제한
PolicyStaging	정책 검증	운영 적용 전 Control과 SCP 영향 검토

Control 유형	구현 방식	적용 의미
Preventive	SCP, RCP, declarative policy	위반 작업을 사전에 차단
Detective	AWS Config Rule	위반 상태를 탐지하고 표시
Proactive	CloudFormation Hook	리소스 생성 전에 정책 위반 확인

구분	일반 TLS	mTLS
인증 방향	클라이언트가 서버를 확인	클라이언트와 서버가 서로 확인
주요 목적	서버 신뢰 확인과 암호화	서비스 간 신원 확인과 암호화
활용 예	일반 HTTPS	Service Mesh, B2B API, 내부 API 보호

리소스	적용 대상	의미
IngressClass	Ingress	Ingress 처리 Controller 선택
loadBalancerClass	Service type LoadBalancer	LoadBalancer Service 처리 Controller 선택
GatewayClass	Gateway API	Gateway 구현체 선택

전체 글