LiteLLM이란 무엇인가

LiteLLM은 AWS의 관리형 서비스가 아니라 여러 모델 제공자의 호출 방식을 연결하는 도구입니다. AWS에서 LiteLLM Proxy를 운영하면 애플리케이션의 요청을 Amazon Bedrock으로 전달하는 LLM Gateway를 구성할 수 있습니다. 모델 추론은 Bedrock에서 수행합니다.

사용 방식은 SDK와 Proxy로 나뉩니다. SDK는 애플리케이션 코드 안에 넣어 사용하고, Proxy는 별도 서버로 실행해 여러 애플리케이션의 공통 진입점으로 사용합니다. 이 글에서는 AWS에 LiteLLM Proxy를 배포하고 Amazon Bedrock에 연결하는 구조를 다룹니다.

공통 API를 사용해도 모델별 기능과 입력 제한까지 같아지는 것은 아닙니다. 모델을 교체할 때는 도구 호출, 출력 형식, 스트리밍 동작을 별도로 확인해야 합니다.

LiteLLM 공식 문서에서 SDK와 Proxy의 역할을 확인할 수 있습니다.

공식 문서 확인일은 2026년 9월 5일입니다. 이 글은 구성과 운영 판단을 설명하는 초안이며, 예시의 AWS 실제 호출은 검증하지 않았습니다.

Amazon Bedrock 앞에 LiteLLM을 두는 이유

Amazon Bedrock 앞에 LiteLLM Proxy를 두는 주된 이유는 여러 애플리케이션의 모델 접근 정책과 사용량 관리를 공통화하기 위해서입니다. 단일 애플리케이션의 요구를 Bedrock 직접 호출로 충족한다면 별도 Gateway가 필수는 아닙니다.

가상의 예로, 문서 제목을 제안하는 도구와 고객 문의를 분류하는 도구를 서로 다른 개발팀이 운영한다고 생각해 보겠습니다. 두 팀이 각각 모델 접근 설정과 사용량 집계를 구현하면 정책을 바꿀 때 수정 지점도 늘어납니다.

Proxy를 공통 진입점으로 두면 애플리케이션이 호출할 모델 이름과 접근 정책을 한곳에서 관리하는 구성을 만들 수 있습니다. 다만 공통 진입점에 장애가 생기면 여러 서비스가 영향을 받으므로 운영 책임도 함께 정해야 합니다.

Bedrock 자체도 Converse API를 통해 여러 모델의 호출 형식을 통일할 수 있습니다. 따라서 모델을 여러 개 사용한다는 이유만으로 별도 Gateway가 필요한 것은 아닙니다. 팀별 통제나 다른 제공자와의 연동이 필요한지부터 확인합니다.

AWS에서 전체 요청 흐름 이해하기

클라이언트는 Proxy 주소로 요청을 보내면서 모델 별칭을 지정합니다. Proxy는 요청자의 접근 권한을 확인하고, 별칭에 연결된 Bedrock 모델을 찾아 호출합니다. Bedrock의 응답은 다시 Proxy를 거쳐 클라이언트에 전달됩니다.

예를 들어 애플리케이션에는 demo-assistant라는 이름만 노출하고, 실제 모델 식별자는 Proxy 설정에 둡니다. 모델 연결을 바꾸더라도 애플리케이션의 별칭을 유지할 수 있지만, 응답 품질과 기능 호환성 검증은 필요합니다.

모델의 실행 위치는 Bedrock입니다. Proxy 서버에 GPU를 추가한다고 연결된 Bedrock 모델의 추론 속도가 직접 빨라지는 것은 아닙니다.

AWS 배포 방식 선택하기

처음부터 복잡한 배포 구조를 정하기보다 현재 운영 중인 기반과 담당자의 관리 범위를 확인합니다. 작은 검증 환경에서는 단일 실행 환경으로 호출 흐름을 이해하고, 운영 전환 시 가용성과 확장 요구를 반영하는 편이 단계별 검증에 유리합니다.

ECS와 EKS는 컨테이너 운영 방식의 선택이며, Fargate는 컨테이너 실행에 사용할 수 있는 컴퓨팅 방식입니다. 세 가지를 완전히 같은 층위의 제품으로 비교하지 않도록 구분합니다.

운영 구성에서는 요청을 받는 경로, Proxy 실행 환경, Bedrock에 도달하는 통신 경로를 각각 설계합니다. 여러 Proxy를 실행한다면 키와 사용량 같은 상태를 어떻게 공유할지도 검토해야 합니다.

배포 환경별 선택 기준은 EKS·ECS·Fargate 차이와 선택 기준에서 확인할 수 있습니다.

인증 구조 이해하기: 사용자 키와 IAM Role

인증은 두 구간으로 나눠 생각해야 합니다. 애플리케이션이 Proxy에 접근할 권한과, Proxy가 Bedrock을 호출할 권한은 별개입니다. 클라이언트 키가 정상이어도 AWS 권한이 부족하면 모델 호출은 실패할 수 있습니다.

이 글은 AWS에서 실행되는 Proxy에 IAM Role을 부여하는 구성을 기준으로 합니다. 장기 AWS 자격 증명을 본문이나 설정 파일에 넣지 않고, 실행 환경에 연결된 역할에서 임시 자격 증명을 얻도록 구성합니다.

ECS에서는 컨테이너 내부 애플리케이션의 AWS 접근 권한을 Task Role에 부여합니다. 이미지 가져오기 등 ECS 실행 작업에 쓰이는 Task Execution Role과 혼동하지 않아야 합니다. AWS Task Role 문서에서 역할의 적용 범위를 확인할 수 있습니다.

EKS에서는 EKS Pod Identity 또는 IRSA 같은 Pod 단위 권한 구성을 검토합니다. 선택한 방식에 필요한 SDK 지원과 설정 조건을 확인합니다. EKS Pod Identity 문서를 참고할 수 있습니다.

Bedrock 호출 권한은 사용할 모델과 호출 방식에 맞춰 제한합니다. Converse 호출에는 bedrock:InvokeModel, 스트리밍에는 bedrock:InvokeModelWithResponseStream 권한이 관련됩니다. Inference Profile을 쓰면 그에 맞는 리소스 범위도 확인해야 합니다. Bedrock 추론 사전 조건을 기준으로 점검합니다.

AWS 권한의 기본 개념은 IAM Role·User·Policy 차이에서 이어서 확인할 수 있습니다.

LiteLLM과 Amazon Bedrock 연결하기

다음은 연결 관계를 보여 주는 config.yaml 초안입니다. BEDROCK_MODEL_ID_TO_REPLACE는 실제 모델명이 아니므로, 사용할 리전에서 호출 가능한 모델 또는 Inference Profile 식별자로 교체해야 합니다. 리전과 모델 접근 조건을 확인하기 전에는 그대로 실행할 수 없습니다.

model_name은 애플리케이션이 요청할 별칭이고, litellm_params의 model은 제공자 경로와 실제 모델 식별자를 연결합니다. AWS_REGION_NAME 환경 변수에는 대상 리전을 설정합니다. AWS 자격 증명은 앞서 구성한 IAM Role을 통해 얻는 방식을 전제로 합니다.

LITELLM_MASTER_KEY 환경 변수에는 별도로 생성한 관리자용 비밀 값을 주입합니다. 관리자 키는 애플리케이션 배포용으로 공유하지 않습니다. 아래 설정은 모델 연결의 최소 골격이며, 팀별 Virtual Key 운영에 필요한 데이터베이스 설정은 다음 절에서 설명합니다.

설치할 LiteLLM 버전을 정하고 proxy 의존성과 boto3를 준비한 뒤, litellm --config config.yaml 명령으로 설정을 읽을 수 있습니다. 실제 배포에서는 패키지나 컨테이너 버전을 고정하고 접근 가능한 네트워크 범위를 제한합니다.

LiteLLM Bedrock 연결 문서와 Proxy 설정 문서에서 배포 버전의 지원 설정을 확인합니다.

애플리케이션에서 모델 호출하기

클라이언트는 Proxy의 호출 주소와 발급받은 키, 모델 별칭을 사용합니다. 아래 요청 본문은 가상의 전시 안내 문구를 줄이는 예시이며, 실제 업무 내용이나 개인 정보를 포함하지 않습니다.

POST /v1/chat/completions 경로로 다음 JSON을 전달합니다. Authorization 헤더에는 발급된 클라이언트 키를 Bearer 방식으로 넣고 Content-Type은 application/json으로 지정합니다. 실제 주소와 키는 실행 환경에서 주입하며 본문에 기록하지 않습니다.

일반 응답에서는 반환된 메시지와 오류 여부를 확인합니다. 스트리밍을 검증할 때는 stream 값을 true로 변경하고 클라이언트가 연속 이벤트를 처리하는지 확인합니다. 앞단 로드 밸런서와 클라이언트의 제한 시간도 응답 방식에 맞게 점검합니다.

이 예시는 요청 형태를 설명하는 초안이며 AWS 환경에서 실행 검증한 결과는 아닙니다. 모델별 지원 매개변수와 응답 동작은 실제 연결 후 확인해야 합니다.

팀별 사용량과 비용 관리하기

Virtual Key는 Proxy가 관리하는 호출 키입니다. 키별로 접근할 모델과 사용 정책을 구분하면 어떤 용도의 요청인지 나눠 관리하기 쉬워집니다. AWS IAM 자격 증명을 클라이언트마다 전달하는 것과는 다른 구조입니다.

