외부 기업의 온프레미스 네트워크에서 AWS Direct Connect를 통해 Private API Gateway에 연결하는 완벽 가이드

📅 2026-08-08
📍 AWS Direct Connect × Private API Gateway
⏱️ 약 35분 소요

전체 아키텍처 | DNS 및 HTTPS 경로 | AWS Direct Connect | Route 53 Resolver | Private API Gateway | 보안 및 문제 해결

여기서 주목해야 할 중요한 점은 모든 트래픽이 순서대로 통과하는 "직렬 프록시 체인"이 아니라는 것입니다.

실제로는 두 개의 독립적인 프로세스로 나뉩니다.

  1. DNS 확인 경로 : 프라이빗 도메인 이름을 VPC 엔드포인트의 프라이빗 IP로 확인하는 역할을 담당합니다.
  2. HTTPS 액세스 경로 : 클라이언트가 프라이빗 IP를 얻은 후 Direct Connect를 통해 인터페이스 VPC 엔드포인트에 직접 액세스한 후 AWS PrivateLink를 통해 프라이빗 API 게이트웨이로 전송합니다.

2. 전체 구조

다음은 도쿄 지역 ap-northeast-1을 예로 들어 설명합니다.


외부 회사 네트워크
172.20.0.0/16
│
├─비즈니스 클라이언트
│ 컬 / 자바 / 우편 배달부 / 비즈니스 시스템
│
├─ 외부업체 DNS
│ 조건부 전달:
│    api.partner.example.com
│           ↓
│    10.20.10.10
│    10.20.20.10
│
└─ 외부 기업 라우터
     BGP
      │
      │ AWS Direct Connect
      ▼
Direct Connect Location
      │
      ▼
Direct Connect Gateway
      │
      ├─ Private VIF → VGW
      │ 또는
      └─ Transit VIF → Transit Gateway
                         │
                         ▼
                    AWS VPC
                    10.20.0.0/16
                         │
          ┌──────────────┴──────────────┐
          │                             │
          ▼                             ▼
Route 53 Resolver                Interface VPC Endpoint
Inbound Endpoint                 com.amazonaws.ap-northeast-1.execute-api
UDP/TCP 53                       TCP 443
10.20.10.10                      10.20.11.x
10.20.20.10                      10.20.21.x
          │                             │
          ▼                             │
Route 53 Private Hosted Zone            │
partner.example.com                     │
          │                             │
api.partner.example.com                 │
      Alias → VPC Endpoint ─────────────┘
                                        │
                                        ▼
                            API Gateway Private Domain
                                        │
                              Domain Access Association
                                        │
                                        ▼
                              API Mapping / Base Path
                                        │
                                        ▼
                              Private REST API Gateway
                                        │
                                        ▼
                         Lambda / AWS Service / VPC Link

Route 53 Resolver 인바운드 엔드포인트는 로컬 네트워크로부터 DNS 요청을 받는 반면 프라이빗 호스팅 영역은 프라이빗 도메인 이름 레코드를 저장합니다. 인터페이스 VPC 엔드포인트는 API 게이트웨이로 향하는 HTTPS 데이터 흐름의 실제 진입점입니다.

3. 전체 요청은 어떻게 진행되나요?

외부 회사 시스템이 다음을 요청한다고 가정해 보겠습니다.


https://api.partner.example.com/v1/orders

1. DNS 확인 프로세스

클라이언트는 먼저 외부 회사에 내부 DNS를 요청합니다.


api.partner.example.com의 IP는 무엇입니까?

외부 회사 DNS에 구성된 조건부 전달:


partner.example.com
    → 10.20.10.10
    → 10.20.20.10

이 두 IP는 AWS VPC의 Route 53 Resolver 인바운드 엔드포인트 IP입니다.

DNS 요청은 다음과 같습니다.


외부 회사 DNS
→ Direct Connect
→ Transit Gateway/VGW
→ Resolver Inbound Endpoint
→ Route 53 VPC Resolver
→ Private Hosted Zone

프라이빗 호스팅 영역에 존재:


api.partner.example.com
    A Alias
    → vpce-xxxxxxxx.execute-api.ap-northeast-1.vpce.amazonaws.com

최종적으로 반환되는 것은 API 게이트웨이의 퍼블릭 IP가 아니라 인터페이스 VPC 엔드포인트 ENI의 프라이빗 IP입니다. 예를 들면 다음과 같습니다.


10.20.11.45
10.20.21.82

인바운드 엔드포인트의 IP는 그 자체가 VPC 프라이빗 IP이므로 온프레미스 네트워크는 Direct Connect 또는 VPN을 통해 VPC로 라우팅되어야 합니다. AWS에서는 각 확인자 엔드포인트를 최소 2개의 IP로 구성해야 하며 이를 서로 다른 가용 영역에 배치하는 것이 좋습니다.

2. HTTPS 접속 프로세스

DNS가 종료되면 클라이언트는 확인된 VPC 엔드포인트 프라이빗 IP에 TCP 443을 설정합니다.


클라이언트
→ Direct Connect
→ TGW/VGW
→ VPC Endpoint ENI:443
→ AWS PrivateLink
→ API Gateway Private Custom Domain
→ API Mapping
→ Private REST API

여기서 Route 53 Resolver는 의 HTTPS 전달에 참여하지 않습니다. 이전 DNS 확인만 담당합니다.

프라이빗 API 게이트웨이는 API 게이트웨이의 인터페이스 VPC 엔드포인트를 통해서만 액세스할 수 있으며, API 리소스 정책은 지정된 VPC 또는 VPC 엔드포인트도 허용해야 합니다.

4. 각 서비스는 왜 존재하나요?

1. AWS Direct Connect

기능

Direct Connect는 외부 회사 네트워크와 AWS 간의 전용 회선 연결을 제공합니다.

주로 다음을 담당합니다.

  • 외부 회사의 프라이빗 네트워크 세그먼트를 AWS VPC로 라우팅합니다.
  • AWS VPC 네트워크 세그먼트를 외부 회사에 공개합니다.
  • DNS 요청을 호스팅합니다.
  • HTTPS API 요청을 호스팅합니다.
  • 공용 인터넷을 통과하는 비즈니스 트래픽을 피하세요.
  • 비교적 안정적인 대역폭과 대기 시간을 제공합니다.

