왜 여러 회사에서 AKS는 불안정하고 EKS는 안정적으로 느껴졌을까

 

“왜 AKS는 자잘한 오류가 많고, EKS는 더 안정적으로 느껴질까?”

쿠버네티스를 여러 회사에서 운영해 본 엔지니어들 사이에서 자주 나오는 말이 있다.

“이상하게 AKS는 자잘한 문제가 많고,

EKS는 그냥 조용히 잘 돌아간다.”

 

 

 

---

1. 반복된 실무 체감: “우연이 아니라 패턴”

개인적으로 여러 회사를 거치며 공통적으로 느낀 점은 명확했다.

• AKS:
  • 작은 오류가 잦음
  • “완전히 죽진 않았는데 뭔가 이상한 상태”가 자주 발생
  • 운영자가 계속 개입해야 함
• EKS:
  • 평소에는 매우 조용함
  • 장애가 아예 없다는 건 아니지만 빈도가 낮음
  • 문제가 생기면 비교적 명확한 원인이 드러남

이 체감이 여러 조직에서 반복되었다면,

이는 개인의 운이나 환경 문제가 아니라 플랫폼 구조의 차이로 보는 게 합리적이다.

---

2. SLA 수준에서 이미 시작되는 차이

기본 SLA 비교

 

서비스	기본 SLA
EKS	99.95% (기본 제공)
AKS	99.5% (무료)
AKS(Standard,Premium)	99.95% (유료 옵션)

숫자를 연간 다운타임으로 바꾸면 차이는 극명하다.

• 99.5% → 약 43.8시간
• 99.95% → 약 4.38시간

👉 약 4배 차이

즉, AKS는 비용을 추가하지 않으면

“더 자주 멈춰도 SLA 위반이 아닌 구조”다.

이 자체가 운영 체감에 영향을 준다.

---

3. 아키텍처 차이가 만드는 안정성 격차

EKS: Single-tenant Control Plane

• 클러스터마다 독립 컨트롤 플레인
• 장애 발생 시 영향 범위(blast radius) 제한
• 다른 고객 클러스터로 전파될 가능성 낮음

AKS: Multi-tenant Control Plane

• 여러 고객이 컨트롤 플레인 공유
• 컨트롤 플레인 문제 발생 시
  • 여러 클러스터 동시 영향 가능

👉 이 차이 때문에

AKS는 장애가 발생했을 때 “범위가 넓고 모호하게” 느껴지기 쉽다.

---

4. AKS에서 “자잘한 오류”가 많은 구조적 이유

1️⃣ 관리 계층이 많다

AKS 위에는 쿠버네티스 외에도 다음이 깊게 얽혀 있다.

• Azure Resource Manager (ARM)
• Managed Identity
• Azure CNI
• Azure Load Balancer
• Azure DNS
• Azure Portal

이 중 하나만 느려져도:

• Pod Pending
• 노드 NotReady
• Service 생성 지연
• kubectl은 되는데 Portal은 안 보임

👉 쿠버네티스는 살아 있는데

운영자는 “AKS가 불안정하다”고 느끼게 되는 전형적인 상황

---

2️⃣ 자동 관리 개입이 잦다

AKS는 기본적으로:

• 노드 이미지 자동 업데이트
• OS 패치 자동 반영
• 컨트롤 플레인 마이너 업데이트
• 내부 컴포넌트 재배치

이 과정에서:

• 노드 재시작
• CNI 재기동
• CoreDNS 불안정

👉 대부분 치명적 장애는 아니지만 운영자가 계속 신경 써야 하는 “잔고장”이 된다.

---

3️⃣ Azure CNI 특성상 경계 오류가 잦음

• Pod가 VNet IP를 직접 사용
• IP 부족, NSG, UDR 하나만 어긋나도
  • Pod 생성 실패
  • 특정 노드 통신 불가
  • 외부 트래픽 간헐 실패

이건 장애라기보다 경계 조건 문제인데,

AKS에서는 이런 상황이 비교적 자주 발생한다.

 ip 부족 관련해서는 eks 도 마찬가지이긴 하고 aws, azure에서 이것을 해결하는방법이 있지만 eks 의 경우 에러이벤트가 명확하다.

 

• failed to assign an IP address
• InsufficientFreeAddressesInSubnet

 

---

4️⃣ “진단 도구 자체가 장애”인 상황

Azure는 구조상:

• Entra ID
• ARM
• Front Door

같은 공통 컴포넌트에 거의 모든 서비스가 의존한다.

그래서:

• 인증 장애
• 포털 장애
• API 장애

가 발생하면 AKS 운영·진단 자체가 막힌다.

👉 운영자는

“문제가 뭔지 보려고 했는데, 보는 도구가 죽어 있다”는 경험을 하게 된다.

---

5. EKS가 더 안정적으로 느껴지는 이유

EKS는:

• 컨트롤 플레인 개입 최소화
• 네트워크 모델 비교적 단순
• IAM / VPC 구조 예측 가능

그 결과:

• 자잘한 이상 증상이 눈에 띄게 적다
• 운영자가 개입할 일이 적다

대신:

• 장애가 나면
  • 리전 단위
  • 서비스 단위
  • 크게 터진다

👉 하지만 빈도가 낮기 때문에

“평소엔 안정적”이라는 인식이 강하다.

---

6. 공정한 평가: AWS도 완벽하지는 않다

• 2025년 AWS 역시:
  • us-east-1에서 15시간 이상 대규모 장애
  • 여러 관리형 서비스 동시 영향

즉,

AKS만 문제고 EKS는 무결하다는 주장은 사실이 아니다.

다만 차이는 이것이다.

• AKS: 작은 문제가 자주, 넓게 보인다
• EKS: 큰 문제가 가끔, 명확하게 터진다

---

7. 종합 결론

“AKS가 EKS보다 장애가 많다”는 인식은 절반은 사실이고, 절반은 구조적 체감이다.

사실인 부분

• AKS 기본 SLA가 더 낮다
• 멀티 테넌트 컨트롤 플레인 구조
• Azure 공통 의존성 장애의 연쇄 효과
• 자잘한 오류 노출 빈도 높음

체감의 문제

• EKS도 대형 장애는 존재
• 리전, 구성, 의존 서비스에 따라 체감은 달라짐