beautifulsoups.dev
Published on

EKS STS 엔드포인트 타임아웃 - VPC·NAT·DNS 해결

Authors

서버리스나 EC2에서는 잘 되던 AWS API 호출이, EKS 안에서만 간헐적으로 멈추거나 sts.amazonaws.com 호출에서 타임아웃이 나는 경우가 있습니다. 특히 IRSA(서비스어카운트 기반 AssumeRoleWithWebIdentity), 이미지 풀(간접적으로 ECR 토큰), 외부 시크릿/컨트롤러(Cluster Autoscaler, ExternalDNS, cert-manager 등)가 STS를 자주 때리기 때문에, STS 네트워크 경로가 막히면 클러스터 전체가 연쇄적으로 느려지거나 실패합니다.

이 글은 “STS 엔드포인트 타임아웃”을 VPC(라우팅/보안), NAT(egress), DNS(CoreDNS/프라이빗 DNS) 관점에서 재현 가능한 체크리스트로 정리하고, 가장 안전한 해결책(Interface VPC Endpoint)까지 연결합니다.

관련 EKS 네트워크/운영 이슈를 함께 다룬 글로는 EKS에서 kubectl exec·logs가 안 될 때 진단법, IaC 상태 꼬임이 네트워크 변경과 함께 터질 때 참고할 Terraform EKS 상태 꼬임으로 apply 무한 반복 끊기도 같이 보면 좋습니다.

1) 대표 증상: “STS만” 느리거나 멈춘다

다음 중 하나면 거의 STS 경로 문제입니다.

  • Pod 로그에 RequestError: send request failed / context deadline exceeded / i/o timeout
  • IRSA 사용 Pod에서 AssumeRoleWithWebIdentity가 타임아웃
  • AWS SDK가 sts.amazonaws.com 또는 sts.<region>.amazonaws.com에서만 지연
  • 노드/Pod가 프라이빗 서브넷에 있고, 인터넷 egress가 NAT에 의존
  • 특정 AZ에 있는 노드에서만 더 자주 발생(= AZ별 NAT/라우팅 차이)

STS는 인증의 관문이라, 여기서 막히면 ECR 토큰 갱신, S3 접근, CloudWatch 로그 전송 등도 같이 줄줄이 영향을 받을 수 있습니다.

2) 먼저 확인: STS 엔드포인트 종류(글로벌 vs 리전)

STS는 기본적으로 글로벌 엔드포인트(sts.amazonaws.com)를 쓰기도 하고, 리전 엔드포인트(sts.ap-northeast-2.amazonaws.com)를 쓰기도 합니다. 기업망/프라이빗 환경에서는 글로벌이 막히고 리전은 되는 케이스가 꽤 있습니다.

  • AWS CLI/SDK 설정에서 sts_regional_endpoints = regional로 강제하면 해결되는 경우가 있습니다.
  • 하지만 EKS에서 “타임아웃”이라면 대개 네트워크 egress 또는 DNS 이슈이므로, 근본 해결은 아래 진단을 따라가야 합니다.

3) 재현/진단: Pod 안에서 DNS → TCP → TLS 순서로 쪼개기

3.1 디버그 Pod 띄우기

kubectl run -it --rm netshoot \
  --image=nicolaka/netshoot \
  --restart=Never -- bash

3.2 DNS 확인: STS가 어떤 IP로 풀리는지

dig +short sts.amazonaws.com

dig +short sts.ap-northeast-2.amazonaws.com

nslookup sts.amazonaws.com

여기서 체크 포인트:

  • 응답이 느리거나 time out: CoreDNS/노드 DNS 경로 문제 가능성
  • 사설 IP(10.x/172.16/192.168)로 풀림: VPC Endpoint(PrivateLink) 또는 잘못된 사설 Hosted Zone/Resolver Rule 개입 가능성
  • 응답이 매번 바뀌는데 특정 IP에서만 실패: NAT/라우팅/보안그룹이 특정 경로만 막는 경우

3.3 TCP 연결 확인: 443까지 도달하는지

# TCP 레벨 연결 테스트
nc -vz sts.amazonaws.com 443

