AWS What's New Digest

Appearance

2026年07月01日 ​

[RDS] Amazon RDS for Db2 now supports self-managed Active Directory ​

概要 ​

Amazon RDS for Db2 がセルフ管理の Microsoft Active Directory (AD) ドメインへ直接参加できるようになりました。これにより、AWS Managed Microsoft AD やディレクトリ間トラストを構築せずに、既存のオンプレミス／クラウド上の AD を使って Kerberos による認証（シングルサインオン）を利用できます。

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

新機能により、RDS for Db2 の DB インスタンスをセルフ管理の AD ドメインに直接ドメイン参加（domain-join）させられます。セルフ管理 AD はオンプレミス、AWS 上、他クラウド上のいずれでも利用可能です。認証プロトコルには Kerberos を用い、データベースユーザーの SSO を有効にします。従来はセルフ管理 AD と連携するために AWS Managed Microsoft AD をデプロイし、両ドメイン間でトラスト設定を行う必要がありましたが、本機能によりその追加構成が不要になります。ドメイン参加は新規インスタンス作成時あるいは既存インスタンスの変更時に可能で、ドメイン参加用の委譲サービスアカウントの資格情報は AWS Secrets Manager に保存し、AWS KMS で暗号化します。セルフ管理 AD 自体に対する AWS の追加料金は発生しません。機能は Amazon RDS for Db2 が利用可能な全リージョン（AWS GovCloud (US) を含む）で一般提供されます。詳細な手順、サポートされる DB2 バージョンや細かい設定は Amazon RDS for Db2 User Guide を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ要件上既存の社内 AD を利用したいデータベース管理者、企業のアイデンティティ基盤を使いたいシステム管理者
  • 利用シーン: オンプレミスや別クラウドで運用する Active Directory をそのまま使って RDS for Db2 のユーザー認証（Kerberos/SSO）を実現する場面
  • 運用効果: AWS Managed Microsoft AD の導入やドメイン間トラスト構築の手間と管理コストを削減し、既存の ID 管理ポリシー・コンプライアンスを維持しつつ認証基盤を統合可能

技術的な注意点 ​

  • IAM権限: RDS が Secrets Manager のシークレットを参照・KMS で復号できるよう適切な IAM ポリシー/ロールを付与してください
  • ネットワーク: RDS インスタンスからセルフ管理 AD のドメインコントローラーへ到達可能であること（VPC ルーティング、セキュリティグループ、NACL、VPN/Direct Connect/Transit Gateway などの設定確認が必要）
  • DNS と 時刻同期: ドメイン参加には AD の DNS 解決と正確な時刻同期（NTP）が必須です。RDS がドメインコントローラーを解決できる DNS 設定を用意してください
  • AD の委譲アカウント: ドメイン参加に必要な権限を持つ委譲サービスアカウント（コンピュータをドメインに参加させる権限）を用意し、その資格情報を Secrets Manager に保存・暗号化してください
  • ポート/プロトコル: Kerberos/DNS/LDAP 等の通信が許可されている必要があります（代表的なポート例: TCP/UDP 88 (Kerberos), TCP/UDP 53 (DNS), TCP 389/636 (LDAP/LDAPS), TCP 445/135 など）。詳細は User Guide を確認してください
  • コスト: セルフ管理 AD 自体に追加料金は発生しませんが、RDS の利用料金、Secrets Manager のシークレット保存・API 呼び出し料金、KMS の暗号化/復号料金は発生します
  • リージョン制限: RDS for Db2 が提供されている全リージョン（AWS GovCloud (US) 含む）で一般提供されていますが、詳細なリージョンサポートや制限は User Guide を確認してください
  • サポートされる DB バージョン/構成: 対象となる Db2 のエンジンバージョンやインスタンスタイプ、既知の制約はドキュメントで確認してください

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service optimized for log analytics ​

概要 ​

Amazon OpenSearch Serviceはログ分析向けに最適化された新しいエンジンを追加しました。内部ベンチマークで最大4倍の価格性能比を実現しつつ、従来の全文検索機能も維持します。

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

新エンジンはログ分析（集計・トレンド分析）向けに設計されており、列指向ストレージを導入することで集計ワークロードのストレージ効率を大幅に改善します。主な性能指標は、内部ベンチマークで最大4xの価格性能向上、列指向により最大70%のストレージ削減（同コストで最大3x多くのデータ保持可能）、同ハードウェア上で最大2xの取り込み（ingestion）スループット、ならびに分析クエリが最大2x高速化する点です。全文検索（テキスト検索）機能は保持されており、同一サービス内でPPL（Piped Processing Language）やSQLを使った分析クエリと全文検索の述語を組み合わせたクエリ実行が可能です。利用開始はOpenSearch 3.5以上のドメインを新規作成し、コンソールで“observability”ユースケースを選択してエンジンモードを“optimized”に設定します。クエリ実行はOpenSearch UIのPPL、SQL API、JDBC/ODBCドライバ、Query Workbenchなどから行えます。追加のエンジン料金は発生しません。対応リージョンは12リージョン（US East (N. Virginia, Ohio)、US West (Oregon)、Canada (Central)、APAC: Mumbai, Singapore, Sydney, Tokyo、EU: Frankfurt, Ireland, London, Spain）。

影響範囲・利用シーン ​

  • 対象ユーザー: ログプラットフォーム構築者、SRE/運用チーム、セキュリティ/コンプライアンスチーム、データプラットフォーム担当者
  • 利用シーンまたは効果: 大量ログの長期保持と集計分析（トレンド、メトリクス抽出）、インシデント調査のための全文検索を同一基盤で実行。ストレージ効率向上によりデータ保持量を増やしつつコスト抑制が可能
  • 運用効果: 高速な取り込みと分析による遅延短縮、ストレージ削減による運用コスト削減、SQL/PPLやJDBC経由での既存BIツール連携が容易になることによる運用性向上

技術的な注意点 ​

  • バージョン要件: OpenSearch 3.5以上で新しいエンジンモード（optimized）を選択して利用します
  • ドメイン作成/移行: 新エンジンはドメイン作成時に選択するモードのため、既存ドメインからの切替は新規ドメイン作成とデータ移行（再インデックスまたはスナップショット/復元）が必要になる可能性があります
  • クエリ互換性: PPLおよびSQL経由で分析クエリを実行でき、全文検索述語との組合せクエリもサポートしますが、カスタムプラグインや一部拡張との互換性は確認が必要です
  • IAM権限: ドメイン作成・設定変更・アクセス制御のための権限（コンソール/CloudFormation/API操作）が必要です。事前に管理者とIAMポリシーを確認してください
  • リージョン制限: 発表時点で12リージョンに限定（US East (N. Virginia, Ohio)、US West (Oregon)、Canada (Central)、APAC: Mumbai, Singapore, Sydney, Tokyo、EU: Frankfurt, Ireland, London, Spain）。未対応リージョンでは利用不可
  • コスト: 新エンジン自体に追加料金はありません。ただしインスタンスタイプ、EBS（またはストレージクラス）、データ送受信、スナップショット等の通常コストは発生します。ストレージ効率向上により総コスト低減が期待できます
  • 運用上の注意: 高い取り込み/分析性能を得るためにインスタンスサイズやシャード設計、インデックス戦略（タイムベース、ロールオーバー）を再検討してください

参考情報 ​

[General] Amazon CloudWatch Logs enriches log events with AWS resource tags ​

概要 ​

Amazon CloudWatch Logsがログ受け取り時にAWSリソースのタグを各ログイベントに付与できるようになり、ログのフィルタリング・検索・分析をリソースメタデータで容易に行えるようになりました。設定はCloudWatchの設定画面、CLI、SDKから有効化できます。

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

タグエンリッチメントは、ログがCloudWatch Logsに取り込まれる（ingestion）タイミングで該当ログイベントに当該AWSリソースに設定されたタグを付加します。これにより、アプリケーションやログ送信側の計測コードを変更することなく、team、environment、cost-center、applicationなどの既存のリソースタグを使って即座にログクエリで絞り込みや集約が可能になります。タグはCloudWatch Logsのクエリ言語で参照でき、カスタムパイプラインやログに手動でコンテキストを注入する手間が不要になります。利用可能リージョンは全ての商用リージョン（Middle East (UAE)、Middle East (Bahrain)、Israel (Tel Aviv) を除く）です。設定はAmazon CloudWatch SettingsからGUIで有効化するか、AWS CLI／SDK経由で有効化します。記事では追加料金は発生しないと明記されていますが、タグ追加によりイベントサイズが増えるため、ログインジェスト量／保存量の課金影響を検討してください。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、SRE/運用チーム、セキュリティチーム、コスト管理・FinOps担当者
  • 利用シーン: チーム所有のプロダクションリソースのログ絞り込み、インシデント調査時のコストセンター別フィルタリング、環境別（prod/stage/dev）集計やアプリケーション別トラブルシュート
  • 運用効果: カスタムログ付与やパイプライン改修不要で運用負荷を削減し、タグベースで迅速にログをスコープできるため、トラブルシュートやコスト分析の効率が向上する

