Run interactive IDEs on Amazon EKS with SageMaker AI to power up your AI workflows

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker AI Spaces 애드온은 기존 Amazon EKS 클러스터 안에서 관리형 주피터랩과 코드 편집기를 실행해, 데이터 과학자가 파이프라인과 동일한 GPU·스토리지·권한 환경을 대화형 작업에도 활용하도록 지원합니다.

📌 핵심 요약

• SageMaker AI Spaces 애드온은 별도 주피터허브나 로컬 노트북으로 이동하지 않고 기존 EKS 클러스터에서 관리형 주피터랩과 코드 편집기 환경을 제공합니다.
• 구성은 외부 접속과 네트워크, 클러스터 내부 라우팅, 컴퓨팅과 스토리지의 세 계층으로 나뉘며 Route 53, ALB, ACM, Traefik, KMS, EBS·EFS·FSx, EKS Pod Identity를 사용합니다.
• 클러스터에는 쿠버네티스 1.30 이상과 전통적인 EC2 기반 노드가 필요하며, 두 개 이상의 가용 영역에 걸친 공용·사설 서브넷과 사설 서브넷용 NAT 게이트웨이를 구성해야 합니다.
• 설치 과정에는 서브넷 태그 지정, External DNS 권한 설정, AWS Load Balancer Controller 배포, TLS 인증서 발급, JWT 암호화용 KMS 키 생성, SSM 고급 인스턴스 계층 활성화가 포함됩니다.
• 대화형 환경과 훈련 워크로드를 한 클러스터에 통합하면 전용 노트북 플릿 대비 GPU 활용률을 최대 30% 높일 수 있으며, 상시 실행되는 별도 GPU 환경의 월 수천 달러 규모 비용을 피할 수 있습니다.

🧩 주요 포인트

1. 대화형 개발 환경을 파이프라인과 같은 클러스터에 배치하면 환경 전환을 줄이는 동시에 기존 GPU·공유 스토리지·IAM 권한을 그대로 활용할 수 있습니다.
2. 브라우저 접속과 VS Code 원격 접속에 서로 다른 경로를 사용하고, TLS·KMS·Pod Identity를 결합해 외부 접근과 파드 권한을 구분해 통제합니다.
3. 약 5분의 Space 생성 경험은 자동으로 주어지는 것이 아니라, 올바른 서브넷 태그와 컨트롤러 설정, DNS·인증서·IAM·SSM 기반 구성이 선행되어야 합니다.

🧠 상세 정리

1. 기존 대화형 개발 방식의 한계와 Spaces의 역할

EKS에서 인공지능 파이프라인을 운영하는 데이터 과학자에게는 주피터랩이나 코드 편집기 같은 대화형 개발 환경이 필요하지만, 기존에는 이를 사용하기 위해 클러스터 밖으로 이동하는 경우가 많았습니다. 별도의 주피터허브를 배포하거나 로컬 노트북을 사용하면 파이프라인이 의존하는 GPU 노드, 공유 스토리지, IAM 역할을 동일하게 이용하기 어려워집니다. SageMaker AI Spaces 애드온은 이미 운영 중인 EKS 클러스터 내부에 관리형 주피터랩과 코드 편집기 환경을 실행함으로써 이 간극을 줄입니다. GPU 접근, 스토리지, 인증을 포함한 독립형 주피터허브 환경을 플랫폼 팀이 준비하는 데 일반적으로 3~5일이 걸리는 것과 달리, 기반 구성이 완료된 뒤 데이터 과학자는 약 5분 만에 완전히 설정된 Space를 시작할 수 있다고 본문은 설명합니다.

2. 세 계층으로 구성된 전체 아키텍처

해결 구조는 하나의 EKS 클러스터 위에서 네트워크와 접근, 클러스터 라우팅, 컴퓨팅과 스토리지라는 세 계층으로 작동합니다. 네트워크 계층에서는 Route 53이 와일드카드 도메인을 인터넷 공개형 애플리케이션 로드 밸런서로 연결하고, ACM 인증서가 TLS를 제공합니다. 클러스터 내부에서는 AWS Load Balancer Controller가 로드 밸런서를 프로비저닝하며, Traefik이 호스트 이름에 따라 요청을 전달하고 인증 미들웨어가 KMS를 이용해 JWT 관련 암호화를 처리합니다. Space 파드는 사설 서브넷의 작업자 노드에서 실행되고, EBS CSI 드라이버가 영구 볼륨을 제공하며 EFS나 FSx가 공유 또는 고처리량 스토리지 역할을 맡습니다. 각 파드의 AWS 권한은 EKS Pod Identity를 통해 범위가 제한된 IAM 역할로 부여되고, VS Code 원격 접속은 SSM이 Space 파드까지 직접 터널을 형성하는 방식으로 제공됩니다.

