外部企業のオンプレミスネットワークから AWS Direct Connect 経由で Private API Gateway に接続する完全ガイド

以下では、東京リージョン ap-northeast-1 を例に説明します。


社外ネットワーク
172.20.0.0/16
│
§─ビジネスクライアント
│カール / Java / Postman / 業務システム
│
§─ 社外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 リゾルバーインバウンドエンドポイントはローカルネットワークから DNS リクエストを受信し、プライベートホストゾーンはプライベートドメイン名レコードを保存します。インターフェイス VPC エンドポイントは、API ゲートウェイへの HTTPS データフローの実際のエントリポイントです。

外部企業のシステムが次のことを要求したとします。


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

これら 2 つの IP は、AWS VPC の Route 53 リゾルバーインバウンドエンドポイント 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 リゾルバーは、 の HTTPS 転送に参加しません。以前の DNS 解決のみを担当します。

プライベート API ゲートウェイには、API ゲートウェイのインターフェイス VPC エンドポイントを介してのみアクセスできます。また、API リソースポリシーでは、指定された VPC または VPC エンドポイントも許可する必要があります。

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 でサイト間 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

これにより、次の 2 つの問題が解決されます。

フレンドリー発信アドレス

使用する必要はありません:


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 Gateway はエンドポイントがこのプライベートドメイン名を使用することを許可しません。

6. Private API Gateway

プライベート API ゲートウェイは、最後の API 入り口です。

引き続き次のものを統合できます。

Lambda。
AWS のサービス。
HTTP バックエンド。
VPC リンクを介して ALB/NLB および VPC 内サービスに接続します。

プライベートAPIは「専用回線を通れば誰でも呼び出せる」というものではありません。少なくとも次の認可レイヤーも存在します。


VPC Endpoint Security Group
VPC Endpoint Policy
Private Domain Resource Policy
Private API Resource Policy
APIメソッドレベルの認証
バックエンドビジネス認定

プライベート API のリソースポリシーは、aws:SourceVpce または aws:SourceVpc を通じてソースを制限できます。 AWS では、すべてのオリジンを許可するのではなく、VPC または VPC エンドポイントを明示的に指定することをお勧めします。

以下に具体例を示す。

プロジェクト	例
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 を個別に設定します。
個別のフローログ。
コストを特定します。
ルーティンググループとセキュリティグループの独立した制御。
その後の交換または拡張。

シナリオ A: VPC が 1 つだけ

使用できるもの:


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

プライベート VIF は主に、プライベート 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 VIF は、Direct Connect Gateway に関連付けられた Transit Gateway に接続するために使用されます。 Direct Connect Gateway で許可されているプレフィックスは、ローカルネットワークに公開される AWS 側のプレフィックスに影響します。

ダイレクトコネクトの設定手順

1. 物理接続またはホスト接続を確立する

次のことが考えられます:

Dedicated Connection。
パートナーによって提供されるホスト型接続。

企業の正式な運用環境では、リンクが 1 つだけになることは避けるべきです。 AWS の高可用性モデルでは、さまざまなデバイスおよびさまざまな Direct Connect ロケーションからの冗長接続を使用することが推奨されており、Resiliency Toolkit を使用して BGP フェイルオーバーをテストできます。

2. ダイレクトコネクトゲートウェイの作成

たとえば:


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

3. トランジットゲートウェイの作成

たとえば:


TGW ASN: 64530

API が配置されている VPC を TGW にアタッチします。

4. DXゲートウェイとTGWを関連付ける

許可されるプレフィックスを設定する必要があります。例:


10.20.0.0/16

ランダムに投稿しないでください。


0.0.0.0/0
10.0.0.0/8

これが明確に精査された Web デザインでない限り。

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
    → ダイレクトコネクトゲートウェイ/TGW アソシエーションの方向

API VPC サブネットルートテーブルには以下が必要です。


172.20.0.0/16
    → Transit Gateway

外部企業ルーターには次のものが必要です。


10.20.0.0/16
    → 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 が一貫していません

