software

Amazon Bedrock AgentCore Gateway를 접근 가능하게 만들기 (오직 CloudFront를 통해서만)

발행: (2026년 2월 17일 오전 04:21 GMT+9)
11 분 소요
원문: Dev.to

Source: Dev.to

Tags: aws, architecture, genai, cloud, security

aws architecture genai cloud security

Amazon Bedrock AgentCore Gateway는 GenAI 기반 API를 손쉽게 노출할 수 있게 해줍니다.
AWS는 CloudFront를 사용해 사용자 지정 도메인을 연결하는 공식 패턴을 제공합니다:

Client → CloudFront → AgentCore Gateway

공식 문서:

많은 사용 사례에서 이 접근 방식으로 충분합니다.
하지만 요구 사항이 더 강력해야 한다면 어떨까요?

이 엔드포인트는 특정 CloudFront 배포를 통해서만 접근 가능해야 합니다.

이때가 바로 아키텍처 경계가 중요한 순간입니다.

숨겨진 노출 문제

다음과 같은 경우에도:

  • CloudFront가 앞에 배치됨
  • AWS WAF가 연결됨
  • 사용자 지정 도메인이 구성됨

기본 AgentCore Gateway 서비스 엔드포인트는 공개적으로 접근 가능합니다. CloudFront는 역방향 프록시 역할을 할 뿐, 엄격한 격리 경계는 아닙니다.

AgentCore는 리소스 기반 정책을 지원합니다:

이 정책들은 주로 누가 게이트웨이를 호출할 수 있는지를 제어합니다 (IAM 주체, AWS 계정, 지원되는 조건 키). 이 모델은 내부 서비스‑간 통신에는 잘 맞지만, 공개 API의 경우:

  • 외부 소비자는 IAM을 사용해 인증하지 않습니다.
  • 인증은 일반적으로 OAuth, JWT, API 키 또는 사용자 정의 헤더에 의존합니다.
  • 정당한 사용자를 위해 엔드포인트는 인터넷에서 접근 가능해야 합니다.

따라서 정당한 트래픽이 CloudFront를 통해 흐르더라도, 추가적인 제어가 도입되지 않으면 기본 Gateway 엔드포인트는 여전히 인터넷에서 직접 접근 가능할 수 있습니다. IAM 기반 제한은 서비스 엔드포인트 자체가 공개된 상태이기 때문에 그 노출을 제거하지 못합니다. 인그레스 격리 요구사항이 엄격한 환경에서는 이것이 중요한 격차가 됩니다.

이것을 S3 + CloudFront (OAI / OAC)와 비교하기

Amazon S3는 오직 CloudFront만 버킷에 접근할 수 있다는 기본적인 강제 수단을 제공합니다. Origin Access Identity (OAI) 또는 Origin Access Control (OAC) 를 사용하면 S3 버킷을 비공개로 만들고 특정 CloudFront 배포에만 접근을 제한할 수 있습니다.

예시 S3 버킷 정책:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccessOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123ABC456XYZ"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-private-bucket/*"
    }
  ]
}

이 모델에서는:

  • 버킷이 공개되지 않습니다.
  • 직접 인터넷 접근이 실패합니다.
  • 오직 CloudFront 아이덴티티만 허용됩니다.

AgentCore는 현재 동등한 격리 구조를 제공하지 않으므로, 추가적인 경계가 도입되어야 합니다.

CloudFront‑Only 액세스 강제 아키텍처

CloudFront‑Only 액세스 강제 아키텍처

예시:

  • 공용 진입점: ext-clients-api-57x9abc.mycompany.com
  • 필수 하위 Host 헤더: gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

네트워크 계층에서 CloudFront‑전용 적용

**Application Load Balancer (ALB)**는 공개 주소를 가질 수 있지만, 공개 인터넷에서 접근할 필요는 없습니다. 인바운드 트래픽은 AWS Managed Prefix Lists for CloudFront를 사용하여 제한할 수 있습니다:

AWS는 CloudFront origin‑facing IP 범위를 포함하는 관리형 프리픽스 리스트를 유지합니다. 이 관리형 프리픽스 리스트를 ALB 보안 그룹에 연결하고 인바운드 HTTPS를 오직 다음으로부터 허용합니다:

com.amazonaws.global.cloudfront.origin-facing

이것이 달성하는 것

  • 오직 CloudFront 엣지 로케이션만 ALB와 TCP 연결을 수립할 수 있습니다.
  • 직접 인터넷 트래픽은 보안‑그룹 수준에서 차단됩니다.
  • IP 스푸핑으로 제한을 우회할 수 없습니다.

CloudFront가 없으면 ALB에 접근할 수 없으며, 진정한 네트워크 적용 경계를 형성합니다.

AWS WAF와 DDoS 보호가 위치하는 곳

이 설계는 계층형 보호를 가능하게 합니다.

