VPC 엔드포인트로 AWS 서비스 프라이빗 연결

AWS 서비스에 프라이빗하게 접근하는 VPC 엔드포인트의 개념과 설정 방법을 알아봅니다. 게이트웨이 엔드포인트와 인터페이스 엔드포인트의 차이점, S3 연결 설정, 그리고 비용 절감 효과까지 실무 중심으로 설명합니다.

---

목차

1. VPC_엔드포인트의_필요성
2. 게이트웨이_엔드포인트_vs_인터페이스_엔드포인트
3. S3_게이트웨이_엔드포인트_생성
4. 라우팅_테이블_자동_업데이트_확인
5. NAT_Gateway_비용_절감_효과
6. 엔드포인트_정책으로_접근_제어

---

1. VPC 엔드포인트의 필요성

김개발 씨는 프라이빗 서브넷에 배포된 Lambda 함수에서 S3 버킷의 파일을 읽어오는 작업을 맡았습니다. 분명히 코드는 맞는 것 같은데, 타임아웃 에러가 계속 발생합니다.

"프라이빗 서브넷이라 인터넷이 안 되는 건가?" 김개발 씨는 고개를 갸우뚱했습니다.

VPC 엔드포인트는 VPC 내부에서 AWS 서비스로 가는 전용 통로입니다. 마치 회사 건물 안에 있는 전용 엘리베이터처럼, 외부로 나가지 않고도 원하는 곳에 도달할 수 있게 해줍니다.

이를 통해 인터넷을 거치지 않고 프라이빗하게 AWS 서비스에 접근할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# 프라이빗 서브넷의 EC2에서 S3 접근
# VPC 엔드포인트가 없으면 이 코드는 타임아웃됩니다
s3_client = boto3.client('s3', region_name='ap-northeast-2')

# VPC 엔드포인트가 있으면 프라이빗하게 S3에 접근
response = s3_client.list_buckets()

for bucket in response['Buckets']:
    print(f"버킷 이름: {bucket['Name']}")

# 엔드포인트를 통해 인터넷 없이도 S3 사용 가능

김개발 씨는 입사 6개월 차 클라우드 엔지니어입니다. 오늘 선배 박시니어 씨에게 급한 호출을 받았습니다.

프라이빗 서브넷에 있는 애플리케이션이 S3에 접근하지 못하는 문제가 발생한 것입니다. "김개발 씨, 혹시 이 서브넷이 프라이빗인 거 알고 있었어요?" 박시니어 씨가 물었습니다.

김개발 씨는 고개를 끄덕였습니다. "네, 보안 때문에 프라이빗 서브넷에 배포했는데요.

S3는 AWS 내부 서비스니까 당연히 접근될 줄 알았어요." 박시니어 씨가 고개를 저었습니다. "S3는 AWS 서비스지만, 기본적으로 퍼블릭 엔드포인트를 통해 접근해요.

즉, 인터넷을 통해야 한다는 뜻이죠." 프라이빗 서브넷은 인터넷 게이트웨이로의 라우팅이 없는 서브넷입니다. 외부에서 들어오는 접근을 차단하여 보안을 강화할 수 있지만, 반대로 외부로 나가는 것도 불가능합니다.

그렇다면 S3에 접근하려면 어떻게 해야 할까요? 첫 번째 방법은 NAT Gateway를 사용하는 것입니다.

NAT Gateway를 통해 인터넷으로 나가서 S3에 접근할 수 있습니다. 하지만 이 방법에는 문제가 있습니다.

NAT Gateway는 시간당 요금과 데이터 처리 요금이 발생합니다. 대용량 데이터를 S3에서 자주 가져온다면 비용이 눈덩이처럼 불어납니다.

게다가 트래픽이 인터넷을 거치므로 보안 측면에서도 완벽하지 않습니다. 바로 이 문제를 해결하기 위해 VPC 엔드포인트가 등장했습니다.

VPC 엔드포인트는 VPC 내부에서 AWS 서비스로 직접 연결되는 전용 통로입니다. 마치 비밀 터널처럼, 인터넷을 전혀 거치지 않고 AWS 백본 네트워크를 통해 서비스에 접근합니다.