プライベート VIF は 1500 または 9001 を使用でき、トランジット VIF は 1500 または 8500 を使用できます。ジャンボフレームを有効にする前に、顧客のルータ、オペレータ、DX リンク、TGW、および中間機器がすべてそれをサポートしていることを確認してください。そうしないと、小さなリクエストは正常であり、大きなリクエストがスタックする可能性があります。

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

2 つの 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 が返される可能性があります。これは、少なくともリクエストがリゾルバーに到達したことを証明します。

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 トラフィックを許可するには、execute-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 ごとにサブネットを 1 つだけ選択でき、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. プライベートDNSスイッチの影響

execute-api プライベート DNS をオンにした後:


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

この VPC 内では、VPC エンドポイントが最初に解決されます。

プライベート API のデフォルトのドメイン名を呼び出す方が便利ですが、副作用もあります。

VPC 内のパブリック API Gateway のデフォルト execute-api URL にアクセスすると、プライベートエンドポイントに解決される場合があります。
したがって、デフォルトのドメイン名ではパブリック API にアクセスできない場合があります。
パブリックネットワーク API には独自の地域カスタムドメインを使用するのが最善です。

AWS のドキュメントには、execute-api エンドポイントのプライベート DNS を有効にすると、VPC のデフォルトのエンドポイントを介したパブリック 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 Gateway は 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"
        }
      }
    }
  ]
}

この書き方の意味は以下の通りです。

原則として通話は可能です。
ただし、ソースエンドポイントが指定されたエンドポイントでない限り、明示的に拒否されます。

AWS は、aws:SourceVpce および aws:SourceVpc に基づいたプライベート API リソースポリシーの例を提供しています。

リソースポリシーを変更した後、API を再デプロイする必要があります。

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 から検出可能である必要があります。 CNAME を Route 53 プライベートホストゾーンに配置するだけでは、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 Gateway は最初にドメイン名へのすべてのアクセスを拒否するポリシーを構成し、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

プライベートドメイン自体でも、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 とプライベートカスタムドメインがリソースポリシーを個別に構成することを明示的に要求しています。

たとえば、次のように希望します。


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 およびステージにマッピングする必要があります。

これは、プライベートカスタムドメインアーキテクチャで最も見逃しやすいステップです。

構築する必要があります:


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 分かかる場合があります。また、プライベートカスタムドメイン自体の作成または証明書の更新にも時間がかかる場合があります。

エンドポイントポリシー制御:

フルアクセスを長期間維持することはお勧めできません。

たとえば、ドメインと 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 リクエストがエンドポイントポリシーによってブロックされる可能性があります。

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、またはリゾルバーエンドポイントではなく、execute-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 またはデュアルスタックを使用している場合は、実際のニーズに応じて AAAA レコードを追加します。

社外の企業は通常、次の情報にアクセスするだけで済みます。

ネットワーク情報


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 キーは測定と使用量プランにのみ適しており、唯一のセキュリティ認証として使用しないでください。

現在、プライベート API は API Gateway の相互 TLS 機能をサポートしていないため、B2B 双方向証明書認証をパブリックネットワークリージョナル API の mTLS 方式に従って直接構成することはできません。 IAM SigV4、JWT/Lambda Authorizer、アプリケーション層の証明書検証を使用したり、フロントエンドプロキシ層を再設計したりできます。

コントロールを 6 つのレイヤーに分割することをお勧めします。

レイヤ 1: 直接接続ルーティング

必要なネットワークセグメントのみを公開します。


外部企業 → AWS:
10.20.0.0/16

AWS → 外部会社:
172.20.10.0/24

エンタープライズネットワークセグメント全体を相互に公開しないようにしてください。

第 2 層: リゾルバーエンドポイントセキュリティグループ

外部企業の公式 DNS サーバーのみが許可されます。


UDP/TCP 53
172.20.1.10/32
172.20.1.11/32

すべてのクライアントがリゾルバーに直接クエリを実行できるようにしないでください。

3 番目の層: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
注文権限
通話頻度
業務監査

ネットワークにアクセスできるからといって、企業がアクセスできるわけではありません。

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. リゾルバー 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 キャッシュ。

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 は、同時に 2 つのフォワーダーで構成されます。

