AWS What's New Digest

Appearance

2026年10月03日 ​

[Fargate] Amazon ECS adds Amazon VPC Lattice support for blue/green, linear, and canary deployments ​

概要 ​

Amazon ECSがAmazon VPC Latticeとの統合により、blue/green、linear、canaryの管理されたトラフィックシフトをネイティブにサポートしました。VPC間・アカウント間のサービス通信で段階的なデプロイを簡単に行えます。

変更内容・新機能の詳細 ​

ECSサービスでVPC Latticeをターゲットに指定すると、ECSから直接トラフィックを段階的に移行できるようになります。サポートされる戦略は一括切替のblue/green、等分割で進めるlinear、先行割合を小さくするcanaryの3種類です。デプロイ時にVPC Latticeのターゲットグループとリスナールールを指定し、コンソール／CLI／SDK／IaC（CloudFormation/CDK等）から設定可能です。ライフサイクルフック（Lambdaフックや一時停止フック）を使ったカスタム検証や手動承認が可能で、CloudWatchアラームやECSのデプロイメントサーキットブレーカーと組み合わせて異常検知時に自動ロールバックできます。ベイクタイム（bake time）で旧バージョンを残しておくことで、ダウンタイムなく迅速にロールバックできる設計になっています。この機能は既存サービス／新規サービスの両方で有効化でき、VPC Latticeが利用可能な全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナアプリケーション開発者、プラットフォームチーム、SRE/運用チーム
  • 利用シーン: クロスVPC／クロスアカウントのマイクロサービスを段階的にリリースしたい場合（canary／linear／blue-green）や、リリース前にテストトラフィックで新バージョン検証を行いたい場合
  • 運用効果: 本番トラフィックの段階的移行によるリスク低減、CloudWatchやデプロイサーキットブレーカーと組み合わせた自動ロールバックでダウンタイムと障害影響の最小化、ライフサイクルフックによる自動検証／承認ワークフローの実現

技術的な注意点 ​

  • IAM権限: ECSサービス更新やVPC Latticeリソースへの操作権限が必要です（ecs:UpdateService等、vpc-lattice系APIや関連のEC2/ELB系の読み取り権限）。Lambdaフックを使う場合はLambda呼び出し権限やiam:PassRoleが必要です
  • リージョン制限: VPC Latticeが利用可能なリージョンで利用可能です。該当リージョンでVPC Latticeがサポートされているか事前に確認してください
  • 対応サービス: ECSのサービス（Fargate含む）で使用可能ですが、既存の構成によってはターゲットグループ／リスナールールの追加作業が必要です
  • 設定依存: トラフィックシフトにはVPC Latticeのターゲットグループとリスナールールの正しい設定が必須。CloudWatchアラームやECSデプロイメントサーキットブレーカーを組み合わせることで自動ロールバックが有効になります
  • コスト: VPC Latticeの利用料金、CloudWatchアラーム・ログ、Lambda実行コスト、データ転送や追加のリソースに対する料金が発生する可能性があります。事前にコスト見積りを行ってください

参考情報 ​

[Health] AWS Health introduces the version catalog for software lifecycle management ​

概要 ​

AWS Healthが「バージョンカタログ」を導入しました。サービスごとのソフトウェアバージョンとサポート期限を一元的に把握でき、アカウント固有の予定イベントを待たずに事前対応できるようになります。

変更内容・新機能の詳細 ​

バージョンカタログはAWSサービス横断でサポートされるソフトウェアバージョンと各バージョンのライフサイクル情報（サポート開始・終了のタイムライン等）を提供する機能です。AWS Healthダッシュボード上で参照でき、またBusiness Support Plus、Enterprise Support、Unified Operationsの契約を持つ顧客はAWS Health APIを通じてオペレーションワークフローへ組み込めます。従来のPlanned Lifecycle Eventsはアカウント／リソース固有に主要バージョンのEoS（End of Support）を十分前に通知するものでしたが、バージョンカタログはサービス全体のサポート状況を示すことで、事前にアップグレード計画やガバナンス制御を構築し、アカウント固有の通知が来る前に新しいサポート済みバージョンへ移行することを可能にします。ローンチ時点でのカバレッジにはAmazon RDS、Amazon EKS、AWS Lambdaが含まれ、今後対応サービスが追加される予定です。機能はすべてのAWS商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用・SRE、プラットフォームチーム、セキュリティチーム、DB/コンテナ運用者
  • 利用シーン: ソフトウェア（DBエンジン・Kubernetes・ランタイム等）のアップグレード計画作成、脆弱性対応の優先度付け、ガバナンス／コンプライアンスチェックの自動化
  • 運用効果: アカウント固有の通知を待たずに計画的なアップグレードが可能になり、EoSに伴うリスク（セキュリティ、サポート切れによる障害）を低減できる
  • システム統合: AWS Health API経由でCI/CDパイプラインやCMDB、インシデント管理ツールへ組み込み、検知→計画→実行の自動ワークフローを構築しやすくなる