문서상의 Virtual Key 구성에는 PostgreSQL 연결과 관리자 키가 필요합니다. DATABASE_URL을 안전하게 주입하고 데이터베이스 연결을 준비한 뒤, 관리 경로인 /key/generate에서 키를 생성하는 흐름을 사용합니다. Virtual Key 공식 문서를 기준으로 설정합니다.

가상의 demo-editor와 demo-helper를 별도 사용 단위로 두고, 허용 모델·예산 기간·호출 제한을 각각 정하는 방식으로 설계할 수 있습니다. 배포할 버전과 사용 기능의 제공 조건은 적용 전에 확인합니다.

Gateway에 기록되는 사용량만으로 AWS 전체 비용을 설명할 수는 없습니다. 모델 호출 비용 외에 Proxy 실행 환경, 데이터베이스, 로드 밸런서와 네트워크 비용도 함께 봐야 합니다. 비용 집계는 AWS 청구 내역과 대조하고, 예산 제한은 진행 중인 호출과 동시 요청이 있는 조건에서도 검증합니다.

운영 환경에서 확인할 보안·안정성 기준

Proxy는 여러 애플리케이션이 공유하는 서비스가 되므로 관리 기능과 일반 호출 경로의 접근 범위를 정해야 합니다. 외부 통신에는 HTTPS를 적용하고, 관리자 키와 데이터베이스 연결 정보는 비밀 값 저장 체계로 관리합니다.

관측 지표는 요청 수, 오류율, 응답 시간, 사용량부터 정합니다. 요청 본문과 응답 전체를 저장하면 민감한 내용이 로그에 남을 수 있으므로 기록 필요성과 보존 기간을 먼저 결정합니다.

재시도는 일시 오류 복구에 도움이 되지만, 호출량과 비용을 늘릴 수 있습니다. 클라이언트와 Proxy가 동시에 반복 요청을 만들지 않도록 재시도 횟수와 전체 대기 시간을 함께 설계합니다.

다른 모델로 전환하는 복구 방식을 도입한다면 가격뿐 아니라 답변 품질, 도구 호출 호환성, 처리 리전을 확인해야 합니다. 복구 성공 여부는 정상 응답 코드만으로 판단하지 않고 애플리케이션 결과까지 검증합니다.

호출 실패 시 어디부터 확인할까

문제가 생기면 요청이 어느 구간까지 도달했는지 먼저 확인합니다. Proxy에 도착하지 않은 요청과 Bedrock에서 거절된 요청을 같은 방식으로 조사하면 확인 범위가 불필요하게 넓어집니다.

상태 코드 하나로 원인을 확정하지 말고 Proxy 로그와 제공자 오류 내용을 함께 확인합니다. 로그를 공유할 때는 키·계정 정보·입력 내용을 제거합니다.

LiteLLM 도입 판단 기준

도입 여부는 모델 개수보다 공통 관리가 필요한 범위로 판단합니다. 여러 팀의 접근 정책과 사용량을 한곳에서 관리할 필요가 크고 운영 담당자가 있다면 Gateway를 검토할 수 있습니다.

단일 애플리케이션에서 Bedrock만 사용하고 별도 통제 요구가 적다면 직접 호출부터 시작하는 선택도 가능합니다. 기존 구성으로 해결하기 어려운 요구를 먼저 적고, Proxy를 추가했을 때 얻는 효과와 운영 비용을 비교합니다.

아래 표는 특정 제품의 성능 비교가 아니라 시스템 설계 시 사용할 판단 기준입니다.

FAQ

AWS Network Firewall 설계의 핵심

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

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

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

단일 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을 처음 도입하는 환경에 적합합니다.

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

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

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

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

중앙 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이 함께 맞아야 하므로 라우팅 설계가 복잡해진다는 점입니다.

중앙 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 같은 애플리케이션 계층 보호에 강합니다.

앞단·뒷단 이중 NFW 구성

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

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

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

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

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 같은 선택지도 함께 검토해야 합니다.

구성별 선택 기준 비교

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

설계 시 반드시 확인할 항목

첫 번째는 대칭 라우팅입니다. 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 검사 대상으로 지원되지 않는다고 설명합니다.

참고 공식문서

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

FAQ

AWS Control Tower가 필요한 이유

AWS 계정이 하나일 때는 IAM, CloudTrail, AWS Config, 보안 로그, 백업, 네트워크 기준을 직접 관리해도 운영이 가능합니다. 하지만 계정이 늘어나면 계정마다 보안 설정이 달라지고, 로그 위치가 흩어지고, 권한 기준이 서로 달라질 수 있습니다.

AWS Control Tower는 이런 문제를 줄이기 위해 멀티 계정 환경의 기본 틀을 제공합니다. Landing Zone을 만들고, OU와 계정을 관리하며, Control을 통해 보안과 컴플라이언스 기준을 지속적으로 적용합니다.

핵심은 계정 생성 자동화가 아니라 거버넌스 표준화입니다. 계정이 많아져도 동일한 보안 기준, 로깅 기준, 접근 기준을 유지하는 것이 Control Tower의 목적입니다.

기본 설계 방식

Control Tower의 기본 단위는 Landing Zone입니다. Landing Zone은 AWS Organizations 기반의 멀티 계정 환경이며, 그 안에 OU, 계정, 사용자 접근, 로그 계정, 감사 계정, Control이 포함됩니다.

공식 기본 구조에는 Security OU가 포함됩니다. Security OU에는 보통 Log Archive Account와 Audit Account가 위치합니다. Log Archive Account는 중앙 로그 저장 역할을 하고, Audit Account는 보안 감사와 읽기 전용 점검 역할을 담당합니다.

Sandbox OU는 초기 설정에서 선택적으로 만들 수 있습니다. 운영 환경이 커지면 Workloads, Infrastructure, PolicyStaging, Suspended 같은 OU를 추가해 목적별로 계정을 분리하는 방식이 일반적입니다.

OU 구조에 따라 정책을 다르게 적용하는 이유

Control Tower에서 Control은 OU 단위로 적용됩니다. 그래서 OU 구조는 단순한 폴더 구분이 아니라 정책 적용 범위를 결정하는 설계 단위입니다.

예를 들어 운영 서비스 계정에는 강한 제한이 필요하지만, Sandbox 계정에는 실험을 허용해야 할 수 있습니다. 반대로 Sandbox 계정에는 비용과 리전 제한을 강하게 두고, 운영 계정에는 변경 권한과 배포 경로를 엄격히 제한할 수 있습니다.

OU와 SCP 설계를 더 깊게 이해하려면 AWS Organizations + SCP 설계 방법을 함께 보면 좋습니다. Control Tower의 예방 통제는 Organizations 정책과 연결되기 때문에 OU 상속 구조를 같이 이해해야 합니다.

Control 정책의 차이

Control Tower의 Control은 동작 방식에 따라 preventive, detective, proactive로 나뉩니다. 이름은 비슷하지만 적용 시점과 구현 방식이 다릅니다.

Preventive control은 위반 작업이 실행되지 못하게 차단합니다. Detective control은 이미 만들어진 리소스나 이벤트를 감지해 위반 상태를 보여줍니다. Proactive control은 CloudFormation으로 리소스가 만들어지기 전에 정책 위반 여부를 검사합니다.

시험이나 설계 검토에서 중요한 부분은 “정책이 언제 동작하는가”입니다. 차단이 필요한지, 탐지만 필요한지, 배포 전에 막아야 하는지에 따라 선택하는 Control 유형이 달라집니다.

일반적인 설계 방안

처음부터 복잡한 OU 계층을 만들면 운영이 어려워질 수 있습니다. 초기에는 Security, Infrastructure, Workloads, Sandbox, PolicyStaging 정도로 목적을 분리하고, 계정 수와 운영 요구가 커질 때 세분화하는 방식이 현실적입니다.

Production과 NonProduction은 분리하는 것이 좋습니다. 운영 계정에는 변경 통제와 보안 기준을 강하게 적용하고, 개발·검증 계정은 실험과 배포 속도를 고려해 일부 정책을 다르게 둘 수 있습니다.

Security OU와 Management Account는 일상 작업 계정으로 사용하지 않는 편이 좋습니다. Management Account는 조직과 Landing Zone 관리에 집중하고, 보안 점검은 Audit Account, 로그 보관은 Log Archive Account로 분리하는 구조가 관리하기 쉽습니다.

초기 배포 방식: 콘솔, API, CloudFormation, Terraform

Control Tower Landing Zone은 콘솔로 시작할 수 있고, API 또는 CloudFormation으로도 생성할 수 있습니다. Landing Zone 배포에는 manifest가 사용되며, manifest에는 IAM Identity Center 연동, 중앙 로깅, AWS Config, 보안 역할, governed Region 같은 기본 설정이 들어갑니다.

CloudFormation은 Landing Zone 자체나 EnabledControl 같은 Control Tower 리소스를 선언적으로 관리할 때 사용할 수 있습니다. 다만 실제 배포 전에는 사용하려는 Landing Zone 버전과 manifest 스키마를 확인해야 합니다.