技術的な注意点 ​

  • IAM権限: CloudWatchの設定を変更する権限（CloudWatch設定変更を行えるIAM権限）およびリソースのタグを読み取る権限が必要です
  • リージョン制限: 商用全リージョンで利用可（ただし Middle East (UAE)、Middle East (Bahrain)、Israel (Tel Aviv) を除く）
  • コスト: タグエンリッチメント自体に追加料金はかかりませんが、タグ付与によりログイベントのペイロードが増えるため、ログの取り込み量・保存量に応じたCloudWatch Logsの料金に影響する可能性があります
  • 設定方法: CloudWatch SettingsからGUIで有効化するか、AWS CLI／SDKで有効化します（既存のリソースタグを活用）。有効化後は取り込み時点で自動的にタグが付与されます
  • 対象ログ/リソース: 既にAWSリソースに紐づくログイベントに対してリソースタグが付与されます。外部システムやリソース関連付けがないログにはタグが付与されない可能性があります
  • プライバシー/セキュリティ: タグに機密情報（個人情報やシークレット）を含めないよう運用ルールを確認してください。タグがログに付与されることで可視化される範囲が広がります

参考情報 ​

[General] AWS CloudFormation and CDK accelerate development feedback loops with pre-deployment validation on all stack operations ​

概要 ​

CloudFormationがCreate/Updateスタック操作でもデプロイ前バリデーションを自動実行するようになり、プロビジョニング前に一般的なデプロイ失敗を秒単位で検出できるようになりました。CDKも検証結果を統合レポートで出力し、CI/CDやAIエージェントのフィードバックループを高速化します。

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

従来はChange Set作成時のみ実行されていたプロパティ構文エラー、リソース名競合、S3バケットの空であるべき制約などの事前検証が、今回のリリースでCreateStackおよびUpdateStack操作でも自動的に実行されるようになりました。これにより、フルなプロビジョン＋ロールバックサイクルを待たずに、予防可能な失敗を即時に検出できます。さらに、Change Set作成時に警告として出る新たな検証が3種類追加されました：サービスクォータ超過の可能性、AWS Config レコーダーに関する競合（Config recordingが有効でないアカウントへルールを追加する、または既にアクティブなRecorderを再定義する等）、および削除対象のECRリポジトリにイメージが残存しているかの確認（ECR delete readiness）。検出された問題は、操作IDを用いてDescribeEvents APIで参照するか、CloudFormationコンソールのスタックEventsタブ→操作ID（バナーやstatus reasonのリンク）→Operation viewのDeployment validationsタブで確認できます。各エラーは論理リソースIDとプロパティパスを含み、資源がプロビジョニングされる前に特定・修正できます。CDKでは cdk deploy / cdk validate が検証結果を構成単位のトレース付きで統一レポートとして出力し、AIエージェントや自動化ツールが構造化レスポンスを解析して即時に自己修正できるようになっています。事前検証はデフォルトで有効で、無効化したい場合はCreateStack／UpdateStack／CreateChangeSet APIのDisableValidationパラメータ、またはCLIの--disable-validationフラグを使用できます。本機能はCloudFormationがサポートされる全リージョン（中国リージョンを除く）で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: インフラ開発者、SRE、CI/CDエンジニア、IaCを利用するAIエージェント
  • 利用シーン: ローカル反復開発、CIパイプラインでの自動デプロイ、AIによるインフラ構築の自動化、障害原因の早期検出
  • 運用効果: プロビジョニング失敗やロールバックによる無駄な時間・コストを削減し、デプロイのフィードバックループを数秒〜数分短縮
  • セキュリティ/コンプライアンス: AWS Config関連の競合検出により、Config設定ミスによるコンプライアンス逸脱を予防できる
  • コスト影響: 失敗による無駄なリソース作成を減らすことで間接的なコスト削減に寄与（検証自体に追加課金は発生しない想定）

技術的な注意点 ​

  • IAM権限: DescribeEventsやCloudFormationのスタック作成/更新権限が必要です。運用上、検証結果を参照する自動化ツールに適切な権限を付与してください。
  • API/CLIフラグ: CreateStack/UpdateStack/CreateChangeSet に DisableValidation パラメータが追加されました。CLIでは --disable-validation を使用して当該操作のみ検証をスキップできます。
  • 警告とエラーの扱い: 既存のChange Set作成時の検証に加え、Create/Updateでの自動検証が有効になりました。Change Set時に追加された3つのチェックは警告として出るケースが明記されています（運用上は警告内容を確認して対応することが推奨されます）。
  • 出力場所: 問題はDescribeEvents API（操作ID指定）またはCloudFormationコンソールのOperation view→Deployment validationsタブで参照可能。各エラーは論理リソースIDとプロパティパスを含みます。
  • CDK統合: cdk deploy と cdk validate が検証結果を構成単位のトレース付きで出力します。自動化やAIエージェントは構造化レスポンスを解析して自動修正ロジックを組み込めます。
  • リージョン制限: CloudFormationがサポートされる全リージョンで利用可能（中国リージョンは除く）。
  • コスト: 追加の直接課金は明示されていませんが、検証をスキップするとロールバック等でコストが発生するリスクがあります。
  • 運用上の注意: 自動検証を無効化すると、従来通りプロビジョニング開始→失敗→ロールバックのサイクルになるため、CI等で明示的にDisableValidationを使う場合は注意してください。

参考情報 ​

[General] AWS CloudFormation and CDK express mode speeds up infrastructure deployments by up to 4x ​

概要 ​

CloudFormation と AWS CDK に「Express mode」が追加され、リソースの完全な安定化（伝播やトラフィック準備など）を待たずに、設定が適用された時点でスタック操作を完了することで、開発・反復のデプロイ速度を最大4倍に短縮します。開発環境やAIエージェントによるインクリメンタルなインフラ構築で高速なイテレーションを可能にします。

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

Express mode は、従来の "完全なリソース安定化完了まで待機" から完了条件を変更し、「CloudFormation がリソースの設定適用を確認した時点」でスタックの作成・更新・削除を完了扱いにします。たとえば CloudFront のエッジ伝播完了（数分）の待機を不要にし、ドメイン名など必要な情報が得られ次第デプロイを終了させ、残りの伝播はバックグラウンドで続行します。依存関係順の処理や同一スタック内での依存リソース失敗の扱いは維持されますが、デフォルトでロールバックが無効化され（即時の fix-and-retry を容易にするため）、失敗時でも即座に再試行できます。利用方法は CLI/SDK/コンソールで --deployment-config '{"mode": "EXPRESS"}' を指定するか、CDK 利用者は cdk deploy --express を使用します。既存のテンプレート変更は不要でネストされたスタックにも対応します。内部ベンチマークで最大4x の短縮を確認しており、CloudFormation がサポートするすべてのリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、インフラを素早く反復したいSREやMLOpsチーム、AIエージェントや自動化パイプライン
  • 利用シーン: 開発/ステージング環境での頻繁なスタック更新、インフラを小刻みに組み上げるテストワークフロー、CDK を使った高速デプロイのループ
  • 運用効果: デプロイ完了判定が早くなることでフィードバックループが短縮され、イテレーション速度が最大4倍向上（内部ベンチマーク）
  • 注意点（利用時の考慮事項）: 本モードは「設定適用時点」を完了とするため、本番でリソースの完全な伝播やトラフィック切替完了を待つ必要があるワークロードでは期待する動作と異なる可能性があるため注意が必要です。

技術的な注意点 ​

  • IAM権限: 通常の CloudFormation 操作に必要な権限が必要です（モード指定は追加権限不要）。
  • ロールバック: Express mode ではデフォルトでロールバックが無効化されます。失敗時に未完全なリソースが残る可能性があるため、クリーンアップ/再試行運用手順を用意してください。
  • リージョン制限: CloudFormation がサポートするすべてのリージョンで利用可能とされていますが、リージョンごとのサービス提供状況は AWS Region 表を確認してください。
  • コスト: 機能自体の追加料金は示されていませんが、バックグラウンドでの伝播や未削除リソースによる想定外のリソース課金リスクに注意してください。
  • 互換性: 既存のテンプレートやネストされたスタックでそのまま動作します。テンプレートの修正は不要です。
  • 運用推奨: 開発/テスト環境での利用を推奨します。本番で使用する場合は、伝播完了が必須のリソース（例: DNS/Routing/CloudFront トラフィック切替等）に対するフォローアップ策を設計してください。
  • 有効化方法: CLI/SDK/コンソールで --deployment-config '{"mode": "EXPRESS"}' を指定（作成/更新/削除、change set）。CDK は cdk deploy --express を使用。
  • 障害時挙動: 依存関係順の処理や同一スタック内での依存リソース失敗の扱いは維持されますが、ロールバックが無効化されている点を踏まえた復旧設計が必要です。

参考情報 ​

[RDS] Amazon RDS Enhances IAM Database Authentication with Connection Rate Scaling ​

概要 ​

Amazon RDSがIAMデータベース認証の接続レートをインスタンスの利用可能リソースに応じて動的にスケールする機能を提供開始しました。これにより、リソースに応じた高頻度のIAM認証リクエストを伴うエンタープライズワークロードでIAM認証を利用しやすくなります。

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