技術的な注意点 ​

  • IAM権限: AWS Health APIを呼び出すために適切なIAMポリシーが必要です（例: health:DescribeEvents / health:DescribeEventDetails 等）。API呼び出し用のロール/ユーザーポリシーを設定してください
  • サポートプラン: AWS Health APIによるライフサイクルデータの統合はBusiness Support Plus, Enterprise Support, Unified Operationsの顧客が利用可能です（ダッシュボードは全ユーザーが参照できる箇所がある場合あり）
  • リージョン制限: 記事では「すべてのAWS商用リージョンで利用可能」と明記されています。GovCloud（US）や中国リージョンについては記事で言及されていないため、必要であれば個別確認してください
  • コスト: 記事上はバージョンカタログ自体の追加料金についての言及はありません。ただし、API利用に伴う通常のネットワーク費用や運用コスト、サポートプラン費用は考慮してください
  • データカバレッジ: ローンチ時はAmazon RDS、Amazon EKS、AWS Lambdaなどが含まれ、対象サービスは順次拡張されます。特定サービス/エンジンの詳細はドキュメントで確認してください
  • 運用上の注意: 大規模環境ではAPIのポーリング頻度やレート制限を考慮し、キャッシュや差分取得（変更通知）を用いた設計を推奨します。自動化導入時はテスト環境でアップグレード手順を検証してください

参考情報 ​

[Govcloud Us] Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.37 ​

概要 ​

Amazon EKS と Amazon EKS Distro が Kubernetes 1.37 をサポート開始しました。EKS クラスターの新規作成および既存クラスターのアップグレードがコンソール、eksctl、IaC ツール経由で可能です。

変更内容・新機能の詳細 ​

Kubernetes 1.37 では複数の機能改良とバグ修正が含まれています。主なポイントは以下の通りです。

  • Metrics API が一般提供 (GA) となり metrics.k8s.io/v1 に昇格。これにより kubectl top や HPA が Pod/Node の CPU・メモリ使用量を安定して参照できます。
  • Dynamic Resource Allocation (DRA) の device taints/tolerations が GA に。GPU 等のデバイスをドライバーや管理者が taint できるようになり、スケジューラは toleration がない Pod をそれらのデバイスから避けます。
  • Horizontal Pod Autoscaler の scale-to-zero がベータに進み既定で有効。minReplicas: 0 を許容する autoscaler（object/external metrics を使用するもの）は、アイドル時に Pod を 0 にスケールダウンし需要回復時に復帰できます。
  • EKS は EKS の利用可能リージョン（AWS GovCloud (US) を含む）で Kubernetes 1.37 をサポート。EKS Distro のビルドは ECR Public Gallery と GitHub で入手可能です。
  • クラスターの作成・アップグレードは EKS コンソール、eksctl、または Terraform 等の IaC で実行可能。アップグレード前に EKS Cluster Insights（CloudWatch Container Insights）で問題点を確認することが推奨されます。
  • 詳細や互換性、ライフサイクル方針は EKS ドキュメントおよび Kubernetes のリリースノートを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kubernetes を運用するクラウドエンジニア、SRE、プラットフォームチーム、機械学習/GPU を利用するアプリケーション開発者
  • 利用シーンまたは効果: kubectl top や HPA によるリソース監視・自動スケーリングの信頼性向上、DRA による GPU 等専用デバイスのスケジューリング制御、スケール-to-zero によるコスト最適化（アイドル時に Pod を 0 にしてリソース削減）
  • 運用効果: オートスケーリングの精度向上とコスト削減、デバイス割当ての明確化によりクラスタ安定性やリソース利用効率が改善
  • 互換性リスク: クラスター内のアドオン・CRD・ドライバの互換性確認が必要。事前のステージング検証を推奨
  • リージョン影響: すべての EKS 利用可能リージョン（GovCloud (US) 含む）でサポート済み