Terraform은 Control Tower의 Account Factory for Terraform, 즉 AFT에서 많이 사용됩니다. AFT는 Terraform 기반 계정 요청과 계정 커스터마이징을 GitOps 방식으로 처리합니다. 단, AFT는 애플리케이션 리소스 배포용 파이프라인이 아니라 계정 프로비저닝과 초기 계정 설정 자동화를 위한 도구로 이해하는 것이 정확합니다.

CloudFormation과 Terraform 샘플 코드

아래 코드는 구조 이해를 위한 더미 예시입니다. 실제 계정 ID, KMS Key ARN, OU ARN, Control ARN은 운영 환경 값을 그대로 공개하지 말고 별도 보안 기준에 따라 관리해야 합니다.

CloudFormation 예시는 Landing Zone 설정을 선언적으로 표현하는 흐름이고, Terraform 예시는 AFT에서 계정 요청 파일을 통해 새 계정을 만드는 흐름입니다. 실제 운영에서는 계정 생성, 네트워크 기본값, 보안 로그, 기본 VPC 삭제, 태그 정책 같은 초기 설정을 함께 표준화합니다.

보안 설정 기준

Control Tower 보안 설계의 핵심은 Management Account를 일상 작업에서 분리하고, 보안 감사와 로그 보관을 별도 계정으로 나누는 것입니다. Management Account는 조직 관리와 Landing Zone 관리에 집중해야 합니다.

사용자 접근은 IAM Identity Center를 기준으로 표준화하는 것이 좋습니다. 계정별 IAM User를 직접 늘리는 방식은 장기적으로 관리가 어려워지고, 권한 회수와 감사가 복잡해집니다.

계정 간 역할 전환 구조를 이해하려면 AWS IAM AssumeRole 이해하기를 함께 보면 좋습니다. Control Tower 환경에서도 여러 계정에 접근할 때는 역할 기반 접근 흐름을 이해해야 합니다.

운영 시 주의할 점

첫 번째 주의점은 기존 AWS Organizations 환경에 Control Tower를 도입하는 경우입니다. 기존 OU와 계정이 이미 있다면 Control Tower를 새로 시작하는 것과 기존 조직에 거버넌스를 확장하는 것은 다르게 봐야 합니다.

두 번째는 Control 변경 전 검증입니다. OU에 적용되는 preventive control이나 SCP는 계정 내부 IAM 권한보다 상위에서 동작할 수 있으므로, 잘못 적용하면 정상 서비스 작업도 차단될 수 있습니다.

세 번째는 drift 관리입니다. Control Tower가 관리하는 리소스를 외부에서 임의로 변경하면 Landing Zone이나 계정이 의도한 기준에서 벗어날 수 있습니다. 운영에서는 변경 경로를 표준화하고, 정책 변경은 PolicyStaging OU에서 먼저 검증하는 흐름이 안전합니다.

참고 공식문서

아래 문서는 글 전체를 검증할 때 참고한 대표 공식문서입니다. 주요 섹션에는 필요한 링크만 넣고, 전체 확인용 문서는 마지막에 모았습니다.

FAQ

mTLS란 무엇인가

mTLS는 mutual TLS의 약자입니다. 일반 TLS가 주로 클라이언트가 서버 인증서를 확인하는 방식이라면, mTLS는 서버도 클라이언트 인증서를 확인합니다.

즉, mTLS는 통신을 암호화하는 것에서 끝나지 않고 “요청을 보낸 쪽이 신뢰할 수 있는 주체인지”까지 확인합니다. 마이크로서비스 환경에서는 서비스 A가 서비스 B를 호출할 때 서로의 신원을 검증하는 데 사용할 수 있습니다.

EKS에서 mTLS가 직접 기능이 아닌 이유

EKS는 Kubernetes Control Plane을 제공하는 관리형 서비스입니다. EKS 자체가 모든 Pod 간 트래픽에 mTLS를 자동으로 적용하는 구조는 아닙니다.

EKS에서 mTLS를 적용하려면 보통 Service Mesh, Ingress Gateway, 애플리케이션 TLS 설정 중 하나를 사용합니다. AWS 공식 모범 사례에서도 EKS 네트워크 보안을 설명할 때 Service Mesh를 암호화와 보안 정책을 추가하는 계층으로 분리해서 설명합니다.

NetworkPolicy나 Security Group for Pods는 주로 어떤 트래픽을 허용할지 제어합니다. mTLS는 그 트래픽이 암호화되었는지, 그리고 상대가 신뢰할 수 있는 주체인지 확인하는 역할에 가깝습니다.

Service Mesh에서 Pod 간 통신을 보호하는 방식

Service Mesh는 애플리케이션 코드 바깥에서 서비스 간 통신을 제어하는 계층입니다. Istio 기준으로 보면 Pod 옆의 proxy 또는 node 단위 구성요소가 트래픽을 가로채고, 서비스 간 통신에 mTLS를 적용합니다.

이 방식의 장점은 애플리케이션마다 TLS 로직을 직접 구현하지 않아도 된다는 점입니다. 서비스는 기존처럼 HTTP 또는 gRPC 요청을 보내고, Mesh 계층이 인증서 기반 신원 확인과 암호화를 처리합니다.

EKS에서 Istio를 사용할 경우, 서비스 계정 기반의 workload identity와 인증서가 연결됩니다. 그래서 “어떤 Pod IP에서 왔는가”보다 “어떤 workload identity가 호출했는가”를 기준으로 보안 정책을 설계할 수 있습니다.

Istio에서 STRICT와 PERMISSIVE를 구분하는 이유

Istio에서 mTLS를 적용할 때 자주 보는 개념이 `PERMISSIVE`와 `STRICT`입니다. `PERMISSIVE`는 mTLS 트래픽과 일반 평문 트래픽을 모두 받을 수 있는 전환용 모드입니다.

반면 `STRICT`는 mTLS가 아닌 트래픽을 허용하지 않는 모드입니다. 운영 중인 시스템을 한 번에 바꾸기 어렵다면 먼저 PERMISSIVE로 관찰하고, 준비가 끝난 뒤 STRICT로 전환하는 흐름을 사용할 수 있습니다.

시험 관점에서는 “mTLS를 켰다”는 말만으로는 부족합니다. 실제로 평문 트래픽이 차단되는지, namespace 전체에 적용하는지, 특정 workload에만 적용하는지를 구분해야 합니다.

Gateway에서 외부 클라이언트를 인증하는 방식

Service Mesh의 mTLS가 주로 내부 서비스 간 통신을 보호한다면, Gateway의 mTLS는 외부에서 들어오는 클라이언트를 인증하는 데 사용합니다.

예를 들어 파트너 시스템이 EKS 안의 API를 호출해야 한다면 일반 HTTPS만으로는 “서버가 진짜인지”만 확인할 수 있습니다. mTLS Gateway를 사용하면 서버가 클라이언트 인증서까지 확인하므로, 허용된 클라이언트만 진입하도록 만들 수 있습니다.

Istio Gateway에서는 TLS mode를 `MUTUAL`로 설정하고, 서버 인증서와 클라이언트 인증서를 검증할 CA 정보를 함께 구성합니다. 실제 운영 값은 Secret에 저장하고, 블로그나 문서에는 노출하지 않는 것이 안전합니다.

인증서와 신뢰 체인 관리

mTLS의 핵심은 인증서입니다. 서버 인증서, 클라이언트 인증서, 그리고 이 인증서를 신뢰할 수 있는지 판단하는 CA가 필요합니다.

Service Mesh를 사용하면 인증서 발급과 갱신을 Mesh가 자동화할 수 있습니다. Istio는 기본 CA를 사용할 수 있고, 필요하면 외부 CA와 연동하는 방식도 검토할 수 있습니다.

Gateway mTLS에서는 서버 인증서뿐 아니라 클라이언트 인증서를 검증할 CA 정보도 필요합니다. 인증서가 만료되거나 신뢰 체인이 맞지 않으면 연결은 암호화 이전 단계에서 실패할 수 있습니다.

mTLS와 AuthorizationPolicy의 차이

mTLS는 상대의 신원을 확인합니다. 하지만 신원이 확인되었다고 해서 모든 접근을 허용해야 한다는 뜻은 아닙니다.

예를 들어 `order-api`와 `payment-api`가 모두 유효한 인증서를 가지고 있더라도, `payment-api`에는 특정 namespace나 service account만 접근하도록 제한할 수 있어야 합니다. 이때 필요한 것이 AuthorizationPolicy 같은 접근 제어 정책입니다.

정리하면 mTLS는 “누구인지 확인”이고, AuthorizationPolicy는 “무엇을 할 수 있는지 제한”입니다. 둘을 함께 사용해야 서비스 간 통신 보안이 완성됩니다.

EKS에서 설계할 때 주의할 점

mTLS는 보안성을 높이지만 운영 복잡도도 함께 증가합니다. 인증서 수명, CA 관리, rollout 순서, sidecar 또는 mesh 구성요소의 리소스 사용량을 함께 봐야 합니다.

모든 통신에 무조건 mTLS를 적용하는 것보다 보호해야 할 경계가 어디인지 먼저 정하는 것이 좋습니다. 내부 서비스 간 호출을 보호하려면 Service Mesh가 적합하고, 외부 파트너나 내부 운영 클라이언트의 진입을 제한하려면 Gateway mTLS가 적합합니다.

AWS App Mesh는 mTLS를 지원하지만, 공식 문서 기준으로 2026년 9월 30일 지원 종료가 공지되어 있습니다. 신규 설계에서는 이 일정을 고려해 Istio, Linkerd, Gateway 중심 구성을 검토하는 것이 안전합니다.

