制約と判断ポイントのクイズ

このクイズでは、6つの移行上の制約、判断の順序、料金体系について理解度を確認します。

多肢選択問題

1. TLS IDとTCP接続モデルを正しく区別している説明はどれですか？
   • A) SigV4署名とEnvoyのiptables例外によるアプリケーションへの影響
   • B) 認証済みHTTP IDと匿名TLSポリシー、ServiceリスナーとTCPリソース接続を分けて考える
   • C) ホップごとの料金とSTSへの依存
   • D) 障害ドメインの集中とクォータ制限

回答を表示

回答: B) 認証済みHTTP IDと匿名TLSポリシー、ServiceリスナーとTCPリソース接続を分けて考える

解説: これらは現在のAPIと信頼境界についての選択です。すべてのTLS認証ポリシーが不可能だと証明するものでも、Lattice製品全体でTCPリソース接続が提供されないと示すものでもありません。

2. 移行設計で最初に決めるべきことは何ですか？
   • A) 共有ライブラリとegressプロキシのどちらで署名するか
   • B) 規制でエンドツーエンド暗号化またはワークロード間の相互認証が必要かどうか。これによってHTTPSリスナー + IAM AuthとTLS Passthroughが分かれ、その後の設計の大部分が決まる
   • C) Lattice Serviceの数と推定コスト
   • D) ノードのSecurity Groupで使うプレフィックスリストの設定

回答を表示

回答: B) 規制でエンドツーエンド暗号化またはワークロード間の相互認証が必要かどうか。これによってHTTPSリスナー + IAM AuthとTLS Passthroughが分かれ、その後の設計の大部分が決まる

解説: この判断は組織のセキュリティ要件に基づきます。TLS Passthroughでは、LatticeはSigV4の呼び出し元を認証したり、L7ルーティング用のHTTPフィールドを検査したりできません。認証ポリシーのプリンシパルは匿名に限られます。そのため認証済みワークロードIDと認可には、mTLSやSPIREを含む可能性があるエンドポイント/アプリケーション設計が必要です。HTTPSリスナーを選ぶと、次に署名方式を決めます。設計を選択する前に、セキュリティレビュー担当者とこの境界に合意してください。

3. Latticeのコストはどのように見積もるべきですか？
   • A) 呼び出しチェーンが深いほど、Serviceのプロビジョニング料金が増える
   • B) データ量とプロビジョニング時間に加え、チェーンの深さ、fan-out、リトライを含む実際のService呼び出し数を数える
   • C) チェーンの深さでAZ間の料金が決まる
   • D) チェーンが深いほどクォータに早く到達する

回答を表示

回答: B) データ量とプロビジョニング時間に加え、チェーンの深さ、fan-out、リトライを含む実際のService呼び出し数を数える

解説: 単純な4回の呼び出しチェーンでも、その前提でのみリクエストは4件になります。時間単位の料金、転送バイト数、リトライ、アクセスモデルもコストに影響します。この資料では節約額は測定していません。

4. 呼び出しチェーンの証拠はどのように維持すべきですか？
   • A) 移行後にアプリケーションが変わり、呼び出しチェーンも異なるため
   • B) 移行前後のアプリケーショントレースを保持し、LatticeログやリクエストIDと関連付ける
   • C) CloudWatchにチェーンの深さのメトリクスがないため
   • D) 移行後はコスト見積もりが不要なため

回答を表示

回答: B) 移行前後のアプリケーショントレースを保持し、LatticeログやリクエストIDと関連付ける

解説: Latticeにネイティブのspanがなくても、アプリケーションのspanが消えたり、移行後に呼び出しチェーンを分析できなくなったりするわけではありません。

5. 平文TCPのトラフィックがある環境では、どの構成が推奨されますか？
   • A) どこでもTLSを導入し、すべてをLatticeに移す
   • B) ServiceのHTTP/TLSリスナーをTCPリソース接続や既存のプライベート接続の代替案と分けて評価する
   • C) 平文TCPのServiceをすべて削除する
   • D) Latticeのraw TCPリスナーを有効にする