技術的な注意点 ​

  • IAM権限: クラスター作成/アップデートには eks:CreateCluster / eks:UpdateClusterVersion、マネージドノードの更新には eks:UpdateNodegroupVersion 等の権限が必要。ノードの IAM ロールを渡すために iam:PassRole も必要
  • アップグレード手順: 管理プレーン→アドオン→ノード順が一般的。マネージドノード/Managed Node Group とセルフマネージドノードで手順が異なるためドキュメントに従って実施
  • 互換性: アドオン（CNI、CSI、metrics-server、カスタムコントローラ等）、CRD、カスタムリソースの互換性確認が必要。kubectl/kubelet のクライアント互換も確認
  • DRA 注意点: DRA を利用するには対応するデバイスドライバ/デバイスプラグインが必要。デバイスを taint することでスケジューリング挙動が変わるためテストが必要
  • scale-to-zero 要件: minReplicas: 0 を使用する HPA が object/external metrics を参照する場合に有効。外部メトリクス基盤や metrics-adapter の設定を確認
  • クラスタインサイト/監視コスト: Cluster Insights（CloudWatch）を有効化すると追加の CloudWatch コストが発生する可能性あり
  • EKS Distro 入手: ECR Public Gallery と GitHub でイメージ/ビルドを取得可能。ECR public にアクセスする権限とネットワーク設定を確認
  • コスト: Kubernetes バージョン自体に追加課金はないが、アップグレードに伴うノード再作成や CloudWatch 監視、追加リソース利用により費用が増加する可能性あり
  • リージョン制限: 記事時点では全リージョン（GovCloud (US) 含む）で対応。ただし将来的な差異や一部リージョンでのアドオン未対応があり得るため事前確認を推奨

参考情報 ​

[General] Amazon Aurora DSQL now supports partial indexes ​

概要 ​

Amazon Aurora DSQLが部分インデックス（partial indexes）をサポートしました。テーブル全体ではなく特定の条件を満たす行だけをインデックス化でき、クエリ性能向上とインデックス保存コストの削減が期待できます。

変更内容・新機能の詳細 ​

CREATE INDEX 文に WHERE句を追加して、インデックスに含める行の条件を指定できるようになりました。部分インデックスは指定した条件を満たす行だけを格納するため、テーブル全体が大きくなってもインデックスサイズは小さく保たれます。Aurora DSQLのクエリオプティマイザは、クエリのフィルタ条件が部分インデックスの条件に含まれる（＝インデックス条件の範囲内である）場合にその部分インデックスを使用します。これにより、例えば「open orders」など稼働中の小さなワーキングセットに対する検索で読み取るデータ量を削減し、高速化とストレージ節約が図れます。部分インデックスはAurora DSQLが利用可能なすべてのAWSリージョンで利用可能です。詳細はCREATE INDEXのAurora DSQLユーザーガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース設計者、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: 履歴データと稼働中データが混在するテーブル（例：完了済み注文の長い履歴の中の未処理注文）に対する高速検索
  • 運用効果: インデックスのサイズと読み取りI/Oを削減し、クエリ遅延の低減およびストレージコストの削減が可能

技術的な注意点 ​

  • DBユーザー権限: CREATE INDEXを実行できるデータベース内の権限が必要です（通常はDBスキーマのALTER/CREATE権限）。IAMではなくDBユーザーの権限管理に注意してください
  • リージョン制限: Aurora DSQLが提供されているすべてのリージョンで利用可能です（記事時点）。リージョンによる差異はAWSのサービス提供状況に依存します
  • コスト: インデックス保存容量は削減される可能性がありますが、部分インデックスに該当する行の挿入/更新/削除時はインデックスの更新が発生するため書き込みコスト（IOPS/レイテンシ）が増える場合があります
  • クエリ最適化: オプティマイザはクエリのフィルタが部分インデックス条件に含まれる場合にのみ適用します。WHERE句の条件が一致しないとインデックスは利用されないため、実際のクエリプランをEXPLAINで確認してください
  • 制約と互換性: 部分インデックスでサポートされる条件式や制限（式の種類、関数使用の可否、一意制約の挙動など）はドキュメントを確認してください。既存のアプリケーションやORMが生成するクエリと条件が合致するかを検証してください
  • インデックスメンテナンス: 長期的にはインデックスの有用性を監視し、不要になった部分インデックスは削除することを検討してください

参考情報 ​

[General] AWS Brazil automates distribution of non-Brazilian software product licenses to Brazilian customers ​

概要 ​