대표 YAML 예시

아래 예시는 실제 환경 값이 아닌 더미 예시입니다. 실제 인증서 이름, Secret 이름, namespace, 도메인 값은 운영 환경에 맞게 관리하고 외부에 노출하지 않아야 합니다.

이 예시에서 첫 번째 설정은 내부 서비스 간 통신을 mTLS로 강제하는 흐름입니다. 두 번째 설정은 인증된 주체 중에서도 특정 service account만 허용하는 흐름입니다. 세 번째 설정은 외부 클라이언트가 Gateway에 접근할 때 클라이언트 인증서를 요구하는 흐름입니다.

FAQ

AWS Load Balancer Controller란 무엇인가

AWS Load Balancer Controller는 Kubernetes 리소스를 보고 AWS Load Balancer 리소스를 생성하고 관리하는 컨트롤러입니다. 사용자가 AWS 콘솔에서 ALB나 NLB를 직접 만드는 방식이 아니라, Kubernetes에 선언한 상태를 AWS 리소스로 맞추는 방식입니다.

대표적으로 `Ingress`는 ALB 생성 흐름과 연결되고, `Service type: LoadBalancer`는 NLB 생성 흐름과 연결됩니다. Controller는 Kubernetes API를 감시하다가 필요한 AWS 리소스를 만들고, 변경 사항이 생기면 다시 맞춥니다.

핵심은 Controller가 “Kubernetes 리소스와 AWS Load Balancer 사이의 번역기” 역할을 한다는 점입니다.

EKS에서 LB Controller를 사용할 수 있는 이유

Kubernetes Controller는 API Server에 저장된 리소스 상태를 계속 관찰합니다. AWS Load Balancer Controller도 같은 방식으로 `Ingress`, `Service`, `TargetGroupBinding` 같은 리소스를 감시합니다.

Controller Pod는 EKS 안에서 실행되지만, ALB, NLB, Target Group, Listener 같은 AWS 리소스를 만들려면 AWS API 호출 권한이 필요합니다. 그래서 IRSA 또는 EKS Pod Identity 같은 방식으로 Controller에 IAM 권한을 부여합니다.

이 구조 덕분에 사용자는 Kubernetes YAML을 적용하고, Controller는 그 YAML을 보고 AWS 네트워크 리소스를 생성하는 방식으로 운영할 수 있습니다.

NLB는 언제 생성되는가

NLB는 주로 `Service` 리소스에서 생성됩니다. `type: LoadBalancer`를 사용하고 `spec.loadBalancerClass: service.k8s.aws/nlb`를 지정하면 AWS Load Balancer Controller가 해당 Service를 NLB 대상으로 처리합니다.

NLB는 L4 계층에서 TCP, UDP, TLS 트래픽을 처리하는 데 적합합니다. HTTP 경로 기반 라우팅보다 네트워크 계층의 빠른 전달과 고정적인 연결 처리가 필요할 때 자주 사용합니다.

과거 방식에서는 annotation으로 NLB 생성을 지정하는 예시도 많지만, 새 구성에서는 `loadBalancerClass`를 함께 이해하는 것이 좋습니다.

NLB 생성 시 EKS 안에 생기는 리소스

NLB를 만들 때 사용자가 직접 생성하는 핵심 리소스는 `Service`입니다. 이 Service가 어떤 Pod로 트래픽을 보낼지는 selector와 EndpointSlice를 통해 연결됩니다.

AWS Load Balancer Controller는 Service를 처리하는 과정에서 `TargetGroupBinding`을 사용할 수 있습니다. TargetGroupBinding은 Kubernetes Service와 AWS Target Group을 연결하는 CRD입니다.

트러블슈팅할 때는 Service만 보면 부족합니다. Service, EndpointSlice, TargetGroupBinding, Event, Controller 로그를 같이 봐야 실제로 어떤 단계에서 막혔는지 알 수 있습니다.

ALB는 언제 생성되는가

ALB는 주로 `Ingress` 리소스에서 생성됩니다. `ingressClassName: alb`를 지정하거나 관련 IngressClass를 구성하면 AWS Load Balancer Controller가 해당 Ingress를 처리합니다.

ALB는 L7 계층에서 HTTP/HTTPS 요청을 처리합니다. Host 기반 라우팅, Path 기반 라우팅, TLS 종료, Listener Rule 같은 웹 트래픽 제어가 필요할 때 적합합니다.

Ingress annotation을 사용하면 internet-facing 또는 internal scheme, target type, health check path, certificate, listener port 같은 세부 동작을 설정할 수 있습니다.

ALB 생성 시 EKS 안에 생기는 리소스

ALB 흐름에서 사용자가 주로 작성하는 리소스는 `Ingress`, `Service`, `Deployment`입니다. Ingress는 외부 요청 규칙을 정의하고, Service는 Pod 집합의 접근 지점을 제공합니다.

추가로 `IngressClass`와 `IngressClassParams`를 사용할 수 있습니다. IngressClass는 어떤 Controller가 Ingress를 처리할지 지정하고, IngressClassParams는 ALB 관련 기본 설정을 묶는 데 사용할 수 있습니다.

Controller는 이 정보를 기반으로 AWS에 ALB, Listener, Listener Rule, Target Group을 생성합니다. EKS 안에서는 관련 Event와 TargetGroupBinding 상태를 확인할 수 있습니다.

TargetGroupBinding이 중요한 이유

TargetGroupBinding은 Kubernetes Service와 AWS Target Group을 연결하는 리소스입니다. 쉽게 말해 “이 Service의 대상 Pod 또는 Node를 이 Target Group에 등록하라”는 연결 정보입니다.

AWS Load Balancer Controller는 Ingress, Service, Gateway 흐름을 처리할 때 TargetGroupBinding을 내부적으로 사용할 수 있습니다. 공식 문서에서도 TargetGroupBinding은 controller에 의해 자동 생성될 수 있다고 설명합니다.

또한 이미 존재하는 AWS Target Group을 Kubernetes Service와 연결하고 싶을 때 TargetGroupBinding을 직접 작성하는 방식도 가능합니다.

IngressClass, loadBalancerClass, GatewayClass 차이

`IngressClass`는 어떤 Controller가 Ingress를 처리할지 나타냅니다. ALB Ingress를 만들 때 `ingressClassName: alb`를 쓰는 이유가 여기에 있습니다.

`loadBalancerClass`는 Service type LoadBalancer를 어떤 Controller가 처리할지 나타냅니다. AWS Load Balancer Controller에서 NLB를 처리할 때 `service.k8s.aws/nlb` 값을 사용할 수 있습니다.

`GatewayClass`는 Gateway API에서 어떤 구현체가 Gateway를 처리할지 나타냅니다. 사용자가 말한 `lb choice`는 공식 리소스명으로 확인되지는 않으며, 문맥상 `loadBalancerClass` 또는 `IngressClass`를 의미한 것으로 보는 것이 맞습니다.

Instance Target과 IP Target 차이

Target Group에는 대상 등록 방식이 있습니다. `instance` 모드는 Worker Node를 Target으로 등록하고 NodePort를 통해 Pod로 전달합니다.

`ip` 모드는 Pod IP를 Target Group에 직접 등록합니다. 이 방식은 Pod로 더 직접적인 경로를 만들 수 있지만, VPC CNI와 Pod IP 접근 가능성을 고려해야 합니다.

ALB와 NLB 모두 어떤 target type을 사용할지에 따라 보안 그룹, health check, 트래픽 경로, 장애 분석 방식이 달라질 수 있습니다.

대표 YAML 예시

아래 예시는 실제 환경 값이 아닌 더미 예시입니다. 실제 도메인, 계정 ID, Target Group ARN, 인증서 ARN, subnet ID는 블로그에 노출하지 않는 것이 안전합니다.

YAML을 볼 때는 어떤 리소스가 AWS Load Balancer 생성을 트리거하는지 먼저 보면 됩니다. ALB는 Ingress 중심, NLB는 Service 중심, TargetGroupBinding은 Service와 Target Group 연결 중심입니다.

트러블슈팅 시 봐야 할 것

문제가 생기면 Kubernetes 리소스와 AWS 리소스를 함께 봐야 합니다. Controller는 두 세계를 연결하므로 한쪽만 보면 원인을 놓치기 쉽습니다.

특히 Target Group Health Check가 실패하면 Load Balancer는 생성되어 있어도 실제 트래픽은 Pod로 전달되지 않을 수 있습니다. 그래서 “LB가 생성됐는가”와 “Target이 healthy인가”를 분리해서 확인해야 합니다.

FAQ

Kubernetes 트래픽 진입 구조를 먼저 이해하기

Kubernetes에서 외부 사용자의 요청이 Pod까지 도달하려면 보통 여러 계층을 거칩니다. 외부 Load Balancer, Ingress 또는 Gateway, Service, Pod가 순서대로 관여합니다.

Service는 Pod 집합에 안정적인 접근 지점을 제공합니다. Ingress나 Gateway는 HTTP/HTTPS 요청을 어떤 Service로 보낼지 정하는 진입 규칙을 담당합니다.

따라서 ALB Controller, NGINX Ingress, Gateway API, Istio를 비교할 때는 “외부 진입을 처리하는가”, “클러스터 내부에서 프록시하는가”, “서비스 간 통신까지 제어하는가”를 나눠서 봐야 합니다.