CloudFront (엣지 레이어)

CloudFront는 AWS Shield Standard에 의해 자동으로 보호되며, 엣지에서 DDoS 완화를 제공합니다. CloudFront에 연결된 AWS WAF는 다음을 제공할 수 있습니다:

  • 비율 기반 규칙(남용 방지 및 스크래핑 보호)
  • IP 평판 필터링
  • 지리적 제한
  • AWS 관리형 규칙 그룹
  • AWS Bot Control
  • 계정 탈취 방지(ATP)
  • 인증 필드 검사
  • 헤더 검증
  • 페이로드 크기 제한

악의적인 트래픽은 인프라에 도달하기 전에 필터링됩니다.

ALB (인그레스 레이어)

AWS WAF는 ALB에도 연결하여 다음을 적용할 수 있습니다:

  • 필수 커스텀 헤더 검증(예: CloudFront가 삽입한 비밀 헤더)
  • 서비스에 더 가깝게 적용되는 추가 비율 제한 또는 봇 제어
  • CloudFront 규칙을 우회하는 애플리케이션 레이어 공격에 대한 보호

이러한 레이어를 결합하면 “CloudFront‑only” 요구 사항을 만족하면서도 정당한 사용자가 접근할 수 있는 공개 API를 제공하는 방어‑심층(Defense‑in‑Depth) 자세를 구현할 수 있습니다.

CloudFront가 삽입한 비밀 헤더

  • 엄격한 Host 헤더 검증
  • 추가 관리형 규칙 그룹
  • 인증 흐름 검사

ALB DNS 이름이 발견되더라도:

  • 관리형 프리픽스 리스트 제한으로 직접 연결 시도가 실패합니다.
  • 헤더 검증 및 WAF 규칙으로 위조된 요청이 차단됩니다.

이로 인해 세 가지 시행 레이어가 형성됩니다:

  1. 엣지 – Shield + WAF
  2. 네트워크 – 관리형 프리픽스 리스트 제한
  3. 애플리케이션 – ALB WAF + 리스너 규칙

기술적 과제: TLS vs Host Header

  • ALB는 맞춤 도메인에 대한 인증서를 사용하여 TLS를 종료해야 합니다, 예시:

    ext-clients-api-57x9abc.mycompany.com

  • 하위 라우팅에서는 다른 HTTP Host 헤더가 필요할 수 있습니다, 예시:

    gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

이들은 서로 다른 프로토콜 계층에 속합니다:

계층목적
TLS (SNI)인증서 검증을 제어
HTTPHost 헤더가 라우팅 로직을 제어

AgentCore는 임의의 맞춤 도메인을 인바운드로 수용하지 않으므로, 이 불일치는 트래픽이 AgentCore에 도달하기 전에 해결되어야 합니다.

솔루션: CloudFront 오리진 수정

CloudFront Functions는 다음을 수정할 수 있습니다:

  • domainName – TLS/SNI용 오리진 연결 호스트명
  • hostHeader – 오리진에 전달되는 HTTP Host 헤더

예시 함수

import cf from 'cloudfront';

const ORIGIN_DOMAIN_NAME = 'ext-clients-api-57x9abc.mycompany.com';
const OVERRIDE_HOST_HEADER = 'gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com';

function handler(event) {
  const request = event.request;

  cf.updateRequestOrigin({
    domainName: ORIGIN_DOMAIN_NAME,
    hostHeader: OVERRIDE_HOST_HEADER
  });

  return request;
}

이를 통해 다음을 구현할 수 있습니다:

  • ALB 인증서에 대한 TLS 검증.
  • 필요한 Host 헤더에 기반한 ALB 라우팅.
  • 외부 클라이언트가 오직 커스텀 도메인만을 통해 상호 작용하도록 제한.
  • AgentCore가 오직 제어된 CloudFront → ALB → PrivateLink 경로를 통해서만 접근 가능하도록 유지.

최종 결과

아키텍처는 다음을 제공합니다:

  • 맞춤 도메인 지원
  • 엣지 수준 DDoS 보호 (Shield Standard)
  • 고급 WAF 보호 (속도 제한, ATP, 봇 제어, 관리형 규칙)
  • 네트워크 수준 CloudFront 전용 적용
  • ALB에서의 인그레스 검증
  • VPC 엔드포인트 (PrivateLink)를 통한 프라이빗 연결
  • GenAI 워크로드를 위한 강력한 인그레스 격리

기본 AWS 패턴은 표준 배포에 잘 맞습니다.
엄격한 CloudFront 전용 접근성이 필요할 때는 아키텍처 경계가 필요합니다.

CloudFront + 관리형 프리픽스 리스트 + ALB + PrivateLink + 계층형 WAF가 해당 경계를 제공합니다.

0 조회
#software #programming #community
원문 보기
Share:
Back to Blog

관련 글

더 보기 »