Direct Connect가 책임지지 않는 사항

Direct Connect 자체는 다음 사항에 대해 책임을 지지 않습니다.

  • DNS 확인.
  • API 인증.
  • API 인증.
  • TLS 인증서.
  • API 게이트웨이 라우팅.
  • 모든 링크를 자동으로 암호화합니다.

Direct Connect는 "개인 회선"이지만 단순히 "종단 간 암호화 회선"과 동일시할 수는 없습니다. 링크 암호화가 필요한 경우 지원되는 경우 MACsec을 고려하거나 Direct Connect에서 Site-to-Site VPN/IPsec을 오버레이하세요. MACsec의 must_encrypt 모드는 암호화를 설정할 수 없는 경우 전송을 중지합니다. should_encrypt은 실패 시 암호화되지 않은 통신으로 대체될 수 있습니다.

2. Route 53 Resolver Inbound Endpoint

기능

외부 회사의 자체 DNS 서버를 활성화하여 AWS VPC 내에서 DNS를 쿼리합니다.

이것이 없으면 외부 회사의 로컬 DNS를 직접 쿼리할 수 없습니다.

  • Route 53 Private Hosted Zone。
  • VPC 내부 프라이빗 DNS 이름입니다.
  • VPC 엔드포인트와 관련된 개인 기록입니다.

인바운드 엔드포인트가 생성되면 지정된 서브넷에 ENI가 생성되고 고정 프라이빗 IP가 할당됩니다. 외부 회사 DNS는 해당 도메인 이름에 대한 요청을 이러한 IP로 전달합니다.

VPC의 VPC+2 DNS에 직접 물어볼 수 없는 이유는 무엇입니까?

VPC의 일반 DNS 주소는 유사합니다.


VPC CIDR：10.20.0.0/16
VPC Resolver：10.20.0.2

그러나 외부 네트워크에서는 10.20.0.2을 일반 DNS 서버로 직접 사용해서는 안 됩니다. 하이브리드 네트워크의 표준 진입점은 확인자 인바운드 엔드포인트입니다.

3. Route 53 Private Hosted Zone

기능

개인 도메인 이름과 해당 레코드를 저장합니다. 예:


Private Hosted Zone:
partner.example.com

Record:
api.partner.example.com
    A Alias
    → execute-api Interface VPC Endpoint

프라이빗 호스팅 영역은 연결된 VPC 및 해당 확인자 인바운드 엔드포인트를 통해 입력된 쿼리에만 적용됩니다. 실제 API 주소를 퍼블릭 DNS에 노출할 필요가 없습니다.

4. Interface VPC Endpoint

서비스 이름:


com.amazonaws.ap-northeast-1.execute-api

기능

인터페이스 VPC 엔드포인트는 VPC 내 프라이빗 API 게이트웨이의 프라이빗 입구입니다.

선택한 각 가용 영역 서브넷에 ENI를 생성합니다.


AZ-a：10.20.11.45
AZ-c：10.20.21.82

외부 회사의 HTTPS 요청은 결국 이러한 ENI에 도달한 후 AWS PrivateLink를 통해 API 게이트웨이로 들어갑니다.

인터페이스 엔드포인트는 다음을 지원합니다.

  • Security Group。
  • VPC Endpoint Policy。
  • 다중 가용 영역.
  • 개인 DNS 이름.
  • 서비스 및 구성에 따라 IPv4, IPv6 또는 이중 스택.

AWS에서는 가용성을 향상시키기 위해 인터페이스 엔드포인트가 여러 서브넷을 선택할 것을 권장합니다.

5. API Gateway Private Custom Domain

예를 들면:


api.partner.example.com

이는 두 가지 문제를 해결합니다.

친절한 전화주소

사용할 필요가 없습니다:


https://a1b2c3d4-vpce123.execute-api.ap-northeast-1.amazonaws.com/prod

대신 다음을 사용하십시오.


https://api.partner.example.com/v1

TLS 인증서

API 게이트웨이는 TLS SNI를 기반으로 합니다.


api.partner.example.com

해당 ACM 인증서를 선택합니다.

프라이빗 사용자 지정 도메인과 VPC 엔드포인트 사이에 생성되어야 합니다.


Domain Name Access Association

그렇지 않으면 DNS가 엔드포인트를 가리키더라도 API 게이트웨이는 엔드포인트가 이 개인 도메인 이름을 사용하는 것을 허용하지 않습니다.

6. Private API Gateway

프라이빗 API 게이트웨이는 최종 API 입구입니다.

계속해서 통합할 수 있습니다.

  • Lambda。
  • AWS 서비스.
  • HTTP 백엔드.
  • VPC 링크를 통해 ALB/NLB 및 VPC 내부 서비스에 연결합니다.

Private API는 "전용회선을 통해서는 누구나 호출할 수 있다"는 의미는 아닙니다. 최소한 다음과 같은 인증 레이어도 존재합니다.


VPC Endpoint Security Group
VPC Endpoint Policy
Private Domain Resource Policy
Private API Resource Policy
API 메소드 수준 인증
백엔드 사업 인증

Private API의 리소스 정책은 aws:SourceVpce 또는 aws:SourceVpc을 통해 소스를 제한할 수 있습니다. AWS에서는 모든 오리진을 허용하는 대신 VPC 또는 VPC 엔드포인트를 명시적으로 지정할 것을 권장합니다.

5. 추천 주소 및 자원 계획

구체적인 예가 아래에 나와 있습니다.

프로젝트 예
AWS Region ap-northeast-1
AWS VPC 10.20.0.0/16
외부 회사 네트워크 세그먼트 172.20.0.0/16
확인자 끝점 서브넷 A 10.20.10.0/24
확인자 끝점 서브넷 C 10.20.20.0/24
Resolver IP A 10.20.10.10
Resolver IP C 10.20.20.10
실행-API 끝점 서브넷 A 10.20.11.0/24
실행-API 끝점 서브넷 C 10.20.21.0/24
개인 도메인 이름 api.partner.example.com
Private Hosted Zone partner.example.com
API Stage prod
Base Path v1