# TLS 핸드셰이크까지 확인
openssl s_client -connect sts.amazonaws.com:443 -servername sts.amazonaws.com -brief </dev/null
  • nc가 타임아웃이면 라우팅/NAT/보안그룹/NACL 쪽이 유력
  • openssl에서 인증서 교환 전에 멈추면 네트워크/프록시/MTU 이슈 가능

3.4 HTTP 레벨 확인

curl -I --connect-timeout 3 --max-time 10 https://sts.amazonaws.com/

STS는 루트에 403/404가 나도 “연결 자체는 된다”는 의미입니다. 중요한 건 타임아웃이냐 아니냐입니다.

4) VPC·NAT·라우팅 체크리스트(가장 흔한 원인)

4.1 프라이빗 서브넷의 기본 경로(0.0.0.0/0)가 NAT로 가는지

EKS 노드가 프라이빗 서브넷에 있으면, 해당 서브넷 라우팅 테이블에 다음이 있어야 합니다.

  • 0.0.0.0/0 -> nat-xxxxxxxx

확인:

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-xxxx" \
  --query 'RouteTables[].Routes'

실수 패턴:

  • NAT가 없는 프라이빗 서브넷(인터넷 완전 차단 의도였는데 STS는 필요)
  • 라우팅 테이블을 다른 서브넷에 잘못 연결
  • 멀티 AZ인데 AZ A 서브넷은 NAT A, AZ B 서브넷은 NAT 없음/다른 NAT

4.2 NAT Gateway 상태 및 포트 고갈(간헐적 타임아웃의 단골)

NAT Gateway는 대규모 동시 연결에서 SNAT 포트 고갈로 드랍이 발생할 수 있습니다. STS 호출이 짧고 잦으면 특히 티가 납니다.

  • CloudWatch NATGW 지표 확인:
    • ErrorPortAllocation
    • PacketsDropCount
    • ActiveConnectionCount

가능한 해결:

  • AZ별 NAT Gateway 분리(각 프라이빗 서브넷이 “같은 AZ의 NAT”로 나가게)
  • 워크로드의 재시도/커넥션 재사용(HTTP keep-alive) 튜닝
  • 근본적으로는 STS VPC Endpoint(Interface) 로 NAT를 우회

4.3 NACL/보안그룹에서 443 egress가 막히지 않았는지

  • 노드 SG egress가 0.0.0.0/0:443 또는 VPC Endpoint SG로 허용되어야 합니다.
  • NACL은 stateless이므로 **아웃바운드 443 + 인바운드 ephemeral(1024-65535)**가 필요합니다.

간단 점검(개념):

  • SG: egress 443 허용?
  • NACL: outbound 443 허용 + inbound ephemeral 허용?

5) DNS(CoreDNS/Resolver) 체크리스트

네트워크가 멀쩡해도, DNS가 꼬이면 STS가 “가끔” 터집니다.

5.1 CoreDNS 상태/로그

kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n kube-system logs -l k8s-app=kube-dns --tail=200

이런 로그가 보이면 위험 신호:

  • upstream timeout
  • SERVFAIL 증가
  • plugin/errors 다수

5.2 CoreDNS가 참조하는 upstream 확인

kubectl -n kube-system get configmap coredns -o yaml

forward . /etc/resolv.conf 형태면 노드의 resolv.conf를 따라가는데, 노드가 사내 DNS/Route53 Resolver로 포워딩하면서 특정 도메인(amazonaws.com)을 잘못 처리하는 케이스가 있습니다.

5.3 VPC Endpoint 사용 시 “Private DNS”와 충돌

Interface VPC Endpoint를 만들면 보통 Private DNS 활성화를 켭니다. 이때 sts.amazonaws.com이 사설 IP로 해석되어 VPC 내부로 라우팅됩니다.

  • 의도한 구성이라면 좋습니다(인터넷/NAT 불필요).
  • 하지만 중간에 다른 Private Hosted Zone이 amazonaws.com을 덮어쓰면 엉뚱한 IP로 풀릴 수 있습니다.

확인 포인트:

  • Route 53 Private Hosted Zone에 amazonaws.com 또는 sts.amazonaws.com 레코드가 있는지
  • Resolver Rule이 해당 도메인을 온프레미스 DNS로 포워딩하는지

