本日の主なトピック #
- Amazon CloudFront がオリジンへの Mutual TLS (mTLS) をサポートし、セキュリティを強化
- Amazon Connect が音声対話の自動テスト用 API と、より正確な待ち時間予測機能を提供開始
- SageMaker JumpStart に DeepSeek OCR や MiniMax などの新モデルが追加
- AWS STS が OIDC フェデレーションでプロバイダー固有のカスタムクレーム検証をサポート
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon CloudFront がオリジンへの Mutual TLS (mTLS) サポートを発表 #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon CloudFront は、オリジンサーバーに対する相互TLS認証 (mTLS) のサポートを開始しました。このセキュリティプロトコルにより、顧客はオリジンサーバーへのリクエストが許可された CloudFront ディストリビューションからのみ来ていることを、TLS証明書を使用して検証できるようになります。この証明書ベースの認証により、CloudFront の身元を暗号技術的に検証できるため、顧客が独自のセキュリティ制御を管理する必要がなくなります。 顧客は、AWS Private Certificate Authority によって発行されたクライアント証明書、または AWS Certificate Manager を通じてインポートしたサードパーティのプライベート認証局の証明書を利用できます。
何が嬉しいのか #
これまでは、オリジンサーバー側でリクエストが CloudFront からのものであることを確認するために、共有シークレットヘッダーやIP許可リストなどのカスタム認証ソリューションを構築・維持する必要がありました。これらはシークレットのローテーションやリストの更新といった運用上のオーバーヘッドを伴いました。 今回のオリジン mTLS サポートにより、標準化された証明書ベースの認証アプローチを実装でき、これらの運用負担を排除できます。これにより、組織は独自のコンテンツに対して厳格な認証を強制し、AWSオリジン（Application Load Balancer や API Gateway など）、オンプレミスサーバー、サードパーティクラウドプロバイダー、外部CDNなどを含むバックエンドインフラストラクチャに対して、検証済みの CloudFront ディストリビューションのみが接続を確立できるようにすることが可能になります。
これまでとどう変わるのか #
- これまで: CloudFront からのリクエストであることを検証するために、共有シークレットヘッダーの埋め込みや、CloudFront のIPアドレス範囲の許可リスト管理といった、運用コストのかかるカスタムソリューションが必要でした。
- これから: CloudFront 側でクライアント証明書を提示し、オリジン側でそれを検証する標準的な mTLS プロトコルを利用できるようになり、カスタムソリューションの管理が不要になります。
具体的なユースケース #
- セキュリティ要件の厳しいバックエンド保護: オンプレミスサーバーや他のクラウドにあるオリジンサーバーに対し、CloudFront 経由のアクセスのみを厳密に許可したい場合。
- API Gateway や ALB へのアクセス制限: 特定の CloudFront ディストリビューションからのアクセスのみを受け入れるように、mTLS を使ってロックダウンする場合。
mTLS は「Mutual Transport Layer Security」の略です。 通常のTLS（SSL）ではサーバー側のみが証明書を提示してクライアント（ブラウザなど）がサーバーを認証しますが、mTLSではクライアント側も証明書を提示し、サーバーとクライアントがお互いに認証し合います。 主な特徴は以下の通りです。
- 双方向の認証による高いセキュリティ
- IoTデバイスやゼロトラストネットワークでのデバイス認証によく利用される
- 認証鍵の管理が必要
Amazon Connect が改善された待ち時間予測機能をローンチ #
投稿日: 2026年01月30日
何ができるようになったのか #
Amazon Connect は、キューおよびキュー待機中のコンタクトに対する、より正確な「推定待ち時間」メトリクスの提供を開始しました。この改善されたメトリクスは、ルーティング基準やエージェントの熟練度設定ともシームレスに連携して機能します。
何が嬉しいのか #
コンタクトセンターは、顧客に対してより正確な待ち時間を伝えることができ、顧客体験を向上させることができます。また、待ち時間が長引く場合にコールバックを提案するなどの判断も、より適切なタイミングで行えるようになります。 さらに、この正確な予測値を利用して、複数のキュー間でワークロードを効果的に分散させる戦略的なルーティングが可能になります。例えば、あるキューの待ち時間が長すぎる場合に、より空いている別の対応可能なチームへ転送するといった判断が自動化しやすくなります。
これまでとどう変わるのか #
- これまで: 待ち時間の予測精度が状況によっては十分でなかったり、複雑なルーティング条件下での活用が難しかった可能性があります。
- これから: 改善された精度により、例えば「請求担当への電話が混雑（待ち時間15分）しているため、2分で対応可能なクロストレーニング済みの別チームへ転送する」といった動的で高度なルーティング判断を、自信を持って実装できるようになります。
具体的なユースケース #
- 動的なフロー制御: 推定待ち時間が閾値を超えた場合のみ、自動的にコールバックのオファーを再生する。
- 負荷分散: 複数のスキルグループ間で、推定待ち時間が短い方へ優先的に着信を振り分ける。
Amazon Connect が音声対話をテスト・シミュレーションするための API を提供開始 #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon Connect は、コンタクトセンターの体験をシミュレーションするテストを構成および実行するための API の提供を開始しました。 この API を使用すると、発信者の電話番号や顧客プロファイル、電話の理由（例：「注文状況を確認したい」）、期待される応答（例：「リクエストは処理されました」）、および営業時間外やキューが満杯といったビジネス条件などのテストパラメータをプログラムで設定できます。
何が嬉しいのか #
これまで、音声対話フロー（IVR）のテストは手動で行うか、サードパーティ製のツールに頼る必要がありました。 今回の API 公開により、テストを CI/CD パイプラインに直接統合し、デプロイサイクルの一部として自動回帰テストを実行できるようになります。また、複数のテストを同時に実行して大規模にワークフローを検証することも可能です。 これにより、ワークフローの変更を迅速に検証し、新しい顧客体験を自信を持って本番環境にデプロイできます。
これまでとどう変わるのか #
- これまで: 音声フローの変更を確認するには、実際に電話をかけたり、管理コンソール上のシミュレーターを手動で操作するなど、自動化が困難でした。
- これから: API 経由でプログラム的に通話シミュレーションを実行できるため、コードとしてのインフラストラクチャ (IaC) や自動デプロイメントパイプラインと組み合わせた、モダンな開発プロセスが実現できます。
具体的なユースケース #
- CI/CD パイプラインへの組み込み: 新しい問い合わせフローをデプロイする前に、自動的にシナリオテストを実行し、意図した通りに応答が返るかを確認する。
- 異常系のテスト: 営業時間外や混雑時など、再現させるのが面倒な条件をパラメータで設定して挙動を確認する。
AWS GovCloud (US) リージョンで AWS Network Firewall の柔軟なコスト配分が可能に #
投稿日: 2026年02月02日
何ができるようになったのか #
AWS GovCloud (US) リージョンにおいて、AWS Transit Gateway のネイティブアタッチメントを通じて、AWS Network Firewall の柔軟なコスト配分 (Flexible Cost Allocation) が利用可能になりました。 これにより、データ処理コストを異なる AWS アカウント間で自動的に分配できるようになります。
何が嬉しいのか #
これまでは、ファイアウォール所有者のアカウントにすべての費用が集約されていました。そのため、セキュリティチームやネットワークチームが中央集権的にファイアウォールを管理する場合、利用部門へのコスト配賦（チャージバック）を行うには独自の計算や管理が必要でした。 今回の機能により、組織の要件に基づいてデータ処理料金を適用するメータリングポリシーを作成でき、実際に利用したアプリケーションチームやビジネスユニットのアカウントに自動的に検査コストを割り当てることが可能になります。
これまでとどう変わるのか #
- これまで (GovCloud): AWS Network Firewall のコストは、ファイアウォールリソースを所有するアカウントが一括で負担していました。
- これから: トラフィックの発生元や送信先など、実際の利用状況に基づいて、他の AWS アカウントへコストを直接請求・配分できるようになります。これは既に商用リージョンでは提供されていた機能と同等です。
具体的なユースケース #
- セキュリティコストの透明化: 中央のセキュリティ部門がファイアウォールを一元管理しつつ、そのコストを利用している各アプリケーション部門の予算から拠出させる。
AWS HealthImaging が JPEG XL のサポートを追加 #
投稿日: 2026年02月02日
何ができるようになったのか #
AWS HealthImaging は、JPEG XL 転送構文 (1.2.840.10008.1.2.4.112) で圧縮された非可逆 (Lossy) 医療画像の保存と取得をサポートしました。 これにより、デジタル病理学のホールスライドイメージングシステムなど、JPEG XL エンコードされた DICOM データを必要とするアプリケーションとの統合が容易になります。
何が嬉しいのか #
このサポートにより、JPEG XL 画像データはトランスコード（形式変換）されることなく、そのまま保存されます。 これにより、データの忠実度（Fidelity）が維持され、再圧縮による画質の劣化を防ぐことができます。また、取り出し時にもトランスコードのレイテンシーが発生しないため、高速に画像を取得できます。さらに、JPEG XL の高い圧縮効率を活かしてストレージコストを削減できる可能性があります。
これまでとどう変わるのか #
- これまで: AWS HealthImaging は通常、データを内部的に High-Throughput JPEG 2000 (HTJ2K) 形式に正規化して保存していました。そのため、JPEG XL データは変換処理が必要であり、処理時間や画質の変化、あるいはサポート外であるといった制約があったと考えられます。
- これから: JPEG XL 形式のままネイティブに保存・取得できるようになり、変換処理のオーバーヘッドがなくなります。
具体的なユースケース #
- デジタル病理学: JPEG XL を標準的に利用するスライドスキャナやビューアとの連携。
- 医療画像アーカイブ: 高効率な圧縮フォーマットである JPEG XL を用いて、大量の画像データを低コストかつ高品質に保存する。
AWS STS が Google, GitHub, CircleCI, OCI の特定プロバイダー固有クレームの検証をサポート #
投稿日: 2026年02月02日
何ができるようになったのか #
AWS Security Token Service (STS) は、IAM ロールの信頼ポリシーおよびリソースコントロールポリシーにおいて、Google, GitHub, CircleCI, Oracle Cloud Infrastructure (OCI) といった主要な ID プロバイダー (IdP) 固有の特定のクレーム（claims）の検証をサポートしました。
AssumeRoleWithWebIdentity API を介した OpenID Connect (OIDC) フェデレーションを行う際に、これらのプロバイダーが送信するカスタムクレームを IAM ポリシーの条件キー (Condition Keys) として直接参照できるようになります。
何が嬉しいのか #
これまで、OIDC フェデレーションでのアクセス制御は、主に sub (Subject) や aud (Audience) といった標準的なクレームに依存していました。
今回のアップデートにより、IdP が提供するより詳細な属性情報（カスタムクレーム）を使って、きめ細やかなアクセス制御ルールを記述できるようになります。これにより、フェデレーテッドアイデンティティに対するデータ境界（Data Perimeters）の確立が容易になり、セキュリティを強化できます。
これまでとどう変わるのか #
- これまで: 例えば GitHub Actions との連携では、
subクレーム（例:repo:user/repo:ref:refs/heads/main）に対してStringLikeなどの演算子を使ってパターンマッチングを行うことで、リポジトリやブランチを制限するのが一般的でした。 - これから: プロバイダーが公開する特定のクレーム（属性）が個別の条件キーとして利用可能になるため、より明示的かつ厳密に条件を指定できるようになる可能性があります（例：特定のプロジェクトIDやワークフローIDなどを個別に判定するなど）。
具体的なユースケース #
- GitHub Actions: 特定のリポジトリかつ特定の環境（Environment）からのみロールの引き受けを許可するポリシーを、個別のクレーム条件で記述する。
- CircleCI: プロジェクトIDやコンテキストIDに基づいて、AWS リソースへのアクセス権限を厳密に分離する。
DeepSeek OCR, MiniMax M2.1, Qwen3-VL-8B-Instruct が SageMaker JumpStart で利用可能に #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon SageMaker JumpStart に、新たに以下の3つの基盤モデルが追加され、簡単にデプロイして利用できるようになりました。
- DeepSeek OCR: 文書処理のための視覚テキスト圧縮を探求したモデル。フォーム、請求書、図表、密集したテキストレイアウトを持つ複雑な文書から構造化情報を抽出できます。
- MiniMax M2.1: コーディング、ツール使用、指示の追従、長期的な計画（Long-horizon planning）に最適化されたモデル。多言語ソフトウェア開発の自動化や、複雑なマルチステップのオフィスワークフローを実行できます。
- Qwen3-VL-8B-Instruct: 優れたテキスト理解と生成、深い視覚的知覚と推論、拡張されたコンテキスト長、強化された空間およびビデオダイナミクスの理解を提供するビジョン言語モデルです。
何が嬉しいのか #
これらの高度に専門化された最新モデルを、SageMaker JumpStart のマネージドな環境を通じて数クリックでデプロイできます。 インフラのセットアップやモデルの最適化に時間をかけることなく、文書解析、自律型エージェント開発、マルチモーダルアプリケーションといった高度なAI機能を自社のアプリケーションに組み込むことが可能になります。
これまでとどう変わるのか #
- これまで: これらの特定のモデルを利用するには、自分でコンテナイメージをビルドしたり、モデルの重みをダウンロードして SageMaker エンドポイントにデプロイする構成を手動で行う必要がありました。
- これから: SageMaker コンソールや SDK から直接選択するだけで、すぐに推論エンドポイントを立ち上げることができます。
具体的なユースケース #
- DeepSeek OCR: 紙の請求書や手書きのメモを含む複雑な業務文書のデジタル化とデータ抽出。
- MiniMax M2.1: 社内開発者向けの高度なコーディングアシスタントや、定型業務を自動化するAIエージェントの構築。
- Qwen3-VL-8B-Instruct: 画像やビデオの内容を理解し、それに基づいて対話を行うマルチモーダルチャットボットの開発。