エッジ最適化)で構成するかを検討した際に改めて調査した結果をアウトプットします。実は昨年担当した案件でも同じ悩みがありました。設定したらなぜか繋がらない。機能は廃止されたため、プライベートは要注意だという印象を持ったまま腹落ちしない状況でした。今日は、改めて当時の課題を再現しつつ、解決策を整理させていただきます。プライベートタイプを使う時にハマる落とし穴があります。Endpointを設定しなければVPC内のサーバー(EC2、Lambdaなど)からアクセスできない。Endpointを設定した途端パブリックにアクセスできなくなるというもの。Gatewayをすべてパブリックの構成に統一できるなら、すべてパブリックの構成とするのが安全です。DNSの設定変更を行います。アクセスする際のヘッダにパラメータを付加するといった注意も必要です。→そのため、混在する環境では少し難易度が上がります。Endpointの正しい使い方をお読みください。Gatewayのパブリックとプライベートの構成を作りながら、設定方法と、動作を順を追って説明します。Gatewayのパブリックのエンドポイントタイプを使用した構成を作ります。Gatewayを作成時に、非プライベートを選択します。typeにエッジ最適化を選択します。以降の操作は、こちらの記事を参考にモックで構わないのでAPIのデプロイまで行います。エンドポイントに対して、外部のクライアント、VPC内に配置されたサーバーから疎通確認を行います。Gatewayはパブリックアクセスとなるため、外部のクライアントからのアクセスも、VPC内に配置されたサーバーからのアクセスも可能です。Gatewayにアクセスします。Endpointを作成します。VPCのコンソールを開き、Endpointsを選択します。Nameにcom.amazonaws.ap-northeast-1.execute-api(東京リージョンの場合)を選択します。VPC、Subnetsを選択します。Gatewayなし)を選択とします。nameを有効とします。Groupを選択します。Accessのままとします。Endpointが作成できました。nameは、ちゃんと有効になっていますね。Endpoint作成後に動作がどの様に変わったかを確認します。外部のクライアント、VPC内に配置されたサーバーからそれぞれ疎通確認を行います。Endpoint経由となるため、VPC内に配置されたサーバーからアクセスができなくなりました。Gatewayのプライベートのエンドポイントタイプを使用した構成を作ります。Gatewayを作成時に、プライベートを選択します。typeにプライベートを選択します。以降の操作は、こちらの記事を参考にモックで構わないのでAPIのデプロイまで行います。Policyを選択します。Whitelist」を例に、ポリシーを記述します。以下、VPCホワイトリストのリソースポリシーサンプルです。Endpoint以外のアクセス)を拒否します。]}リソースポリシーができたら、Saveします。エンドポイントに対して、外部のクライアント、VPC内に配置されたサーバーから疎通確認を行います。疎通はOKとなりました。Gatewayにはアクセスできません。Gatewayにはアクセスできます。DNS設定は、後からでも変更できます。VPCのコンソールを開き、Endpointsを選択します。選択します(東京リージョンの場合、com.amazonaws.ap-northeast-1.execute-apiですね)。DNS設定変更後に動作がどの様に変わったかを確認します。外部のクライアント、VPC内に配置されたサーバーからそれぞれ疎通確認を行います。疎通はOKに変わり、プライベートの疎通もOKとなっています(但し、ヘッダの追加が必要です↓)。名前解決ができません。Endpointの情報からも確認可)。curlにはx-apigw-api-idヘッダを追加で指定する必要があります。