各リゾルバーエンドポイント IP は、多数のクエリを処理できます。現在の AWS ドキュメントには、条件が適切な場合、単一の IP で最大約 10,000 の UDP DNS QPS を処理できると記載されていますが、実際の容量はクエリサイズ、プロトコル、応答レイテンシー、セキュリティグループ接続追跡によって影響されます。

Interface VPC Endpoint

少なくとも 2 つの AZ:


Endpoint ENI A
Endpoint ENI C

Route 53 エイリアスは、対応するエンドポイントアドレスを返します。

AWS はまた、プライベートカスタムドメインが少なくとも 2 つのアベイラビリティゾーンで VPC エンドポイントを使用することを明確に推奨しています。

API Gateway

API Gateway 自体はリージョンホスティングサービスであり、EC2 スタイルのアクティブインスタンスとスタンバイインスタンスをデプロイする必要はありません。ただし、バックエンドは引き続き個別に考慮する必要があります。

ラムダ同時実行。
VPC Link。
ALB/NLB には複数の AZ があります。
データベースには複数の AZ があります。
地域を越えた災害復旧。

少なくとも以下の項目を有効にすることをお勧めします。

Direct Connect

モニター:


ConnectionState
VirtualInterfaceBpsIngress
VirtualInterfaceBpsEgress
VirtualInterfacePpsIngress
VirtualInterfacePpsEgress
BGPステータス

そして、BGP フェールオーバーテストを実行して、バックアップリンクが実際に引き継ぐことができることを確認します。 AWS Resiliency Toolkit は、BGP セッションを一時的に閉じることによる冗長ルートの検証をサポートしています。

Route 53 Resolver

有効にする:


Resolver Query Logging
CloudWatch Resolver Endpoint Metrics

ログをクエリすると、次のことを確認できます。

ドメイン名のクエリを受信したかどうか。
クエリの送信元の VPC。
クエリの種類。
結果を返します。

リゾルバーキャッシュにヒットした繰り返しのクエリは、通常、それぞれの独立したクエリとしてクエリログに表示されないことに注意してください。

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

最初に 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、または署名をサポートする対応する署名ライブラリを使用できます。

1.DNSリクエストのタイムアウト

パフォーマンス:


掘削タイムアウト

優先順位のチェック:


外部 DNS からリゾルバー IP へのルーティング
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 は 1 つのレイヤーのみをカバーします。


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ゲートウェイの設定は基本的に正しい
問題は DX ルーティング、エンドポイント SG、または外部 DNS に集中しています

9. 小さなリクエストは正常ですが、大きなリクエストは失敗します。

確認してください:


MTU
PMTUD
ICMP Fragmentation Needed
中間ファイアウォール
Jumbo Frame

Direct Connect の通信は自動では暗号化されません。
DNS と HTTPS は、それぞれ独立した経路を通ります。
Resolver Endpoint では UDP/TCP の両方でポート53を許可する必要があります。
Private Hosted Zone は Resolver が存在する VPC に関連付ける必要があります。
Alias の宛先は Resolver ではなく、execute-api VPC Endpoint です。
execute-api Endpoint のセキュリティグループでは、外部企業の送信元ネットワークから TCP 443 を許可する必要があります。
Private Domain Policy と Private API Policy は別々のポリシーです。
Domain Name Access Association の作成が必要です。
API の Endpoint 関連付けやリソースを変更した後は、API を再デプロイする必要があります。
ACM パブリック証明書の DNS 検証レコードは、Private Hosted Zone だけでなく、パブリック DNS から参照できる必要があります。

正式な B2B システムには次の構成が推奨されます。


2 つの直接接続
+ VPN バックアップ リンク

Transit VIF
+ Direct Connect Gateway
+ Transit Gateway

スタンドアロン共有サービス VPC

2 つの AZ のリゾルバー インバウンド エンドポイント
+ 公式 DNS サーバーのみを許可 UDP/TCP 53

2 つの 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
→ バックエンドサービス

外部企業のオンプレミスネットワークから AWS Direct Connect 経由で Private API Gateway に接続する完全ガイド

2. 全体構成

3. 完全なリクエストはどのように流れますか?

1. DNS解決プロセス