다음을 용이하게 하기 위해 전용 서브넷에서 확인자 엔드포인트와 인터페이스 엔드포인트를 분리하는 것이 좋습니다.

  • NACL을 독립적으로 구성합니다.
  • 별도의 흐름 로그.
  • 비용을 식별합니다.
  • 라우팅 및 보안 그룹을 독립적으로 제어합니다.
  • 후속 교체 또는 확장.

6. 1단계: 직접 연결 구성

시나리오 A: 단 하나의 VPC

사용할 수 있습니다:


Direct Connect
→ Private VIF
→ Direct Connect Gateway
→ Virtual Private Gateway
→ VPC

Private VIF는 주로 Private IP를 통해 VPC에 접속하는데 사용됩니다. 생성 시 VLAN, 클라이언트 BGP ASN, BGP 피어 IP, MTU 등의 매개변수를 설정해야 합니다.

옵션 B: 여러 VPC 또는 공유 네트워크 센터

권장사항:


Direct Connect
→ Transit VIF
→ Direct Connect Gateway
→ Transit Gateway
→ Shared Services VPC

이는 다음과 같이 따를 수 있기 때문에 엔터프라이즈 환경에서 보다 일반적인 디자인입니다.

  • DNS VPC。
  • API VPC。
  • 비즈니스 VPC.
  • 보안 검사 VPC.

Transit Gateway에 대한 통합 액세스.

Transit VIF는 Direct Connect Gateway와 연결된 Transit Gateway에 연결하는 데 사용됩니다. Direct Connect 게이트웨이에 허용되는 접두사는 로컬 네트워크에 게시된 AWS 측 접두사에 영향을 미칩니다.

Direct Connect 구성 단계

1. 물리적 또는 호스팅 연결 설정

다음과 같을 수 있습니다:

  • Dedicated Connection。
  • 파트너가 제공하는 호스팅 연결.

기업의 공식 프로덕션 환경에서는 링크가 하나만 있으면 안 됩니다. AWS의 고가용성 모델은 다양한 장치 및 다양한 Direct Connect 위치의 중복 연결 사용을 권장하며 Resiliency Toolkit을 사용하여 BGP 장애 조치를 테스트할 수 있습니다.

2. Direct Connect 게이트웨이 생성

예를 들면:


Name: dxgw-partner-api
Amazon side ASN: 64520

3. Transit Gateway 생성

예를 들면:


TGW ASN: 64530

API가 있는 VPC를 TGW에 연결합니다.

4. DX 게이트웨이와 TGW 연결

허용되는 접두사를 설정해야 합니다. 예를 들면 다음과 같습니다.


10.20.0.0/16

무작위로 게시하지 마세요.


0.0.0.0/0
10.0.0.0/8

명시적으로 검증된 웹 디자인이 아닌 한.

5. 대중교통 VIF 생성

주요 매개변수는 다음과 같습니다.


VLAN: 120
Customer ASN: 65010
AWS ASN: DXGW에서
Customer Peer IP: 169.254.x.x/30
AWS Peer IP: 169.254.x.x/30
BGP MD5 키: 자동으로 생성되거나 지정됨
MTU: 1500 또는 8500

6. 로컬 라우터 구성

AWS에 로컬로 게시:


172.20.0.0/16

AWS가 로컬로 릴리스:


10.20.0.0/16

7. TGW 라우팅 테이블 구성

AWS 측에는 최소한 다음이 필요합니다.


172.20.0.0/16
    → Direct Connect Gateway/TGW 연결 방향

API VPC 서브넷 라우팅 테이블에는 다음이 필요합니다.


172.20.0.0/16
    → Transit Gateway

외부 회사 라우터에는 다음이 필요합니다.


10.20.0.0/16
    → Direct Connect

Direct Connect의 가장 일반적인 오류

경로가 한 방향으로만 구성되어 있습니다.

예를 들면:


외부업체는 10.20.11.45로 이동 가능
하지만 AWS는 172.20.0.0/16으로 돌아가는 방법을 모릅니다.

결과는 일반적으로 TCP 연결 시간 초과입니다.

CIDR 중복

예를 들면:


외부 회사: 10.20.0.0/16
AWS VPC：10.20.0.0/16

이 상황은 일반적인 라우팅으로는 해결할 수 없습니다. 일반적으로 다음이 필요합니다.

  • 주소를 다시 계획하십시오.
  • NAT。
  • 중개 대리인.
  • PrivateLink 서비스 기반 아키텍처.

MTU 불일치

Private VIF는 1500 또는 9001을 사용할 수 있고 Transit VIF는 1500 또는 8500을 사용할 수 있습니다. 점보 프레임을 활성화하기 전에 고객 라우터, 운영자, DX 링크, TGW 및 중간 장비가 모두 이를 지원하는지 확인하십시오. 그렇지 않으면 작은 요청은 정상이 되고 큰 요청은 중단될 수 있습니다.

7. 2단계: Route 53 Resolver 인바운드 엔드포인트 생성

1. 보안 그룹 생성

예를 들면:


sg-r53-inbound

인바운드 규칙:


UDP 53
출처 : 외부업체 DNS 서버 IP/32

TCP 53
출처 : 외부업체 DNS 서버 IP/32

예를 들면:


UDP 53  ← 172.20.1.10/32
UDP 53  ← 172.20.1.11/32
TCP 53  ← 172.20.1.10/32
TCP 53  ← 172.20.1.11/32

UDP 53만 열지 마세요. TCP는 다음과 같은 상황에서 사용될 수 있습니다.

  • DNS 응답이 너무 큽니다.
  • DNSSEC。
  • UDP 잘린 후 다시 시도하세요.
  • 일부 내부 DNS 제품의 동작.

AWS에서는 인바운드 엔드포인트 보안 그룹이 TCP 및 UDP 53을 허용하도록 명시적으로 요구합니다.

2. 인바운드 엔드포인트 생성

콘솔 경로:


Route 53
→ Resolver
→ Inbound endpoints
→ Create inbound endpoint