今回の更新で、IAMデータベース認証の「新規認証リクエスト処理能力」が固定値ではなく、対象DBインスタンス（またはAuroraノード）のCPU／メモリ等の利用可能リソースと実際のワークロード特性に応じてスケールするようになりました。結果として、従来は高頻度接続がネックになって採用をためらっていた環境でもIAM認証を採用しやすくなります。パフォーマンスはインスタンスクラス、同時処理中のクエリ負荷、ネットワークやTLSハンドシェイク等の要因に依存します。推奨される最適化として、同一のIAMユーザーやIAMロール（assumed role）を用いて認証トークンを生成する、もしくは認証トークン自体を可能な限り再利用する（トークンの有効期限内でキャッシュする）ことが挙げられています。対応は全AWSリージョン（IAM DB認証がサポートされるリージョン、GovCloud含む）で利用可能で、対象データベースエンジンはAmazon AuroraおよびAmazon RDSのPostgreSQL、MySQL、MariaDBです。追加の運用改善策としては、コネクションプーリングやRDS Proxyなどのプロキシによる接続管理を組み合わせることで認証負荷と接続オーバーヘッドをさらに抑えられます。詳細はIAMデータベース認証のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベースをIAMで認証している、または認証置換を検討しているクラウドエンジニア、SRE、アプリケーション開発チーム
  • 利用シーン: マイクロサービスやサーバーレスで高頻度にDB接続を行うワークロード、または短時間で多数の新規接続が発生するバースト型トラフィック
  • 運用効果: インスタンスリソースに応じた認証処理能力の向上により、IAM認証採用時の接続ボトルネックが緩和され、セキュアな認証方式を高トラフィック環境でも利用しやすくなる
  • 留意点（利用上の制約）: スケーリングはインスタンスの余剰リソースとワークロード特性に依存するため、インスタンスサイズやアプリの接続方法（トークン再利用、プーリング等）の見直しが必要になる場合がある

技術的な注意点 ​

  • IAM権限: 認証トークン生成には適切なIAM権限（sts:AssumeRole等、アプリが使用するロール／ユーザーの権限付与）とRDS接続用の権限設定が必要です
  • トークン有効期限: RDSのIAM認証トークンは短期間（通常は最大15分）で有効期限が切れるため、トークンのキャッシュ/更新ロジックを実装してください
  • トークン再利用: 新規トークン生成は認証負荷になるため、可能な限り同一プリンシパルでのトークン再利用や生成回数の削減を推奨します
  • クライアント実装: SDK／ドライバでのGenerateAuthenticationToken（または同等機能）利用、TLS接続の確立、システム時計の同期（署名検証のため）を確認してください
  • 接続管理: 接続頻度が高い場合はコネクションプーリングやRDS Proxyの併用で接続数と認証回数を削減できます（RDS ProxyはIAM認証をサポート）
  • リージョン制限: 本機能は全リージョン（IAM DB認証がサポートされるリージョン）で利用可能。GovCloud (US) の対応も含まれますが、利用前にターゲットリージョンでのIAM DB認証対応状況を確認してください
  • コスト: 直接の追加料金は発表されていませんが、高い認証／接続負荷によるCPU／メモリ使用増加が発生した場合、より大きなインスタンスへのスケールやオートスケーリング、またはProxy導入によるコスト影響が考えられます

参考情報 ​

[General] AWS Parallel Computing Service supports in-place Slurm major version upgrades ​

概要 ​

AWS Parallel Computing Service (PCS)が既存クラスターに対して、稼働中ジョブを中断せずにSlurmのメジャーバージョンを最大3バージョン分までインプレースでアップグレードできる機能をサポートしました。管理されたSlurmコンポーネント（コントローラー、会計DB、REST API）がPCS側で順次アップグレードされます。

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

PCSのUpdateCluster（コンソール／AWS CLI／UpdateCluster API）で目標のSlurmバージョンを指定すると、PCSが管理下のSlurmコンポーネント（コントローラー、会計データベース、REST API）を自動でアップグレードします。アップグレード中も既に実行中のジョブは停止せず継続し、キューに入っているジョブはアップグレード完了後に再開されます。会計データはデータベースに保持されます。コンピュートノード（ジョブ実行ノード）はユーザーの任意タイミングで新しいSlurmバージョンへ更新可能です。対応は「最大で現在から3つ先のSlurmメジャーバージョンまで」で、クラスター構成やプラグイン等に応じた検討事項があるため、PCSユーザーガイドの手順と注意点に従って実施してください。なお本機能はPCSが利用可能な全リージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: HPCエンジニア、クラスター管理者、SRE/運用チーム
  • 利用シーン: Slurmのメジャーアップグレード（機能追加／バグ修正／セキュリティ対応）をダウンタイムなしで実施したい場面
  • 運用効果: コントローラー側のアップグレードをサービス管理下で自動化でき、稼働中ジョブへの影響を避けつつ会計データを保持して段階的にノード更新が可能になるため、運用負荷とリスクが低減する

技術的な注意点 ​

  • 対応バージョン: 現行から最大3メジャーバージョン先までアップグレード可能
  • 実行方法: AWS Management Console／AWS CLI／UpdateCluster APIでターゲットSlurmバージョンを指定
  • ジョブへの影響: 実行中ジョブは中断されない。キュー中ジョブは完了後に再開
  • コンピュートノード更新: コントローラー更新後、コンピュートノードはユーザーが任意のタイミングで更新する必要あり（自動で強制更新されない）
  • データ保全: 会計データベースは保持されるが、事前にバックアップを取ることを推奨
  • IAM権限: UpdateCluster等のPCS更新を実行できる権限および、必要に応じてEC2/SSMなどノード操作に必要な権限を確認してください
  • 互換性: カスタムSlurmプラグイン、ジョブスクリプト、サードパーティ統合（例: プラグイン、カスタムDB連携）はバージョン間互換性を検証する必要があります
  • ロールバック: 記載なしのため、ロールバック手順は事前に確認し、必要ならステージングで検証してください
  • リージョン制限: PCSが提供されている全リージョンで利用可能（ただし各リージョンのPCS提供状況を確認）
  • コスト: アップグレード自体に追加料金の明示はないが、ノード置換やスナップショット作成、テスト環境の利用に伴う通常のAWSリソース料金が発生します

参考情報 ​

[General] Amazon ElastiCache T4g nodes now available in additional AWS Regions ​

概要 ​

Amazon ElastiCacheでGraviton2ベースのT4gノードが新たに5つのリージョンで利用可能になりました。バースト可能なCPU性能を必要とするキャッシュ用途に適した低コストのノードファミリーです。

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

今回の拡張により、Amazon ElastiCacheは以下のリージョンでT4gノードをサポートします：Africa (Cape Town) (af-south-1)、Asia Pacific (Jakarta) (ap-southeast-3)、Asia Pacific (Osaka) (ap-northeast-3)、AWS GovCloud (US-East) (aws-us-gov-east-1)、AWS GovCloud (US-West) (aws-us-gov-west-1)。T4gノードはAWS Graviton2プロセッサ（ARMベース）を採用し、ベースラインのCPU性能を維持しつつ必要時にCPUをバーストできる特性を持ち、突発的な負荷増大があるキャッシュ用途に向いています。既存のクラスターはコンソール、AWS CLI、またはAPI経由でノードタイプを変更して移行できます。地域ごとの料金・提供状況や、対応ノードタイプの詳細はElastiCacheの料金ページおよびユーザーガイドの「Supported node types」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: キャッシュ層を利用するアプリケーション開発者、SRE/運用チーム、コスト最適化を図るクラウドアーキテクト
  • 利用シーン: バースト的なトラフィックを処理するRedis/Memcachedのキャッシュ、開発/ステージング環境での低コスト運用、リージョン間レイテンシ要件に対応するローカル展開
  • 運用効果: Graviton2によるコストパフォーマンス向上と、バースト可能なCPUにより突発負荷時のレスポンス維持が期待できる（ただし実働確認推奨）
  • コンプライアンス: GovCloudリージョンへの展開により米国政府向け・規制対応用途でもT4gを利用可能（GovCloudは別アカウント／アクセス要件あり）

技術的な注意点 ​

  • IAM権限: クラスター作成/変更には elasticache:Create*, elasticache:Modify*, elasticache:Describe* 等の権限が必要です。ロールやポリシーを事前に確認してください。
  • リージョン制限: 新たにサポートされたのは af-south-1, ap-southeast-3, ap-northeast-3, aws-us-gov-east-1, aws-us-gov-west-1 の5リージョンのみ。その他リージョンは既存のサポート状況を確認してください。
  • コスト: Graviton2（T4g）は一般にコスト効率が高いが、料金はリージョンごとに異なるためElastiCacheの料金ページで要確認。インスタンスタイプ変更による課金差分に注意。
  • 互換性: T4gはGraviton2（ARM）ベースですが、ElastiCacheはマネージドサービスのためクライアント側のバイナリ差異は通常不要。ただし、特定のサードパーティ製プラグインやネイティブバイナリ連携がある場合は互換性確認を推奨。
  • 移行時の注意: 既存クラスターのノードタイプ変更はダウンタイムやリードレプリカ/フェイルオーバーの挙動に影響する可能性があるため、メンテナンスウィンドウやバックアップ計画を検討してください。
  • 監視: CPUバースト特性の評価にはAmazon CloudWatchのCPU関連メトリクス（CPUUtilization等）とキャッシュヒット率を組み合わせて検証してください。
  • GovCloud特記事項: GovCloudは商用リージョンとアカウント分離されており、アクセス・契約要件が異なります。該当する場合は事前にAWSアカウント担当者と調整してください。