AWS Load Balancer Controller란 무엇인가

AWS Load Balancer Controller는 Kubernetes 리소스를 보고 AWS Load Balancer를 생성하고 관리하는 컨트롤러입니다. Ingress 리소스를 사용하면 ALB를 만들 수 있고, Service type LoadBalancer를 사용하면 NLB를 만들 수 있습니다.

이 방식의 핵심은 트래픽 진입점이 AWS 관리형 Load Balancer라는 점입니다. 클러스터 밖의 사용자는 ALB 또는 NLB로 접근하고, Load Balancer가 Kubernetes Service나 Pod 쪽으로 트래픽을 전달합니다.

AWS 환경에서 L7 라우팅, TLS 종료, 보안 그룹, AWS 네트워크 통합을 자연스럽게 활용하고 싶을 때 자주 사용합니다.

NGINX Ingress Controller란 무엇인가

NGINX Ingress Controller는 Kubernetes Ingress 리소스를 해석하고, 클러스터 안의 NGINX 프록시가 HTTP/HTTPS 요청을 Service로 라우팅하게 만드는 컨트롤러입니다.

Host 기반 라우팅, Path 기반 라우팅, 리다이렉트, 헤더 처리 같은 웹 프록시 기능을 클러스터 내부에서 세밀하게 제어할 수 있습니다.

AWS에서는 ALB 뒤에 NGINX Ingress를 두는 구조도 가능합니다. 이 경우 ALB는 외부 진입점 역할을 하고, NGINX는 클러스터 내부의 세부 라우팅 역할을 맡습니다.

Gateway란 무엇인가

Gateway라는 단어는 문맥에 따라 의미가 달라질 수 있습니다. Kubernetes 표준 관점에서는 Gateway API의 Gateway를 의미하는 경우가 많습니다.

Gateway API는 기존 Ingress보다 역할을 더 명확히 나누려는 표준 API입니다. GatewayClass는 어떤 구현체를 사용할지, Gateway는 실제 진입점을, HTTPRoute는 어떤 요청을 어떤 Service로 보낼지 정의합니다.

즉, Gateway API는 특정 제품 하나가 아니라 Kubernetes 트래픽 진입을 표현하는 표준 리소스 모델입니다.

Istio란 무엇인가

Istio는 Service Mesh입니다. 단순히 외부 트래픽을 Service로 보내는 도구라기보다, 서비스 간 통신을 제어하고 보호하고 관측하는 데 초점이 있습니다.

Istio를 사용하면 mTLS, 트래픽 분할, 재시도, 타임아웃, 회로 차단, 관측성 같은 기능을 서비스 간 통신에 적용할 수 있습니다.

외부 트래픽 진입에는 Istio Ingress Gateway를 사용할 수 있지만, Istio의 핵심 가치는 내부 서비스 간 통신 제어까지 포함한다는 점입니다.

ALB Controller와 NGINX Ingress의 차이

ALB Controller는 AWS 관리형 Load Balancer를 생성하고 관리합니다. 반면 NGINX Ingress Controller는 클러스터 안에서 동작하는 NGINX 프록시가 Ingress 규칙을 처리합니다.

둘은 경쟁 관계로만 볼 필요는 없습니다. 요구사항에 따라 ALB만 쓰거나, ALB 뒤에 NGINX를 두는 구조도 선택할 수 있습니다.

Gateway와 Ingress의 차이

Ingress는 오래전부터 사용된 Kubernetes HTTP 라우팅 리소스입니다. 단순한 웹 서비스 노출에는 충분하지만, 역할 분리와 확장성 측면에서 한계가 있었습니다.

Gateway API는 이 한계를 줄이기 위해 GatewayClass, Gateway, Route 계층으로 역할을 나눕니다. 인프라 담당자는 Gateway를 관리하고, 애플리케이션 담당자는 HTTPRoute를 관리하는 식으로 책임을 분리할 수 있습니다.

따라서 Gateway API는 단순히 Ingress의 이름만 바꾼 것이 아니라, 클러스터 진입 구조를 더 표준적이고 확장 가능하게 표현하는 방식입니다.

Istio Gateway와 Kubernetes Gateway API의 차이

Istio Gateway는 Istio에서 외부 트래픽을 Mesh 안으로 들여보내기 위해 사용하는 Istio 리소스입니다. VirtualService와 함께 어떤 Host와 경로를 어떤 서비스로 보낼지 정의하는 방식으로 사용됩니다.

Kubernetes Gateway API는 Kubernetes 표준 API입니다. 특정 구현체에 종속된 개념이 아니라 여러 컨트롤러가 구현할 수 있는 공통 모델입니다.

Istio는 Gateway API를 구현할 수 있습니다. 따라서 “Istio Gateway”와 “Gateway API”는 같은 말이 아니며, 하나는 Istio의 리소스이고 다른 하나는 Kubernetes 표준 모델로 구분해야 합니다.

대표 아키텍처 패턴

아래는 실제 도메인이나 IP가 아닌 개념 예시입니다. 환경에 따라 Service, Target Group, Gateway 구현체 구성은 달라질 수 있습니다.

패턴을 고를 때는 기능보다 운영 모델을 먼저 봐야 합니다. AWS Load Balancer를 직접 활용할지, 클러스터 내부 프록시를 둘지, 서비스 메시까지 필요한지에 따라 선택이 달라집니다.

무엇을 선택해야 할까

AWS에서 단순히 외부 HTTP 서비스를 노출하려면 AWS Load Balancer Controller가 가장 자연스러운 선택일 수 있습니다. AWS ALB와 보안 그룹, 인증서, Target Group 통합을 활용하기 쉽기 때문입니다.

복잡한 HTTP 프록시 제어가 필요하면 NGINX Ingress Controller가 적합할 수 있습니다. 표준화된 차세대 진입 모델과 역할 분리를 원한다면 Gateway API를 검토할 수 있습니다.

서비스 간 mTLS, 트래픽 분할, 재시도, 관측성처럼 내부 통신 제어가 핵심이면 Istio가 더 적합합니다. Istio는 외부 진입 도구라기보다 Service Mesh로 보는 것이 정확합니다.

FAQ

AI 판도가 달라진 이유

초기 생성형 AI 경쟁은 주로 어떤 모델이 더 자연스럽게 답하고, 더 긴 문맥을 처리하고, 더 어려운 추론을 수행하는지에 집중됐다. 하지만 2026년 현재 AI 시장은 모델 성능만으로 설명하기 어렵다. 성능이 좋아질수록 더 많은 GPU, 전력, 데이터센터, 네트워크, 메모리, 클라우드 계약이 필요해졌기 때문이다.

이 변화는 AI 기업의 경쟁 조건을 바꿨다. 뛰어난 모델을 만들 수 있어도 충분한 연산 자원을 확보하지 못하면 학습과 추론 규모를 키우기 어렵다. 반대로 클라우드 기업은 AI 모델을 통해 데이터센터 수요를 만들고, 반도체 기업은 그 수요를 통해 다음 세대 칩과 네트워킹 장비를 판매한다.

따라서 AI 판도는 모델 회사끼리의 순위 경쟁이 아니라, 모델·클라우드·반도체·데이터센터·애플리케이션이 맞물린 산업 구조 경쟁으로 봐야 한다.

최상위 모델 경쟁: OpenAI·Anthropic·Google·Meta·xAI

OpenAI는 ChatGPT와 API 생태계를 바탕으로 대중 시장과 개발자 시장에서 강한 위치를 가지고 있다. Microsoft와의 관계도 핵심이다. OpenAI는 2026년 4월 발표에서 Microsoft가 OpenAI의 주요 클라우드 파트너로 남고, OpenAI 제품이 우선 Azure에서 제공된다고 설명했다. 동시에 OpenAI가 다른 클라우드에서도 제품을 제공할 수 있는 유연성이 커졌다는 점도 중요하다.

Anthropic은 Claude를 중심으로 기업 고객, 안전성, 장문 처리, 코딩 및 업무 자동화 영역에서 존재감을 키우고 있다. Anthropic은 Google 및 Broadcom과 차세대 TPU 용량 확대를 발표했고, AWS Trainium, Google TPU, NVIDIA GPU를 함께 활용한다고 밝혔다. 이는 특정 칩이나 클라우드 하나에만 묶이지 않으려는 전략으로 해석할 수 있다.

Google은 Gemini, 검색, YouTube, Android, Workspace, Google Cloud, TPU를 모두 가진 수직 통합형 플레이어다. Meta는 Llama 계열 공개 모델을 통해 개발자와 기업의 자체 배포 수요를 흡수하고 있다. xAI는 X 플랫폼과 실시간 데이터 흐름을 바탕으로 차별화를 시도한다. 이들은 모두 같은 AI 기업처럼 보이지만, 실제 강점은 유통망, 데이터, 인프라, 제품 접점에서 다르게 나타난다.

AI 인프라 권력: NVIDIA·Broadcom·TSMC가 중요한 이유

AI 산업의 병목은 점점 더 물리적인 영역으로 이동하고 있다. 모델이 커지고 사용량이 늘수록 필요한 것은 GPU, HBM, 고속 네트워킹, 액체 냉각, 전력, 파운드리 생산 능력이다. 그래서 NVIDIA, Broadcom, TSMC, 메모리 기업, 서버 제조사, 데이터센터 사업자가 AI 판도의 중심으로 들어왔다.