쉽게 비유하자면, 회사 건물에서 은행 업무를 보러 간다고 생각해보세요. 원래는 건물 밖으로 나가서 은행까지 걸어가야 합니다.

하지만 건물 안에 은행 창구가 생긴다면요? 밖으로 나갈 필요 없이 바로 업무를 볼 수 있습니다.

VPC 엔드포인트가 바로 이 역할을 합니다. VPC 엔드포인트를 사용하면 크게 세 가지 이점이 있습니다.

첫째, 보안이 강화됩니다. 트래픽이 인터넷을 거치지 않으므로 외부 노출 위험이 없습니다.

둘째, 비용이 절감됩니다. NAT Gateway의 데이터 처리 비용을 아낄 수 있습니다.

셋째, 지연 시간이 줄어듭니다. AWS 내부 네트워크를 사용하므로 더 빠른 응답을 기대할 수 있습니다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 VPC 엔드포인트가 필요한 거군요!" 이제 VPC 엔드포인트의 필요성을 이해했으니, 다음으로 어떤 종류의 엔드포인트가 있는지 알아보겠습니다.

실전 팁

💡 - 프라이빗 서브넷에서 AWS 서비스 접근이 안 되면 VPC 엔드포인트 설정을 확인하세요

• 보안과 비용 두 마리 토끼를 잡으려면 NAT Gateway 대신 VPC 엔드포인트를 고려하세요

---

2. 게이트웨이 엔드포인트 vs 인터페이스 엔드포인트

VPC 엔드포인트가 필요하다는 것을 알게 된 김개발 씨는 AWS 콘솔을 열었습니다. 그런데 엔드포인트를 생성하려고 보니 두 가지 타입이 있습니다.

Gateway와 Interface. "둘이 뭐가 다른 거지?" 김개발 씨는 다시 박시니어 씨를 찾아갔습니다.

VPC 엔드포인트는 게이트웨이 엔드포인트와 인터페이스 엔드포인트 두 종류가 있습니다. 게이트웨이 엔드포인트는 S3와 DynamoDB 전용이며 무료입니다.

인터페이스 엔드포인트는 그 외 대부분의 AWS 서비스에 사용하며 요금이 부과됩니다. 마치 무료 고속도로와 유료 고속도로의 차이라고 생각하면 됩니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 게이트웨이 엔드포인트 생성 (S3용 - 무료)
gateway_endpoint = ec2.create_vpc_endpoint(
    VpcId='vpc-12345678',
    ServiceName='com.amazonaws.ap-northeast-2.s3',
    VpcEndpointType='Gateway',  # 게이트웨이 타입
    RouteTableIds=['rtb-12345678']
)

# 인터페이스 엔드포인트 생성 (Secrets Manager용 - 유료)
interface_endpoint = ec2.create_vpc_endpoint(
    VpcId='vpc-12345678',
    ServiceName='com.amazonaws.ap-northeast-2.secretsmanager',
    VpcEndpointType='Interface',  # 인터페이스 타입
    SubnetIds=['subnet-12345678'],
    SecurityGroupIds=['sg-12345678']
)

박시니어 씨가 화이트보드를 꺼내들었습니다. "두 가지 엔드포인트의 차이를 그림으로 설명해줄게요." 먼저 게이트웨이 엔드포인트에 대해 알아봅시다.

게이트웨이 엔드포인트는 이름처럼 VPC의 게이트웨이 역할을 합니다. 라우팅 테이블에 특별한 경로를 추가하여, 특정 서비스로 가는 트래픽을 VPC 내부에서 처리합니다.

박시니어 씨가 그림을 그리며 설명했습니다. "마치 고속도로 톨게이트처럼 생각하면 돼요.

차가 톨게이트를 통과하면 고속도로로 진입하잖아요? 게이트웨이 엔드포인트도 비슷해요.

라우팅 테이블이 '이 목적지로 가려면 이 게이트웨이를 통과해'라고 안내해주는 거죠." 게이트웨이 엔드포인트의 가장 큰 장점은 무료라는 점입니다. 하지만 지원하는 서비스가 제한적입니다.

현재 S3와 DynamoDB만 게이트웨이 엔드포인트를 지원합니다. 반면 인터페이스 엔드포인트는 조금 다른 방식으로 작동합니다.