参考情報 ​

[Neptune] Amazon Neptune announces dual stack support with IPv6 ​

概要 ​

Amazon Neptuneがデュアルスタック（IPv4/IPv6同時対応）をサポートしました。これにより、既存のIPv4運用を維持しつつIPv6を段階的に導入できます。

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

Neptuneクラスタがデュアルスタックモードをサポートし、IPv4・IPv6・または両方のプロトコルで接続を受け付けられるようになりました。デュアルスタックには「プライベートデュアルスタック」と「パブリックデュアルスタック」の2種類があり、前者はIPv6エンドポイントがインターネットから隔離された内部利用向け（VPC内のみ）、後者はIPv6エンドポイントがインターネットから到達可能でインターネット向けやハイブリッド環境に適しています。クライアントは利用するネットワークスタックに応じてIPv4/IPv6を透過的に選択でき、アプリケーション側のコード変更は原則不要です。DNSはA（IPv4）/AAAA（IPv6）レコードで提供され、デュアルスタック環境では両方のレコードが返る想定です。この記事によれば、デュアルスタックはAmazon Neptuneがサポートされている全リージョンで利用可能となっています。導入手順や設定はNeptuneのセットアップドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアーキテクト、DBA、SRE、アプリケーション開発者
  • 利用シーン: IPv6への移行を段階的に行いたい組織、インターネット向けサービスやハイブリッドネットワークでIPv6クライアントをサポートする場合
  • 運用効果: IPv6対応クライアントを受け入れつつ既存のIPv4接続を維持でき、ネットワーク設計の柔軟性と将来性が向上する
  • セキュリティ運用: IPv6アドレスを考慮したセキュリティグループ／NACL／ファイアウォールルールやアクセス制御の更新が必要になる可能性がある

技術的な注意点 ​

  • IAM権限: 特別な新規IAM権限は不要。ただし、Neptuneのインスタンス作成やVPC設定など既存の権限は必要です
  • リージョン制限: 記事によればNeptune対応リージョン全てで利用可能ですが、利用前に対象リージョンのドキュメントで確認してください
  • ネットワーク設定: VPCルートテーブル、サブネット（IPv6割当）、インターネットゲートウェイ/EGW、NATやTransit Gatewayなどの設定をIPv6向けに適切に構成する必要があります
  • DNS挙動: デュアルスタックではAおよびAAAAレコードを返すため、クライアント側のDNS解決ポリシーや接続ライブラリの挙動（優先プロトコル）を確認してください
  • クライアント互換性: 多くのクライアントは透過的にIPv6を使えますが、OS/ランタイムやサードパーティ製ツールがIPv6をサポートしているか事前確認が必要です
  • セキュリティ: セキュリティグループはIPv6アドレス範囲（CIDR/128等）を明示して設定する必要があります。ログ収集やアクセス制御リストもIPv6対応が必要です
  • 監視／ログ: IPベースのアラートやアクセスログの集約ツールがIPv6アドレスを正しく解析できるか確認してください
  • コスト: Neptune自体の追加料金は明記されていませんが、IPv6導入に伴うネットワーク構成変更（インターネットトラフィック、データ転送料金、NAT GatewayやTransit Gateway利用など）で費用影響が出る場合があります
  • その他: 公開エンドポイント（パブリックデュアルスタック）を有効にする場合は、攻撃面が増えるためアクセス制御と監視を強化してください

参考情報 ​

[General] AWS End User Messaging RCS now supports rich media and interactive messaging ​

概要 ​

AWS End User MessagingがRCS（Rich Communication Services）でリッチメディアとインタラクティブメッセージングをサポートしました。SendRcsMessage APIを使い、カード・カルーセル・画像・動画・提案ボタンなどを全22カ国で送信できます。

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

今回のアップデートで、SendRcsMessage APIにより以下を実現できます：RCSのリッチカード、カルーセル、画像、動画、および受信者がメッセージアプリ内で直接操作できるインタラクティブな提案ボタン（返信ボタン、URL、WebView、発信、地図、カレンダー登録など）を送信。受信者はアポイント確認、商品カタログ閲覧、WebViewでの支払い、位置情報共有、AIエージェントとの対話をメッセージアプリを離れずに行えます。サポートされるRCSメッセージタイプはテキスト、ファイル、リッチカード、カルーセルの4種類で、6種類のアクションと組み合わせて利用可能です。RCS未対応端末向けにはSMSまたはMMSへのフォールバックを個別に設定できます。さらに、21カ国向けに「RCS Conversation」価格モデルを導入し、24時間セッション内の無制限メッセージを単一の定額レートで提供するため、双方向ワークフローを従来よりコストを気にせず構築できます。RCSはAWS End User Messaging利用可能なすべてのリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: チャット/メッセージングで顧客接点を持つ開発者、マーケティング、CRM、SRE/運用チーム
  • 利用シーン: 予約確認・リマインダー、商品カタログ／購入フロー、支払いを含むトランザクション、位置情報共有、AIチャットボットによる対話型サポート
  • 運用効果: 受信側アプリを離れずにリッチなUXを提供できるためコンバージョン向上や応答率改善が期待できる。24時間セッション定額により双方向ワークフローのメッセージ数増加がコスト抑制につながる
  • 制限・互換性: RCS対応端末で最大の体験を提供可能だが、非対応端末はSMS/MMSフォールバックとなりインタラクティビティが制限される

技術的な注意点 ​

  • IAM権限: SendRcsMessageを呼び出すためのAPI権限が必要（例: End User Messaging用のSendRcsMessage権限を付与）。既存のIAMロール/ポリシーでAPI呼び出し権限を確認してください
  • リージョン制限: RCS機能はAWS End User Messagingが利用可能なリージョンで提供されます。機能サポートは22カ国ですが、RCS Conversation価格は21カ国で導入されています。対象国のサポート状況を事前に確認してください
  • コスト: 21カ国向けに24時間セッション単位の定額（無制限メッセージ）料金が導入されています。SMS/MMSフォールバックやメディア送信（画像/動画）には別途キャリア/送信コストが発生する場合があります。料金モデルを確認のうえ設計してください
  • メッセージ制限: 送信できるメディアタイプやサイズ、WebViewや外部決済連携のセキュリティ要件（CSP、HTTPS）などプラットフォーム側制約があります。APIドキュメントでペイロード形式、最大サイズ、サポートされるMIMEタイプを確認してください
  • フォールバック挙動: RCS非対応端末へは設定に応じてSMS/MMSが送信されますが、カルーセルやインタラクティブボタン等の機能は制限されます
  • セッションウィンドウ: Conversation価格は24時間セッション単位の取り扱いです。セッションの開始条件や継続条件を理解した上でメッセージング設計を行ってください

参考情報 ​

[Ec2] Amazon Time Sync Service adds support for Microsecond accurate time on 26 additional EC2 instance types in all commercial regions ​

概要 ​

Amazon Time Sync Serviceが、さらに26のEC2インスタンスタイプでマイクロ秒精度の時刻サポートを全ての商用リージョンで開始しました。Nitro Systemのリファレンスクロックとハードウェアタイムスタンプを利用して、アプリケーションイベントの順序付けや片方向レイテンシ測定を容易にします。

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

今回の拡張により、Amazon Time Sync Serviceは26種類の追加EC2インスタンスタイプでマイクロ秒単位の時刻精度およびナノ秒精度のハードウェアタイムスタンプを利用可能にしました。精度はAWS Nitro System上で動作するリファレンスクロックから直接得られ、Precision Time Protocolハードウェアクロック（PHC）とナノ秒精度のタイムスタンプをアプリケーションが利用できます。利用にあたっては新しい配置戦略であるPrecision Time Placement Group（PTPG）を作成し、PHCを有効にしたインスタンスで起動する必要があります。低レイテンシが必要なワークロード向けに、PTPGはCluster Placement Group（CPG）と関連付けることができ、クラスター内のインスタンスは低遅延と高精度時刻の両方の恩恵を受けられます。これにより、分散トランザクションの高速化、イベントの厳密な時系列付け、1-wayネットワークレイテンシの測定などが容易になります。対象インスタンスタイプは記事で列挙されており、適用は全ての商用AWSリージョンです。

影響範囲・利用シーン ​

  • 対象ユーザー: 分散システム設計者、SRE、ネットワークエンジニア、金融トレーディングや計測用途を扱う開発者
  • 利用シーン: イベント順序付け（ログ/トランザクション整合性）、1-wayレイテンシ測定、低遅延分散トランザクションの同期、精密計測アプリケーション
  • 運用効果: 分散アプリケーションの時刻ずれによる不整合を低減し、レイテンシ測定やトランザクションの整列精度が向上することでデバッグ／チューニングが容易になる