권장 설정:


Name: r53-inbound-partner-api
VPC: vpc-api-shared
Endpoint category: Default
Protocol: Do53
Security Group: sg-r53-inbound

두 개의 AZ를 구성합니다.


AZ-a
Subnet: subnet-dns-a
IP: 10.20.10.10

AZ-c
Subnet: subnet-dns-c
IP: 10.20.20.10

AWS에는 최소 2개의 IP가 필요하며 서로 다른 가용 영역에 있을 것을 권장합니다. 이러한 IP는 엔드포인트 수명 동안 변경되지 않습니다.

3. 외부업체 DNS 구성 조건부 전달

Windows DNS 예:


Conditional Forwarder:
partner.example.com

Master Servers:
10.20.10.10
10.20.20.10

바인드 예:


zone "partner.example.com" {
    type forward;
    forward only;
    forwarders {
        10.20.10.10;
        10.20.20.10;
    };
};

정확한 도메인 이름만 전달하는 것이 좋습니다.


partner.example.com

불필요하게 구성하지 마십시오.


.
com
example.com

그렇지 않으면 관련 없는 DNS 쿼리가 많이 AWS로 전달될 수 있습니다.

4. DNS 링크 확인

AWS 해석기 IP를 직접 테스트합니다.


dig @10.20.10.10 api.partner.example.com

그런 다음 외부 회사의 일반 DNS 테스트를 통과합니다.


dig api.partner.example.com

초기 단계에서 프라이빗 호스팅 영역이 생성되지 않은 경우 NXDOMAIN이 반환될 수 있으며 이는 최소한 요청이 Resolver에 도달했음을 증명합니다.

8. 3단계: 실행 API 인터페이스 VPC 엔드포인트 생성

1. 엔드포인트 보안 그룹 생성

예를 들면:


sg-vpce-execute-api

인바운드 규칙:


TCP 443
Source: 172.20.0.0/16

더 엄격한 경우에는 비즈니스 시스템 네트워크 세그먼트만 허용됩니다.


TCP 443
Source: 172.20.10.0/24

VPC CIDR을 허용하는 것만으로도 충분하다고 생각하는 실수를 저지르지 마십시오. 발신자가 외부 회사 네트워크에 있습니다. VPC 엔드포인트가 보는 소스는 대개 외부 기업의 원래 프라이빗 IP이므로 해당 네트워크 세그먼트를 허용해야 합니다.

AWS에서는 HTTPS 443 트래픽을 허용하기 위해 run-api 엔드포인트 보안 그룹이 필요합니다.

2. 엔드포인트 생성

콘솔 경로:


VPC
→ Endpoints
→ Create endpoint

선택:


Service category: AWS services
Service:
com.amazonaws.ap-northeast-1.execute-api

Type:
Interface

구성:


VPC: vpc-api-shared
Subnets:
  subnet-endpoint-a
  subnet-endpoint-c

Security Group:
  sg-vpce-execute-api

Private DNS:
  Enabled

2개 이상의 가용 영역을 선택하는 것이 좋습니다. 선택한 각 AZ에 대해 하나의 서브넷만 선택할 수 있으며, AWS는 각 서브넷에 엔드포인트 ENI를 생성합니다.

AWS CLI 예:


aws ec2 create-vpc-endpoint \
  --region ap-northeast-1 \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-northeast-1.execute-api \
  --subnet-ids subnet-aaa subnet-ccc \
  --security-group-ids sg-0123456789abcdef0 \
  --private-dns-enabled

3. Private DNS 전환의 영향

Execute-api Private DNS를 활성화한 후:


*.execute-api.ap-northeast-1.amazonaws.com

이 VPC 내에서는 VPC 엔드포인트가 먼저 확인됩니다.

Private API의 기본 도메인 이름을 호출하는 것이 더 편리하지만 다음과 같은 부작용도 있습니다.

  • VPC에서 퍼블릭 API 게이트웨이 기본 execute-api URL에 액세스할 때 프라이빗 엔드포인트로 확인될 수 있습니다.
  • 따라서 기본 도메인 이름을 통해 공개 API에 액세스할 수 없습니다.
  • 공용 네트워크 API에는 자체 지역 사용자 정의 도메인을 사용하는 것이 가장 좋습니다.

AWS 설명서에서는 Execute-api 엔드포인트 프라이빗 DNS를 활성화한 후 VPC의 기본 엔드포인트를 통한 퍼블릭 API에 대한 액세스가 영향을 받을 수 있음을 명확하게 상기시킵니다.

9. 4단계: 프라이빗 REST API 생성

1. API 생성

콘솔:


API Gateway
→ Create API
→ REST API
→ Build

선택:


Endpoint type: Private
IP address type: Dualstack
VPC Endpoint IDs: vpce-xxxxxxxx

여기서 프라이빗 API 게이트웨이는 REST API 프라이빗 엔드포인트을 나타냅니다. Execute-api VPC 엔드포인트를 생성할 때 직접 연결할 수 있습니다. 연결되면 API 게이트웨이는 API ID 및 엔드포인트 ID와 관련된 호출 DNS 이름을 생성합니다.

CLI 예:


aws apigateway create-rest-api \
  --region ap-northeast-1 \
  --name partner-private-api \
  --endpoint-configuration '{
    "types":["PRIVATE"],
    "ipAddressType":"dualstack",
    "vpcEndpointIds":["vpce-0123456789abcdef0"]
  }'

2. 리소스 및 메소드 생성

예를 들면:


/
└── orders
    ├── GET
    └── POST

또는:


/health
/orders
/orders/{orderId}

Lambda 또는 기타 통합을 구성한 후 다음에 배포하십시오.


Stage: prod

3. API Resource Policy

지정된 엔드포인트만 허용하는 것이 좋습니다.


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

이 글쓰기 방식의 의미는 다음과 같습니다.

  1. 통화는 원칙적으로 허용됩니다.
  2. 그러나 소스 엔드포인트가 지정된 엔드포인트가 아닌 한 명시적으로 거부됩니다.