인터페이스 엔드포인트를 생성하면 지정한 서브넷에 **ENI(Elastic Network Interface)**가 생성됩니다. 이 ENI는 프라이빗 IP 주소를 가지며, 해당 IP로 트래픽을 보내면 AWS 서비스에 도달합니다.

박시니어 씨가 비유를 들었습니다. "인터페이스 엔드포인트는 마치 회사 내선 전화와 같아요.

외부 전화번호 대신 내선 번호로 연락하면, 교환원을 거쳐 원하는 부서에 연결되는 거죠. ENI가 바로 그 내선 번호 역할을 해요." 인터페이스 엔드포인트는 AWS PrivateLink라는 기술을 사용합니다.

이 기술 덕분에 거의 모든 AWS 서비스에 프라이빗하게 접근할 수 있습니다. EC2 API, Lambda, Secrets Manager, CloudWatch 등 수많은 서비스를 지원합니다.

하지만 인터페이스 엔드포인트는 비용이 발생합니다. 시간당 약 0.01달러의 요금과 함께 데이터 처리 비용도 있습니다.

물론 NAT Gateway보다는 저렴하지만, 게이트웨이 엔드포인트처럼 무료는 아닙니다. 또 하나 중요한 차이점이 있습니다.

게이트웨이 엔드포인트는 라우팅 테이블에 자동으로 경로가 추가되어 별도 설정 없이 사용할 수 있습니다. 반면 인터페이스 엔드포인트는 프라이빗 DNS를 활성화하거나, 엔드포인트의 DNS 이름을 직접 사용해야 합니다.

김개발 씨가 정리해보았습니다. "그러니까 S3나 DynamoDB는 무료인 게이트웨이 엔드포인트를 쓰고, 다른 서비스는 인터페이스 엔드포인트를 써야 하는 거네요?" 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 그리고 인터페이스 엔드포인트는 보안 그룹도 설정해야 해요.

ENI에 보안 그룹을 연결해서 어떤 트래픽을 허용할지 제어할 수 있거든요."

실전 팁

💡 - S3와 DynamoDB는 무료인 게이트웨이 엔드포인트를 사용하세요

• 인터페이스 엔드포인트는 반드시 필요한 서비스만 선별하여 비용을 관리하세요
• 인터페이스 엔드포인트 생성 시 프라이빗 DNS 활성화를 권장합니다

---

3. S3 게이트웨이 엔드포인트 생성

이론은 충분히 배웠으니 이제 직접 만들어볼 시간입니다. 김개발 씨는 박시니어 씨와 함께 AWS 콘솔 앞에 앉았습니다.

"자, 이제 S3 게이트웨이 엔드포인트를 직접 만들어볼까요?" 박시니어 씨가 화면을 가리키며 말했습니다.

S3 게이트웨이 엔드포인트는 VPC 콘솔에서 몇 번의 클릭으로 생성할 수 있습니다. VPC를 선택하고, 서비스로 S3를 지정한 후, 연결할 라우팅 테이블을 선택하면 됩니다.

생성 즉시 해당 라우팅 테이블에 S3로 가는 경로가 자동으로 추가됩니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# S3 게이트웨이 엔드포인트 생성
response = ec2.create_vpc_endpoint(
    VpcId='vpc-0abc123def456789',
    ServiceName='com.amazonaws.ap-northeast-2.s3',
    VpcEndpointType='Gateway',
    RouteTableIds=[
        'rtb-private-a',  # 프라이빗 서브넷 A의 라우팅 테이블
        'rtb-private-b',  # 프라이빗 서브넷 B의 라우팅 테이블
    ],
    TagSpecifications=[{
        'ResourceType': 'vpc-endpoint',
        'Tags': [{'Key': 'Name', 'Value': 's3-gateway-endpoint'}]
    }]
)

endpoint_id = response['VpcEndpoint']['VpcEndpointId']
print(f"생성된 엔드포인트 ID: {endpoint_id}")

박시니어 씨가 AWS 콘솔을 열었습니다. "VPC 서비스로 들어가서 왼쪽 메뉴에서 Endpoints를 찾아보세요." 김개발 씨가 화면을 따라가며 클릭했습니다.

Endpoints 페이지가 열리자 오른쪽 상단의 Create endpoint 버튼이 보였습니다. "먼저 이름을 지어줘야 해요.