回答を表示

回答: B) ServiceのHTTP/TLSリスナーをTCPリソース接続や既存のプライベート接続の代替案と分けて評価する

解説: リソース設定では、ServiceのL7ルーティング/認証を引き継がずにTCPを利用できます。各プロトコルに適切なモデルを選び、Controller/APIのサポートを確認してください。

6. クラスター内通信をLattice経由にしない場合、どのようなトレードオフがありますか？
   • A) 常に有利なので、トレードオフはない
   • B) コストとレイテンシーを抑えられるが、Kubernetes Service DNSへの直接呼び出しには認証ポリシーが評価されない。そのため内部トラフィックの認可はNetworkPolicyまたはアプリケーション層で別途設計する必要がある
   • C) 可観測性は失われるが、認可は維持される
   • D) Gateway API Controllerが動作しなくなる

回答を表示

回答: B) コストとレイテンシーを抑えられるが、Kubernetes Service DNSへの直接呼び出しには認証ポリシーが評価されない。そのため内部トラフィックの認可はNetworkPolicyまたはアプリケーション層で別途設計する必要がある

解説: Latticeはクラスター、VPC、アカウントの境界をまたぐ通信を得意とします。同一クラスター内では利点が少ない一方でコストとレイテンシーが増えるため、境界を越える通信だけをLattice経由にするのが合理的な場合が多くあります。ただしIAMAuthPolicyが認可するのは、Gateways/HTTPRoutes/GRPCRoutesを通るトラフィックだけです。内部トラフィックをLatticeから外すと、その区間の認可がなくなります。ここでコスト最適化と認可の一貫性が衝突します。

7. 障害ドメインをどのように比較すべきですか？
   • A) Latticeはマネージドサービスなので障害は発生しない
   • B) どちらの経路にもローカルと共有の依存関係がある。影響を受けるService、AZ、ポリシー、復旧制御を評価する
   • C) どちらのモデルでも障害範囲は同じである
   • D) Sidecarモデルの方が障害範囲は広い

回答を表示

回答: B) どちらの経路にもローカルと共有の依存関係がある。影響を受けるService、AZ、ポリシー、復旧制御を評価する

解説: プロキシ障害がローカルに限られる場合もありますが、共有メッシュ設定の障害は広範囲に及ぶ場合があります。Latticeの障害がEast-West通信のすべてに影響するとは限らず、顧客側のポリシー/ターゲット/コントローラーの修正作業も残ります。

8. 公式ドキュメントでは確認できなかったため、Needs verificationとされている項目はどれですか？
   • A) SigV4のサービス名がvpc-lattice-svcsであること
   • B) API GatewayがLatticeのService Networkをプライベート統合ターゲットとしてネイティブにサポートするかどうか
   • C) App Meshのサポート終了日が2026年9月30日であること
   • D) リスナープロトコルがHTTP/HTTPS/TLS_PASSTHROUGHの3種類であること

回答を表示

回答: B) API GatewayがLatticeのService Networkをプライベート統合ターゲットとしてネイティブにサポートするかどうか

解説: API Gatewayがプライベート統合ターゲットとしてLattice Service Networkをネイティブに受け入れるという証拠は見つかりませんでした。VPC Linkの背後にあるALB/NLBリスナーへの対応は、ALB/NLBからLatticeのリンクローカル経路へ直接接続できる証拠にはなりません。ブリッジ接続がサポートされているとする前に、対象となるAPIタイプ、サポートされるターゲット/接続、必要な署名と障害動作を実装したプロキシまたはコンシューマーを明示的に検証してください。現行のアカウント/リージョンクォータを確認し、バックエンドターゲットの配置を測定してください。DNS ingressのAZアフィニティは、同じAZ内のバックエンドを保証しません。TLSの匿名プリンシパルポリシーの制限、Controllerの関連付け制限、TLSリスナーのECH/ESNI除外は別途文書化されており、全面的に未確認であるかのように説明してはいけません。