技術的な注意点 ​

  • IAM権限: PTPG作成やインスタンス起動には EC2:CreatePlacementGroup, EC2:RunInstances, EC2:ModifyInstanceAttribute 等の権限が必要になる可能性があります（IAMポリシーを確認してください）
  • リージョン制限: 記事のとおり「全ての商用リージョン」で利用可能。ただしAWS GovCloudや中国リージョンなど商用外リージョンは対象外の可能性があるため確認してください
  • コスト: Time Sync Service自体に追加料金は通常発生しませんが、対象のインスタンスタイプや配置（PTPG/CPG利用）によるインスタンス料金やデータ転送コストは発生します
  • OS/ドライバ: PHCとハードウェアタイムスタンプを利用するにはゲストOS側での対応が必要です（LinuxカーネルのPHC/PTPサポート、ptp4l/phc2sysやchrony等の設定、SO_TIMESTAMPING等のアプリ側対応）。提供されるAMIsやカーネルが必要条件を満たしているか確認してください
  • 配置制約: Cluster Placement GroupはAZ単位のクラスター配置を要求します。PTPGとCPGを関連付ける場合は同一AZや配置制約に注意し、起動失敗や期待通りのレイテンシが得られないケースに留意してください
  • 互換性: すべてのアプリが自動で恩恵を受けるわけではありません。アプリ/ライブラリが高精度タイムソース（PHC）を参照するように設定や改修が必要になる場合があります
  • 測定上の注意: 正確な1-wayレイテンシ測定には送受信双方での時刻設定とネットワーク経路の対称性が重要です。アプリケーション設計でクロックオフセットやジッタの扱いを考慮してください

参考情報 ​

[Workspaces] Announcing general availability of Amazon WorkSpaces for AI agents ​

概要 ​

Amazon WorkSpaces for AI agents が一般提供(General Availability)になりました。AIエージェントが管理された WorkSpaces 環境上でデスクトップアプリを人間と同じように操作でき、既存アプリのモダナイズやカスタム統合を不要にします。

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

WorkSpaces for AI agents は、ERP、CRM、メインフレーム接続クライアント、社内専用ツールなどの「既に稼働中で変更困難なデスクトップアプリケーション」を、クラウド上の管理された仮想デスクトップ（WorkSpaces）経由で AI エージェントが画面を見て操作できるようにするサービスです。以下が主な技術的特徴です。

  • エージェント操作モデル: エージェントは人間と同様に画面を見る・クリックする操作を行えるほか、Model Context Protocol (MCP) を使うことで任意のエージェントフレームワークと連携できます。MCP tool forwarding により、OSやアプリケーションへの直接的な MCP 呼び出しで操作・データ取得が可能となり、従来の「画面自動化ツール経由」の手法より精度向上、レイテンシ低下、コスト削減が期待されます。
  • セキュリティとガバナンス: WorkSpaces が提供する既存のアイデンティティ制御（例: IAM と Active Directory 連携）、ネットワーク分離（VPC）、コンプライアンス境界をエージェントに適用できます。エージェントは人間ユーザーと同等の監査・アクセス制御ポリシー下で動作します。
  • ドメイン結合サポート: ドメイン参加（Active Directory）されたフリート上でのエージェント稼働が可能で、既存のアクセス権や監査帰属（誰が操作したか）を拡張できます。
  • リアルタイム制御: ライブセッション監視とセッション途中でのアクセス取り消し（revoke）が可能で、オペレーターがエージェントの動作を即時介入・停止できます。
  • 価格モデル: アクティブなセッション時間に基づく課金。長時間未使用のインスタンス保持に比べセッション単位課金でコスト効率を図れます。
  • プレビューからの改良点: 顧客／パートナーフィードバックに基づく MCP tool forwarding、リアルタイムセッション制御、ドメイン結合フリート対応などが GA で提供されています。

結果として、既存デスクトップアプリを改修せずに RPA や AI ベースの自動化を導入でき、クレーム処理、患者記録更新、取引決済、バックオフィス業務などのワークフロー自動化が容易になります。

影響範囲・利用シーン ​

  • 対象ユーザー: システム統合が困難なレガシーデスクトップアプリを抱える企業、業務自動化を進めるSRE/運用チーム、RPA/AIプラットフォーム開発者
  • 利用シーン: クレーム審査や保険処理、電子医療記録の更新、証券/決済の後処理、社内基幹システムのデータ入力・照合など、既存GUIアプリケーションをそのまま自動化したい場面
  • 運用効果: アプリ改修なしで自動化を導入できるため導入コストと期間を短縮。既存のアクセス制御・監査を維持しつつ自動化により人的作業削減と処理速度向上を実現
  • セキュリティ影響: エージェントは WorkSpaces のアイデンティティ／ネットワーク境界内で動作するため、既存のガバナンスモデルを拡張して利用可能
  • コスト影響: セッション時間課金により短時間オンデマンド実行ではコスト効率が高いが、常時稼働セッションが多い場合はコスト計算が必要

技術的な注意点 ​

  • IAM権限: WorkSpaces の作成・管理、MCP 関連の操作、ネットワーク（VPC）やディレクトリサービス（AD/SSO）との連携に必要な権限を付与する必要があります。最小権限でロールを設計してください
  • リージョン制限: GA リリースでも一部リージョンで未提供の可能性があります。利用前に対象リージョンでの提供状況を確認してください
  • コスト: 課金はアクティブなセッション時間ベース。セッション頻度・長さに応じたコスト試算（常時稼働 vs オンデマンド）を実施してください。ドメイン結合や追加のログ収集／監査のためのインフラコストも考慮が必要です
  • ドメイン/AD: ドメイン結合フリートを利用する場合は既存のActive Directory設計・ネットワーク接続（VPN/Direct Connect/PrivateLink 等）を事前に準備してください
  • 監査・ログ: エージェント操作は監査対象になります。CloudWatch Logs、CloudTrail、WorkSpaces の監査機能と組み合わせ、アクセス履歴と操作ログの保管方針を決めてください
  • 互換性: 任意のエージェントフレームワークが MCP を実装すれば接続可能。ただし MCP の仕様やバージョン互換性、tool forwarding の実装要件を確認してください
  • 運用注意: リアルタイムセッション制御やセッション取り消し機能は管理者権限で行われるため、誤操作防止の運用プロセスを整備してください

参考情報 ​

[Ec2 Auto Scaling] Amazon EC2 Auto Scaling now supports reservations then balanced Availability Zone distribution ​

概要 ​

Amazon EC2 Auto Scaling に「reservations-then-balanced」という新しい AZ 配布戦略が追加されました。事前確保したキャパシティ（Capacity Reservations 等）を優先して利用し、残りのインスタンスは可用性ゾーン間で均等に分散します。

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

reservations-then-balanced は、Auto Scaling グループの AvailabilityZoneDistribution の capacity distribution strategy に設定できる新しい分散ポリシーです。動作は次のとおりです:

  • まず、指定した Capacity Reservation Group ARN または個別の Capacity Reservation ID に紐づくアクティブな予約キャパシティ（On‑Demand Capacity Reservations、Capacity Blocks、Interruptible Capacity Reservations 等）を優先してインスタンスを起動します。
  • 予約でカバーしきれない残りのインスタンスは、可用性ゾーン間で均等に（balanced）分配して起動します。 実装面では、Auto Scaling グループの AvailabilityZoneDistribution 設定で capacity distribution strategy を reservations-then-balanced に変更し、ターゲットとなる予約を指定します。従来の Auto Scaling の冗長性と運用の簡便さを維持しつつ、事前購入／確保したキャパシティの活用率を最大化できます。追加料金はなく、予約や起動された On‑Demand/Spot インスタンスには通常の EC2 料金が適用されます。reservations-then-balanced は全ての AWS 商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: インスタンスの事前確保（Capacity Reservation）を行っているクラウド/インフラ担当者、SRE、コスト最適化担当者
  • 利用シーン: 事前購入した ODCR や Capacity Blocks を優先的に使用しておきたい本番ワークロードや、予約枠を有効活用したい定常負荷のスケーリング
  • 運用効果: 予約キャパシティの未使用を削減しコスト効率を改善。AZ 別の偏りを抑えつつ予約を最大限活用することで可用性と予測可能性を両立できる
  • 適用範囲: Auto Scaling グループ単位で設定。Launch Template のインスタンスタイプ/プラットフォーム/テナンシーが予約条件と一致する必要あり