AWS Brazilが「Brazil 2P Distribution Program」を開始し、非ブラジル系ISVのSaaSライセンスをブラジル国内の顧客へ自動的に流通・請求・支払処理するワークフローを提供します。AWS BrazilがSeller of RecordとしてBRL建て請求・税計算・源泉徴収・支払を代行します。

変更内容・新機能の詳細 ​

主な機能と処理フロー:

  • 対象: 非ブラジルの独立系ソフトウェアベンダー(ISV)が対象で、ISVはAWS Brazilにローカル配布権を許諾することで参加します（Brazil 2P distribution termsに同意）。
  • 許諾作成: ISVはAWS Partner Centralまたは公開APIで配布許諾(distribution authorizations)を作成してAWS Brazilに配布権を付与します。
  • 販売者/価格決定: AWS BrazilがSeller of Recordとなり、ブラジル向けにプライベートオファーを作成し、購入者向け価格を決定します（ISVが直接価格を請求するわけではない点に注意）。
  • 請求・通貨・支払: 購入者にはUSD価格が提示されますが、請求はBRLで行われ、請求書日付の為替レートが使用されます。支払方法はクレジットカード（Visa/Mastercard/American Express）またはPay by Invoice（PBI、請求書支払）で、購入者は発注番号（PO番号）を追加可能、請求書はAWS Billing Consoleで参照できます。
  • 税務・源泉徴収・送金: ブラジルの税法に従った税計算と源泉徴収（withholding tax）の計算・差引・支払（disbursement）をAWS Brazilが実行し、ISVへの支払も自動化されています。
  • レポーティング: ISVはSeller Insightsダッシュボードで取引・支払状況を追跡可能。配布許諾、支払明細、源泉徴収の計算結果、請求書発行のステータス等が可視化されます。
  • 自動化の対象: 配布許諾の管理、販売オファー作成、請求書発行、税計算と源泉徴収、支払（disbursement）、およびレポーティングが自動化されています。
  • 留意点: AWSがローカルの売り手（Seller of Record）として動作するため、価格提示・請求通貨・税処理の責任分担が従来の自己販売とは異なります。

影響範囲・利用シーン ​

  • 対象ユーザー: 非ブラジルISV（Marketplace出品者）、AWS Marketplaceを通じてブラジル市場に展開したいソフトウェアベンダー
  • 利用シーン: ブラジル顧客向けのSaaSライセンス販売をローカライズ（BRL請求・現地税処理）して短期間で販売開始したい場合
  • 運用効果: 税務・請求・支払周りのローカル手続きをAWSが代行するため、ISVは市場参入障壁を下げて販売に集中できる（現地法人や複雑な税務処理の負担軽減）
  • 購買側の利便性: ブラジルの買い手はBRL請求・複数支払手段・PO番号添付などローカル慣習で購入できるため採用障壁が低下
  • 会計／コンプライアンス影響: AWSがSeller of Recordとして請求・源泉徴収を実施するため、ISV側の収益計上・源泉税処理の扱いが変更される可能性があり、会計処理の調整が必要

技術的な注意点 ​

  • IAM権限: ISV側はAWS Partner CentralおよびMarketplace用APIにアクセスする権限が必要（配布許諾を作成・管理するための権限）。
  • リージョン制限: 本プログラムはブラジル顧客向けのローカル配布（AWS BrazilがSeller of Record）に限定される。ブラジル以外の地域には適用されない可能性あり。
  • コスト: AWSによる請求・税計算・送金等のサービスにはMarketplace手数料や為替差損、源泉税に起因する実質受取額の減少などが発生する可能性があるため、収益モデルを再評価してください。
  • 税務／コンプライアンス: ブラジルの消費税・源泉徴収ルールに基づく計算が行われる。ISVは現地税務処理、二重課税の回避、税務報告要件について自社の税務顧問と確認する必要があります。
  • API/インテグレーション: 配布許諾作成はPartner Central UIおよび公開APIで可能。自動化のためにAPI統合を行う場合はAPI仕様・認証・レート制限を確認してください。
  • 請求通貨と為替: 購入者向けにUSD価格が表示されるが請求はBRLかつ請求書日付の為替レートが適用されるため、為替差損リスクがある点に留意してください。
  • レポーティング: Seller Insightsダッシュボードで取引および支払の状況を確認可能。定期的な照合と会計連携を推奨します。
  • 支払手段: クレジットカード（Visa/Mastercard/AmEx）とPBIが利用可能。PBIを利用する場合の与信・回収条件を事前に確認してください。

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026