3. GPU 활용률과 독립형 환경 비용 절감

대화형 개발 환경과 훈련 작업을 한 클러스터에 통합하는 핵심 효과는 기존 GPU 노드를 작업 사이의 유휴 시간에도 활용할 수 있다는 점입니다. 본문은 이런 구성이 전용 노트북 플릿을 별도로 운영하는 방식과 비교해 GPU 활용률을 최대 30% 높일 수 있다고 제시하지만, 이는 가능한 최대 개선 폭으로 표현되어 있습니다. 또한 대화형 작업만을 위해 GPU 환경을 항상 켜 두지 않아도 되므로, 월 수천 달러에 이를 수 있는 상시 실행 환경의 비용을 피할 수 있습니다. 즉, 이 접근법은 별도 개발용 인프라를 추가하는 대신 이미 훈련 파이프라인을 실행하는 클러스터의 컴퓨팅과 스토리지를 공동 활용하는 구조입니다. 다만 로드 밸런서, EBS 볼륨, EKS 클러스터 및 SSM 고급 인스턴스 계층 등에는 각각 사용 요금이 발생하므로 작업을 마친 뒤 정리 절차를 수행해야 합니다.

4. 설치 전 필수 도구와 권한

실습에는 대상 리전에 맞게 구성된 AWS CLI 2.x 이상, kubectl 1.30 이상, Helm 3가 필요하며, 사용자가 소유한 도메인의 Route 53 공개 호스팅 영역도 준비해야 합니다. IAM 역할과 정책, EKS 애드온, 접근 항목, Pod Identity 연결, ACM 인증서, KMS 키를 생성할 수 있는 권한 역시 요구됩니다. Spaces 애드온은 0.1.4 이상이어야 하며, 본문은 그 이전 버전이 SageMaker HyperPod만 지원했다고 명시합니다. 클러스터 이름과 리전, 호출자 계정 식별자를 환경 변수로 설정한 뒤 이후 명령에서 반복해서 사용합니다. 모든 IAM 역할은 EKS Pod Identity를 통해 쿠버네티스 서비스 계정이 맡는 구조이므로, 파드 서비스가 역할을 인수하고 세션 태그를 사용할 수 있도록 하는 공통 신뢰 정책을 한 번 작성해 재사용합니다.

5. EKS 클러스터와 서브넷 구성 요건

Spaces 애드온을 사용하려면 EKS Auto Mode를 비활성화하고 쿠버네티스 1.30 이상의 전통적인 EC2 기반 노드를 사용해야 합니다. VPC는 두 개 이상의 가용 영역에 공용 및 사설 서브넷을 포함해야 하며, 사설 서브넷에는 NAT 게이트웨이가 연결되고 클러스터 엔드포인트는 공용과 사설 접근을 모두 허용하도록 설정합니다. 초기 클러스터 생성 시 Pod Identity Agent, EBS CSI Driver, 인증서 관리자, External DNS 애드온을 추가하되, SageMaker Spaces와 AWS Load Balancer Controller는 이후 단계에서 설치합니다. 관리형 노드 그룹은 사설 서브넷에 Amazon Linux 2023, m5.xlarge 이상 인스턴스, 노드 두 개를 기준으로 생성합니다. 특히 Spaces 설치 전에 모든 서브넷에 클러스터 공유 태그를 부여하고 공용 서브넷에는 외부 로드 밸런서 태그, 사설 서브넷에는 내부 로드 밸런서 태그를 지정해야 합니다. 이 단계를 놓치면 컨트롤러가 ALB를 사설 서브넷에 배치해 외부에서 Space에 접속할 수 없는 상태가 될 수 있습니다.

6. 기반 애드온 확인과 External DNS 권한 설정

클러스터가 준비되면 AWS CLI로 kubeconfig를 갱신하고 kubectl을 통해 두 작업자 노드가 모두 준비 상태인지 확인합니다. 이어 전체 네임스페이스의 파드를 조회해 시스템, 인증서 관리자, External DNS 네임스페이스의 모든 파드가 실행 상태인지 검증한 뒤 다음 단계로 진행합니다. External DNS가 Route 53 레코드를 관리할 수 있도록 전용 IAM 역할을 만들고, 레코드 변경과 호스팅 영역 및 레코드 조회에 필요한 정책을 연결합니다. 이 역할은 external-dns 네임스페이스의 external-dns 서비스 계정에 Pod Identity로 결합하며, 연결 후 해당 배포를 재시작해 새 권한을 적용합니다. 본문은 각 역할의 작업과 리소스를 최소 범위로 제한하고 가능한 경우 와일드카드 대신 명시적인 리소스 식별자를 사용하며, 의도한 서비스 계정만 역할을 맡을 수 있는지 확인하라고 강조합니다.