技術的な注意点 ​

  • IAM権限: Auto Scaling グループの更新に必要な権限（autoscaling:UpdateAutoScalingGroup 等）および Capacity Reservation 情報を参照・指定する権限が必要
  • リージョン制限: 発表時点で全ての AWS 商用リージョンで利用可能（リージョン固有の機能差分はドキュメントで確認してください）
  • コスト: 機能利用自体に追加料金は発生しませんが、使用する Capacity Reservation と起動された On‑Demand/Spot インスタンスには通常の EC2 課金が発生します
  • 予約整合性: Auto Scaling が予約を消費するには、起動設定（Launch Template/Launch Configuration）のインスタンスタイプ、プラットフォーム、テナンシーなどが予約条件と一致している必要があります。条件不一致だと予約は利用されません
  • 設定方法: Auto Scaling グループの AvailabilityZoneDistribution の capacity distribution strategy を reservations-then-balanced に設定し、Capacity Reservation Group ARN または個別の Capacity Reservation IDs を指定します。コンソール、CLI、SDK/API、CloudFormation からの設定が可能です
  • 既存のスケーリングポリシー: reservations-then-balanced は AZ 配布戦略に関する設定であり、スケーリングポリシーの動作ロジック自体は変更しません。ただし起動先の AZ/予約利用可否によってインスタンス起動の成功/遅延が影響を受ける可能性があります
  • 注意点: 予約が特定 AZ に偏っていると、予約優先で起動される分だけ一時的に AZ 偏りが発生する可能性があります。高可用設計では予約配置と AZ バランスのトレードオフを考慮してください

参考情報 ​

[General] Announcing Capability Insights for AWS, an open-source solution for regional capabilities ​

概要 ​

Capability Insightsは、AWSのリージョン別機能情報をユーザーのVPC内にセルフホストで展開できるオープンソースのダッシュボードソリューションです。データはVPC内に留まり、24時間ごとに自動更新され、マルチリージョン設計・コンプライアンス要件に対応します。

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

このソリューションはGitHub等で公開されたオープンソースのテンプレート／アプリケーションを使って、組織のAmazon VPC内にリージョナルな「Capabilities」データをデプロイするものです。主な機能は以下の通りです。

  • リージョン別のAWS能力情報（サービス、機能、APIオペレーション、CloudFormationリソースタイプ等）を収集し、ダッシュボードで表示。全リージョン分のデータを扱える設計。
  • ダッシュボードは24時間ごとにAWSの能力データを自動更新（auto-refresh）。
  • Workload Analysis機能は、お客様のAWS CloudTrailログとAWS CloudFormationスタックをスキャンし、200+のサービス一覧から実際に該当アカウントで利用しているサービス群へ絞り込む。これにより、従来の数週間にわたるギャップ分析を短時間のレビューに短縮可能。
  • すべてのデータと処理はユーザーのVPC内に保持されるため、データレジデンシーや内部監査／コンプライアンス要件に適合しやすい。組織はインフラの完全な所有権と制御を維持できる。
  • マルチリージョン展開設計やリージョナル拡張計画、マルチリージョンのリカバリ戦略策定時の意思決定資料として活用可能。 注：ソリューション自体はセルフホスト型のため、展開・運用に必要なAWSリソース（EC2/ECS/EKS、RDS、S3等）やネットワーク構成は導入側で管理する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチリージョン設計を行うクラウドアーキテクト、セキュリティ/コンプライアンスチーム、およびデプロイガバナンスを重視する組織
  • 利用シーンまたは効果: リージョンごとのサービス可用性やAPI/リソースタイプの差分確認、地域拡張計画立案、地域別コンプライアンス確認、マルチリージョンDR設計の前提確認
  • 運用効果: CloudTrail／CloudFormationに基づくWorkload Analysisで不要なサービスの誤認識を減らし、ギャップ分析時間を数週間から短期間に短縮
  • データ管理効果: すべてVPC内でホストされるため、データレジデンシー要件や内部報告・監査ニーズに対応可能
  • 導入の負荷: セルフホスト運用のためインフラコストと運用工数（パッチ適用、監視、バックアップ等）が発生

技術的な注意点 ​

  • IAM権限: CloudTrail、CloudFormation、必要なAWS API（例: Describe系）、およびデプロイ対象リソース（EC2/ECS/EKS、S3等）に対する読み取り・作成権限が必要。最小権限の設定を推奨。
  • ネットワーク/アウトバウンド: ダッシュボードの24時間更新やAWS API呼び出しのため、インターネット経路または必要なVPCエンドポイント（CloudFormation、CloudTrail、S3、STS等）を構成する必要がある。VPC内に完全に閉じたい場合は適切なエンドポイントの利用を検討してください。
  • CloudTrail前提: Workload AnalysisはCloudTrailログへのアクセスを前提とするため、対象アカウントでCloudTrailが有効かつログがアクセス可能であることを確認してください。
  • データ保護・コンプライアンス: 全データがVPC内に留まる設計だが、ログの保存先やスナップショット等の周辺リソース（S3、バックアップ）についても組織のポリシーに従って暗号化やライフサイクルを設定してください。
  • コスト: ソリューション自体はオープンソースだが、セルフホストするためのEC2/ECS/EKS、ストレージ、ネットワーク、ログ保管などのAWSリソースに対する通常の実行コストが発生します。
  • リージョン制限: 記事では“全リージョン分のデータを扱う”とあるが、利用前に対象リージョンでのAPI提供状況やVPCエンドポイント可否を確認してください。ソリューションのデプロイ可能リージョンや依存サービスのサポート状況はソース／ドキュメントで要確認。
  • 運用保守: OSSのため更新・セキュリティパッチ適用は導入者の責任。定期的なアップデート確認と脆弱性対応を計画してください。

参考情報 ​

[SageMaker] Amazon SageMaker AI cuts generative AI inference scale-out time by up to half with automatic container image caching ​

概要 ​

Amazon SageMaker Inferenceがコンテナイメージの事前キャッシュに対応し、スケールアウト時の新規インスタンス起動によるコールドスタートを削減。ジェネレーティブAIモデルのエンドツーエンドのスケールアウト時間を最大で約2倍高速化します。

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

SageMaker Inferenceはエンドポイントで指定されたコンテナイメージURIを自動的に事前プル（キャッシュ）する機能を追加しました。これにより、スケールアウトで新しいインスタンスが起動する際に、Amazon ECRから数GB〜10GB以上の大容量イメージを個別にダウンロードする待ち時間が不要になり、起動からトラフィック受け入れまでの時間（コールドスタート）を短縮します。お客様側の設定変更は不要で、指定されたイメージURIをそのままサービス側がキャッシュします。対応はアクセラレータ（GPU/Inferentia等）インスタンスタイプ、シングルモデルエンドポイント、および推論コンポーネントベースのエンドポイントに含まれます。本機能は、既存のスケーリング最適化群（サブ分単位の同時接続メトリクスで最大6xのロード検知高速化、既存インスタンス向けのインスタンスストアコンテナキャッシュなど）と併用可能で、新規インスタンス起動時のボトルネックを解消します。利用可能リージョンはSageMaker Inferenceがサポートする全てのAWS商用リージョンです。

影響範囲・利用シーン ​

  • 対象ユーザー: ジェネレーティブAIモデルをSageMakerで提供する機械学習エンジニア、SRE、運用チーム
  • 利用シーン: オートスケーリングやオンデマンドスケールアウトが頻発するエンドポイント（負荷変動の大きいチャット/生成APIやバーストワークロード）のコールドスタート短縮
  • 運用効果: 新規インスタンスの起動待ち時間が短縮され、スループット回復が速くなり、ユーザー待ち時間の低減とスケーリングによるパフォーマンス安定化が期待できる

技術的な注意点 ​

  • IAM権限: SageMakerがECRイメージにアクセスできるよう、ECRリポジトリやイメージに対するアクセス権限（SageMakerのサービスロールやリポジトリポリシー）を確認してください
  • リージョン制限: SageMaker Inferenceがサポートする全てのAWS商用リージョンで利用可能と発表されていますが、ご利用リージョンの最新対応状況はコンソール/ドキュメントで確認してください
  • コスト: AWSから直截の追加料金は明記されていませんが、事前プルによるネットワーク利用やキャッシュストレージの影響（アカウント内のECRデータ転送量やストレージ使用量）を運用で考慮してください
  • 互換性/制限: 対応対象はアクセラレータインスタンス、シングルモデルエンドポイント、推論コンポーネントベースのエンドポイントです。マルチモデルエンドポイント等への対応は明記されていないため、該当する場合は検証が必要です
  • 運用上の注意: ユーザー側のイメージURIが変更された場合は新しいイメージがキャッシュされる挙動となるため、イメージのバージョン管理やデプロイ運用ルールを整備してください

参考情報 ​

[Security Hub] AWS Security Hub CSPM launches AI Security Best Practices standard with 31 automated controls ​

概要 ​

AWS Security Hub CSPMが「AI Security Best Practices」標準を公開しました。Amazon Bedrock（およびBedrock AgentCore）とAmazon SageMakerのAIリソース向けに、31の自動化されたセキュリティコントロールで継続的にベストプラクティス準拠を評価します。

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