AWS는 aws:SourceVpce 및 aws:SourceVpc을 기반으로 하는 프라이빗 API 리소스 정책의 예를 제공합니다.

리소스 정책을 수정한 후에는 API를 다시 배포해야 합니다.

10. 5단계: 인증서 및 개인 사용자 정의 도메인

1. ACM 인증서 준비

인증서에는 다음이 포함되어야 합니다.


api.partner.example.com

그리고 인증서는 API 게이트웨이가 있는 지역에 있어야 합니다. 예를 들면 다음과 같습니다.


ap-northeast-1

다음을 사용할 수 있습니다.


api.partner.example.com

또는 적절한 경우:


*.partner.example.com

비공개 사용자 정의 도메인은 와일드카드 인증서를 지원하지만 와일드카드 사용자 정의 도메인 이름 자체는 지원하지 않습니다. 개인 도메인 이름은 항상 TLS 1.2를 사용합니다.

ACM 공인 인증서와 관련된 중요한 문제

도메인 이름이 인트라넷에만 사용되는 경우에도 ACM은 ACM 공인 인증서를 신청할 때 도메인 이름 소유권을 확인해야 합니다.

DNS 확인 레코드는 ACM이 퍼블릭 DNS에서 검색할 수 있어야 합니다. Route 53 프라이빗 호스팅 영역에 CNAME을 배치하는 것만으로는 ACM 공개 인증서 확인을 완료할 수 없습니다.

따라서 더 안전한 접근 방식은 다음과 같습니다.

  • api.partner.example.com과 같이 회사가 실제로 소유한 공개 도메인 이름 하위 도메인을 사용하십시오.
  • ACM에서 검증한 CNAME만 퍼블릭 DNS에 넣습니다.
  • 실제 API의 A 레코드는 프라이빗 호스팅 영역에만 배치됩니다.
  • 공용 네트워크 DNS는 API의 실제 주소를 게시할 필요가 없습니다.

2. 개인 맞춤형 도메인 생성

콘솔:


API Gateway
→ Custom domain names
→ Add domain name

구성:


Domain name:
api.partner.example.com

Endpoint type:
Private

Routing mode:
API mappings only

ACM Certificate:
api.partner.example.com에 대한 인증서

생성 후 API 게이트웨이는 처음에 도메인 이름에 대한 모든 액세스를 거부하고 VPC 엔드포인트를 지정하기 위해 수동 인증을 요구하는 정책을 구성합니다.

CLI 예:


aws apigateway create-domain-name \
  --region ap-northeast-1 \
  --domain-name api.partner.example.com \
  --certificate-arn arn:aws:acm:ap-northeast-1:111122223333:certificate/xxxxxxxx \
  --security-policy TLS_1_2 \
  --endpoint-configuration '{"types":["PRIVATE"]}' \
  --policy file://domain-policy.json

11. 프라이빗 도메인 리소스 정책

프라이빗 도메인 자체에서도 VPC 엔드포인트를 지정할 수 있어야 합니다.

domain-policy.json：


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

다음은 매우 간과하기 쉬운 요점입니다.

요청이 성공하려면 최소한 다음 사항이 충족되어야 합니다.


개인 도메인 정책은 다음을 허용합니다.
비공개 API 정책은 다음을 허용합니다.
VPC 엔드포인트 정책은 다음을 허용합니다.
메소드 수준 인증을 통해

AWS에서는 리소스 정책을 별도로 구성하기 위해 프라이빗 API와 프라이빗 사용자 지정 도메인이 명시적으로 필요합니다.

12. 6단계: API 매핑 생성

예를 들면 다음과 같습니다.


https://api.partner.example.com/v1/orders

다음 대상에 매핑:


API: partner-private-api
Stage: prod
Base Path: v1

콘솔:


API Gateway
→ Custom domain names
→ api.partner.example.com
→ API mappings
→ Configure mappings

설정:


API: partner-private-api
Stage: prod
Path: v1

CLI：


aws apigateway create-base-path-mapping \
  --region ap-northeast-1 \
  --domain-name api.partner.example.com \
  --domain-name-id abcd1234 \
  --rest-api-id a1b2c3d4 \
  --stage prod \
  --base-path v1

프라이빗 사용자 정의 도메인은 API 매핑 또는 라우팅 규칙을 통해 특정 프라이빗 API 및 스테이지에 매핑되어야 합니다.

13. 7단계: 도메인 이름 액세스 연결 생성

이는 프라이빗 사용자 정의 도메인 아키텍처에서 가장 쉽게 놓칠 수 있는 단계입니다.

구축해야 할 사항:


Private Custom Domain
        ↕
execute-api VPC Endpoint

콘솔:


API Gateway
→ Custom domain names
→ api.partner.example.com
→ Resource sharing
→ Domain name access associations
→ Create

선택:


Domain ARN:
arn:aws:apigateway:ap-northeast-1:111122223333:
/domainnames/api.partner.example.com+domain-id

VPC Endpoint:
vpce-0123456789abcdef0

CLI：


aws apigateway create-domain-name-access-association \
  --region ap-northeast-1 \
  --domain-name-arn \
  arn:aws:apigateway:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234 \
  --access-association-source vpce-0123456789abcdef0 \
  --access-association-source-type VPCE

연결이 생성된 후 연결을 사용할 수 있게 되기까지 약 15분 정도 걸릴 수 있으며, 프라이빗 사용자 지정 도메인 자체를 생성하거나 인증서를 업데이트하는 데도 시간이 걸릴 수 있습니다.

14. 8단계: VPC 엔드포인트 정책 구성

엔드포인트 정책 제어:

장기간 동안 전체 액세스를 유지하는 것은 권장되지 않습니다.

예를 들어 도메인과 API만 지정할 수 있습니다.


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": [
        "arn:aws:execute-api:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234",
        "arn:aws:execute-api:ap-northeast-1:111122223333:a1b2c3d4/*"
      ]
    }
  ]
}

execute-api:viaDomainArn을 사용하여 지정된 개인 사용자 정의 도메인에 대한 액세스만 제한할 수도 있습니다. AWS는 프라이빗 도메인 이름, API 및 방법으로 VPC 엔드포인트 정책을 제한하는 예를 제공합니다.