2.HTTPSアクセス処理

4. 各サービスはなぜ存在するのですか?

1. AWS Direct Connect

機能

Direct Connect が責任を負わないもの

2. Route 53 Resolver Inbound Endpoint

機能

VPC の VPC+2 DNS に直接問い合わせることができないのはなぜですか?

3. Route 53 Private Hosted Zone

機能

4. Interface VPC Endpoint

機能

5. API Gateway Private Custom Domain

フレンドリー発信アドレス

TLS証明書

6. Private API Gateway

5. 推奨されるアドレスとリソースの計画

6. フェーズ 1: 直接接続構成

シナリオ A: VPC が 1 つだけ

オプション B: 複数の VPC または共有ネットワーク センター

ダイレクトコネクトの設定手順

1. 物理接続またはホスト接続を確立する

2. ダイレクトコネクトゲートウェイの作成

3. トランジットゲートウェイの作成

4. DXゲートウェイとTGWを関連付ける

5.トランジット VIF の作成

6. ローカルルーターの設定

7. TGWルーティングテーブルの設定

ダイレクトコネクトの最も一般的なエラー

ルートは一方向のみに設定されています

CIDR の重複

MTU が一貫していません

7. フェーズ 2: Route 53 リゾルバー インバウンド エンドポイントの作成

1. セキュリティグループを作成する

2. インバウンドエンドポイントの作成

3. 外部企業の DNS 設定の条件付き転送

4.DNSリンクを確認する

8. フェーズ 3: API 実行インターフェイス VPC エンドポイントの作成

1. エンドポイントセキュリティグループを作成する

2. エンドポイントの作成

3. プライベートDNSスイッチの影響

9. フェーズ 4: プライベート REST API の作成

1. APIの作成

2. リソースとメソッドを作成する

3. API Resource Policy

10. ステージ 5: 証明書とプライベート カスタム ドメイン

1. ACM証明書を準備する

ACM 公開証明書に関する重要な問題

2.プライベートカスタムドメインの作成

11. プライベート ドメイン リソース ポリシー

12. ステージ 6: API マッピングの作成

13. ステージ 7: ドメイン名アクセス関連付けの作成

14. ステージ 8: VPC エンドポイント ポリシーの構成

認可ヘッダーの注記

15. ステージ 9: プライベート ホスト ゾーンとエイリアス レコードの作成

1. プライベートホストゾーンの作成

2. エイリアスレコードの作成

16. 外部企業は最終的に何を構成する必要がありますか?

ネットワーク情報

DNS情報

API情報

認証情報

17. 完全なセキュリティ制御層

レイヤ 1: 直接接続ルーティング

第 2 層: リゾルバー エンドポイント セキュリティ グループ

3 番目の層:execute-api エンドポイント セキュリティ グループ

レイヤ 4: VPC エンドポイント ポリシー

レイヤ 5: ドメインおよび API リソース ポリシー

レベル 6: メソッドレベルおよびビジネスレベルの認定

18. DNS設計における注意点

1. Split-Horizon DNS

2. プライベートホストゾーンの関連付けエラー

3. リゾルバー IP をビジネス A レコードに書き込まないでください

4. TTL とキャッシュ

19. 高可用性設計

Direct Connect

VPC の `VPC+2` DNS に直接問い合わせることができないのはなぜですか?

オプション B: 複数の VPC または共有ネットワークセンター

7. フェーズ 2: Route 53 リゾルバーインバウンドエンドポイントの作成

10. ステージ 5: 証明書とプライベートカスタムドメイン

11. プライベートドメインリソースポリシー

14. ステージ 8: VPC エンドポイントポリシーの構成

15. ステージ 9: プライベートホストゾーンとエイリアスレコードの作成

第 2 層: リゾルバーエンドポイントセキュリティグループ

3 番目の層:execute-api エンドポイントセキュリティグループ

レイヤ 4: VPC エンドポイントポリシー

レイヤ 5: ドメインおよび API リソースポリシー

ステップ 2: リゾルバーエンドポイントを直接テストする

7. デフォルトの API 実行 URL にはアクセスできますが、カスタムドメインにはアクセスできません。