어떤 용도인지 알 수 있게 's3-gateway-endpoint' 정도가 좋겠네요." 박시니어 씨가 말했습니다. 다음으로 서비스를 선택해야 합니다.

검색창에 's3'를 입력하면 여러 서비스가 나타납니다. 여기서 중요한 것은 com.amazonaws.ap-northeast-2.s3를 선택하는 것입니다.

뒤에 Interface가 붙은 것은 인터페이스 엔드포인트이고, 그냥 s3로 끝나는 것이 게이트웨이 엔드포인트입니다. 김개발 씨가 조심스럽게 물었습니다.

"Type에 Gateway라고 표시된 걸 선택하면 되는 거죠?" "맞아요. AWS가 친절하게 타입을 표시해줘요." 박시니어 씨가 확인해주었습니다.

VPC를 선택하는 부분에서는 당연히 프라이빗 서브넷이 있는 VPC를 선택해야 합니다. 여러 VPC가 있다면 올바른 VPC를 선택했는지 확인하세요.

가장 중요한 부분은 라우팅 테이블 선택입니다. 게이트웨이 엔드포인트는 선택한 라우팅 테이블에 S3로 가는 경로를 자동으로 추가합니다.

따라서 프라이빗 서브넷에서 S3에 접근해야 한다면, 해당 프라이빗 서브넷이 사용하는 라우팅 테이블을 선택해야 합니다. 김개발 씨가 라우팅 테이블 목록을 보며 물었습니다.

"여러 개의 라우팅 테이블을 선택해도 되나요?" "물론이죠. 여러 프라이빗 서브넷이 각각 다른 라우팅 테이블을 사용한다면 모두 선택하세요." 박시니어 씨가 대답했습니다.

Policy 부분은 기본값인 Full access로 두어도 됩니다. 나중에 필요하면 특정 버킷만 접근 가능하도록 제한할 수 있습니다.

이 부분은 뒤에서 더 자세히 다루겠습니다. 모든 설정을 마치고 Create endpoint 버튼을 클릭하면 끝입니다.

몇 초 후 상태가 Available로 바뀌면 엔드포인트가 활성화된 것입니다. 김개발 씨가 기쁜 표정으로 말했습니다.

"생각보다 간단하네요! 서브넷도 보안 그룹도 설정할 필요가 없군요." "그게 게이트웨이 엔드포인트의 장점이에요.

라우팅 테이블에 경로만 추가되니까 설정이 정말 간단하죠." 박시니어 씨가 미소 지었습니다.

실전 팁

💡 - 서비스 선택 시 Type이 Gateway인지 확인하세요 (S3는 Interface 타입도 있습니다)

• 프라이빗 서브넷이 사용하는 모든 라우팅 테이블을 선택해야 합니다
• 생성 후 상태가 Available인지 확인하세요

---

4. 라우팅 테이블 자동 업데이트 확인

엔드포인트 생성은 완료했지만, 정말로 라우팅 테이블이 업데이트되었는지 확인해볼 필요가 있습니다. 김개발 씨는 "말로만 듣지 말고 직접 눈으로 확인해봐야 믿어지겠어요"라며 라우팅 테이블 페이지로 이동했습니다.

게이트웨이 엔드포인트를 생성하면 선택한 라우팅 테이블에 S3 프리픽스 리스트로 가는 경로가 자동으로 추가됩니다. 이 경로의 Target은 vpce-로 시작하는 엔드포인트 ID입니다.

개발자가 직접 라우팅 규칙을 추가할 필요가 없습니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 라우팅 테이블 정보 조회
route_tables = ec2.describe_route_tables(
    RouteTableIds=['rtb-private-a']
)

# 라우팅 규칙 확인
for rt in route_tables['RouteTables']:
    print(f"라우팅 테이블: {rt['RouteTableId']}")
    for route in rt['Routes']:
        # VPC 엔드포인트 경로 확인
        if 'GatewayId' in route and route['GatewayId'].startswith('vpce-'):
            print(f"  S3 엔드포인트 경로 발견!")
            print(f"  Destination: {route.get('DestinationPrefixListId')}")
            print(f"  Target: {route['GatewayId']}")
        elif 'DestinationCidrBlock' in route:
            print(f"  {route['DestinationCidrBlock']} -> {route.get('GatewayId', route.get('NatGatewayId', 'local'))}")

