[NW-JAWS DAY]「うちのAWS、インターネット出られないんで」― AWS外の自社サービスをPrivateLinkでシュッと公開する方法

NW-JAWS DAY（2026.11.14）での登壇資料です。

「うちのAWS、インターネットに出られないんで」と言うエンプラ企業のAWS環境に、AWS外のクラウドで動く自社サービスを公開したい。PrivateLinkで何とかできないかを検討した話です。

前半：構成
・Endpoint Service（NLB）のIPターゲットで、専用線／VPNの先にあるAWS外のLBを直接つなぐ
・名前解決はPrivate DNS、TLS証明書は公開ドメイン＋公開CAのマネージド証明書に任せる
・接続制御は許可するプリンシパル、接続承認、Security Groupで行う

後半：エンプラ企業への説明
「インターネットに出ません」と伝えるだけでは通りません。従来の手段（専用線による外部接続）で相手が本質的に守りたいこと、つまり接続元・接続先の限定とリクエストの起点がどちらにあるかを理解したうえで、「手段は変わっても守りたいことは変わらない」と説明する、という話をしています。

※本発表は架空のケーススタディであり、現在の所属企業・関係企業とは無関係です。

1. NW-JAWS DAY 「うちのAWS、インターネット出られないんで」 AWS外の自社サービスをPrivateLinkでシュッと公開する方法 木美 雄太（Yuta KIMI） VP of Architecture Technology & Development Div. 2026.11.14 © 2026 Japan Digital Design, Inc. 1
2. とあるエンプラ企業「あ、うちのAWS、インターネット出られないんで」 あるエンプラ企業のAWS環境に自社サービスを公開したい。自社サービスはAWS以外のクラウドで稼働。 コンテナをシュッとデプロイするだけであれやこれや柔軟にゼロスケールもできちゃう XXXXX Run でマルチモーダルなAIプロダクトを提供。 技術的な話以外も 色々と苦労しそう... AWS外から公開 いいね！となっても ラストワンマイルで 本番利用までいけない どうつなぐ？ ※本発表は架空のケーススタディであり、現在の所属企業・関係企業とは無関係です © 2026 Japan Digital Design, Inc. 2
3. 木美 雄太（きみ ゆうた） VP of Architecture, Japan Digital Design, inc. 兵庫県・姫路市在住。東京の会社でSolution ArchitectチームとInfra Engineerチームを所管するグループマネージャ。 10年以上のエンプラ経験から、今日はしばらくはAIに奪われそうにない、AIにまったく関係のない話をします。 業務端末 M5 MacBook Pro ※Windowsも選択可 長女 勤務場所 リモートワーク前提で 地方在住者も多数（私も） 開発環境 Claude Code、Codex などなど https://speakerdeck.com/ykimi © 2026 Japan Digital Design, Inc. 3
4. 結論：好きなAWSサービスは「PrivateLink」です ちょっとアプリを公開したいだけなのでエンプラ企業と専用線で外部接続するのはとてもとても大変… PrivateLinkで何とかする方法を説明指針とともに検討 まずサービス名が素晴らしい。 「プライベートな接続」 エンプラ企業の第一印象は二重丸 AWS PrivateLink ん...？ PrivateLinkでAWS以外とも接続できるの？ © 2026 Japan Digital Design, Inc. 4
5. まずPrivateLinkではAWSの他のVPCで稼働するサービスに接続可能 NW-JAWSでは釈迦に説法どころか、気軽に「インターネットには出ない」とかふんわり言うと怖いのでAWS公式ドキュメントを引用。 サービス公開側はエンドポイントサービスを作成し、サービス利用側はエンドポイントサービスに対するVPCエンドポイントを作成する。 VPC サービスを公開 インターネットには 出ない VPC NLB PrivateLink VPC Endpoint VPC内のプライベートIPを持つ 接続インターフェース Client Endpoint Service VPCエンドポイントとエンドポイントサービスまたはリソース間の トラフィックは、パブリックインターネットを経由することなく、 AWSネットワーク内に留まります。 ー AWS公式ドキュメント「AWS PrivateLink接続」より © 2026 Japan Digital Design, Inc. 5
6. 構成は単純。NLBなのでAWS外のプライベートIPもターゲットにできる 自前のリバースプロキシサーバを立てるといった対応も不要。 自社内でAWSと他クラウドを接続する対応は必要なものの他社との接続に比べれば何倍もマシかと（既設ならなお良し） エンプラ企業 自社 他クラウド App LB 専用線 /VPN IPターゲット NLB PrivateLink VPC Endpoint Client Endpoint Service 気になるのは 名前解決 TLS証明書 接続制御 © 2026 Japan Digital Design, Inc. 6
7. 名前解決は「Private DNS」というとても気の利いた機能に任せる クライアントはVPC EndpointのプライベートIPアドレスの名前解決が必要。既定では ` vpce-093a…..vpce.amazonaws.com` で名前解決。 Private DNSを使うと、エンドポイントサービス側で決めた名前で名前解決できるように自動で構成してくれる。 自社 エンプラ企業 Private DNS名 “api.example.com” パブリックドメインとして ドメイン所有権の確認が必要 他クラウド App LB Private DNSを 有効可 専用線 /VPN VPC Endpoint NLB PrivateLink Endpoint Service ホスト部を含む1レコード ゾーン“api.example.com” が自動作成される 自社のパブリックドメインというのがまた良くて... Client Private Hosted Zone “api.example.com”でVPC Endpointの プライベートIPが名前解決される © 2026 Japan Digital Design, Inc. 7
8. 公開ドメイン・公開CAでTLS証明書もマネージド機能に任せればOK HTTPSのサーバ認証ではクライアントから見たFQDNに対応する証明書が必要。DNS名が一致しない場合、証明書の検証に失敗する。 他クラウドのCertificate Managerで証明書の発行・更新をマネージドにでき、クライアントは公開CAの証明書として検証できる。 “api.example.com”に対する公開証明書を発行 エンプラ企業 自社 Certificate 他クラウド Manager 証明書付与 App LB TLS終端 TCPリスナー 専用線 /VPN (TLS終端しない) NLB Endpoint Service PrivateLink “api.example.com” で名前解決。 通常のCAストアで 証明書を検証可能 VPC Endpoint Client Private Hosted Zone 名前解決・証明書もシンプルかつマネージドに構成。PrivateLink最高 © 2026 Japan Digital Design, Inc. 8
9. 接続制御もPrivateLinkの機能やSecurity Groupで制御可能 エンドポイントサービスに接続要求を送れるプリンシパルは制限可能。手動承認の必須化も可能。 接続口（VPCエンドポイント）に対する接続元はセキュリティグループで制御可能。 自社 接続要求を送れるアカウント / ロール / ユーザを制限可能 エンプラ企業 接続口も 自由に閉じられる 他クラウド App LB 許可するプリンシパル 専用線 /VPN NLB 接続承認 Endpoint Service PrivateLink Security Group VPC Endpoint Client Private Hosted Zone 接続要求に対する 手動承認が構成可能 （自動承認も可） © 2026 Japan Digital Design, Inc. 9
10. つながることは分かった。 では、この構成は「インターネットに出られない」と 言っているエンプラ企業が受け入れられるものなのか？ （ここからは私のN=1の浅い経験にもとづくどう説明するかの話） CONFIDENTIAL © 2026 Japan Digital Design, Inc. 10
11. どこまでを気にするかによって異なるもののインターネットには出ない エンプラ企業側の責任範囲だけが気にする範囲で、責任境界の先は関知しません。というスタンスならPrivateLinkだけで担保。 責任境界の先まで気にされる場合はNLBの先の経路は別途検討なものの、End-to-Endでインターネットに出ない構成は組める。 エンプラ企業 自社 インターネットには 出ない 他クラウド App LB 専用線 NLB End-to-Endで インターネットに出ない 構成も組める PrivateLink VPC Endpoint Client Endpoint Service 責任境界 インターネットへの 経路は不要 ただ「インターネットに出ない」さえ説明すればOKになる...？ © 2026 Japan Digital Design, Inc. 11
12. 従来手段が頭の中にあり、それを前提に考えているケースが経験上多い そもそも、エンプラ企業が従来手段で本質的に守りたいことは何かを理解しないと説明責任は果たせない。 相手の考え、行為には正当な理由があり誰しも懸命に仕事をしていることを前提に置いて、彼らが本質的に守りたいことを理解する。 例えば、他企業との接続手段として「専用線による外部接続」が頭の中にあるならば 1 接続元・接続先がネットワーク的に限定されており、仮に認証情報の漏えいや 認可設定のミスがあってもネットワークの到達性という多層防御があること 2 リクエストの主導権・起点は常にエンプラ企業側にあり 統制外の外部企業側を起点としたリクエストはできないこと © 2026 Japan Digital Design, Inc. 12
13. 手段は変わっても本質的に守りたいことは変わらないことを説明する PrivateLinkは接続元・接続先が限定された単方向の接続なので、前ページで記載の2点は守れる。 ただ「インターネットに出ません」ではなく、本質的に守るべきことは変えずに手段だけが変わることを説明することも大切。 自社 エンプラ企業 指定の接続元しか 接続許可しない 他クラウド App LB 専用線 /VPN NLB AWS仕様として 単方向のみ エンドポイントは 指定サービスにしかつながらない PrivateLink VPC Endpoint Client Endpoint Service © 2026 Japan Digital Design, Inc. 13
14. まとめ 1 PrivateLinkで入口は作りNLBのIPターゲットでAWS外まで接続可能 2 名前解決や証明書もマネージドな機能に任せよう 3 エンプラ企業が従来手段で本質的に守りたいことを理解しないと 説明責任は果たせない CONFIDENTIAL © 2026 Japan Digital Design, Inc. 14
15. Thank you. D is c l ai m er : T he i n fo r m at i o n pr o v i ded i n t h is pr es e nt at i o n i s f o r i n fo r m at i o n al p u rp o s es o nl y a nd d oe s n o t c o ns t i t u te l ega l , f i na n ci al , o r pr o fe s s i o nal adv i ce . Ev e ry ef for t h as bee n made t o e nsu r e t he ac cu r ac y of t h e i n for mat i on , bu t th e pr ese nt er an d t h e compa ny acc ept no r espon si bi l i t y for an y er r or s or omi ssi ons. Th e vi ew s ex pr es s ed a re t h o s e o f t h e pr es en t er a nd do no t ne ces s a r il y r efl ec t t h e v i ew s of t h e co m pa ny . C onf i den t ia l it y Noti c e: Th is prese nt at i on c ont ai n s c onf i den t i al i n format i on i n te nd ed onl y for t h e desi gn at ed aud ie nc e. Un au t h o r iz ed di st r i bu t i o n o r r epr o d uc t i o n o f th i s c o nt e nt i s st ri c t ly pr o h ib i te d. 免責事項: このプレゼンテーションで提供される情報は、情報提供のみを目的としており、法的、財務的、または専門的なアドバイスを構成するものではありません。 情報の正確性を確保するために努めていますが、誤りや脱落について発表者および会社は一切の責任を負いません。 本プレゼンテーションで表明された見解は、発表者の個人的なものであり、会社の見解を必ずしも反映するものではありません。 機密性に関する注意: このプレゼンテーションには機密情報が含まれており、指定された対象者のみを対象としています。無断での配布や複製は固く禁じられています。 CONFIDENTIAL © 2026 Japan Digital Design, Inc. 15