みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 8 月 4 日（火）に、半導体業界向けのイベント EDA on the Cloud 2026 – Tokyo を AWS 麻布台オフィスで開催します。EDA ワークロードのクラウド活用に加えて、Cadence AI Super Agent による設計・検証フローや、Anthropic Japan による「半導体のためのフロンティア AI」など、AI 関連のセッションが揃っています。ソニーセミコンダクタソリューションズ株式会社様による「ソニー半導体 EDA 基盤の Cloud Journey」の講演も予定されています。定員 100 名、参加費無料です。ご興味のある方はお早めにご登録ください。 それでは、7 月 20 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース 寄稿：弁護士ドットコムにおける AWS DevOps Agent の活用事例 – インシデント対応の自動化と属人化の解消 弁護士ドットコム株式会社 様は、法律相談ポータル「弁護士ドットコム」や電子契約サービス「クラウドサイン」を運営する企業です。サービスの拡大とともにアラートが増える一方、調査は一部の熟練エンジニアに依存していました。これを解決するために、Datadog Monitor のアラートを起点に AWS DevOps Agent が自動で調査を始める構成を組み、Skills と Jira の MCP で起票までつなげました。その結果、あるレイテンシ障害では、従来 30 分ほどかかっていた根本原因の特定を約 10 分で終えています。今後は、繰り返すアラートへの予防策を提案する Proactive Incident Prevention の活用を本格化させるそうです。 ブログ記事「9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、「書く」から「決める」への転換」を公開 9 社 11 チーム・約 90 名が自社の実課題を持ち込み、 Kiro と Claude Code で AI 駆動開発ライフサイクル（AI-DLC）を 2 日間走り切った合同ワークショップのレポートです。「Kiro は 1 ヶ月と見積もった。私たちは 2 日で 80% 終わった」という声の一方で、生成物の正しさを判断し続ける負荷が人間に集中したという指摘も率直に載っています。満足度は 4.7/5.0、体感の工数削減率は平均 74.0%。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」に、2 日間の学びが凝縮されています。 ブログ記事「22社51名の参加者が2時間で業務アプリを自作し発表 ！Claude ・Kiro実践ワークショップの記録」を公開 22 社 51 名が 2 時間のハンズオンで自分の業務課題を題材にアプリを作り、その場で発表したワークショップの記録です。日本曹達株式会社様の広報課の方が、過去の問い合わせ回答を検索できる農業化学品 FAQ アプリを作られた例が取り上げられています。「このアプリを作ってください」というお題をあえて出さない設計が、満足度 100% につながったようです。社内で同じような会を企画される方のヒントになりそうです。 ブログ記事「【開催報告】AWS Summit Japan 2026 – AWS for Telcom 展示ブース」を公開 通信業界向けの 7 ブースをまとめた開催報告です。株式会社NTTドコモ様は AWS 上の 5G コアを国内初のハイブリッドクラウド構成で商用化し、 Amazon Bedrock AgentCore 上のエージェントと GitOps による構築自動化でリードタイムを 80% 短縮されました。100 万台超の機器を扱うネットワーク保守 AI エージェントでは、障害復旧時間を 50% 以上縮めています。KDDI株式会社様は基地局制御基盤の内製開発に AI-DLC を導入して開発期間を 70% 削減、ソフトバンク株式会社様は Amazon Neptune でネットワークトポロジーを時系列管理する様子を展示されました。 ブログ記事「スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援」を公開 「あの商品どこ？」に新人スタッフが即答できない、という店舗の困りごとをスマートグラスと音声 AI エージェントで解く展示の解説記事です。音声をそのまま受けて音声で返す Amazon Nova 2 Sonic がモデル内で Tool Use まで済ませ、Amazon Bedrock AgentCore Gateway に登録した 5 つの Lambda を MCP 経由で呼び出します。自店舗に在庫がなければ近隣店舗や EC まで自律的に探しにいく挙動が読みどころです。手が塞がる現場での情報アクセスという課題は、製造や物流にもそのまま当てはまります。 ブログ記事「【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫」を公開 複数システムにデータが散らばり、日次レポートの目視確認で異常発見が数日遅れる。そんな物流現場の課題に Amazon Quick で応える展示の紹介です。Quick Automate が業務システムを横断監視して Microsoft Teams へ通知し、Quick Sight で滞留状況を確認、Chat Agent が基幹データと過去報告書をまたいで原因を掘り、Connectors で業者へのメール送信まで完結します。半日かかっていた原因追及が数分になる流れを、4 ステップで追えます。 ブログ記事「AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告」を公開 建設機械 20 台のフリート管理を題材に、同じデータへの 3 つの異常検知アプローチを並べて比べた展示報告です。人手による報告、 Amazon SageMaker AI の古典的な機械学習、そして Amazon Bedrock AgentCore と Strands Agents によるエージェント型。「異常スコアは出るが、なぜ起きたのか、何をすべきかは分からない」という機械学習の限界に対して、対処指示まで含むアラートを返せる差が具体例つきで示されます。機械を止める判断は人間に残す、という線引きの考え方も参考になります。 ブログ記事「AWS Summit Japan 2026 に見る Resilience at AWS」を公開 レジリエンス関連のセッション 4 本とブース展示 6 本のまとめです。生成 AI 視点では、AI 駆動カオスエンジニアリング、AWS DevOps Agent による「調査は AI、判断は人」のインシデント対応、Kiro と AWS Resilience Hub を組み合わせて、マルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで生成するデモが目を引きます。ナレッジを整えたことで DevOps Agent の根本原因到達が 6 分 32 秒から 3 分 38 秒に縮んだ、という実測値も載っています。 ブログ記事「【開催報告】Neuron Community – 2026 Vol.1」を公開 AWS Trainium / Inferentia と AWS Neuron の知見を共有するコミュニティイベントの開催報告です。カラクリ株式会社様は、Amazon EKS 上の Neuron 分散学習プラットフォームと、NKI カーネル開発を自律的に進めるエージェントを発表されました。AWS 側からは、デバイス指定を変えるだけで PyTorch のコードを Trainium で動かせる Native PyTorch support（ベータ）や vLLM on Trainium、Neuron 2.31 の NKI 強化が共有されています。Project Rainier では 140 万個超の Trainium が稼働中とのことです。 ブログ記事「AI エージェントが変える AWS 運用の未来【AWS DevOps Agent & AWS サポート ランチタイムセミナー開催レポート】」を公開 「深夜にアラートが鳴っても調査する人手が足りない」というスタートアップの悩みに向けたランチタイムセミナーのレポートです。Amazon ECS の 500 エラーを題材にした AWS DevOps Agent のデモに加えて、一次調査はエージェント、判断が必要なところは AWS サポートの専門エンジニアへ、という組み合わせ方が解説されています。DevOps Agent からサポートチケットを直接起票できる点と、AWS Business Support+ や AWS Activate クレジットといったコスト面の選択肢も整理されています。 ブログ記事「今月の AWS オブザーバビリティ – 2026年6月」を公開 6 月に発表された Amazon CloudWatch と AI 駆動型オペレーションの新機能のまとめです。OpenTelemetry メトリクスと PromQL クエリの一般提供、Logs Insights への 23 コマンド追加、AWS DevOps Agent のカスタム SRE エージェントと MCP / A2A 対応などが並びます。Amazon EKS 上の AI/ML ワークロードを namespace やチーム単位で GPU コスト配賦するリファレンスアーキテクチャ、Claude Code のトークン消費量を追跡するパターンまでカバーしています。 ブログ記事「AWS Certified Machine Learning Engineer – Associate アップデート (MLA-C02) のお知らせ」を公開 AWS Certified Machine Learning Engineer – Associate が MLA-C02 に更新されます。ドメイン構成は変えずに、基盤モデルのファインチューニングや RAG アーキテクチャの実装、エージェンティック AI、 Amazon Bedrock のカバレッジ、責任ある AI の実践が加わります。ベータ版試験（英語のみ、170 分、85 問、75 USD）の予約は 9 月 1 日開始、現行 MLA-C01 の英語での最終受験日は 9 月 28 日です。日本語はベータ期間中も MLA-C01 で受験でき、全言語対応の標準版は 2027 年初頭の予定です。 ブログ記事「Claude Opus 5 が Kiro で利用可能になりました」を公開 （ changelog ） Kiro の IDE / CLI / Web すべてで Claude Opus 5 が使えるようになりました。時間のかかる作業に強くなり、並列で動かしたエージェントが互いの成果を上書きしてしまうケースが減っています。スタブやプレースホルダを残さずタスクを完走する点、コードレビューで誤検知を抑えつつ実バグを拾う点が Opus 4.8 からの差分です。あわせて、 Kiro で GPT-5.6 が利用可能に なった記事（前号で触れた英語版の日本語訳）も出ています。 サービスアップデート Claude Opus 5 が AWS で利用可能に Anthropic の Claude Opus 5 が AWS で利用可能になりました。数時間から夜通し動き続けるエージェント、コードベースを理解しながら戦略を組み替えるコーディング、長文ドキュメントの推論が強みです。ドキュメント中心の業務で最も伸びが大きいと説明されています。Amazon Bedrock 経由（ゼロデータ保持がデフォルト有効）と Claude Platform on AWS 経由（ゼロデータ保持はリクエストベース）の 2 つから選べます。 Amazon Bedrock AgentCore がトレースとログを単一ロググループにまとめた統合オブザーバビリティを提供 Amazon Bedrock AgentCore が、トレース・プロンプト・構造化ログ・標準出力をエージェントごとの単一の CloudWatch ロググループへ配信するようになりました。これまではトレースが共有の aws/spans、イベントログが別のロググループに分かれており、1 回の呼び出しをデバッグするために複数のロググループを探す必要がありました。エージェント単位で IAM ポリシーとカスタマー管理キーによる暗号化を適用できるようにもなっています。7 月 20 日以降に作ったエージェントはデフォルトで有効、既存分は環境変数と ADOT 0.17.1 以降への更新で移行できます。 Claude Sonnet 5 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock でも Claude Sonnet 5 が使えるようになりました。Claude Opus 4.8 とあわせて、GovCloud (US-West / US-East) の bedrock-runtime と、GovCloud (US-West) の次世代推論エンジン bedrock-mantle の両エンドポイントから呼び出せます。 Amazon SageMaker AI 推論の GPU インスタンスが拡充、G7e が東京リージョンでも利用可能に NVIDIA RTX PRO 6000 Blackwell を最大 8 基積む G7e インスタンスが、Amazon SageMaker AI 推論のアジアパシフィック（東京 / ソウル）、欧州（ロンドン）に広がりました。合計最大 768 GB の GPU メモリで、FP8 なら最大 70B パラメータのモデルをマルチノードなしで載せられます。推論性能は G6e 比で最大 2.3 倍。国内のユーザーに大きめのモデルを低レイテンシーで届けたいときの選択肢になります。同じ週に G7 インスタンス （米国 3 リージョン、G6 比で最大 4.6 倍、7B〜30B 向け）と G6 の AWS GovCloud (US-East) 対応 も発表されています。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポート Amazon SageMaker Unified Studio が Amazon OpenSearch をデータソースとして扱えるようになりました。プロジェクトに接続を追加すると data explorer に OpenSearch のデータが並び、クエリエディタやノートブック、ビジュアル ETL ジョブから Amazon Redshift や Amazon S3 のデータと突き合わせられます。アプリケーションログとトランザクションデータを、ツールを行き来せずに見たいときに便利です。Unified Studio が使えるすべてのリージョンが対象です。 Kiro IDE 1.0.182 と CLI 2.14.0 が公開 Kiro IDE 1.0.182 では、ユーザーレベルのグローバル hooks と検索できるセッション履歴パネルが加わり、企業プロキシ環境での安定性が上がりました。応答が中断したときの自動復帰と、MCP ツールの動的な再読み込みにも対応しています。CLI 2.14.0 では、V2 のカスタムエージェント設定を V2 / V3 共通の形式へ移す /upgrade-agent コマンドが入りました。 Kiro が AWS GovCloud (US) で Opus 4.8 / Sonnet 5 とユーザーアクティビティモニタリングに対応 AWS GovCloud (US) の Kiro IDE / CLI で、Claude Opus 4.8（1M コンテキスト、クレジット倍率 2.2 倍）と Claude Sonnet 5（実験的サポート、同 1.3 倍）が使えるようになりました。あわせて管理者向けに、利用状況ダッシュボードと、クレジットやモデル利用の日次 CSV を自分の S3 バケットへ配信するレポート、任意のプロンプトログが提供されます。データは自社アカウントに残り、S3 のストレージ以外の追加料金はかかりません。 Amazon CloudWatch がコーディングエージェントインサイトを発表 Amazon CloudWatch に、AI コーディングエージェントの利用状況を可視化するコーディングエージェントインサイトが加わりました。Claude apps gateway for AWS と統合されているため、計装なしで Claude Code のテレメトリが集まります。Codex や GitHub Copilot も対象です。トークン支出の傾向を追ってアラートを設定できます。エージェントの導入率とコミットやプルリクエストの速度との相関、費用対効果の高いモデルの見極めにも使えます。中東（UAE / バーレーン）とイスラエル（テルアビブ）以外のすべての商用リージョンで使えます。 AWS Data Exports が Amazon Bedrock の標準化された製品メタデータを提供 AWS Data Exports が、Amazon Bedrock のコストにモデルプロバイダー、モデル名、料金単位、推論タイプ、オンデマンドやバッチといった機能区分を、標準化された属性として付けるようになりました。Bedrock のコストは統一の「Amazon Bedrock」製品ファミリー名にまとまります。CUR 2.0 のメタデータを解析する自作ロジックなしで支出を配賦できます。追加料金なしで、デフォルトで適用されます。 AWS が AI エージェント向けのオープンソースベンチマーク aws-bench を発表 AI エージェントが実際の AWS タスクをどれだけ正確に、どれだけ効率よく片づけられるかを測るオープンソースのベンチマーク aws-bench が、リサーチプレビューで公開されました。テストケースは調査・トラブルシューティング・インフラ作成の 3 領域。自然言語のクエリ、クラウドリソースの状態、正解を組にしてあるので、任意のエージェントやモデルを同じ基準で採点できます。エージェントの実行基盤を自作している方は、改善の物差しとして試してみてはいかがでしょうか。 Amazon Connect のエージェンティック音声が 50 以上の言語に対応、日本語もサポート Amazon Connect のエージェンティック音声が、日本語を含む 50 以上の言語と 100 を超える音声オプションに対応しました。不自然な間を埋める応答ペーシング、同時発話を避けるターンテイキングの改善、速度・音量・感情の制御も入っています。日本語で自然な音声セルフサービスを組みたいコンタクトセンターには、大きな一歩です。 AWS パートナーセントラルのエージェントが資金調達ガイダンスをすべてのプログラムに拡大 AWS パートナーセントラルのエージェントが、すべての資金調達プログラムに対応しました。今回の拡張で戦略的協業契約（SCA）と AWS Growth Initiative（AGI）が加わっています。資格要件や申請プロセスについては、公式ドキュメントに基づく回答が数秒で返ります。適格性の検証、提出書類の要件照合、必要項目が埋まった申請書ドラフトの作成もエージェントが行うため、手入力とチェック漏れを減らせます。 生成 AI を活用したビジネス課題の解決に取り組むお客様を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング / モデルカスタマイズ / モデル活用の 3 コースから選べて、想定コストの半額を上限とした AWS クレジットの付与や技術支援も用意されていますので、ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。 a