本標準はAWSのセキュリティ専門家が作成した31の自動コントロール群で、デプロイ済みのAI関連リソースが推奨されるセキュリティ設定と一致しているかを検出します。カバーする主要領域にはネットワーク分離、保存時・転送時の暗号化、VPC配置、KMSキーの使用、プライベートコンテナレジストリ要件、認可制御などが含まれます。対象リソースはBedrock AgentCoreのランタイム／ゲートウェイ／メモリストア／カスタムブラウザから、SageMakerのノートブックインスタンス、エンドポイント、モデル、モニタリングジョブ、フィーチャーグループまで幅広く対応します。各コントロールはセキュリティカテゴリが割り当てられ、逸脱が検出されるとSecurity Hubのファインディングを生成します。これらのファインディングは既存の運用ワークフロー（EventBridge→Lambda/ITSM、SIEM連携など）に組み込んで自動修復やエスカレーションに利用可能です。標準の識別子は standards/ai-security-best-practices/v/1.0.0 で、Security Hub CSPMが利用可能な全リージョン（AWS GovCloud (US)、中国リージョン含む）で有効です。カスタムルール作成は不要で、30日間の無償トライアルで評価可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティチーム、クラウド/SREエンジニア、AI/MLプラットフォーム管理者
  • 利用シーン: Bedrock/SageMakerベースのAIワークロードのセキュリティ構成自動評価と逸脱検出（ネットワーク分離、KMS・暗号化・VPC設定など）
  • 運用効果: 手動評価や独自ルール作成を削減し、AIリソースのミスコンフィグを早期検出して迅速に対応できることでセキュリティリスクを低減する

技術的な注意点 ​

  • IAM権限: Security Hub CSPMとリソースの読み取りに必要なIAM権限（Security Hubの有効化権限に加え、Bedrock/SageMaker/KMS/VPC/ECR等のリソース読み取り権限）が必要です
  • リージョン制限: Security Hub CSPMが利用可能なリージョンで使用可能（AWS GovCloud (US) と中国リージョンを含む）。ただし、ご利用のリージョンでCSPMが有効化されていることを確認してください
  • コスト: 30日間の無償トライアルあり。トライアル後はSecurity Hub CSPMの課金体系が適用されるため、導入前にコスト見積りを行ってください
  • 事前条件: Security Hub CSPMを有効化し、該当AIサービス（Bedrock/Bedrock AgentCore/SageMaker）がアカウント内に存在している必要があります
  • 誤検知/チューニング: 管理された自動コントロールのため、環境固有の例外やFalse Positiveが発生する場合は例外対応や運用ルールでの抑制が必要です
  • 自動対応連携: FindingsはEventBridgeやSecurity Hubの既存機能を通じて自動化（Lambda/Systems Manager/ITSM連携）可能です
  • データ保管・コンプライアンス: Findingsは使用リージョンのSecurity Hubに保持されます。地域別のデータ管理要件がある場合は注意してください
  • 標準ID: standards/ai-security-best-practices/v/1.0.0

参考情報 ​

[General] IAM Identity Center now enables programmatic AWS account access for customer managed applications ​

概要 ​

IAM Identity Center（組織インスタンス）で、カスタマー管理アプリケーションが外部IdP経由でサインインしたユーザーに成り代わってAWSアカウントへプログラム的にアクセスできるようになりました。これにより、ユーザーのアカウント・ロール探索や一時的な認証情報の取得がシームレスに可能になります。

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

技術的には、外部アイデンティティプロバイダー(IdP)をIAM Identity Centerの信頼トークン発行元（Trusted Token Issuer: TTI）として設定した上で、管理者が各カスタマー管理アプリケーションに対し「AWSアカウントアクセス」を明示的に有効化します。有効化されたアプリケーションは、IAM Identity Centerが提供するAPIを通じて、対象ユーザーに割り当てられたAWSアカウントとロールを照会（discover）し、当該ロールに対する一時的なセキュリティ認証情報（STS相当の一時クレデンシャル）を取得できます。ユーザーが既に外部IdPで認証済みであれば、追加のサインインフローを要求せずにアカウントへアクセスできるため、従来の二重認証プロンプトが不要になります。管理は組織（Organization）インスタンス単位で行われ、管理アカウントの管理者または委任管理者のみがこの機能を有効化可能で、中央集権的なガバナンスが維持されます。本機能は商用リージョン、AWS GovCloud（US）および中国リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、SRE、アプリ開発者、独自アプリケーションで外部IdPを利用する組織
  • 利用シーン: カスタマー管理アプリがユーザーの代わりに割り当て済みアカウント/ロールを列挙し、一時クレデンシャルを取得してAWS APIやコンソール相当の操作を実行する場合
  • 運用効果: ユーザーの二重サインインが不要になりUXが改善されると同時に、アプリ側での自動化（例: マルチアカウントのリソース管理、セルフサービスポータル、監査ツール）が容易になる
  • ガバナンス影響: 管理者がアプリ単位で有効化を制御できるため、どのアプリがアカウントレベルのアクセスを得るかを中央管理できる

技術的な注意点 ​

  • IAM権限: 管理アカウントの管理者または委任管理者のみがカスタマー管理アプリに対してAWSアカウントアクセスを有効化できます。事前に適切な管理者権限が必要です。
  • 組織制限: 本機能はIAM Identity Centerの組織（Organization）インスタンスで利用可能です。組織外のインスタンスや非組織構成では利用できない点に注意してください。
  • 外部IdP要件: アプリで利用する外部IdPをIAM Identity CenterのTrusted Token Issuer（TTI）として登録・設定する必要があります。IdP側のトークン発行やクレーム構成が要件に合致していることを確認してください。
  • リージョン制限: 商用リージョン、AWS GovCloud（US）、中国リージョンで利用可能と発表されています。特定リージョンでの細かな差異がある場合は公式ドキュメントを確認してください。
  • セキュリティ: アプリに付与されるアクセスはユーザーの割り当てロールを用いるため最小権限の原則を守ること。CloudTrailや監査ログでの追跡、許可されたアプリの限定、権限セットやセッション継続時間の適切な設定を推奨します。
  • 可視化と監査: どのアプリがアカウント情報や一時クレデンシャルを取得したかを監査可能にするため、ログとモニタリングの設定（CloudTrail等）を確認してください。
  • コスト: 本機能自体に対する追加料金は発表されていませんが、取得した一時クレデンシャルで呼び出すAWS APIや利用するサービスには通常の料金が発生します。API呼び出しやログ保管に伴うコストにも留意してください。

参考情報 ​

[Bedrock] Claude Sonnet 5 is now available on AWS ​

概要 ​

Anthropicの最新世代Sonnetモデル「Claude Sonnet 5」がAWSで利用可能になりました。コーディング・エージェント・ナレッジワークで高い性能を発揮し、Sonnet帯のコスト／速度バランスを維持します。

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

Claude Sonnet 5はAnthropicの最も高性能なSonnetシリーズで、大規模コードベースの理解とマルチファイル変更、デバッグやリファクタリングを少ない修正サイクルで完了できるよう設計されています。エージェント用途では精度の高いツール呼び出し、複数ステップにわたる状態保持、エラーからの回復能力が向上しており、実行の成功率が高まります。ナレッジワークではスプレッドシート作成、ドキュメント草案作成、非構造化データの構造化分析などに強みがあります。

AWS上では2つの利用経路が用意されています。1) Amazon Bedrock経由: モデル呼び出しがAWS管理下で完結し、Guardrails（安全性制御）、Knowledge Basesによるモデル拡張、リージョン内データ所在などAWSの管理機能を利用できます。Bedrockは複数モデルを統一APIで扱えるため、既存のBedrockワークフロー（ログ、監査、IAM、VPCエンドポイントなど）に組み込みやすいです。2) Claude Platform on AWS: AnthropicのネイティブなコンソールとAPI体験をAWSコンソール経由で利用でき、Anthropic側の機能やUXをそのまま使いつつAWS請求・認証と統合されます。詳細なリージョン対応状況や導入手順は公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者（特に大規模コードベースを扱うエンジニア）、SRE/運用、データサイエンティスト、プロダクトチーム
  • 利用シーン: 大規模リポジトリの自動修正・リファクタリング、マルチステップ自動化エージェントの実行、ドキュメント生成や非構造化データの構造化・分析
  • 運用効果: 修正ラウンド数の削減による開発効率向上、エージェントの成功率向上による自動化信頼性改善、資料作成や分析の工数削減による業務生産性向上

技術的な注意点 ​

  • IAM権限: Bedrock経由で利用する場合はBedrock呼び出し用のIAM権限（モデル呼び出しやログ出力権限など）を事前に設定してください。Claude Platform利用時もAWS側の認証・課金連携に必要な権限確認が必要です。
  • リージョン制限: 全リージョンで即時利用できるわけではありません。導入前に公式のリージョン対応状況を確認してください。
  • データ所在／プライバシー: Bedrock経由はAWSインフラ内で完結する運用が可能で、データレジデンシー要件を満たしやすいです。Claude Platform on AWSはAnthropicネイティブの挙動を維持するための処理経路がある可能性があるため、機密データの取り扱いは利用規約とドキュメントで確認してください。
  • コスト: Sonnet帯の価格設定（Sonnet pricing）で提供されますが、推論の利用量、Knowledge Baseやストレージ、データ転送、Bedrockの追加機能利用に応じた課金が発生します。想定負荷でのベンチマークとコスト試算を推奨します。
  • API互換性: Bedrockでは統一API（AWS側のモデル呼び出しインターフェース）で扱える一方、Claude Platform on AWSではAnthropicのネイティブAPI／コンソール体験が利用可能です。既存の実装を移行する際はAPI仕様と認証フローの差分を確認してください。
  • 性能上の注意: 大規模コンテキストやマルチターンのエージェント処理はレイテンシやスループットに影響します。バッチ化、並列度、最大トークン数の設定などパフォーマンスチューニングが必要になる場合があります。
  • 導入前テスト: 実運用前に代表的なワークロードで精度・コスト・レイテンシを評価し、GuardrailsやKnowledge Baseの設定で望ましい出力と安全性を検証してください。