NVIDIA는 GPU와 CUDA 생태계, 네트워킹, 랙 스케일 시스템을 통해 AI 학습과 추론 인프라의 핵심 공급자로 남아 있다. Broadcom은 맞춤형 ASIC과 고속 네트워킹에서 중요하다. Google TPU처럼 특정 클라우드와 대형 AI 고객에게 최적화된 칩이 늘어날수록 Broadcom의 역할도 커진다.

TSMC는 최첨단 반도체 제조의 핵심 축이다. AI 칩 설계사가 늘어나도 실제 생산 능력과 첨단 패키징이 충분하지 않으면 공급은 제한된다. 결국 AI 판도는 소프트웨어 경쟁처럼 보이지만, 아래층에는 제조와 전력의 제약이 깔려 있다.

AI 판도 핵심 축 표로 보기

AI 생태계는 한 줄로 설명하기 어렵다. 아래 표처럼 각 축이 서로 다른 방식으로 수익과 영향력을 만든다.

핵심은 한 기업이 모든 영역을 완전히 지배하기 어렵다는 점이다. 모델 회사는 클라우드와 칩이 필요하고, 클라우드 회사는 인기 있는 모델과 기업 고객이 필요하며, 반도체 회사는 대규모 수요를 만들어 줄 AI 서비스가 필요하다.

클라우드 기업의 전략: Microsoft·AWS·Google Cloud·Oracle

Microsoft는 OpenAI와의 관계를 통해 Azure 수요와 Copilot 제품군을 동시에 키우고 있다. OpenAI 발표 기준으로 Microsoft는 OpenAI의 주요 클라우드 파트너로 남아 있고, OpenAI 관련 지식재산권 라이선스도 장기간 유지된다. 이는 Microsoft가 단순 투자자가 아니라 AI 배포망과 제품화를 함께 잡는 구조라는 뜻이다.

AWS는 Anthropic과의 협력, Trainium 같은 자체 칩, Bedrock 같은 모델 유통 계층을 통해 기업 AI 시장을 공략한다. Google Cloud는 Gemini와 TPU를 모두 보유했고, Anthropic의 TPU 사용 확대에도 관여한다. Oracle Cloud는 대형 GPU 클러스터와 AI 인프라 수요를 앞세워 후발 클라우드의 존재감을 키우고 있다.

클라우드 기업에게 AI는 단순 기능 추가가 아니다. AI는 데이터센터 사용량, 스토리지, 네트워크, 데이터베이스, 보안, 개발 도구까지 함께 끌어올리는 수요 엔진이다. 그래서 AI 경쟁은 곧 클라우드 시장 점유율 경쟁이기도 하다.

오픈소스 AI의 역할

오픈소스 AI는 폐쇄형 상위 모델을 완전히 대체한다기보다, 기업과 개발자가 선택할 수 있는 두 번째 경로를 만든다. 민감한 데이터를 외부 API로 보내기 어렵거나, 특정 산업에 맞게 모델을 조정해야 하거나, 추론 비용을 장기적으로 낮추려는 기업에게 오픈 모델은 현실적인 선택지가 된다.

Meta의 Llama 문서는 모델을 직접 받거나 파트너를 통해 사용할 수 있다고 안내한다. 이는 개발자와 기업이 클라우드 API만 쓰는 방식에서 벗어나, 자체 환경이나 파트너 환경에서 모델을 다루는 흐름을 보여준다.

다만 오픈소스가 항상 더 저렴하거나 더 안전한 것은 아니다. 운영 인력, GPU 비용, 보안 검토, 평가 체계, 업데이트 관리가 필요하다. 그래서 많은 기업은 폐쇄형 API와 오픈 모델을 함께 쓰는 혼합 전략을 선택할 가능성이 크다.

AI 애플리케이션 전쟁

AI가 실제 돈을 벌려면 사용자가 매일 쓰는 제품 안으로 들어가야 한다. Microsoft는 Office와 GitHub, Google은 검색과 Workspace, Salesforce는 CRM, Adobe는 콘텐츠 제작, ServiceNow는 업무 자동화 영역에서 AI를 붙이고 있다.

이 단계에서는 모델 성능만큼이나 워크플로우가 중요하다. 사용자가 별도 챗봇으로 이동하지 않아도 문서 작성, 코드 리뷰, 고객 응대, 보고서 작성, 이미지 편집, 데이터 분석 화면 안에서 AI를 쓰게 되면 사용 빈도와 지불 의사가 커진다.

따라서 AI 애플리케이션 경쟁은 모델 API를 누가 쓰느냐보다, 기존 업무 데이터를 누가 가지고 있고 사용자의 반복 행동을 누가 장악하고 있느냐에 달려 있다.

AI 시장의 핵심 이해관계

AI 시장의 이해관계는 서로 충돌하면서도 협력한다. 모델 기업은 독립성을 원하지만 클라우드와 반도체 없이는 규모를 키우기 어렵다. 클라우드 기업은 자체 모델을 키우면서도 외부 모델을 고객에게 제공해야 한다. 반도체 기업은 고객사가 자체 ASIC을 만들수록 일부 GPU 수요가 분산될 수 있지만, 전체 AI 인프라 수요가 커지는 효과도 얻는다.

이 때문에 시장은 단순한 승자 독식보다 다층 경쟁에 가깝다. OpenAI와 Microsoft는 협력하면서도 유연성을 조정하고, Anthropic은 AWS를 주요 파트너로 두면서 Google TPU와 NVIDIA GPU도 활용한다. Google은 자체 모델과 자체 칩을 모두 밀고, Meta는 오픈 모델로 생태계 영향력을 넓힌다.

AI 판도를 볼 때 중요한 질문은 하나다. 어느 회사가 가장 좋은 모델을 만들었는가보다, 어느 회사가 모델을 대규모로 운영하고 고객 업무 안에 배포하며 비용 구조를 버틸 수 있는가다.

앞으로 확인해야 할 포인트

첫째, 추론 비용이다. AI 사용량이 늘어날수록 학습보다 추론 인프라가 더 큰 비용 항목이 될 수 있다. 모델 경량화, 캐싱, 전용 ASIC, 온디바이스 AI가 중요해지는 이유다.

둘째, 전력과 데이터센터다. TrendForce는 2026년 주요 클라우드 기업의 AI 관련 인프라 투자가 크게 늘고 AI 서버 출하량 전망도 상향됐다고 설명했다. 이는 AI 수요가 소프트웨어 매출뿐 아니라 전력, 냉각, 부동산, 네트워크 투자로 이어지고 있음을 보여준다.

셋째, 규제와 데이터 통제다. AI가 검색, 업무, 금융, 의료, 교육에 들어갈수록 개인정보, 저작권, 보안, 모델 책임 문제가 커진다. 넷째, 실제 매출화다. 많은 기업이 AI 기능을 발표하고 있지만, 장기적으로는 사용자가 추가 비용을 지불할 만큼 생산성이 개선되는지가 판도를 가를 것이다.

FAQ

도메인이란 무엇인가

도메인은 사용자가 기억하기 쉬운 인터넷 주소입니다. 예를 들어 `example.com`은 사람이 읽는 이름이고, DNS는 이 이름을 실제 서비스가 있는 위치로 연결합니다.

사용자가 브라우저에 도메인을 입력하면 DNS 조회가 일어나고, 결과에 따라 웹 서버, CDN, 로드 밸런서, API 엔드포인트 같은 대상으로 트래픽이 이동합니다.

즉, 도메인은 서비스 자체가 아니라 서비스를 찾아가기 위한 이름입니다. 실제 연결 대상은 DNS 레코드와 연결된 리소스가 결정합니다.

서브도메인이란 무엇인가

서브도메인은 하나의 도메인 아래에 만든 하위 주소입니다. `www.example.com`, `api.example.com`, `admin.example.com`처럼 앞부분에 역할을 붙여 사용합니다.

서브도메인은 서비스를 역할별로 분리할 때 유용합니다. 웹 화면은 `www`, API는 `api`, 관리자 페이지는 `admin`, 정적 파일은 `static`처럼 나눌 수 있습니다.

서브도메인은 같은 상위 도메인을 공유하지만, DNS 레코드와 연결 대상은 서로 다르게 설정할 수 있습니다.

도메인과 서브도메인의 핵심 차이

도메인은 상위 주소 단위이고, 서브도메인은 그 아래에서 역할별로 나눈 주소입니다. 운영 관점에서는 주소 계층, DNS 레코드, 인증서 범위, 관리 책임이 달라집니다.

실무에서는 도메인 하나에 모든 서비스를 억지로 넣기보다, 서비스 성격에 맞게 서브도메인을 나눠 운영하는 경우가 많습니다.

AWS에서는 도메인을 어떻게 운영하는가

AWS에서는 Route 53 Hosted Zone을 사용해 도메인과 서브도메인의 DNS 레코드를 관리할 수 있습니다. 상위 도메인의 Hosted Zone에 서브도메인 레코드를 만들 수도 있고, 서브도메인 전용 Hosted Zone을 따로 만들어 위임할 수도 있습니다.

레코드 타입은 연결 대상에 따라 달라집니다. A 레코드는 IPv4 주소로 연결하고, CNAME은 다른 이름으로 연결합니다. Route 53 Alias 레코드는 CloudFront, S3, Elastic Load Balancing 같은 AWS 리소스로 트래픽을 보낼 때 자주 사용됩니다.