こちらの記事は「MEDLEY Summer Tech Blog Relay」の6日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 本記事では、CLINICS が長きにわたって使用してきたクライアント認証サーバを OpenResty から Nginx へ移行するに至った経緯について紹介します。 特に実際に直面したビジネス課題や技術選定にフォーカスを当ててお話しします。 なお、本記事の主眼は「OpenResty vs Nginx」のツール比較ではありません。比較検討を進めるなかで「そもそも電子署名が要らないのではないか」という気づきに至り、結果として認証サーバ単体ではなくアーキテクチャ全体を見直すことになりました。本記事ではその評価軸と判断の過程を共有します。 想定読者: 既存システムの技術選定・刷新に取り組むエンジニア 検証環境: AWS (ALB / NLB / NAT Gateway / VPC) を前提 執筆時点: 2026年3月。OpenResty / Nginx のバージョン記述は当時の情報 本記事のポイント 本記事は CLINICS のクライアント認証サーバを OpenResty から Nginx へ移行した事例ですが、話の中心はツール置き換えそのものではなく、「そもそも認証サーバは何を解決しているのか」を問い直した過程にあります。 入口の問い : OpenResty の後継として何を選ぶか 見直した問い : 認証サーバに残すべき役割は本当に何か 辿り着いた答え : 経路をネットワーク層で分離すれば、アプリ層の電子署名は不要となり、認証サーバの役割は mTLS 検証のみに縮む 技術選定の決め手 : 「新規ユーザーがクライアント証明書なしでアクセスできる導線が必要」という CLINICS 固有の仕様が、ALB mTLS ではなく Nginx 単体を選ぶ根拠となった ここに至れた理由をひとことで言えば、「OpenResty の代替を探す」ことをやめて、アーキテクチャの前提そのものを問い直したためです。ツール比較は入口にすぎず、本質は技術スタックの外側 — アーキテクチャの前提とサービスの使われ方 — にありました。 前提: なぜクライアント認証 (mTLS) が必要なのか 本題に入る前に、CLINICS のような医療プロダクトにおいて、なぜクライアント認証 (mTLS) を行う認証サーバが必要なのかを整理します。 CLINICS は医療機関で利用される情報システムであり、厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」(2023年5月) の対象となります。同ガイドラインの システム運用編 [Control] 13. ネットワークに関する安全管理措置 では、オープンなネットワークを介した通信について次のように明記されています ( 厚生労働省 ガイドライン公式ページ )。 ⑥ オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用した TLS クライアント認証を実施すること。ただしシステム・サービス等の対応が困難な場合には TLS1.2 の設定によることも可能とする。その際、TLS の設定はサーバ/クライアントともに「TLS 暗号設定ガイドライン 3.0.1 版」に規定される最も安全性水準の高い「高セキュリティ型」に準じた適切な設定を行うこと。 — 医療情報システムの安全管理に関するガイドライン 第6.0版 システム運用編 [Control] つまり、CLINICS がオープンなネットワーク経由でクライアントと通信する以上、TLS 1.3 (または高セキュリティ型設定の TLS 1.2) + mTLS はガイドライン上の要請になります。IPA「TLS 暗号設定ガイドライン」の高セキュリティ型については、公式ページ ( IPA 公式ページ ) を参照してください (執筆時点の最新版は第3.1.1版 (2025年4月25日公開)。上記引用文中の「3.0.1 版」は医療情報ガイドライン第6.0版本文の記載に基づきます)。 CLINICS にクライアント認証サーバが存在する根本理由はここにあります。「ベストプラクティスとして導入している」のではなく、医療情報を扱うサービスとして満たすべき要件として、ネットワーク経路上に mTLS 検証を担うコンポーネントが配置されています。 この「mTLS をどこで終端し、誰が検証するか」が、本記事で扱う設計判断の出発点となります。 旧構成と OpenResty 採用の背景 CLINICS のクライアント認証サーバは、約4年にわたって OpenResty で運用されてきました。サービスがスケールアップしていく時期に設計され、その後も大きな改修を加えずに動き続けてきたものです。 なぜ当時 OpenResty が選ばれたのか、要件と設計判断の順に追ってみます。 要件: mTLS によるクライアント認証 前項で述べたとおり、CLINICS がオープンなネットワーク経由でクライアントと通信する以上、医療情報ガイドラインの要請として mTLS の実装が必要です。クライアント認証サーバは、その mTLS 検証を担うコンポーネントとして配置されています。 設計判断: Web サーバの共通化 一方、CLINICS の Web サーバは、性質の異なる複数経路からのリクエストを単一で捌く構成になっていました。ここでいう「複数経路」とは、次の3種類のユーザーからのリクエストです。 社内オペレーター: サポートデスクなど、社内のオペレーション業務を担うユーザー melmo ユーザー: 患者向けアプリ melmo の利用者 医師 / 医療事務 (本記事では「カルテ利用ユーザー」とも表記): CLINICS カルテをご利用いただいている医療機関のユーザー 追加要件: リクエスト経路の識別 Web サーバを共通化した結果、受け取ったリクエストが「どの経路を辿ってきたか」を判定する必要が生まれました。 設計判断: 電子署名によるリクエスト経路の識別 CLINICS ではこの「経路識別」を、クライアント認証サーバが付与する電子署名で実現していました。 つまり、認証サーバは「mTLS の実装」と「リクエスト経路の識別」の2つの要件を同時に満たす必要がありました。特に経路識別を電子署名で実現するには、リクエストの各種情報を Lua スクリプトから Nginx の変数経由で取り出す必要があります。両方を1つの技術スタックで実現できる選択肢として OpenResty を採用していました。当時の要件に対しては、合理的な選択だったと言えます。 ただし、システムは要件と一緒に古びるものです。約4年の間に、サービスのスケール、ユーザー属性の多様化、AWS 側で利用できる機能の進化があり、当初の前提が少しずつズレてきていました。 旧構成で見えてきた2つの課題 長年運用するうちに、構成上の課題が顕在化してきました。 1. NAT Gateway 依存による経路構成の課題 Web サーバの ALB が Internet-facing スキームのため、ドメイン解決ではパブリック IP が返されます。OpenResty から proxy_pass で ALB へリクエストを送る経路は、結果として VPC 外を経由するルーティングとなり、NAT Gateway を必ず通る構成になっていました。 加えて、OpenResty の Docker Hub 上で公開されている公式イメージ ( openresty/openresty ) は執筆時点で 1.29.2.3 (Nginx 1.29.2 ベース) までが公開されており、Nginx 本家で upstream への keep-alive がデフォルト化された 1.29.7 の変更 ( NGINX Community Blog ) を取り込むには、自前で Docker イメージをビルドする必要がありました。proxy_pass の度に新規 TCP セッションが張られるオーバーヘッドも、サービスを提供する上でのパフォーマンス課題の一つでした。 さらに問題なのは、この経路上にいる NAT Gateway が単一障害点として機能してしまうことです。検討当時、AWS の NAT Gateway は AZ 単位 (Zonal) 動作のみで、CLINICS の構成では認証サーバから Web App への経路が単一の NAT Gateway を経由していました (執筆時点では複数 AZ へ自動展開する Regional NAT Gateway も選択肢に加わっています)。これが落ちると、次の2方向が同時に止まります。 インバウンド方向: 認証サーバ → Web App へのリクエスト経路が遮断され、カルテ利用ユーザーのリクエスト受付が停止する アウトバウンド方向: Web App → 外部 SaaS への連携が不能になる 本来であれば、この経路を NAT Gateway のような単一障害点に依存させることは避けたいところでした。 2. 障害発生時の影響範囲の広さ 社内オペレーター / melmo ユーザー / カルテ利用ユーザーが同じ Web サーバを共有しているため、Web サーバで障害が起きると、性質の異なる全ユーザーに同時に影響が波及する構造になっていました。サービスの成長に対して、リスクが線形以上に膨らんでいた状態とも言えます。 解決の方向性 — 経路の分離と VPC 内閉域化 2つの課題を、打ち手に対応させると次のようになります。 NAT Gateway 依存による経路構成の課題 → ALB を Private Subnet に配置し、認証サーバから Web App までの通信を VPC 内に閉じる 障害発生時の影響範囲の広さ → カルテ利用ユーザーの経路を、社内オペレーター・melmo ユーザーの経路から分離する つまり今回の刷新では、「カルテ利用ユーザーの経路を分離し、VPC 内で完結させる」というアーキテクチャの方針が先に決まります。認証サーバをどう作り直すかは、この方針のあとに続く問いです。 分離の帰結 — 電子署名の存在理由が消える 方針が決まったところで、OpenResty が担ってきた役割を分解し直します。 mTLS によるクライアント認証 — 医療情報ガイドラインの要請 電子署名による経路識別 — 単一の Web サーバが全経路を捌くための仕組み 1 は外せない。では 2 はどうか。 電子署名で経路を識別しなければならなかったのは、「社内オペレーター / melmo ユーザー / カルテ利用ユーザーのすべての経路を、単一の Web サーバが捌いている」からです。経路がネットワーク的に区別できないからこそ、アプリ層の電子署名で区別していました。経路をネットワーク層で分けるなら、電子署名そのものが要らなくなります。 これは何かを工夫して削った結果というより、分離という方針の論理的な帰結です。ただし、この帰結が持つ意味は大きく、認証サーバに残る役割は mTLS によるクライアント認証ただ1つになります。「OpenResty の後継に何が必要か」という問いは、この時点で「mTLS だけなら、何で実装するか」という、ずっと小さな問いに変わっています。 検討した選択肢 — mTLS だけなら、何で実装するか 認証サーバに残る役割が mTLS のみに絞れたことで、選択肢は次の2つになります。 選択肢 A: AWS ALB の mTLS 機能 — クライアント認証をマネージド機能で代替し、認証サーバそのものを廃止する 選択肢 B: Nginx 単体 — 認証サーバは残し、Lua スクリプト (OpenResty) を抜いて標準機能のみで再構成する まず魅力的に見えたのは選択肢 A でした。mTLS しか担わないコンポーネントのために、サーバを自前で運用し続ける理由はないかもしれません。運用負荷を下げ、構成も単純にできると考えていました。 選択肢 A: AWS ALB の mTLS 機能 AWS は ALB に mTLS 機能を提供しています ( ALB Mutual TLS 公式ドキュメント )。ALB の mTLS には verify モード と passthrough モード の2つがあり、それぞれ動作と責務範囲が大きく異なります。 A-1. verify モード ALB がクライアント証明書を直接検証するモードです。クライアントが提示した X.509 証明書を、ALB に紐付けた Trust Store の CA 証明書および CRL (失効リスト) と照合し、検証を TLS ハンドシェイク内で完結させます。検証結果は X-Amzn-Mtls-Clientcert-Serial-Number ・ X-Amzn-Mtls-Clientcert-Issuer ・ X-Amzn-Mtls-Clientcert-Subject ・ X-Amzn-Mtls-Clientcert-Validity などのヘッダでバックエンドに渡されます。 検証・失効確認まで ALB に委任できる: Web App 側に証明書処理コードが不要となり、認証関心をネットワーク基盤側に閉じ込められる 検証失敗の負荷がバックエンドに及ばない: ハンドシェイク段階で検証が完結するため、不正な証明書が Web App に到達することがない 証明書を提示しないクライアントは TLS ハンドシェイクが成立しない: これは「不正アクセスを早期に遮断できる」というメリットでもあり、「正当な理由で証明書を持たないクライアント」を一切通せないという制約でもある A-2. passthrough モード 検証ロジックをアプリ側で自由にカスタマイズできる: Subject や Issuer に応じた認可、組織固有のポリシー適用などが、アプリのコードベースで完結する 検証ポリシーをコードでバージョン管理しやすい: Trust Store の更新を ALB の管理画面ではなくデプロイパイプラインで扱える 証明書チェーン検証・失効確認のコストはすべて Web App 側に乗る: 検証ロジックの実装責任に加え、性能チューニング (チェーン検証のキャッシュ、CRL/OCSP の取得経路) も Web App で持つ必要がある セッション再開 (Session Resumption) はサポートされない: AWS 公式ドキュメント上、passthrough と verify の両モードで Session Resumption は無効化される旨が明記されている ( Mutual authentication with TLS - Before you begin ) 選択肢 B: Nginx 単体 電子署名を捨てたあとの認証サーバに必要なのは、TLS の終端、クライアント証明書の検証、バックエンドへの proxy_pass だけです。これらはすべて Nginx の標準機能で完結します。 そもそも OpenResty を採用していた理由は「電子署名のためにリクエスト情報を Lua で柔軟に扱える」ことでした。Lua を使う動機がなくなった以上、本家 Nginx に戻るのが自然な選択肢になります。本家に戻れば、upstream への keep-alive がデフォルト化された 1.29.7 のような、本家のリリースにも直接追従できます。 比較と評価 — ALB mTLS を採用しなかった理由 ALB mTLS は魅力的に見えましたが、CLINICS のアプリケーション仕様と照らし合わせると採用できませんでした。 CLINICS の仕様 — カルテ利用ユーザーでも mTLS なしで通る経路が必要 CLINICS には、カルテ利用ユーザーであっても、新規ユーザーのクライアント証明書発行時はクライアント証明書を持たない状態でサービスにアクセスできる必要があるという仕様があります。 ALB の verify モードを採用すると、証明書を持たないクライアントは TLS 接続自体が確立しないため、ユーザー登録の導線が壊れてしまいます。 この仕様は、QA チームと「現状どんなパターンのアクセスを通しているか」を一緒に棚卸ししたタイミングで整理できたものでした。コードを読んだだけでは見えてこない「使われ方」が、QA チームの実機検証ノウハウから浮き上がってきた形です。「機能要件」ではなく「サービスの使われ方」の文脈で捉え直す必要がありました。 passthrough モードの場合の難点 では passthrough モードはどうか。ALB は証明書チェーンをヘッダで渡すだけなので、実際の mTLS 検証は Web App 側で行うことになります。これは次のような別種のオーバーヘッドを生みます。 認証ロジックを Web App に持ち込むため、認証関心とビジネス関心が混ざる mTLS の検証コスト (証明書チェーンの検証、失効確認) が Web App の応答時間に直接影響する 「認証サーバを廃止して ALB に寄せる」つもりが、結局 Web App 側に複雑性が移るだけの結果となります。 こうして、mTLS の実装は選択肢 B の Nginx に決まりました。方針 (経路の分離と VPC 内閉域化) と技術選定 (Nginx) を合わせた結果が、次の新構成です。 新構成 各コンポーネントの役割と設計意図 NLB (L4 ロードバランサ) NLB は TCP のままパススルーする L4 ロードバランサとして残しました。理由は、TLS 終端を Nginx に置きたかったためです。ALB を最前段に置くと L7 で TLS を終端することになり、mTLS 検証の選択肢は ALB の verify/passthrough モードに限定されてしまいます。NLB を前段にして TCP のまま Nginx に届けることで、TLS の終端と mTLS 検証を Nginx 側で完結できます。 Nginx (TLS 終端 + mTLS 検証) Nginx を TLS 終端の位置に置いた設計意図は次のとおりです。 Web App を TLS 終端にしない: Web App 側に TLS 終端と mTLS 検証ロジックを持たせると、認証関心とビジネス関心が混ざる (ALB passthrough モードで指摘した課題と同じ理由) 認証ロジックを「単一の場所」に閉じ込める: 認証は Web App より手前で完結させ、Web App はビジネスロジックに集中させる OpenResty 時代の Lua スクリプトが不要になる: 経路識別 (= 電子署名) を捨てたことで、Nginx の標準機能のみで構成できる Private Subnet ALB (L7 ルーティング + ヘルスチェック) ALB は Internet-facing から Private Subnet 配置に変更しました。これにより、Nginx から ALB への通信が VPC 内に閉じ、NAT Gateway を経由しなくなります。 ALB を完全に外して Nginx から Web App に直結する案もあり得ましたが、ALB を残したのは次の役割分担を意図したためです。 L7 ルーティング (パスベース・ホストベース) を ALB に任せ、Nginx は認証に集中させる ヘルスチェックとデプロイ時のローテーションを ALB に委ねる Nginx は認証、ALB は配送 — 関心の分離をネットワーク上の役割としても明示する設計としました。 変更がもたらしたもの 整理すると、新構成は次の4点を同時に実現しています。1 と 3 が2つの課題への直接の回答、2 は分離の帰結、4 はその副産物です。 スコープを「カルテ利用ユーザーからのリクエスト」に限定。社内オペレーター・melmo ユーザーは別経路へ分離 経路がネットワーク的に分かれたため、電子署名による経路識別が不要に。OpenResty で Lua を使う動機がなくなり、Nginx 単体で十分な構成に NAT Gateway を経由しなくなり、構成上の単一障害点が消滅 VPC 内閉域通信になったことで、Nginx 1.29.7 のデフォルト upstream keep-alive ( NGINX Community Blog ) の恩恵もそのまま享受できる構成に 移行で苦戦した点 — 「設計図に書かれていない経路」が一番怖い 新構成を絵に描くこと自体は比較的早く終わりました。本当に時間がかかったのは、その後の「現状どう使われているか」の棚卸しです。 CLINICS には、カルテ利用ユーザーであっても、新規ユーザーのクライアント証明書発行時はクライアント証明書を持たない状態でアクセスできる必要があるという仕様があります。 これは設計図ではなく、サービスの使われ方として存在する仕様です。 この経路の存在に気づくことができたのは、QA チームに依頼した E2E テストの結果を確認したときでした。 SRE 側で設計図やコードを追いかけていた段階では拾えなかった仕様が、その資産を通した検証で表に出てきた、というのが正直なところです。机上の設計図だけを追いかけていたら、リリース後に登録導線が壊れていたかもしれません。 ここで大きかったのは、他チームが積み上げてきた資産を、SRE の移行検証としてそのまま活用できたことです。QA チームが整備している E2E テストは、この移行のために作られたものではなく、日常的な品質担保のなかで育ってきたものです。それを移行検証にも転用できるという、チームをまたいで資産にアクセスできる状態が、机上の設計だけでは見えない仕様を移行前に洗い出すセーフティネットになっていました。 加えて、デグレ検証も大きな工数を割いた工程でした。「動いている既存サーバを置き換える」とは、既存のすべての挙動を保証する必要があるということでもあります。本番と等価な振る舞いをするか、QA チームに新環境での機能の総ざらいを依頼して確認しました。SRE 単独で同等の観点をゼロから組み立てようとしていたら、この検証は成立していなかったと思います。 教訓 — ツール比較の前に、役割の分解があった 今回の移行を通じて残った教訓は、次の2つです。 1. 技術選定の前に、役割の分解がある 「OpenResty の移行」として検討を始めると、現行サーバが担っている役割をすべて引き継ぐことが暗黙の前提になります。その前提のままでは、「Lua 相当の柔軟性を持つ後継」を探し続けていたはずです。 実際には、アーキテクチャの前提 — 単一の Web サーバが全経路を捌く — を先に見直したことで、引き継ぐべき役割は mTLS だけに縮みました。そこまで来れば、ツールの比較はほとんど自明です。言い換えると、OpenResty の代替を探すのをやめたら、OpenResty が要らなくなったということです。 「OpenResty vs Nginx」「ALB mTLS を使うか否か」というツールの比較は、入り口にすぎませんでした。本質は「何を解決しているのか」を問い直すことであり、その答えは多くの場合、技術スタックの外側 — アーキテクチャの前提 — にあります。 2. それでも、最後の決め手は「使われ方」 役割を mTLS だけに絞っても、「ALB mTLS か Nginx か」という選択は残りました。これを決めたのは性能でもコストでもなく、「新規ユーザーのクライアント証明書発行時は、証明書なしでアクセスできる必要がある」という仕様でした。そしてこの仕様は、コードや設計ドキュメントではなく、QA チームの実機検証ノウハウのなかにありました。 ALB mTLS は単体で見れば優れた機能ですが、CLINICS の仕様と組み合わせると採用できません。技術選定の良し悪しは、選定対象の優劣ではなく、選定対象とサービス仕様の組み合わせで決まります。 アーキテクチャ刷新における技術選定は、技術的な正しさだけでなく、アプリケーションの仕様やユーザーがどのようにサービスを使っているかを理解した上で行う必要がある。 移行検証の工程も含めて、今回の刷新で最も時間を要したのはこの理解でした。 まとめ CLINICS のクライアント認証サーバを OpenResty から Nginx へ移行した事例を、背景にあるアーキテクチャ見直しの過程とあわせて紹介しました。 旧構成: 単一の Web サーバが全経路を捌くため、アプリ層の電子署名で経路識別 → NAT Gateway 依存による経路構成や障害波及範囲の広さに課題を抱えていた 方針: カルテ利用ユーザーの経路を分離し、VPC 内に閉じる → 分離の帰結として電子署名が不要になり、認証サーバの役割は mTLS のみに縮小 技術選定: ALB mTLS は CLINICS の仕様 (証明書なしで通る導線が必要) と組み合わせると採用できず、Nginx 単体を採用 教訓: ツール比較の前に役割の分解があり、それでも最後の決め手はサービスの使われ方の理解にあった 今回はカルテ利用ユーザーの経路から着手しましたが、社内オペレーター・melmo ユーザーの経路についても同じ考え方で整理を進めていく予定です。 「動いているもの」を変えるのは怖いものですが、設計時の前提が変わったまま放置すると、いつの間にか「動いているだけのもの」になってしまいます。その差分を埋める作業を、これからも続けていきたいと考えています。 We’re hiring メドレーでは、SRE をはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 7日目の記事は斎藤さんです！お楽しみに！！