프라이빗 서브넷 EKS에서 STS가 필요하다면, NAT에 기대는 대신 STS용 VPC Endpoint를 만드는 게 가장 안정적입니다.

장점:

  • STS 트래픽이 VPC 내부에서 처리되어 NAT 장애/포트 고갈 영향 최소화
  • egress 제어가 쉬움(보안그룹으로 제한)
  • 네트워크 경로가 단순해져 “간헐 타임아웃”이 크게 줄어듦

6.1 콘솔/CLI로 생성 개념

  • 서비스: com.amazonaws.<region>.sts
  • 타입: Interface
  • 서브넷: EKS 노드가 있는 프라이빗 서브넷들
  • 보안그룹: 노드 SG(또는 Pod ENI SG)에서 443로 접근 허용
  • Private DNS: 일반적으로 Enable

CLI 예시:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.ap-northeast-2.sts \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-a subnet-b \
  --security-group-ids sg-endpoint \
  --private-dns-enabled

엔드포인트 SG 인바운드 예시(노드/Pod CIDR 또는 노드 SG에서 443 허용):

aws ec2 authorize-security-group-ingress \
  --group-id sg-endpoint \
  --protocol tcp --port 443 \
  --source-group sg-nodes

6.2 적용 후 검증

Pod에서 다시 확인합니다.

dig +short sts.ap-northeast-2.amazonaws.com
nc -vz sts.ap-northeast-2.amazonaws.com 443
curl -I https://sts.ap-northeast-2.amazonaws.com/
  • DNS가 사설 IP로 풀리고
  • 443 연결이 즉시 성공하며
  • curl이 지연 없이 응답하면 성공입니다.

7) IRSA를 쓰는 경우 추가 체크(“STS는 되는데 AssumeRole이 실패”)

STS 네트워크가 해결됐는데도 IRSA가 실패한다면, 다음을 같이 봐야 합니다.

  • OIDC Provider가 클러스터와 일치하는지
  • 서비스어카운트 어노테이션 role-arn이 맞는지
  • IAM Role trust policy의 sub 조건이 정확한지
  • 시간 동기(NTP) 문제로 토큰 검증 실패(드물지만 발생)

다만 이 글의 범위(타임아웃)에서는 대부분 네트워크/DNS가 원인입니다.

8) 운영 팁: “간헐적”일수록 관측을 먼저 붙인다

간헐 타임아웃은 재현이 어렵기 때문에, 다음을 먼저 켜두면 원인 규명이 빨라집니다.

  • NAT Gateway CloudWatch 지표 대시보드 (ErrorPortAllocation, PacketsDropCount)
  • CoreDNS metrics(프로메테우스 스크랩) 및 SERVFAIL, request_duration_seconds
  • 노드 서브넷/AZ별 실패율 비교(특정 AZ NAT/라우팅 문제를 빨리 찾음)

EKS에서 네트워크 문제가 다른 형태로 터질 때는 EKS kube-proxy CrashLoopBackOff iptables 오류 해결처럼 “증상은 파편적이지만 원인은 네트워크 계층”인 경우가 많아, 계층별 분해(DNS→TCP→TLS→HTTP)가 가장 효율적입니다.

9) 결론: 해결 우선순위

  1. Pod에서 DNS/TCP 테스트로 ‘어디서’ 막히는지 분리
  2. 프라이빗 서브넷이면 라우팅 테이블의 0.0.0.0/0 → NAT 확인
  3. 간헐이면 NAT 포트 고갈/드랍 지표 확인(AZ별 NAT 분리)
  4. 장기적으로는 STS Interface VPC Endpoint + Private DNS로 NAT 의존 제거
  5. DNS가 느리면 CoreDNS/upstream/Resolver Rule/Private Hosted Zone 충돌 점검

이 순서대로 보면, “EKS에서만 STS 타임아웃” 문제는 대부분 1~2시간 내에 원인까지 좁히고, VPC Endpoint로 깔끔하게 종결할 수 있습니다.

Discuss on Twitter • View on GitHub