CloudFront, ALB, API Gateway, S3 정적 웹사이트 같은 서비스에 사용자 도메인을 붙일 때는 보통 DNS 레코드와 ACM 인증서 설정을 함께 구성합니다.

애플리케이션에서는 서브도메인을 어떻게 운영하는가

애플리케이션에서는 들어온 요청의 Host Header를 보고 어떤 서비스로 처리할지 판단할 수 있습니다. 예를 들어 `api.example.com` 요청은 API 서버로, `admin.example.com` 요청은 관리자 서비스로 보낼 수 있습니다.

서비스별로 배포를 나누는 방식도 많이 사용합니다. 프론트엔드, API, 관리자, 정적 파일 서버를 각각 다른 배포 단위로 운영하면 장애 영향 범위와 권한을 분리하기 쉽습니다.

또한 개발, 검증, 운영 환경을 `dev.example.com`, `staging.example.com`, `www.example.com`처럼 나눌 수 있습니다. 멀티테넌트 서비스에서는 고객별 서브도메인을 사용하는 방식도 있습니다.

트래픽 분기는 어디에서 일어나는가

트래픽 분기는 한 곳에서만 일어나지 않습니다. DNS, CDN, 로드 밸런서, API Gateway, 애플리케이션 내부 라우터에서 단계적으로 일어날 수 있습니다.

DNS 레벨에서는 `api.example.com`을 API Gateway로, `www.example.com`을 CloudFront로 보내는 식으로 큰 방향을 결정합니다. CloudFront에서는 경로 또는 Host 조건에 따라 Origin을 다르게 보낼 수 있습니다.

ALB는 Host-based Routing을 통해 Host Header 기준으로 Target Group을 나눌 수 있습니다. API Gateway는 Custom Domain과 API Mapping을 사용해 사용자 친화적인 API 주소를 구성할 수 있습니다.

대표 운영 패턴

아래는 실제 운영 도메인이 아닌 더미 예시입니다. 블로그 예시에는 실제 회사 도메인이나 내부 서비스 주소를 넣지 않는 것이 안전합니다.

이런 구조를 쓰면 사용자용 화면, API, 관리자 기능, 정적 리소스, 개발 환경을 주소 단위로 구분할 수 있습니다.

운영 시 주의할 점

첫째, TLS 인증서 범위를 확인해야 합니다. `example.com` 인증서와 `*.example.com` 와일드카드 인증서의 적용 범위는 다릅니다. 더 깊은 하위 주소까지 자동으로 모두 포함되는 것은 아닙니다.

둘째, 쿠키 Domain 설정과 CORS 정책을 주의해야 합니다. 서브도메인이 달라지면 브라우저 보안 정책 때문에 인증 쿠키나 API 호출이 예상과 다르게 동작할 수 있습니다.

셋째, DNS TTL과 SEO 영향도 고려해야 합니다. 주소 변경이나 서비스 이전을 자주 한다면 TTL을 적절히 조정하고, 검색엔진이 어떤 주소를 대표 주소로 볼지 정리해야 합니다.

마무리 요약

도메인은 서비스의 상위 주소 단위이고, 서브도메인은 그 아래에서 역할별로 나눈 하위 주소입니다.

AWS에서는 Route 53 Hosted Zone과 DNS 레코드로 도메인을 운영하고, CloudFront, ALB, API Gateway, S3 같은 서비스에 연결합니다.

애플리케이션에서는 Host Header와 라우팅 규칙을 사용해 서브도메인별 서비스를 분리합니다. 트래픽 분기는 DNS에서 시작하지만, 실제 서비스 분기는 CDN, 로드 밸런서, API Gateway, 애플리케이션 내부에서도 이어질 수 있습니다.

FAQ

Inspection VPC 구조를 먼저 이해하기

Inspection VPC는 여러 VPC 또는 온프레미스에서 오가는 트래픽을 중앙에서 검사하기 위한 VPC입니다. 보통 Transit Gateway를 중심에 두고, 트래픽을 Inspection VPC의 보안 장비로 보낸 뒤 다시 목적지로 전달합니다.

중요한 점은 AWS Network Firewall을 생성했다고 해서 트래픽이 자동으로 방화벽을 통과하지 않는다는 것입니다. 방화벽을 경유하려면 VPC Route Table과 TGW Route Table에서 트래픽 경로를 명시적으로 설계해야 합니다.

따라서 이 설계의 핵심은 “방화벽이 어디에 있는가”보다 “트래픽이 실제로 그 방화벽을 지나가도록 라우팅되어 있는가”입니다.

TGW Attachment subnet의 역할

TGW Attachment subnet은 Transit Gateway가 VPC에 들어오고 나가는 진입점 역할을 합니다. AWS는 TGW VPC Attachment를 만들 때 각 Availability Zone마다 하나의 subnet을 지정하도록 요구합니다.

이 subnet에 생성되는 TGW ENI는 트래픽의 출입구입니다. 공식 문서 기준으로 TGW Attachment subnet의 Route Table에는 TGW를 통해 도달해야 하는 VPC 내부 대상에 대한 적절한 route가 필요합니다.

따라서 TGW Attachment subnet은 일반 애플리케이션을 배치하는 공간이 아니라, 외부에서 들어온 트래픽을 다음 경유지로 넘기는 라우팅 지점으로 보는 것이 안전합니다.

Firewall subnet과 Workload subnet을 분리해야 하는 이유

Firewall subnet은 Network Firewall Endpoint 또는 보안 Appliance가 위치하는 subnet입니다. Workload subnet은 보호 대상 EC2, 애플리케이션, 데이터베이스 같은 리소스가 위치하는 subnet입니다.

두 역할을 같은 subnet에 섞으면 트래픽을 방화벽으로 강제 경유시키기 어렵습니다. 특히 같은 subnet 안의 host 간 트래픽은 middlebox appliance를 통해 라우팅할 수 없다는 제약이 있습니다.

그래서 기본 구조는 TGW Attachment subnet, Firewall subnet, Workload subnet을 분리하는 것입니다. 이 분리가 있어야 Route Table로 “진입 → 검사 → 대상” 흐름을 만들 수 있습니다.

local route가 트래픽을 우회시키는 원리

VPC Route Table에는 기본적으로 VPC CIDR을 향하는 `local` route가 있습니다. 이 route는 같은 VPC 내부 통신을 가능하게 합니다.

문제는 보안 장비를 경유해야 하는 트래픽도 local route 때문에 직접 대상 subnet으로 갈 수 있다는 점입니다. 예를 들어 TGW를 통해 들어온 트래픽의 목적지가 같은 VPC 내부라면, 특별한 route 설계가 없을 때 local 경로가 우선적인 내부 통신 경로가 됩니다.

따라서 Inspection VPC에서는 local route를 그대로 두는 것이 항상 안전하지 않습니다. 검사 대상 흐름은 Firewall Endpoint 또는 Appliance로 보내도록 route를 조정해야 합니다.

Network Firewall에서 local route target을 변경해야 하는 경우

Network Firewall은 트래픽을 자동으로 가로채지 않습니다. 방화벽이 검사할 트래픽은 Route Table을 통해 Firewall Endpoint로 보내야 합니다.

East-West 트래픽이나 TGW에서 들어온 내부 대상 트래픽을 검사해야 한다면 local route target 변경이 필요할 수 있습니다. AWS VPC는 기본 local route의 target을 다른 대상로 변경하거나, 나중에 다시 local로 복구하는 기능을 제공합니다.

다만 local route 전체를 바꾸면 영향 범위가 커질 수 있습니다. 그래서 운영 환경에서는 어떤 subnet과 어떤 트래픽을 검사할지 먼저 정하고, 더 구체적인 route로 해결 가능한지도 함께 검토해야 합니다.

더 구체적인 subnet route를 사용하는 경우

VPC Route Table은 여러 route가 있을 때 더 구체적인 경로를 우선합니다. 이를 Longest Prefix Match라고 이해하면 됩니다.

예를 들어 VPC 전체 CIDR이 `10.0.0.0/16`이고 Workload subnet이 `10.0.2.0/24`라면, `10.0.2.0/24`에 대한 route가 `10.0.0.0/16 local`보다 더 구체적입니다.

이 방식을 사용하면 전체 VPC local route를 바꾸지 않고, 특정 Workload subnet으로 가는 트래픽만 Firewall Endpoint로 보낼 수 있습니다. 영향 범위를 줄이고 장애 분석도 쉬워집니다.

TGW Appliance Mode와 대칭 라우팅

Network Firewall처럼 상태를 추적하는 보안 장비는 요청과 응답이 같은 검사 경로를 지나야 안정적으로 동작합니다. 요청은 A 방화벽을 지나고 응답은 B 방화벽을 지나면 세션 상태가 맞지 않아 트래픽이 차단될 수 있습니다.

TGW Appliance Mode는 Appliance가 위치한 VPC Attachment에서 flow가 같은 Availability Zone 경로를 유지하도록 돕습니다. 즉, Stateful inspection에서 필요한 대칭 라우팅을 만들기 위한 중요한 설정입니다.

다만 Appliance Mode만 켠다고 모든 문제가 해결되는 것은 아닙니다. TGW Route Table, VPC Route Table, subnet 분리, return route가 함께 맞아야 합니다.