AWS 콘솔에서 VPC 서비스로 들어가 Route tables를 클릭했습니다. 방금 엔드포인트 생성 시 선택한 라우팅 테이블을 찾아 클릭합니다.

라우팅 테이블 상세 페이지에서 Routes 탭을 클릭하면 현재 등록된 모든 라우팅 규칙을 볼 수 있습니다. 김개발 씨가 화면을 살펴보았습니다.

기존에 있던 규칙들 외에 새로운 규칙이 하나 추가되어 있었습니다. "여기 Destination에 **pl-**로 시작하는 이상한 값이 있네요.

이게 뭐예요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다.

"그건 **프리픽스 리스트(Prefix List)**예요. S3 서비스의 IP 주소 범위를 담고 있는 목록이죠.

AWS가 관리하기 때문에 우리가 IP 주소를 일일이 지정할 필요가 없어요." S3는 전 세계에 분산된 서비스이고, 사용하는 IP 주소도 수시로 변경될 수 있습니다. 만약 IP 주소를 직접 라우팅 테이블에 넣었다면, AWS가 IP를 변경할 때마다 수정해야 할 것입니다.

프리픽스 리스트는 이 문제를 해결해줍니다. Target 컬럼을 보면 **vpce-**로 시작하는 값이 보입니다.

이것이 바로 우리가 생성한 VPC 엔드포인트 ID입니다. 즉, "S3로 가는 트래픽은 이 엔드포인트를 통해 보내라"는 의미입니다.

김개발 씨가 비유를 떠올렸습니다. "마치 내비게이션에 새로운 길이 추가된 것과 같네요.

예전에는 서울에서 부산 가려면 고속도로로만 안내했는데, 이제는 더 빠른 지름길도 안내해주는 거죠?" "정확해요! 그리고 이 경로는 다른 경로보다 더 구체적이기 때문에 우선순위가 높아요." 박시니어 씨가 덧붙였습니다.

라우팅 테이블에서 경로를 선택할 때는 가장 구체적인 경로가 우선됩니다. 예를 들어 0.0.0.0/0으로 가는 규칙과 S3 프리픽스 리스트로 가는 규칙이 있다면, S3 트래픽은 더 구체적인 프리픽스 리스트 규칙을 따릅니다.

이 자동 라우팅 업데이트 덕분에 애플리케이션 코드를 전혀 수정하지 않아도 됩니다. 기존에 S3에 접근하던 코드는 그대로 동작하며, 트래픽만 엔드포인트를 통해 프라이빗하게 전달됩니다.

김개발 씨가 감탄했습니다. "그러니까 인프라 레벨에서 알아서 처리되는 거군요.

개발자는 신경 쓸 필요가 없고요!"

실전 팁

💡 - 라우팅 테이블의 Routes 탭에서 pl-로 시작하는 프리픽스 리스트를 확인하세요

• Target이 vpce-로 시작하면 VPC 엔드포인트를 통한 경로입니다
• 엔드포인트 삭제 시 라우팅 규칙도 자동으로 제거됩니다

---

5. NAT Gateway 비용 절감 효과

설정은 끝났지만, 실제로 얼마나 비용이 절감되는지 궁금해진 김개발 씨는 계산기를 꺼내들었습니다. 박시니어 씨가 옆에서 말했습니다.

"AWS 비용은 생각보다 눈덩이처럼 불어날 수 있어요. 한번 계산해볼까요?"

NAT Gateway는 시간당 약 0.045달러의 요금과 GB당 0.045달러의 데이터 처리 비용이 발생합니다. S3 게이트웨이 엔드포인트는 완전 무료입니다.

매일 100GB의 S3 데이터를 처리한다면 월 135달러 이상을 절감할 수 있습니다.

다음 코드를 살펴봅시다.

# NAT Gateway vs S3 게이트웨이 엔드포인트 비용 비교

# NAT Gateway 비용 (서울 리전 기준)
nat_hourly_rate = 0.045  # 시간당 요금 (USD)
nat_data_rate = 0.045    # GB당 데이터 처리 비용 (USD)