参考情報 ​

[SageMaker] Amazon SageMaker AI now supports serverless model customization for Gemma 4 models ​

概要 ​

Amazon SageMaker AIは、Google DeepMindのGemma 4（E4Bおよび31B）モデルに対して、サーバーレスでのモデルカスタマイズ（SFT、DPO、RFT）をサポートするようになりました。これにより基盤モデルを自社データで安全に微調整し、インフラ管理なしで利用可能です。

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

今回のアップデートで、Gemma 4ファミリー（E4Bおよび31B）を対象に、監視付き微調整（Supervised Fine-Tuning, SFT）、Direct Preference Optimization（DPO）、および強化学習微調整（Reinforcement Fine-Tuning, RFT）によるカスタマイズがサーバーレスで実行できるようになりました。サーバーレスカスタマイズでは、SageMaker AIがトレーニング用インフラ（計算リソースのプロビジョニング、オーケストレーション、ジョブ管理）を自動で処理するため、ユーザーはデータ準備、ラベル、評価に集中できます。対応モデル群はGemmaに加え、Nova、Nemotron 3、Qwen、Llama、gpt-oss、DeepSeekなど既存のサーバーレスカスタマイズ対応モデルも含まれます。開始方法はAmazon SageMaker StudioのModelsページからカスタマイズジョブを起動するか、SageMaker Python SDKを使ったプログラム操作が可能です。サーバーレスカスタマイズはUS East (N. Virginia)、US West (Oregon)、Asia Pacific (Tokyo)、EU (Ireland)で利用可能です。カスタマイズ用途には、ドメイン固有の精度向上、組織のトーンへの出力整合、独自ラベルデータを使った新タスクの性能改善などが含まれます。トレーニングデータはS3等で管理し、必要なIAMロールや権限設定、モデルライセンスやデータ保護の確認が必要です。詳細な実行パラメータ、データフォーマットや制限事項（最大シーケンス長、バッチサイズ、学習率等）は公式ドキュメントで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: ドメイン固有のNLPタスクで基盤モデルを微調整して精度を上げる（例：医療/法律文書の解析、カスタマーサポートの応答整形）
  • 運用効果: インフラ管理負荷を低減し、短期間での試行・評価が可能になるため開発サイクルが短縮される
  • コスト影響: サーバーレスの従量課金により初期のクラスタ維持費が不要になる一方、トレーニング実行時間・ストレージ（S3）・推論コストは発生する
  • リージョン影響: 利用可能リージョンが限定されるため、データ主権やレイテンシ要件によっては利用可否の判断が必要

技術的な注意点 ​

  • IAM権限: SageMakerによるS3アクセス、トレーニング実行、ログ出力に必要なIAMロール/ポリシーを事前に設定してください（AmazonSageMakerFullAccess等の最小権限での調整推奨）
  • リージョン制限: サーバーレスモデルカスタマイズは現時点で US East (N. Virginia)、US West (Oregon)、Asia Pacific (Tokyo)、EU (Ireland) のみ対応
  • コスト: サーバーレスは従量課金（トレーニング時間・データストレージ・推論）です。大規模データや長時間のRFTはコスト増加の要因になります。料金モデルを事前に確認してください
  • モデルライセンス: GemmaはGoogle DeepMindのオープンモデルですが、利用条件・ライセンス条項を確認し、商用利用やデータの扱いが要件に合致するか確認してください
  • データ保護: 学習データに個人情報や機密情報を含める場合は暗号化、アクセス制御、データマスキング等の対策を講じてください。またリージョン要件に注意
  • トレーニング手法別注意: SFTはラベル付きデータを、DPOは人間の好みに基づくペアデータや評価が必要、RFTは報酬設計（reward model）と複数反復が必要になるため計画的な評価が重要です
  • SDK/操作: SageMaker StudioのUIからのジョブ起動か、SageMaker Python SDK経由でのプログラム制御が可能です。ジョブ設定（データ位置、ハイパーパラメータ、評価スクリプト）を正しく指定してください
  • その他制限: 各モデルの入力サイズ、トークン制限、サポートされるハイパーパラメータやチェックポイント保存ポリシーはモデル/ドキュメントに依存します。実運用前に小規模で検証を行ってください

参考情報 ​

[Ec2] Amazon EC2 C9g and C9gd compute optimized instances are now available ​

概要 ​

Amazon EC2 の C9g / C9gd インスタンス（AWS Graviton5 搭載）が一般提供開始されました。C9g は高い演算性能が必要なワークロード向け、C9gd はそれに加え低遅延のローカル NVMe ストレージを提供します。

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

C9g/C9gd インスタンスは AWS が設計した第5世代プロセッサ AWS Graviton5 を採用するコンピュート最適化インスタンスです。代表的な用途は HPC、バッチ処理、ゲーム、動画エンコード、科学モデリング、分散アナリティクス、CPU ベースの機械学習推論、リアルタイム解析、広告配信などで、C9gd はこれらに対し高速・低遅延な NVMe ベースのローカル SSD（インスタンスストア）を追加で提供します。性能面では Graviton4 ベースの C8g/C8gd と比較して最大で計算性能が25%向上、データベースで最大30%高速、Web アプリや ML で最大35%高速をうたっており、5倍の大容量キャッシュとクラウド上で最速クラスのメモリ帯域を特徴とします。プラットフォームは第6世代 AWS Nitro System 上に構築され、初めて Nitro Isolation Engine（形式的検証に基づく数学的な分離保証）を備え、テナント分離と運用者からのアクセスに対する新しいセキュリティ基準を導入しています。提供リージョンは現時点で US East（N. Virginia、Ohio）、US West（Oregon）、EU（Frankfurt）で、購入はオンデマンド、スポット、Savings Plans、専用インスタンス/専用ホスト経由で可能です。導入時は aarch64（ARM64）向けの AMI／バイナリ／コンテナイメージが必要となり、ENA/NVMe ドライバやカーネル要件、インスタンスストアの特性（エフェメラルで停止/終了で消失）を考慮する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドで高演算性能を求める開発者、SRE、データサイエンティスト、HPC／機械学習エンジニア
  • 利用シーン: 大規模バッチ処理、HPC ジョブ、CPU ベースの ML 推論、動画エンコード、リアルタイム分析、低遅延キャッシュやスクラッチ領域を要するワークロード（C9gd）
  • 運用効果: 既存の Graviton4 インスタンスからの移行で同等コストで性能向上（あるいは同性能でコスト低減）が期待でき、ローカル NVMe により I/O ボトルネックの緩和とレイテンシ低減が可能

技術的な注意点 ​

  • IAM権限: 新規インスタンス作成／購入に必要な EC2 関連権限（RunInstances、CreateTags、AllocateHosts 等）を事前に確認してください
  • リージョン制限: 初期提供リージョンは US East (N. Virginia, Ohio)、US West (Oregon)、EU (Frankfurt) のみ。その他リージョンでの提供は段階的に拡大される可能性あり
  • コスト: Graviton5 の高い価格性能比により総合コスト削減が見込めるが、選択する購入オプション（オンデマンド／スポット／Savings Plans／専用）で単価が変動します。ローカル NVMe を使った I/O 設計により追加の管理コストや暗号化実装が必要になる場合があります
  • AMI/互換性: Arm64 (aarch64) 対応 AMI または再ビルドしたバイナリ／コンテナが必須です。既存の x86_64 バイナリは動作しないため互換性評価と再コンパイルが必要です
  • ドライバ／カーネル: ENA（Enhanced Networking）や NVMe ドライバが必要です。古いカーネルやディストリビューションでは追加のドライバ導入やカーネルアップデートが必要になる可能性があります
  • ストレージ: C9gd のローカル NVMe はインスタンスストア（エフェメラル）であり、停止・終了でデータは消失します。永続化が必要なデータは EBS／S3 に保存するか、OS レベルでの暗号化（LUKS 等）を検討してください（インスタンスストアは EBS のサーバーサイド暗号化管理の対象外です）
  • セキュリティ／コンプライアンス: Nitro Isolation Engine による形式的検証の導入は分離保証を強化しますが、顧客側での責任（データ暗号化、アクセス制御、キー管理等）は継続します
  • 購入オプション: On‑Demand、Spot、Savings Plans、Dedicated Instances / Dedicated Hosts が利用可能です。長期運用の場合は Savings Plans やリザーブドオプションでコスト最適化を検討してください
  • その他: 既存のワークロード移行ではパフォーマンスベンチマーク（実際のアプリでの計測）を必ず行い、メモリ・キャッシュ利用の最適化、ツールチェーン（コンパイラ／ライブラリ）の Arm 最適化を検討してください

参考情報 ​

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

Copyright © 2026