인증 헤더 참고 사항

엔드포인트 정책은 먼저 요청의 Authorization 헤더를 평가합니다.

  • 승인 없음: 익명의 교장이 평가합니다.
  • 올바른 SigV4: IAM 주체로 식별됩니다.
  • 오류 SigV4: 직접 거부.
  • Bearer Token/JWT: 엔드포인트 정책은 일반적으로 익명의 주체를 기반으로 평가됩니다.

따라서 비즈니스 계층에서 OAuth/JWT/Lambda Authorizer를 사용하는 경우 엔드포인트 정책에서 실수로 IAM 사용자를 요청하지 마십시오. 그렇지 않으면 합법적인 JWT 요청이 엔드포인트 정책에 의해 차단될 수 있습니다.

15. 9단계: 프라이빗 호스팅 영역 및 별칭 레코드 생성

1. 프라이빗 호스팅 영역 생성

다음을 생성하는 것이 좋습니다:


partner.example.com

다음 리소스를 포함하는 VPC를 연결합니다.

  • Resolver Inbound Endpoint。
  • execute-api VPC Endpoint。

확인자가 호스팅 영역을 사용하여 외부 쿼리에 응답할 수 있도록 최소한 프라이빗 호스팅 영역은 인바운드 엔드포인트가 있는 VPC와 연결되어야 합니다.

CLI：


aws route53 create-hosted-zone \
  --name partner.example.com \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config Comment="Partner private API",PrivateZone=true \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0123456789abcdef0

2. 별칭 레코드 생성

콘솔:


Route 53
→ Hosted zones
→ partner.example.com
→ Create record

구성:


Record name:
api

Record type:
A

Alias:
On

Route traffic to:
Alias to VPC endpoint

Region:
ap-northeast-1

Endpoint:
vpce-0123456789abcdef0

프라이빗 API 사용자 지정 도메인의 Route 53 별칭 대상은 Lambda, API ID 또는 확인자 엔드포인트가 아니라 실행 API 인터페이스 VPC 엔드포인트여야 합니다.

CLI 레코드 예:


{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.partner.example.com",
        "Type": "A",
        "AliasTarget": {
          "DNSName": "vpce-0123456789abcdef0.execute-api.ap-northeast-1.vpce.amazonaws.com",
          "HostedZoneId": "VPC_ENDPOINT_HOSTED_ZONE_ID",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}

그런 다음:


aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFG \
  --change-batch file://api-alias.json

엔드포인트가 IPv6 또는 Dualstack을 사용하는 경우 실제 필요에 따라 AAAA 레코드를 추가하세요.

16. 외부 회사가 궁극적으로 구성해야 할 것은 무엇입니까?

외부 회사는 일반적으로 다음 정보에만 액세스하면 됩니다.

네트워크 정보


AWS 대상 네트워크 세그먼트:
10.20.0.0/16

계약:
DNS UDP/TCP 53
HTTPS TCP 443

DNS 정보


전달 도메인:
partner.example.com

DNS 대상:
10.20.10.10
10.20.20.10

API 정보


Base URL:
https://api.partner.example.com/v1

건강검진:
GET /health

비즈니스 API:
GET /orders
POST /orders

인증정보

디자인에 따라 다릅니다. 예:

  • OAuth2/JWT。
  • API Gateway Lambda Authorizer。
  • AWS IAM SigV4。
  • HMAC 서명.
  • Cognito Token。
  • 비즈니스 사용자 이름/비밀번호는 단독으로 사용하지 않는 것이 좋습니다.
  • API Key는 측정 및 사용량 계획에만 적합하며 유일한 보안 인증으로 사용되어서는 안됩니다.

Private API는 현재 API Gateway의 상호 TLS 기능을 지원하지 않으므로 공용 네트워크 Regional API의 mTLS 방식에 따라 B2B 양방향 인증서 인증을 직접 구성할 수 없습니다. IAM SigV4, JWT/Lambda Authorizer, 애플리케이션 계층 인증서 확인을 사용하거나 프런트엔드 프록시 계층을 다시 설계할 수 있습니다.

17. 완벽한 보안 제어 계층

컨트롤을 6개의 레이어로 나누는 것이 좋습니다.

레이어 1: Direct Connect 라우팅

필요한 네트워크 세그먼트만 게시합니다.


외부 회사 → AWS:
10.20.0.0/16

AWS → 외부 회사:
172.20.10.0/24

전체 엔터프라이즈 네트워크 세그먼트를 서로 게시하지 마십시오.

두 번째 계층: 확인자 엔드포인트 보안 그룹

외부 회사의 공식 DNS 서버만 허용됩니다.


UDP/TCP 53
172.20.1.10/32
172.20.1.11/32

모든 클라이언트가 확인자에게 직접 쿼리하는 것을 허용하지 마십시오.

세 번째 계층: Execute-api 엔드포인트 보안 그룹

비즈니스 시스템 소스 네트워크 세그먼트만 허용됩니다.


TCP 443
172.20.10.0/24

계층 4: VPC 엔드포인트 정책

허용되는 항목:


개인 도메인 지정
API 지정
방법 또는 단계 지정

계층 5: 도메인 및 API 리소스 정책

또한 통과했습니다:


aws:SourceVpce

지정된 엔드포인트를 제한합니다.

외부 원본 IP를 추가로 제한해야 하는 경우 비공개 API 리소스 정책을 사용할 수 있습니다.


aws:VpcSourceIp

VPC 엔드포인트는 네트워크 계층 소스 IP를 다시 쓸 수 있으므로 aws:VpcSourceIp을 사용하여 원래 요청 소스 주소를 결정합니다.

레벨 6: 방법 수준 및 비즈니스 수준 인증

예를 들면:


OAuth2 Access Token
JWT Claims
Partner ID
Scope
주문 권한
통화 빈도
사업 감사

네트워크를 통해 연결할 수 있다고 해서 해당 기업이 액세스할 수 있다는 의미는 아닙니다.

18. DNS 설계 시 주의할 점

1. Split-Horizon DNS

외부 회사가 이미 내부적으로 관리되고 있다고 가정합니다.


example.com

AWS가 다시 생성합니다.


Private Hosted Zone: example.com

그러면 분할 DNS와 권한 충돌이 발생할 수 있습니다.

전용 하위 도메인을 나누는 것이 더 좋습니다.


aws-api.example.com
partner-api.example.com
private.example.com

그런 다음 이 하위 도메인만 조건부로 전달하세요.

2. 프라이빗 호스팅 영역 연결 오류

만약:


VPC-A의 확인자 엔드포인트
프라이빗 호스팅 영역은 VPC-B에만 연결됩니다.

인바운드 엔드포인트가 예상대로 호스팅 영역을 확인하지 못할 수 있습니다.

가장 간단한 방법은 다음과 같습니다.


Private Hosted Zone
또한 확인자 엔드포인트가 있는 VPC를 연결합니다.
그리고 Execute-api 엔드포인트가 위치한 VPC

둘 다 동일한 VPC에 있으면 더 쉽습니다.

3. Resolver IP를 기업 A 레코드에 기록하지 마십시오.

오류:


api.partner.example.com
A → 10.20.10.10

10.20.10.10은 API 서버가 아닌 DNS 서버입니다.

정답:


api.partner.example.com
A Alias → execute-api VPC Endpoint

4. TTL 및 캐싱

프라이빗 호스팅 영역 레코드가 변경된 후에도 외부 회사 DNS 및 클라이언트는 캐시를 계속 사용할 수 있습니다.

테스트할 때 다음을 수행할 수 있습니다.


dig api.partner.example.com

TTL을 관찰하고 정리합니다.

  • Windows DNS 캐시.
  • Linux systemd-resolved 캐시.
  • Java JVM DNS 캐시.
  • 엔터프라이즈 DNS 캐싱.

19. 고가용성 설계

Direct Connect

프로덕션 환경의 경우 최소한 다음을 고려하십시오.


DX Connection A
DX Connection B
다른 장치
최고의 다른 DX 위치

그리고 준비하세요:


Site-to-Site VPN Backup

BGP 속성을 사용하여 활성 및 대기를 제어합니다.

Resolver Inbound Endpoint

2개 이상의 AZ:


10.20.10.10
10.20.20.10

외부 DNS는 동시에 두 개의 전달자로 구성됩니다.

각 확인자 끝점 IP는 많은 수의 쿼리를 처리할 수 있습니다. 현재 AWS 문서에는 조건이 적합할 때 단일 IP가 최대 약 10,000 UDP DNS QPS를 처리할 수 있다고 명시되어 있지만 실제 용량은 쿼리 크기, 프로토콜, 응답 지연 시간 및 보안 그룹 연결 추적에 의해 영향을 받습니다.

Interface VPC Endpoint

2개 이상의 AZ:


Endpoint ENI A
Endpoint ENI C

Route 53 별칭은 해당 엔드포인트 주소를 반환합니다.

또한 AWS는 프라이빗 사용자 지정 도메인이 최소 두 개의 가용 영역에서 VPC 엔드포인트를 사용할 것을 명확하게 권장합니다.

API Gateway

API 게이트웨이 자체는 지역 호스팅 서비스이므로 EC2 스타일 활성 및 대기 인스턴스 배포가 필요하지 않습니다. 그러나 백엔드는 여전히 별도로 고려해야 합니다.

  • 람다 동시성.
  • VPC Link。
  • ALB/NLB에는 여러 AZ가 있습니다.
  • 데이터베이스에는 여러 AZ가 있습니다.
  • 지역 간 재해 복구.

20. 모니터링 및 로깅

최소한 다음 항목을 활성화하는 것이 좋습니다.

Direct Connect

모니터:


ConnectionState
VirtualInterfaceBpsIngress
VirtualInterfaceBpsEgress
VirtualInterfacePpsIngress
VirtualInterfacePpsEgress
BGP 상태

그리고 BGP Failover Test를 실행하여 실제로 백업 링크가 인계받을 수 있는지 확인합니다. AWS Resiliency Toolkit은 BGP 세션을 일시적으로 닫아 중복 경로 확인을 지원합니다.

Route 53 Resolver

활성화:


Resolver Query Logging
CloudWatch Resolver Endpoint Metrics

로그를 쿼리하면 다음 사항을 확인하는 데 도움이 될 수 있습니다.

  • 도메인 이름 쿼리가 수신되었는지 여부입니다.
  • 쿼리가 발생하는 VPC입니다.
  • 쿼리 유형.
  • 결과를 반환합니다.

Resolver 캐시에 적중된 반복 쿼리는 일반적으로 쿼리 로그에 각각의 독립 쿼리로 표시되지 않는다는 점에 유의해야 합니다.

VPC

활성화:


VPC Flow Logs

하이라이트:

  • Resolver Endpoint ENI。
  • execute-api Endpoint ENI。
  • TGW 관련 트래픽.
  • ACCEPT/REJECT。
  • 소스 IP, 대상 IP, 포트.

API Gateway

활성화:


Access Logs
Execution Logs
Detailed Metrics
AWS X-Ray, 온디맨드

액세스 로그에는 최소한 다음이 포함되는 것이 좋습니다.


$requestId
$context.identity.sourceIp
$context.domainName
$context.httpMethod
$context.resourcePath
$context.status
$context.responseLength
$context.integrationErrorMessage

21. 표준 테스트 순서

처음에 curl을 실행하지 말고 레이어별로 테스트하세요.

1단계: BGP 및 라우팅 확인

외부 라우터는 다음을 학습했음을 확인합니다.


10.20.0.0/16

AWS 측은 다음 사항을 학습했음을 확인합니다.


172.20.0.0/16

2단계: 확인자 끝점을 직접 테스트


dig @10.20.10.10 api.partner.example.com A
dig @10.20.20.10 api.partner.example.com A

3단계: 외부 회사의 공식 DNS 테스트 통과


dig api.partner.example.com A

엔드포인트 개인 IP가 반환되어야 합니다.

4단계: TCP 443 테스트


nc -vz api.partner.example.com 443

또는:


telnet api.partner.example.com 443

5단계: TLS 인증서 확인


openssl s_client \
  -connect api.partner.example.com:443 \
  -servername api.partner.example.com

확인:


Subject Alternative Name
Issuer
Validity
TLS version
Certificate chain

6단계: 상태 확인 호출


curl -v https://api.partner.example.com/v1/health

7단계: 인증을 통해 통화

JWT 예:


curl -v \
  -H "Authorization: Bearer ${TOKEN}" \
  https://api.partner.example.com/v1/orders

SigV4 시나리오는 SDK, AWS CLI 또는 서명을 지원하는 해당 서명 라이브러리를 사용할 수 있습니다.

22. 일반적인 잘못과 판단방법

1. DNS 요청 시간 초과

성능:


발굴 시간 초과

우선순위 확인:


확인자 IP 라우팅에 대한 외부 DNS
TGW 라우팅
VPC 서브넷 라우팅
Resolver SG UDP/TCP 53
외부 방화벽
NACL

2. DNS는 NXDOMAIN을 반환합니다.

이는 네트워크와 DNS 서버가 연결되어 있지만 레코드 레이어에 문제가 있음을 의미합니다.

확인:


프라이빗 호스팅 영역 이름
별칭 레코드
호스팅 영역은 VPC와 연결되어 있습니다.
쿼리된 FQDN이 정확합니까?
좀 더 구체적인 충돌 호스팅 영역이 있나요?

3. 도메인 이름을 확인할 수 있지만 TCP 443이 시간 초과됩니다.

확인:


execute-api Endpoint SG
엔드포인트 ENI로의 외부 라우팅
NACL
TGW 백홀 라우팅
외부 방화벽

4. TLS 인증서 이름 불일치

예를 들어 인증서는 다음과 같습니다.


*.example.com

하지만 도메인 이름은 다음과 같습니다.


api.partner.example.com

*.example.com은 하나의 레이어만 포함합니다.


api.example.com

일반적으로 보장되지 않는 경우:


api.partner.example.com

사용해야 합니다:


*.partner.example.com

또는 정확한 인증서:


api.partner.example.com

5. 403 금지됨 반환

주문 확인:


도메인 이름 액세스 연결을 사용할 수 있나요?
Domain Resource Policy
API Resource Policy
VPC Endpoint Policy
메소드 승인
JWT/IAM 서명
API Key/Usage Plan

6. 누락된 인증 토큰 반환

일반적인 이유:


기본 경로 오류
단계 매핑 오류
HTTP 메소드 오류
리소스 경로가 존재하지 않습니다.
API가 재배포되지 않았습니다.

예를 들어 실제 매핑은 다음과 같습니다.


/v1 → prod

정답:


https://api.partner.example.com/v1/orders

오류:


https://api.partner.example.com/prod/orders

7. 기본 실행 API URL에 접근할 수 있지만 사용자 정의 도메인에는 접근할 수 없습니다.

확인해야 할 핵심 사항:


ACM 인증서
비공개 도메인 상태
Domain Resource Policy
Domain Access Association
API Mapping
Route 53 Alias
Host/SNI

8. VPC 내부에서는 접속이 가능하지만, 외부 업체에서는 접속이 불가능합니다.

일반적으로 다음과 같이 명시됩니다.


API Gateway 구성이 기본적으로 정확합니다.
문제는 DX 라우팅, Endpoint SG 또는 외부 DNS에 집중되어 있습니다.

9. 작은 요청은 정상이지만 큰 요청은 실패합니다.

확인:


MTU
PMTUD
ICMP Fragmentation Needed
중간 방화벽
Jumbo Frame

23. 가장 놓치기 쉬운 장소 10곳

  1. Direct Connect는 자동으로 암호화되지 않습니다.
  2. DNS와 HTTPS는 서로 다른 두 경로입니다.
  3. Resolver 끝점은 UDP와 TCP 53을 모두 열어야 합니다.
  4. 프라이빗 호스팅 영역은 확인자가 있는 VPC와 연결되어야 합니다.
  5. Alias 대상은 Resolver가 아닌execute-api VPC 엔드포인트입니다.
  6. execute-api 엔드포인트 보안 그룹은 외부 회사 소스 네트워크 세그먼트 TCP 443을 허용해야 합니다.
  7. 개인 도메인 정책과 개인 API 정책은 두 가지 정책입니다.
  8. 은 도메인 이름 액세스 연결을 만들어야 합니다.
  9. API의 엔드포인트 연결 또는 리소스를 수정한 후 을 다시 배포해야 합니다.
  10. ACM 공용 인증서의 DNS 확인 레코드는 공용 DNS에서 쿼리할 수 있어야 하며 프라이빗 호스팅 영역에만 배치할 수 없습니다.

24. 권장되는 최종 생산 구성

공식 B2B 시스템에는 다음 구성이 권장됩니다.


2개의 직접 연결
+ VPN 백업 링크

Transit VIF
+ Direct Connect Gateway
+ Transit Gateway

독립형 공유 서비스 VPC

두 AZ의 확인자 인바운드 엔드포인트
+ 공식 DNS 서버 UDP/TCP 53만 허용

두 AZ의 실행-api 인터페이스 엔드포인트
+ 외부 비즈니스 네트워크 세그먼트 TCP 443만 허용

전용 비공개 하위 도메인
api.partner.example.com

Private Custom Domain
+ ACM 인증서
+ Domain Access Association

Private Domain Policy
+ API Resource Policy
+ Endpoint Policy
모든 제한 사항 aws:SourceVpce

JWT 또는 IAM SigV4 인증
+ API Gateway Access Logs
+ Resolver Query Logs
+ VPC Flow Logs
+ DX CloudWatch 경고

최종 링크는 다음과 같이 요약될 수 있습니다.


DNS：
외부 DNS
→ Direct Connect
→ Resolver Inbound Endpoint
→ Private Hosted Zone
→ VPC 엔드포인트 프라이빗 IP로 돌아가기

HTTPS：
대외업무 시스템
→ Direct Connect
→ execute-api Interface Endpoint
→ Private Custom Domain
→ API Mapping
→ Private REST API
→ 백엔드 서비스