# 월간 사용량 가정
hours_per_month = 730    # 24시간 x 30.4일
daily_s3_data_gb = 100   # 하루 S3 데이터 전송량
monthly_data_gb = daily_s3_data_gb * 30

# NAT Gateway 월간 비용
nat_time_cost = nat_hourly_rate * hours_per_month  # $32.85
nat_data_cost = nat_data_rate * monthly_data_gb    # $135.00
nat_total = nat_time_cost + nat_data_cost          # $167.85

# S3 게이트웨이 엔드포인트 비용
endpoint_cost = 0  # 완전 무료!

print(f"NAT Gateway 월간 비용: ${nat_total:.2f}")
print(f"S3 엔드포인트 월간 비용: ${endpoint_cost}")
print(f"월간 절감액: ${nat_total - endpoint_cost:.2f}")

박시니어 씨가 화이트보드에 숫자를 적기 시작했습니다. "NAT Gateway 비용 구조부터 이해해봅시다." NAT Gateway는 두 가지 비용이 발생합니다.

첫째는 시간당 요금입니다. 서울 리전 기준으로 시간당 약 0.045달러가 청구됩니다.

NAT Gateway를 한 달 내내 켜두면 약 32.85달러가 됩니다. 둘째는 데이터 처리 비용입니다.

NAT Gateway를 통과하는 모든 데이터에 대해 GB당 0.045달러가 청구됩니다. 이 부분이 비용 폭탄의 주범입니다.

김개발 씨가 계산해보았습니다. "저희 서비스는 하루에 S3에서 약 100GB 정도의 데이터를 가져오는데요..." "한 달이면 3,000GB네요.

데이터 처리 비용만 135달러가 나오겠군요." 박시니어 씨가 계산을 이어갔습니다. 시간당 요금과 데이터 처리 비용을 합치면 월 약 168달러입니다.

1년이면 약 2,000달러, 한화로 약 260만 원 정도 됩니다. 결코 적은 금액이 아닙니다.

반면 S3 게이트웨이 엔드포인트는 완전 무료입니다. 시간당 요금도 없고, 데이터 처리 비용도 없습니다.

엔드포인트를 통해 아무리 많은 데이터를 전송해도 추가 비용이 발생하지 않습니다. 김개발 씨가 놀란 표정을 지었습니다.

"정말요? 무료라고요?

AWS가 이렇게 후한 서비스가 있나요?" 박시니어 씨가 웃으며 대답했습니다. "AWS 입장에서도 이득이에요.

인터넷을 거치지 않고 내부 네트워크로 트래픽이 흐르니까 인프라 부담이 줄거든요." 물론 S3 자체의 요금은 별도입니다. S3 스토리지 비용과 요청 비용은 그대로 청구됩니다.

하지만 NAT Gateway의 데이터 처리 비용을 없앨 수 있다는 것만으로도 큰 절감 효과가 있습니다. 더 중요한 것은 데이터 양이 늘어날수록 절감 효과가 커진다는 점입니다.

하루 1TB의 S3 데이터를 처리하는 대규모 서비스라면 월 1,350달러를 절감할 수 있습니다. 김개발 씨가 정리했습니다.

"그러니까 S3와 DynamoDB는 무조건 게이트웨이 엔드포인트를 사용해야겠네요. 안 쓸 이유가 없잖아요." 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 프라이빗 서브넷에서 S3에 접근해야 한다면 게이트웨이 엔드포인트는 선택이 아니라 필수예요."

실전 팁

💡 - S3와 DynamoDB는 무조건 게이트웨이 엔드포인트를 사용하세요 (무료입니다)

• NAT Gateway가 있어도 게이트웨이 엔드포인트를 추가하면 S3 트래픽은 엔드포인트로 흐릅니다
• AWS Cost Explorer에서 NAT Gateway 비용을 모니터링하세요

---

6. 엔드포인트 정책으로 접근 제어

비용 절감까지 확인한 김개발 씨는 만족스러웠습니다. 그런데 보안팀에서 연락이 왔습니다.

"특정 S3 버킷에만 접근 가능하도록 제한할 수 있나요?" 김개발 씨는 다시 박시니어 씨를 찾아갔습니다.