本記事は 2026 年 6 月 25 日 に公開された「 Centralized traffic inspection for Oracle Database@AWS 」を翻訳したものです。 前回の記事「 Implement network connectivity patterns for Oracle Database@AWS 」では、3 つの接続パターンを紹介しました。アプリケーション VPC と Oracle Database@AWS ネットワーク間の直接ピアリング、 AWS Transit Gateway を使用した単一リージョン接続、 AWS Cloud WAN を使用したマルチリージョン接続の 3 つです。アプリケーション VPC、オンプレミスネットワーク、Oracle Database@AWS ネットワーク間のトラフィックや、インターネット向けの送信トラフィックのいずれも検査が必要です。本記事では、トラフィックを宛先に到達する前に専用の検査 VPC を経由させる 2 つの集中検査パターンを説明します。1 つは AWS Transit Gateway を使用するパターン、もう 1 つは AWS Cloud WAN のサービス挿入を使用するパターンです。 Oracle Database@AWS は、AWS データセンター内の専用 Oracle Exadata インフラストラクチャ上で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata Database Service と Oracle Autonomous Database へのアクセスを提供するサービスです。金融、ヘルスケア、官公庁などの規制産業では、侵入検知・防止 (IDS/IPS)、データ損失防止 (DLP)、ドメインフィルタリングなどの目的でデータベースとの間を流れるネットワークトラフィックの検査が求められることがあります。 前提条件 前回の接続パターンの記事 で解説した ODB ネットワーク、ODB ピアリング、ピアリングされた CIDR、ODB トランジット VPC の概念を理解しておく必要があります。AWS Transit Gateway または AWS Cloud WAN に接続されたトランジット VPC にピアリングされた ODB ネットワークが必要です。また、 AWS Cloud WAN サービス挿入の概念 や、 Amazon Virtual Private Cloud (Amazon VPC) のルートテーブル、サブネット、 NAT ゲートウェイ 、インターネットゲートウェイといった概念にも精通している必要があります。 重要: 現時点では、ODB トランジット VPC にファイアウォールエンドポイントを直接デプロイできません。トランジット VPC 自身の CIDR 外のアドレス宛てのトラフィックは、サブネットルートテーブルの検索を完全にバイパスして Transit Gateway または AWS Cloud WAN アタッチメント経由で直接転送されます。一部のユースケースでは個別のアプリケーション VPC にファイアウォールエンドポイントをデプロイできますが、この分散型アプローチはルートテーブル設定のオーバーヘッドが増大し、すべての VPC で繰り返す必要があるため、大規模環境では集中検査が実用的な選択肢です。 パターン 1: AWS Transit Gateway による集中トラフィック検査 図 1 のように、このパターンでは ODB ネットワーク、ODB ネットワークとピアリングされた ODB トランジット VPC、アプリケーション VPC、集中検査 VPC (ファイアウォールエンドポイント、NAT ゲートウェイ、インターネットゲートウェイ)、オンプレミスネットワークを Transit Gateway にアタッチメントとして接続します。オンプレミス接続には AWS Direct Connect または AWS Site-to-Site VPN を使用します。Transit Gateway は 2 つのルートテーブルでトラフィックを制御します。検査前ルートテーブルはスポークアタッチメント (アプリケーション VPC、オンプレミス、ODB トランジット VPC) に関連付けられ、デフォルトルート (0.0.0.0/0) が検査 VPC アタッチメントを指します。検査後ルートテーブルは検査 VPC アタッチメントに関連付けられ、アプリケーション VPC CIDR、オンプレミス CIDR、ODB ネットワーク CIDR への個別ルートがそれぞれのアタッチメントを指します。 図 1: Transit Gateway と集中検査 VPC を使用した東西・南北トラフィック検査 東西トラフィックフローのパケットウォークスルー 以下は東西トラフィックフロー (図 1 の ‘a’ / オレンジ色) の手順です。 アプリケーション VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが Oracle データベースのホスト名を解決し、ODB ネットワーク CIDR 内の IP アドレスで接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR (またはデフォルトルート) が Transit Gateway を指すルートがあります。パケットはアプリケーション VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブル (アプリケーション VPC アタッチメントに関連付けられたもの) でルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 検査 VPC の Transit Gateway アタッチメントサブネットにパケットが到着します。サブネットルートテーブルにより、パケットは検査のためファイアウォールエンドポイントにルーティングされます。 検査アプライアンスがセキュリティポリシーに従ってパケットを処理します。検査を通過した場合、サブネットルートテーブルにより検査後のトラフィックは Transit Gateway に戻されます。 Transit Gateway は検査後ルートテーブル (検査 VPC アタッチメントに関連付けられたもの) を参照します。ODB ネットワーク CIDR への個別ルートが ODB トランジット VPC アタッチメントを指しており、パケットはそこに転送されます。 ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続にルーティングします。パケットは ODB ピアリングを経由して ODB ネットワークに入り、Oracle データベースに到達します。 ODB ネットワークからのレスポンストラフィックは対称的な逆パスをたどります。 南北トラフィックフロー (インターネット送信トラフィック) のパケットウォークスルー Oracle データベースワークロードがインターネットアクセスを必要とする場合、インターネットに出る前に集中検査 VPC 経由でトラフィックをルーティングできます。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。このパターンでは、ODB ネットワーク上のピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。詳細は「 Oracle DB@AWS Internet Outbound Traffic blog 」を参照してください。 以下は南北トラフィックフロー (図 1 の ‘b’ / 緑色) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 パケットは ODB トランジット VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブルでルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは NAT ゲートウェイにルーティングされ、ソースアドレス変換が行われます。 NAT ゲートウェイがパケットをインターネットゲートウェイに転送し、インターネットに送出します。 インターネットからの戻りトラフィックは、インターネットゲートウェイ、NAT ゲートウェイ、ファイアウォール、Transit Gateway を経由し、ODB トランジット VPC を通じて ODB ネットワークに戻る逆パスをたどります。 パターン 2: AWS Cloud WAN による集中トラフィック検査 図 2 のように、アプリケーション VPC とオンプレミスネットワークは AWS Cloud WAN コアネットワークにアタッチされ、それぞれのセグメント (App VPC と Hybrid) にマッピングされます。検査 VPC アタッチメントは ネットワーク機能グループ (NFG) にマッピングされます。Transit Gateway は TGW ルートテーブルアタッチメントを介して ODB トランジット VPC と AWS Cloud WAN コアネットワーク間の接続を提供します。ODB ネットワーク CIDR への静的ルートが Transit Gateway 上の ODB トランジット VPC アタッチメントを指しており、この TGW ルートテーブルは Cloud WAN TGW ルートテーブルアタッチメントに関連付けられています。これにより ODB CIDR が BGP 経由で Cloud WAN のセグメントおよび NFG ルートテーブルに動的に伝播されます。 この構成により、Cloud WAN のサービス挿入アクションがトラフィックを検査 NFG 経由で制御します。東西フローには send-via アクション、南北フローには send-to アクションを使用します。以降のセクションで詳しく説明します。 東西トラフィックフロー (send-via アクション) 図 2: AWS Cloud WAN のサービス挿入を使用した東西トラフィック検査 send-via アクションは ODB Network セグメントと App VPC セグメント (およびオンプレミストラフィック用の hybrid セグメント) の間に、検査 NFG を経由するよう設定されます。 以下は東西トラフィックフロー (図 2 の ‘c’) の手順です。 アプリケーション VPC 内の Amazon EC2 インスタンスが Oracle データベースのホスト名を解決し、データベース接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR が AWS Cloud WAN コアネットワークアタッチメントを指すルートがあります。パケットは AWS Cloud WAN コアネットワークに転送されます。 App VPC セグメント (またはオンプレミストラフィックの hybrid セグメント) と ODB Network セグメント間に send-via アクションが設定されています。AWS Cloud WAN のルーティングテーブルがパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは検査 VPC を出て NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。 AWS Cloud WAN は検査後のトラフィックを Transit Gateway ルートテーブルアタッチメントにルーティングします。Transit Gateway から BGP で動的に伝播された ODB ネットワーク CIDR がそこに存在します。 Transit Gateway がパケットを ODB トランジット VPC に転送します。ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続経由で ODB ネットワークにルーティングし、Oracle データベースに到達します。 戻りトラフィックは対称的な逆パスをたどります。send-via アクションは双方向で、ODB ネットワークからのトラフィックもアプリケーション VPC に到達する前に同じ検査 VPC を通過します。 オンプレミストラフィックも同じパターンに従います。hybrid セグメントで Direct Connect または AWS Site-to-Site VPN アタッチメントを通じて AWS Cloud WAN に入り、ODB ネットワークに到達する前に検査 VPC を通過します。 南北トラフィックフロー (インターネット送信トラフィックの send-to アクション) 図 3: AWS Cloud WAN のサービス挿入を使用した南北インターネット送信トラフィック検査 図 3 のように、ODB Network セグメントに検査 NFG を指す send-to アクションが設定されています。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。ODB ネットワークからのインターネット宛てトラフィックは検査 VPC に誘導され、検査後に NAT ゲートウェイとインターネットゲートウェイを経由してインターネットに出ます。パターン 1 と同様に、ピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。 以下はこのフロー (図 3 の ‘d’) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 ODB トランジット VPC がパケットを Transit Gateway に転送します。Transit Gateway は TGW ルートテーブルアタッチメント経由で AWS Cloud WAN コアネットワークにパケットを送信します。 ODB Network セグメントに send-to アクションが設定されているため、AWS Cloud WAN のルーティングテーブルがインターネット宛てパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査を通過したパケットは NAT ゲートウェイに転送されます。NAT ゲートウェイがソース NAT を実行し、インターネットゲートウェイにパケットを転送してインターネットに送出します。 インターネットからの戻りトラフィックはインターネットゲートウェイに到着し、NAT ゲートウェイでアドレス変換を経てファイアウォールに戻り検査されます。検査後、パケットは NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。NFG ルートテーブルには TGW ルートテーブルアタッチメントを指す ODB ネットワーク CIDR の伝播ルートがあり、パケットは Transit Gateway、ODB トランジット VPC を経由して ODB ネットワークに戻ります。 これらのパターンはマルチリージョンデプロイメントにも拡張できます。リージョン VPC、Transit Gateway、検査インフラストラクチャを同じ AWS Cloud WAN コアネットワークにアタッチすることで、追加リージョンをオンボードできます。 考慮事項 Oracle Database@AWS のネットワーク検査を実装する際は、以下の考慮事項を念頭に置いてください。 ODB ピアリングされた CIDR – ピアリングされた CIDR リストは、ピアリング接続を通じて ODB ネットワークと通信可能なすべての CIDR を定義します。東西トラフィックの場合、アプリケーション VPC CIDR (プライマリおよびセカンダリ) とオンプレミスネットワーク CIDR を含めます。AWS 経由で出る南北インターネット宛てトラフィックの場合、データベースが到達する必要がある特定のインターネット宛先 CIDR を含めます。本記事の執筆時点では 0.0.0.0/0 エントリは許可されていないため、ピアリングされた CIDR の制限に準拠する個別の CIDR 範囲にインターネット宛先を分割する必要があります。検査は透過的でオリジナルのソース IP を保持するため、検査 VPC CIDR を含める必要はありません。ピアリングされた CIDR の設定と制限については「 Oracle DB@AWS Internet Outbound Traffic 」を参照してください。 フロー対称性のためのアプライアンスモード – 検査 VPC の Transit Gateway アタッチメント (パターン 1) または AWS Cloud WAN アタッチメント (パターン 2) で アプライアンスモード を有効にしてください。有効にしないと、往路と復路が異なるアベイラビリティゾーンを通過し、ステートフル検査が破綻する可能性があります。 AWS Network Firewall ネイティブ Transit Gateway アタッチメント – AWS Network Firewall は専用の検査 VPC なしで東西検査を行うネイティブ Transit Gateway アタッチメントをサポートしています。南北の送信トラフィックには NAT ゲートウェイを備えた別の VPC が引き続き必要です。 DNS トラフィックパス – ODB ネットワークへの DNS クエリはデータトラフィックと同じ検査パスを通ります。ファイアウォールルールで考慮するか、検査をバイパスするために ODB トランジット VPC に Amazon Route 53 Resolver アウトバウンドエンドポイントを配置してください。 マルチリージョンデプロイメント – クロスリージョンのレイテンシーとデータ転送コストを回避するため、各リージョンに検査 VPC をデプロイしてください。パターン 2 では、AWS Cloud WAN の機能 (シングルホップモード) でどのリージョンの検査 VPC を使用するかを制御できます。 まとめ 本記事では、Oracle Database@AWS に対する集中ネットワークトラフィック検査を実装する方法を紹介しました。単一リージョンデプロイメントでは AWS Transit Gateway と集中検査 VPC を、マルチリージョンアーキテクチャでは AWS Cloud WAN のサービス挿入を使用します。ODB トランジット VPC はインライン検査をサポートしないため、どちらのアプローチも専用の検査 VPC 経由でトラフィックをルーティングします。詳細は「 AWS Network Firewall のドキュメント 」、「 AWS Cloud WAN サービス挿入のドキュメント 」、「 Oracle Database@AWS ユーザーガイド 」を参照してください。 著者について Sameer Malik Sameer は、AWS のプリンシパルデータベースソリューションアーキテクトです。RDS と Aurora に注力し、23 年以上にわたりリレーショナルデータベースに携わってきました。多数のお客様のデータベースワークロード移行・モダナイゼーションを支援しています。 Anvesh Koganti Anvesh は、AWS のソリューションアーキテクトで、ネットワーキングを専門としています。高いスケーラビリティとレジリエンスを備えた AWS ネットワーキングアーキテクチャの構築を支援しています。 Shubham Singh Shubham は、AWS のシニアネットワークスペシャリストソリューションアーキテクトです。AWS サービスを活用した革新的でレジリエントかつコスト効率の高いソリューション設計を支援しています。ネットワーキングとセキュリティ分野でのソリューション構築に注力し、Northeastern 大学でコンピュータネットワーキング専攻のテレコミュニケーションシステム管理修士号を取得しています。 Vihar Kodakandla Vihar は、AWS のドメインスペシャリストエンジニアです。UOps のお客様に対し、オンボーディング、コンテキスト構築、Critical Workload Review を通じたプロアクティブなメカニズムの提供に注力しています。複雑な技術的課題のトラブルシューティングや、AWS ネットワーキングサービス全体のレジリエンスとオブザーバビリティ向上の機会特定を支援しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。