7. AWS Load Balancer Controller 배포

Spaces 사용자 인터페이스 앞단의 ALB는 AWS Load Balancer Controller가 생성하므로, 컨트롤러용 공식 IAM 정책을 내려받아 고객 관리형 정책과 전용 역할을 만들고 서비스 계정에 Pod Identity로 연결합니다. 이후 AWS의 EKS Helm 저장소를 추가하고 차트를 설치하면서 클러스터 이름, 서비스 계정 이름, 리전, VPC 식별자를 값으로 전달합니다. 특히 차트 3.2 이상에서는 파드에 대한 EC2 메타데이터 접근이 EKS에서 차단되므로, 컨트롤러가 메타데이터를 통해 VPC를 자동 감지하도록 두면 실패할 수 있습니다. 따라서 리전과 VPC 식별자를 명시적으로 지정하는 것이 필수적인 설치 조건으로 제시됩니다. 마지막으로 배포 롤아웃 상태를 제한 시간 내에 확인하며, 본문의 예시에서는 컨트롤러 복제본 두 개가 모두 준비되고 사용 가능한 상태로 올라온 결과를 보여 줍니다.

8. TLS·KMS·SSM 구성과 애드온 설치 진입

Spaces 애드온에는 도메인과 와일드카드 하위 도메인을 포함하는 ACM TLS 인증서, JWT 암호화용 KMS 키, 원격 접속을 위한 SSM 서비스 설정이 필요합니다. 인증서는 DNS 검증 방식으로 요청하고 ACM이 제시한 CNAME 레코드를 Route 53에 추가한 뒤 발급 완료 상태가 될 때까지 기다리며, 자동 갱신을 유지하려면 검증 레코드를 삭제하지 않아야 합니다. 인증 미들웨어가 JWT마다 데이터 키 생성을 호출하므로 KMS 키는 대칭형 암호화·복호화 키여야 하며, 생성 후 알아보기 쉬운 별칭을 연결합니다. VS Code 원격 기능이 사용하는 하이브리드 관리형 인스턴스 터널을 지원하기 위해 SSM 고급 인스턴스 계층도 활성화하며, 본문은 Space 파드당 시간당 약 0.00695달러의 추가 비용을 명시합니다. 이후 Spaces 컨트롤러와 인증 미들웨어용 IAM 역할을 만드는 설치 단계로 넘어가고, 먼저 각 Space 파드가 SSM 플릿에서 사용할 관리형 노드 역할 생성을 시작하지만 제공된 본문은 해당 역할의 신뢰 정책 명령 도중에 끝납니다.

🧾 핵심 주장 / 시사점

• 이 구성의 자원 효율은 새로운 노트북 전용 GPU를 추가하는 데서 나오지 않고, 훈련 작업 사이에 비는 기존 클러스터 GPU를 대화형 작업과 공유하는 데서 나옵니다.
• 브라우저는 Route 53·ALB·TLS·클러스터 라우팅을 거치는 반면 VS Code는 SSM으로 Space 파드에 직접 터널링하므로, 두 접속 방식은 동일한 개발 환경을 사용하면서도 네트워크 경로와 필요한 기반 설정이 다릅니다.
• 사용자 관점에서는 Space를 약 5분 만에 시작할 수 있지만, 그 속도는 클러스터 요건과 서브넷 태그, 최소 권한 IAM 역할, DNS·인증서·KMS·SSM 구성을 플랫폼 측에서 먼저 정확히 완료했을 때 성립합니다.

✅ 액션 아이템

• Amazon SageMaker AI Spaces 애드온 도입 전 쿠버네티스 1.30 이상, 전통적인 EC2 기반 노드, 두 개 이상의 가용 영역 조건을 점검한다.
• 관리형 주피터랩과 코드 편집기를 기존 Amazon EKS 클러스터에 배치할 때 파이프라인과 동일한 GPU·공유 스토리지·IAM 권한 활용 범위를 정의한다.
• 설치 과정에서 서브넷 태그, External DNS 권한, AWS Load Balancer Controller, TLS 인증서, JWT 암호화용 KMS 키, SSM 고급 인스턴스 계층을 점검한다.

❓ 열린 질문

• 대화형 환경과 훈련 워크로드를 한 클러스터에 통합할 때 GPU 활용률 최대 30% 상승이 실제 운영에서도 재현 가능한가?
• 브라우저 접속과 VS Code 원격 접속에 서로 다른 경로를 적용할 때 TLS·KMS·EKS Pod Identity의 권한 구분은 어떻게 판단할 것인가?
• 약 5분의 Space 생성 경험을 좌우하는 서브넷 태그, 컨트롤러 설정, DNS·인증서·IAM·SSM 구성의 우선순위는 무엇인가?