엔드포인트 정책은 VPC 엔드포인트를 통해 어떤 리소스에 접근할 수 있는지 제어합니다. 기본값은 모든 접근을 허용하지만, 특정 S3 버킷만 허용하거나 특정 작업만 허용하도록 세밀하게 설정할 수 있습니다.

IAM 정책과 함께 동작하여 이중 보안을 제공합니다.

다음 코드를 살펴봅시다.

import boto3
import json

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 특정 버킷만 허용하는 엔드포인트 정책
endpoint_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificBucket",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-company-data-bucket",
                "arn:aws:s3:::my-company-data-bucket/*"
            ]
        }
    ]
}

# 엔드포인트 정책 업데이트
response = ec2.modify_vpc_endpoint(
    VpcEndpointId='vpce-0abc123def456789',
    PolicyDocument=json.dumps(endpoint_policy)
)

print("엔드포인트 정책이 업데이트되었습니다.")

박시니어 씨가 설명을 시작했습니다. "VPC 엔드포인트를 생성할 때 Policy 부분을 기억해요?

그때 Full access로 두었잖아요. 이걸 수정하면 접근을 제한할 수 있어요." 엔드포인트 정책은 IAM 정책과 비슷한 JSON 형식으로 작성합니다.

Effect, Principal, Action, Resource를 지정하여 누가, 어떤 리소스에, 어떤 작업을 할 수 있는지 정의합니다. 김개발 씨가 질문했습니다.

"그런데 이미 IAM 정책으로 접근을 제어하고 있잖아요. 엔드포인트 정책이 왜 또 필요한 거예요?" 박시니어 씨가 중요한 개념을 설명했습니다.

"엔드포인트 정책과 IAM 정책은 AND 조건으로 동작해요. 둘 다 허용해야 접근이 가능하죠." 예를 들어 IAM 정책에서 모든 S3 버킷에 대한 접근을 허용했다고 가정해봅시다.

하지만 엔드포인트 정책에서 특정 버킷만 허용했다면, 결국 그 특정 버킷에만 접근할 수 있습니다. 두 정책 중 하나라도 Deny하면 접근이 거부됩니다.

이런 이중 보안 구조는 여러 상황에서 유용합니다. 예를 들어 개발 VPC에서는 개발용 S3 버킷에만 접근하도록 제한하고 싶을 수 있습니다.

또는 특정 VPC에서는 읽기만 허용하고 쓰기는 금지하고 싶을 수 있습니다. 박시니어 씨가 실제 사례를 들어 설명했습니다.

"저희 회사에서는 프로덕션 VPC의 엔드포인트 정책에 프로덕션 버킷만 허용해놨어요. 개발자가 실수로 프로덕션 서버에서 개발 버킷에 접근하려고 해도 차단되죠." 엔드포인트 정책을 작성할 때 주의할 점이 있습니다.

정책을 너무 제한적으로 설정하면 예상치 못한 곳에서 문제가 생길 수 있습니다. 예를 들어 S3를 사용하는 다른 AWS 서비스가 동작하지 않을 수 있습니다.

김개발 씨가 물었습니다. "그럼 처음에는 어떻게 설정하는 게 좋을까요?" 박시니어 씨가 조언했습니다.

"처음에는 Full access로 시작해서 정상 동작을 확인한 후, 점진적으로 제한을 추가하는 게 안전해요. CloudTrail 로그를 분석해서 실제로 어떤 버킷에 접근하는지 파악한 다음 정책을 세밀하게 조정하세요." 마지막으로 엔드포인트 정책 변경은 즉시 적용됩니다.

별도의 재시작이나 대기 시간이 필요하지 않습니다. 하지만 그만큼 실수했을 때 바로 영향을 미치므로 신중하게 변경해야 합니다.

김개발 씨가 이해했다는 듯 고개를 끄덕였습니다. "이제 VPC 엔드포인트에 대해 완전히 이해했어요.

보안과 비용, 두 마리 토끼를 잡을 수 있네요!"

실전 팁

💡 - 엔드포인트 정책과 IAM 정책은 AND 조건으로 동작합니다 (둘 다 허용해야 접근 가능)

• 처음에는 Full access로 시작하고 점진적으로 제한을 추가하세요
• CloudTrail 로그를 분석하여 필요한 접근 권한을 파악하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!