권장 라우팅 예시

아래는 실제 환경 값이 아닌 더미 CIDR 기반 예시입니다. 실제 subnet ID, route table ID, endpoint ID, IP 주소는 블로그에 노출하지 않는 것이 안전합니다.

핵심은 TGW에서 들어온 트래픽이 Workload subnet으로 바로 가지 않고 Firewall Endpoint를 먼저 지나도록 만드는 것입니다. 반대 방향 응답도 동일한 검사 경로를 지나야 합니다.

잘못된 설계 예시

가장 흔한 실수는 TGW Attachment subnet에 보호 대상 리소스를 같이 배치하는 것입니다. 이 경우 외부에서 들어온 트래픽이 이미 목적지와 같은 subnet에 도착하므로 보안 장비 경유 경로를 만들기 어렵습니다.

두 번째 실수는 Firewall subnet에 일반 workload를 함께 배치하는 것입니다. Firewall subnet은 검사 경로를 위한 전용 subnet으로 유지하는 것이 좋습니다.

세 번째 실수는 Route Table을 수정하지 않고도 Network Firewall이 자동으로 트래픽을 검사한다고 생각하는 것입니다. 공식 문서 기준으로 Network Firewall을 경로에 넣으려면 VPC Route Table을 수정해야 합니다.

최신 방식: TGW Network Function Attachment

AWS는 Transit Gateway와 Network Firewall을 직접 연결하는 Network Function Attachment 방식도 제공합니다. 이 방식은 별도의 Inspection VPC와 개별 Firewall Endpoint 관리를 줄일 수 있습니다.

다만 이 글의 주요 설명은 기존 Inspection VPC 방식의 라우팅 원리를 이해하기 위한 것입니다. 최신 방식에서는 TGW Route Table에 Network Function Attachment를 대상으로 하는 static route를 추가해 검사 경로를 구성합니다.

따라서 실무에서는 기존 Inspection VPC 방식과 Network Function Attachment 방식 중 어떤 구조를 사용할지 먼저 정하고, 그 방식에 맞는 공식 문서를 기준으로 라우팅을 설계해야 합니다.

FAQ

AssumeRole이란 무엇인가

AssumeRole은 AWS STS에서 제공하는 API입니다. 이 API를 호출하면 특정 IAM Role을 맡고, 그 Role의 권한으로 사용할 수 있는 임시 자격 증명을 발급받습니다.

여기서 중요한 점은 “사용자 권한이 그대로 늘어나는 것”이 아니라는 점입니다. Role을 맡은 뒤에는 발급된 임시 자격 증명으로 AWS API를 호출하며, 이때 권한은 Role에 연결된 권한 정책을 기준으로 평가됩니다.

임시 자격 증명에는 Access Key ID, Secret Access Key, Session Token이 포함됩니다. 일반 장기 Access Key와 달리 만료 시간이 있으며, 만료 후에는 다시 발급받아야 합니다.

Identity-based Policy와 Resource-based Policy 이해하기

Identity-based Policy는 사용자, 그룹, Role 같은 IAM 주체에 붙는 정책입니다. 쉽게 말해 “이 주체가 무엇을 할 수 있는가”를 정의합니다.

Resource-based Policy는 리소스에 붙는 정책입니다. 쉽게 말해 “누가 이 리소스에 접근할 수 있는가”를 리소스 쪽에서 정의합니다.

AssumeRole을 이해할 때는 이 두 정책의 차이가 중요합니다. 같은 `Allow`처럼 보여도 권한을 부여하는 위치가 다르기 때문입니다.

Role Trust Policy는 어떤 정책인가

IAM Role에는 크게 두 종류의 정책이 연결됩니다. 하나는 누가 Role을 맡을 수 있는지 정하는 Trust Policy이고, 다른 하나는 Role을 맡은 뒤 무엇을 할 수 있는지 정하는 Permissions Policy입니다.

AWS 공식 설명 기준으로 Role의 Trust Policy는 Role에 연결된 Resource-based Policy입니다. 즉, Role이라는 리소스가 “어떤 Principal에게 나를 맡는 것을 허용할지” 정하는 구조입니다.

따라서 AssumeRole 문제에서는 항상 두 질문을 나눠서 봐야 합니다. “누가 Role을 맡을 수 있는가?”와 “Role을 맡은 뒤 무엇을 할 수 있는가?”는 서로 다른 문제입니다.

동일 계정 AssumeRole의 핵심 원리

동일 계정에서는 대상 Role의 Trust Policy가 같은 계정의 특정 사용자나 Role을 Principal로 직접 허용하면, 호출자 쪽 Identity-based Policy에 별도 `sts:AssumeRole` Allow가 없어도 Role 전환이 가능할 수 있습니다.

이유는 Role Trust Policy가 Role에 붙은 Resource-based Policy처럼 동작하기 때문입니다. 같은 계정의 Principal을 직접 지정한 리소스 기반 허용은 그 Principal에게 접근 권한을 부여하는 효과를 가질 수 있습니다.

하지만 이것을 “Trust Policy만 있으면 항상 된다”로 외우면 위험합니다. Explicit Deny, Permission Boundary, SCP, 조건 불충족 같은 제한이 있으면 AssumeRole은 실패할 수 있습니다.

교차 계정 AssumeRole과 무엇이 다른가

교차 계정 AssumeRole은 더 엄격하게 이해해야 합니다. 호출자 계정에서는 Identity-based Policy가 `sts:AssumeRole`을 허용해야 하고, 대상 계정의 Role Trust Policy도 해당 Principal 또는 계정을 신뢰해야 합니다.

즉, 다른 계정으로 넘어가는 요청은 한쪽 허용만으로 끝나지 않습니다. 요청자 계정과 리소스가 있는 계정 양쪽에서 평가가 일어납니다.

Root Principal을 Trust Policy에 넣은 경우 주의점

Trust Policy에서 `arn:aws:iam::123456789012:root`를 Principal로 지정하면, 특정 루트 사용자만 의미하는 것이 아니라 해당 AWS 계정 자체를 신뢰한다는 의미로 이해해야 합니다.

이 경우 계정 안의 모든 사용자가 자동으로 Role을 맡을 수 있다는 뜻은 아닙니다. 신뢰받은 계정의 관리자가 특정 사용자나 Role에 `sts:AssumeRole` 권한을 Identity-based Policy로 위임해야 합니다.

따라서 “특정 Principal 직접 허용”과 “계정 root Principal 허용”은 다르게 봐야 합니다. 이 차이를 이해하면 동일 계정과 교차 계정 Role 전환 문제를 더 정확히 판단할 수 있습니다.

그래도 AssumeRole이 실패하는 경우

Trust Policy와 IAM 정책이 맞아 보이는데도 AssumeRole이 실패할 수 있습니다. AWS 권한 평가는 단순히 Allow 하나만 보고 끝나지 않기 때문입니다.

명시적 거부가 있으면 Allow보다 우선합니다. 또한 Permission Boundary, SCP, RCP, Session Policy는 권한의 최대 범위를 제한할 수 있습니다.

MFA 조건, External ID 조건, 특정 태그 조건, Role Max Session Duration 같은 설정도 확인해야 합니다. 특히 조건이 있는 Trust Policy는 조건을 만족하지 않으면 Principal이 맞아도 실패합니다.

시험과 실무에서 헷갈리는 포인트

첫째, IAM 정책에 `sts:AssumeRole`이 없는데도 동일 계정 Role 전환이 되는 경우가 있습니다. 이때는 Role Trust Policy가 같은 계정 Principal을 직접 허용했는지 확인해야 합니다.

둘째, Trust Policy는 “Role을 맡을 수 있는가”를 정하고, Permissions Policy는 “Role을 맡은 뒤 무엇을 할 수 있는가”를 정합니다. 두 개념을 섞으면 원인을 잘못 찾게 됩니다.

셋째, 임시 자격 증명은 권한이 무제한인 키가 아닙니다. Role 권한, Session Policy, Boundary 계열 제한, 조직 정책의 영향을 받습니다.

마무리 요약

AssumeRole은 STS를 통해 Role 권한을 사용할 수 있는 임시 자격 증명을 발급받는 흐름입니다. 핵심은 호출자 권한과 Role Trust Policy를 분리해서 보는 것입니다.

동일 계정에서는 Trust Policy가 특정 Principal을 직접 허용하면 Identity-based Policy의 별도 Allow 없이도 가능할 수 있습니다. 반대로 교차 계정에서는 호출자 쪽 Allow와 대상 Role Trust Policy Allow가 함께 필요합니다.

마지막으로 Explicit Deny와 Permission Boundary, SCP, 조건 정책은 항상 함께 확인해야 합니다. AssumeRole 문제는 “Allow가 있는가”만이 아니라 “어디에서 허용했고, 무엇이 제한하는가”를 봐야 합니다.

aws sts assume-role 임시 자격 증명 발급 예시

아래 예시는 실제 값이 아닌 더미 값입니다. 실제 Account ID, Role 이름, Access Key, Secret Access Key, Session Token은 블로그나 문서에 노출하면 안 됩니다.

이렇게 설정한 뒤 실행하는 AWS CLI 요청은 원래 사용자 권한이 아니라 Assume한 Role의 임시 세션 권한으로 평가됩니다. 만료 시간이 지나면 같은 방식으로 새 임시 자격 증명을 발급받아야 합니다.

FAQ