Skip to content

2026年09月30日 ​

[Marketplace] Partner Revenue Measurement adds Multi-Partner support to Resource Tagging ​

概要 ​

Partner Revenue Measurement(PRM)がリソースタグによるマルチパートナーの収益帰属に対応しました。複数のパートナーが同一リソースに対して収益帰属を受けられるようになります。

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

従来はリソースに1つのパートナータグ(aws-apn-id)のみ付与でき、複数パートナーが同一ワークロードに寄与しても1社しか収益帰属を受けられませんでした。本アップデートでは新しいタグキー形式(プレフィックス)を導入し、各パートナーが自分の貢献したリソースに対してキーを付与できるようになります。新しいキーはプレフィックス 'aws-apn-id-' に続けてパートナー識別子を付ける形式(例: aws-apn-id-<partner-id>)で、同一リソースに複数のパートナータグが存在する場合は、それぞれのパートナーに収益が帰属されます。既存の単一キー aws-apn-id は引き続き有効で、既存タグの変更は不要です。帰属された収益は Attributed Revenue Dashboard の「Resource Tagging」方式として表示され、ダッシュボード側の表示変更はありません。本機能は全ての商用(commercial)AWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AWSパートナー(コンサル/ソフトウェア/マネージドサービス提供者)、SIer、パートナー連携でソリューションを提供する企業
  • 利用シーンまたは効果: 複数パートナーが共同で構築・運用するワークロード(例: ソフトウェアパートナーのプロダクトを導入し運用するコンサルパートナー)に対して、それぞれが正しく収益帰属を受けられるようになる
  • 運用効果: 収益帰属の透明性向上によりパートナー間の報酬分配やインセンティブ設計が容易になり、共同提供ビジネスの促進が期待できる

技術的な注意点 ​

  • IAM権限: リソースにタグを付与するための権限が必要です(サービスによっては ec2:CreateTags、tag:TagResources 等の権限が必要)。タグ付与は対象リソースの管理者または適切なIAMロールから実行してください。
  • リージョン制限: 本機能は全ての商用AWSリージョンで利用可能とされています。AWS ChinaやAWS GovCloud等の分離リージョンは対象外の可能性があるため確認が必要です。
  • タグ数制限: AWSのリソースごとのタグ数上限(通常50キー/リソース)に注意してください。多くのパートナーが同一リソースをタグ付けする場合、上限に達するリスクがあります。
  • 互換性: 既存の aws-apn-id キーはそのまま機能します。移行や追加作業は必須ではありませんが、複数パートナーで正確に帰属させるには新プレフィックス形式の利用を各パートナーで整合させる必要があります。
  • コスト: タグ付与自体に追加のAWS利用料金は通常発生しませんが、PRMによる収益計測・ダッシュボード利用に関するパートナープログラム上の要件がある場合があります。内部運用コスト(タグ運用・監査等)は発生します。

参考情報 ​


[Transfer Family] AWS Transfer Family now automatically approves SFTP connector quota increases up to 1,000 ​

概要 ​

AWS Transfer Familyは、SFTPコネクタのアカウントあたりのリージョンごとのクォータ増加要求を最大1,000コネクタまで自動承認するようになりました。これにより、手動承認を待たずにコネクタ数を拡張できます。

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

今回の変更により、AWSアカウント内でリージョンごとに作成できるSFTPコネクタ数の増加要求が、最大1,000コネクタまで自動的に承認されるようになりました。既定のクォータは引き続きリージョンあたり100コネクタで、必要に応じてService Quotasコンソールから増加を要求します。自動承認は、service-managed(サービス管理)およびAmazon VPC Lattice経由のアウトゴーイング(egress)を使用するコネクタの両方に適用されます。1,000を超えるコネクタが必要な場合は、従来どおりService Quotasコンソールでより高い上限をリクエストしてください。本機能は、Transfer FamilyのSFTPコネクタが提供されているすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: Transfer Familyで多数のSFTP接続を管理・利用するクラウドエンジニア、SRE、システム統合チーム
  • 利用シーンまたは効果: 大量の外部SFTPエンドポイントと接続するマルチテナント環境や、パートナー先ごとに専用コネクタを作成するケースで、手続きの遅延なくコネクタをスケールアウト可能
  • 運用効果: クォータ引き上げの手動承認待ち時間が削減され、迅速な環境構築・オンボーディングやトラフィック増加への対応が容易になる

技術的な注意点 ​

  • IAM権限: Service QuotasやTransfer Familyの操作には該当サービスへの適切なIAM権限(例: servicequotas:RequestServiceQuotaIncrease、transfer:CreateConnector等)が必要です。権限を持つユーザ/ロールで操作してください。
  • リージョン制限: 本機能は「Transfer Family SFTPコネクタが提供されている」全リージョンで利用可能ですが、リージョンによってサービス提供状況が異なるため、事前に該当リージョンでコネクタがサポートされているか確認してください。
  • コスト: コネクタの数増加自体はクォータ緩和を意味しますが、実際の運用ではTransfer Familyの利用料、データ転送料(VPC Lattice経由の場合のネットワークコスト含む)や関連リソースのコストが増える可能性があるため、コスト見積りを行ってください。
  • 既定値/上限: 既定はリージョンあたり100コネクタ。自動承認は最大1,000コネクタまで。1,000超が必要な場合はService Quotasコンソールで追加リクエストを提出してください。
  • コネクタ種別の適用範囲: 自動承認はservice-managedとAmazon VPC Lattice egressを利用するコネクタに適用されます。その他の構成(将来的に追加されるオプション等)は対象外の可能性があります。
  • 運用留意点: 大量のコネクタを作成する場合、管理(命名規則、監視、ログ収集)、接続先ごとの認証情報管理、同時接続数やスループットなどの運用面も検討してください。

参考情報 ​


[Organizations] AWS accounts now support phone number verification ​

概要 ​

AWSアカウントの「プライマリ連絡先電話番号」に対してSMSワンタイムパスコード(OTP)による電話番号の検証が可能になりました。コンソールまたは新しいAPIを使って検証を開始し、検証済みステータスが保持されます。

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

従来、AWSアカウントの連絡先情報に登録された電話番号は書式チェックのみで、外部手段による実効的な検証は行われていませんでした。今回の機能追加により、SendPhoneNumberVerification API(もしくはコンソール)で6桁のSMS OTPを送信し、受信したコードをVerifyPhoneNumber APIで入力することで電話番号を検証・永続化できます。PutContactInformation APIで電話番号を変更した場合は再検証が必要です。GetContactInformation APIは電話番号の検証ステータスを返すようになり、どの番号が検証済みか確認できます。AWS Organizationsを利用している場合、管理アカウントで検証済みの電話番号をメンバーアカウントに適用すると、メンバー側の電話番号が管理アカウントと同一であれば検証済みステータスが継承されます(数千アカウントに対する重複検証の手間を削減)。ただし、メンバーが自身で電話番号を変更した場合はそのメンバー側で改めて検証が必要です。本機能はすべてのAWS商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AWSアカウント管理者、Organizationsの管理者、セキュリティ/コンプライアンス担当者
  • 利用シーンまたは効果: アカウント回復や緊急連絡先の正当性確認、セキュリティ通知や運用連絡の到達性向上。管理アカウントから検証済み電話番号を割り当てて大量アカウントに適用することで運用工数を削減可能
  • 運用効果: 電話番号の正当性が保証されることで通知到達率とセキュリティ対応の信頼性が向上。Organizationsの継承機能により大規模環境での重複検証コストを削減

技術的な注意点 ​

  • IAM権限: 新しいAPIを呼び出すために該当するアクション権限が必要です(例: account:SendPhoneNumberVerification、account:VerifyPhoneNumber、account:PutContactInformation、account:GetContactInformation)。管理アカウントがメンバーの連絡先を更新する操作にも適切なOrganizations/Account管理権限が必要です
  • リージョン制限: 発表では「すべてのAWS商用リージョン」で利用可能。AWS ChinaリージョンやAWS GovCloud等の商用外リージョンは対象外となる可能性があるため、該当環境は要確認
  • コスト: AWS側での追加課金は発表されていません。ただしSMS受信に関する携帯キャリアの規約や料金、国やキャリアによるSMSブロックが影響する可能性があります
  • 検証フローと再検証: フローは SendPhoneNumberVerification → ユーザーが受信した6桁OTP入力 → VerifyPhoneNumber で検証済みフラグを永続化。PutContactInformationで電話番号を変更した場合は再検証が必要
  • Organizationsの挙動: 管理アカウントで検証済みの番号をメンバーに適用すると、メンバー側で同一の番号であれば検証済みステータスを継承。メンバーがその番号を上書きした場合はメンバー側で再検証が必要
  • 運用上の注意: 大量の検証を自動化する際はAPIレート制限や監査ログ(CloudTrail)への記録、権限管理(最小権限)を設計に組み込むことを推奨

参考情報 ​


[Iam Identity Center] AWS IAM Identity Center Identity Store APIs now accept resource ARNs in addition to resource IDs ​

概要 ​

AWS IAM Identity Center(旧AWS SSO)のIdentity Store APIが、従来のリソースIDに加えてユーザー、グループ、グループメンバーシップ、Identity Store自体のARN(Amazon Resource Name)を受け付けるようになりました。既存の統合はそのまま動作します。

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

Identity Store APIの全てのリクエスト識別子フィールドで、従来のリソースIDに加えてリソースARNを直接指定可能になりました。これにより、IAMポリシー評価結果、CloudTrailイベント、あるいは他サービスとの統合で既に得られているARNをそのままAPIに渡せるため、クライアント側でARNからIDを抽出・パースする処理が不要になります。レスポンス側は従来通りリソースIDを返し続けます。誤った形式のARNやリソースタイプが一致しないARNを渡した場合はValidationExceptionが返されます。機能はAWS IAM Identity Centerを提供するすべてのリージョンで利用可能で、追加料金は発生しません。

影響範囲・利用シーン ​

  • 対象ユーザー: IAM Identity Center(Identity Store)を利用するアプリケーション開発者、IAMポリシー評価やCloudTrailを解析する運用/セキュリティチーム
  • 利用シーン: CloudTrailやIAM評価で取得したARNをそのままIdentity Store APIに渡してユーザー/グループ情報を照会する、クロスサービス連携で得たARNを用いたID解決処理の簡素化
  • 運用効果: クライアント側のARNパース処理や変換ロジックを削減でき、パースミスによるエラーが減ることで統合の堅牢性が向上する
  • 互換性: 既存のIDベースの呼び出しは影響なし。レスポンスは引き続きIDを返すため、呼び出し側のレスポンス処理は変更不要
  • エラー処理: 不正なARNやリソース種別不一致はValidationExceptionになるため、入力検証や例外ハンドリングが必要

技術的な注意点 ​

  • IAM権限: 従来通りIdentity Store API呼び出しに必要なIAM/IAM Identity Centerの権限が必要です(ARN対応で権限付与が変わるわけではありません)
  • リージョン制限: AWS IAM Identity Centerが提供される全リージョンで利用可能です(ただし対象リージョンでサービスが有効であることを確認してください)
  • コスト: 追加料金は発生しません(記事で明記されています)が、API呼び出し自体の通常の利用料金や関連するログ/トラフィックに注意してください
  • API互換性: 変更は追加的(additive)で後方互換性があります。レスポンスはIDのままなので、既存クライアントの修正は不要です
  • 入力検証: クライアント側でARN/IDのどちらを受け付けるかを想定した入力検証と、ValidationExceptionを受けた際の処理(再試行やログ出力)を実装してください
  • 注意点: Identity StoreはレスポンスでIDを返すため、ARNで受け渡したい場合はクライアント側でARNとIDを紐づけるロジックが別途必要になる場合があります

参考情報 ​


[Bedrock] Amazon Bedrock Managed Agents, powered by OpenAI, is now available in preview ​

概要 ​

Amazon Bedrock Managed Agents (BMA) は、AWS と OpenAI が共同開発した、OpenAI の Agents API を AWS ネイティブにカスタマイズしたプレビュー機能です。AWS 内で動作するエージェントを簡単に構築・管理し、既存の IAM、ガバナンス、監査機能と統合できます。

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

BMA は OpenAI の Agents API を基に、モデルの状態管理(セッションの永続化)、ツール選択と利用、コード実行、複数ステップのワークフローの調整などを AWS ネイティブで実現します。各エージェントは専用の IAM ロールで動作し、重要なアクションの前に人間の承認を挟む制御が可能です。セッションはメッセージ、ツール呼び出し、中間結果を保持するため、途中で中断して後で再開できます。再利用可能なスキル(特定手順のモジュール化)を追加でき、外部ツールや Model Context Protocol (MCP) サーバー経由での接続にも対応します。サポートされる API 活動は AWS CloudTrail に記録されます。プレビュー中は BMA 自体の追加料金は発生せず、エージェントが消費する基盤となる AWS リソース(Bedrock モデル呼び出し、ストレージ、ネットワーク等)の料金が発生します。プレビュー提供リージョンは米国東部(バージニア北部、オハイオ)と米国西部(オレゴン)です。一般提供(GA)時には料金や対応リージョンが変更される可能性があります。

影響範囲・利用シーン ​

  • 対象ユーザー: ML/AI 開発者、SRE、プラットフォーム/インフラチーム、セキュリティ・ガバナンス担当者
  • 利用シーン: チャットボットや自動化ワークフローにおけるマルチステップの意思決定・ツール連携(例えば、ドキュメント検索→データ抽出→外部 API 呼び出し)
  • 運用効果: IAM と CloudTrail による監査・アクセス制御を維持しつつ、耐久的セッションと再利用可能スキルで運用・メンテナンスが容易になり、人的介入ポイント(承認)を挟むことでリスク管理が可能

技術的な注意点 ​

  • IAM権限: 各エージェントは専用の IAM ロールで動作するため、エージェント作成・実行に必要な権限(Bedrock 関連、役割の割当、必要に応じて外部ツールアクセス権)を事前に設計してください
  • リージョン制限: プレビューは米国東部(バージニア北部)、米国西部(オレゴン)、米国東部(オハイオ)のみ対応。GA 時にリージョン展開が拡大される可能性あり
  • コスト: プレビュー期間中は BMA 自体の追加料金は課されませんが、Bedrock モデル呼び出し、ストレージ、ネットワーク、関連する compute リソース等の従量課金は発生します。GA 時に価格体系が変更される可能性があります
  • データ保護・コンプライアンス: 記載では "AWS 内で実行" とありますが、機密データの取り扱い・モデルへの送信ポリシー、ログ保管ポリシーについては Bedrock のドキュメントと組織のコンプライアンスポリシーを確認してください
  • ロギングと監査: サポートされた API 活動は CloudTrail に記録されますが、すべての内訳(セッション内容、ツールコールの詳細等)が自動的に記録されるかはドキュメントで確認が必要です
  • プレビュー制限: プレビュー版の API 仕様や機能は変更される可能性があり、SLA やサポート範囲が GA 時と異なる場合があります
  • サービス統合: MCP サーバーや外部ツール連携が可能ですが、接続先の認証方式やネットワーク設定(VPC エンドポイント、セキュリティグループ等)を事前に設計する必要があります

参考情報 ​


[RDS] Amazon RDS now adds full snapshot size information to the Console and API ​

概要 ​

Amazon RDSがスナップショットの「フルスナップショットサイズ」をコンソールとAPIで表示可能になりました。DescribeDBSnapshotsの新フィールド 'FullSnapshotSizeInBytes' とコンソールの「Full Snapshot Size」列で確認できます。

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

Amazon RDSのスナップショットは増分方式で動作しますが、本機能は各スナップショットを構成する全てのブロック(そのスナップショットに直接格納されたブロックと、過去スナップショットから参照されるブロックの合計)の合計サイズを返します。APIではDescribeDBSnapshotsレスポンスに新しいフィールド 'FullSnapshotSizeInBytes'(バイト単位)が追加されており、コンソールには「Full Snapshot Size」列が表示されます。例えば、データ50 GBを持つ100 GBのボリュームであれば、最初のスナップショットでも後続のスナップショットでもフルサイズは50 GBと表示されます(これは“そのスナップショットを構成する論理的な総容量”であり、そのスナップショット単体に新規格納された増分データサイズとは異なります)。本機能は全ての商用AWSリージョンのAmazon RDSで利用可能で、RDS Management Console、AWS CLI、AWS SDKを通じて本日から利用開始できます。なお、このフィールドは情報提供目的の値であり、スナップショットの課金は実際に保存されているユニークブロックに基づく(増分ストレージ)ため、表示値がそのまま請求額を意味するわけではありません。運用上は容量計画、リストア時間見積もり、コンプライアンス用の監査レポート等に役立ちます。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、クラウド/バックアップ運用チーム、SRE
  • 利用シーン: スナップショット容量の可視化(容量計画、リストア時間見積もり、バックアップ方針の策定)、監査・レポート作成
  • 運用効果: スナップショットごとの実効データ量を把握できるため、保管戦略の最適化や復旧試算の精度向上が期待できる

技術的な注意点 ​

  • IAM権限: DescribeDBSnapshotsを呼び出せるrds:DescribeDBSnapshots等の権限が必要です
  • リージョン制限: 全ての商用AWSリージョンで利用可能とされています(パブリックAWSリージョンに適用)
  • コスト: 本フィールドの利用自体に追加料金は発生しません。スナップショットの課金は実際に保存されているユニークブロックに基づくため、'FullSnapshotSizeInBytes'はあくまで論理サイズの指標です
  • API/CLI: DescribeDBSnapshotsのレスポンスに'FullSnapshotSizeInBytes'(バイト)を確認できます。AWS CLIやSDKで同フィールドを参照してください
  • 注意点: 'FullSnapshotSizeInBytes'は増分(そのスナップショットに新たに格納されたバイト数)とは異なる値です。増分サイズが必要な場合は別途計測が必要になる可能性があります

参考情報 ​


[Bedrock] OpenAI GPT-6.1 Sol is now generally available on Amazon Bedrock ​

概要 ​

OpenAIのGPT-6.1 SolがAmazon Bedrockで一般提供(GA)になりました。GPT-6 Solの強化版で、エージェント型コーディングや複雑なマルチステップワークフローに向けた高い性能を低コストで提供します。

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

GPT-6.1 SolはGPT-6 Solのアップグレード版で、エージェント的なコード生成・デバッグ、コンピュータ操作の自動化、プロフェッショナルな作業(複雑なコードベースの調査や多段階の推論フロー)で非常に高い性能を発揮します。OpenAIの公表によれば、より高性能とされるGPT-6 Astraに近い評価結果を示しつつ、コストはおおむね5分の1程度となる可能性があるとされています。Amazon Bedrock上では、Bedrockの推論エンジンが低レイテンシと信頼性、セキュリティ制御を提供し、コンソールやサポートされるAPIを通じて利用可能です。主な技術的特徴として、明示的なプロンプトキャッシュ(explicit prompt caching)をサポートし、エージェントが繰り返し同じコンテキストを使うワークロードで効率化・コスト削減が期待できます。加えて、AWSのアクセス制御や監査メカニズムを使ってモデル呼び出しのガバナンスやログ記録が行えます。利用前には対応リージョン、エンドポイント、インフェレンスプロファイル(性能とコストのトレードオフ定義)、API仕様、価格を公式ドキュメントで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、アプリ開発者、SRE/運用チーム、ソフトウェア開発チーム
  • 利用シーン: エージェント型の自動化(コーディング支援、デバッグエージェント)、複雑なマルチステップワークフロー、コードベース解析やリファクタリング補助、反復的なコンテキスト再利用が必要な自動化ワークロード
  • 運用効果: 推論コストの削減(OpenAIが示す同等級モデル比で低コスト)、プロダクション運用に耐える低レイテンシ/高信頼な推論基盤、プロンプトキャッシュによるリクエスト重複の低減とスループット向上

技術的な注意点 ​

  • IAM権限: Bedrock上のモデル呼び出しや管理に必要なIAM権限を付与してください(例: Bedrockのモデル呼び出し権限、CloudWatch/S3などのログ保存権限)。具体的なアクション名はドキュメントで確認してください
  • リージョン制限: 全リージョンで即時利用可能とは限りません。利用前に『対応リージョン/エンドポイント』を公式ドキュメントで確認してください
  • コスト: モデルごとにインフェレンス料金(呼び出し単位/トークン単位など)が発生します。GPT-6.1 Solはコスト優位を謳っていますが、実際の請求はAWSのBedrock料金表とインフェレンスプロファイル設定に依存します
  • プロンプトキャッシュ: 明示的なキャッシュ機能は性能とコストに寄与しますが、キャッシュキー設計・TTL管理・コンテキストの整合性(古い/機密データの誤再利用)に注意してください
  • セキュリティ/ガバナンス: モデル呼び出しの監査(CloudTrail等)やアクセス制御を設定して、不正アクセスやデータ漏洩リスクを低減してください。モデルに送る入力データの機密性(PII含む)も評価する必要があります
  • API/SDK: コンソールのほかAWS SDK/CLI経由で利用可能です。呼び出し方法やインフェレンスプロファイルの指定方法はドキュメントを参照してください
  • 互換性: 既存のBedrockベンダーモデルやカスタムモデルとの共存が可能ですが、レイテンシ・スループット要件に応じてインフェレンスプロファイルを調整してください

参考情報 ​


[Connect] Amazon Connect Customer now lets business users manage more reference data to adjust contact center configurations in real time ​

概要 ​

Amazon Connect Customer のデータテーブル機能が拡張され、1テーブルあたり最大20,000件の参照データを保持できるようになりました。ビジネスユーザーがExcelやDynamoDBなど外部ソースからデータを取り込み、テーブルのエクスポート・一括編集・インスタンス間移動を行うことで、コンタクトセンター設定をリアルタイムで柔軟に調整できます。

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

今回のアップデートでは、Amazon Connect Customer の管理者がコンタクトフローの動作を制御する参照データ(営業時間、エスカレーションルール、AI応答プロンプト、キュー割当てなど)を、データテーブルとしてより大きな容量・柔軟性で管理できるようになりました。主な機能は以下の通りです。

  • テーブル容量: 1テーブルあたり最大20,000件の値を保持可能。大規模なルールセットや多数のキュー割当てを管理できます。
  • データ入出力: テーブルのエクスポートが可能で、Excel等で編集して再インポートしたり、DynamoDBなど外部システムからデータをロードできます。これにより非エンジニアのビジネス担当者でもデータ更新が容易です。
  • 一括編集: 数百レコード単位での編集をサポートし、手動編集の手間を削減します。
  • インスタンス間移動: データテーブルを別の Connect Customer インスタンスへ移動可能で、複数環境(開発/検証/本番)間で設定を共有しやすくなっています。
  • 運用性: 管理者やビジネスチームが自身で参照データを更新し、条件変化に応じてコンタクトセンターの挙動をリアルタイムに調整できます。 この機能は Amazon Connect Customer が提供されているすべての AWS 商用リージョンおよび AWS GovCloud (US-West) リージョンで利用可能です。詳細は管理者ガイドの「Create and configure data tables」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンター管理者、コンタクトセンターのビジネス担当者、SRE/運用担当者
  • 利用シーン: 営業時間やエスカレーションルールの即時更新、AIエージェントの応答プロンプト更新、キュー割当ての動的変更、複数環境間での設定移行
  • 運用効果: ビジネス側で参照データを直接更新可能になり、開発者への依存を減らして応答性を向上。運用負荷の軽減と迅速な設定変更によるサービス品質向上が期待される

技術的な注意点 ​

  • IAM権限: データテーブルの作成・更新・エクスポート・インポート・移動には適切な Amazon Connect 管理権限が必要です。管理者ロールやポリシーを事前に確認してください。
  • リージョン制限: Amazon Connect Customer が提供されている全ての AWS 商用リージョンおよび AWS GovCloud (US-West) で利用可能ですが、利用前に対象リージョンでの提供状況を確認してください。
  • データ制限/クォータ: 1テーブルあたり最大20,000件の値という上限があります。その他のクォータ(テーブル数、同時API呼び出しなど)は管理者ガイドやサービスクォータを確認してください。
  • インポート/エクスポート: ExcelやDynamoDBなどからのロードが可能ですが、取り込み時のフォーマットや型整合性に注意してください。大量データは分割して処理すると安定します。
  • コスト: データテーブル自体の機能利用に直接の追加料金は明示されていない場合が多いですが、外部ストレージ(DynamoDB)利用やデータ転送、API呼び出し頻度に応じた課金影響が発生する可能性があります。コスト見積りを行ってください。
  • 運用注意: 参照データの変更はコンタクトフロー挙動に即時影響するため、変更運用(検証、ロールバック手順、バックアップ/エクスポート)を設計しておくことを推奨します。
  • 自動化: 大量更新や定期同期は AWS CLI / SDK を用いた自動化が可能ですが、使用する API のレート制限やエラーハンドリングを組み込んでください。

参考情報 ​


[Workspaces] Amazon WorkSpaces Applications introduces unified graphics images ​

概要 ​

Amazon WorkSpaces Applicationsが“unified graphics images”を発表しました。これによりG4dn、G5、G6、G7など複数世代のGPU対応インスタンスで単一のイメージを共通利用でき、イメージ管理と世代移行が簡素化されます。

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

従来は各GPU世代ごとに専用のグラフィックスイメージが必要でしたが、unified graphics imagesは複数のサポートされたグラフィックスインスタンスファミリー(G4dn、G5、G6、G7)にまたがって動作する単一イメージタイプです。コンソールでフリート作成時に互換性のあるインスタンスタイプ一覧が表示され、価格と性能に応じて選択できます。既存フリートもコンソールまたはUpdateFleet APIを使って、同一ファミリー内に限られていた変更から、サポートされる別ファミリーへのインスタンスタイプ変更が可能になりました。利用開始は既存のグラフィックスイメージをManaged Image Updateでアップグレードするか、unified base imageからイメージビルダーを起動して行います。unified graphics imagesはAmazon WorkSpaces ApplicationsのグラフィックスインスタンスがサポートされるすべてのAWS商用リージョンおよびAWS GovCloud (US)で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 仮想デスクトップ環境でGPUを利用するエンタープライズユーザー、VDI運用チーム、アプリケーション配布担当者
  • 利用シーン: マルチ世代GPUへ段階的に移行するワークロード(レンダリング、CAD、機械学習推論、GPUアクセラレーテッドアプリの配布)
  • 運用効果: イメージ数と管理負荷の削減、GPU世代切替時の運用作業軽減、フリート更新の柔軟性向上
  • コスト: インスタンスタイプを柔軟に選べるため価格最適化が可能。ただし高性能GPUへ切替えるとコストは増加
  • リージョン: Amazon WorkSpaces ApplicationsのグラフィックスインスタンスがサポートされるすべてのAWS商用リージョンおよびAWS GovCloud (US)で利用可能
  • 運用リスク/注意: 異なるGPU世代間でドライバやランタイムの互換性問題が発生する可能性があるため、切替前にアプリケーションの動作検証が必要

技術的な注意点 ​

  • IAM権限: UpdateFleetやWorkSpaces Applicationsのイメージ管理、イメージビルダー、Managed Image Updateを実行するための適切なIAM権限が必要です(例: workspaces-applications:UpdateFleet, workspaces-applications:CreateImageBuilder, workspaces-applications:StartManagedImageUpdate等)
  • リージョン制限: すべての商用リージョンおよびAWS GovCloud (US)でサポートされますが、各リージョンでWorkSpaces Applicationsのグラフィックスインスタンスが利用可能か確認してください
  • ドライバ/ランタイム: 統一イメージでもGPUドライバ(NVIDIAドライバ、CUDAなど)やランタイムのバージョン互換性を確認・管理する必要があります。アプリケーション固有のGPU最適化設定は世代間で挙動が変わる可能性があります
  • 移行手順: 既存イメージはManaged Image Updateでアップグレード、またはunified base imageからイメージビルダーを起動して新規イメージを作成してからフリートへ適用してください。フリートのインスタンスタイプ変更はコンソールまたはUpdateFleet APIで実施できます
  • 可用性とテスト: インスタンスタイプ変更は性能や互換性に影響するためステージング環境での検証を推奨します。変更によりユーザーワークスペースの再起動や再プロビジョニングが必要になる可能性があります
  • コスト: インスタンスタイプの切替は料金に直結するため、コスト試算と監視を行ってください
  • その他制限: 特定のGPU機能(例: 特定世代固有のハードウェア機能)を利用するアプリケーションは、該当機能のサポート状況を確認する必要があります

参考情報 ​


[General] AWS Service Availability Updates ​

概要 ​

AWSは複数のサービスについて可用性やサポート終了のスケジュールを発表しました。いくつかのサービスは“Maintenance(新規顧客向けの提供停止)”に移行し、別のサービスは“Sunset(段階的終了)”や既に“End of Support(サポート終了)”になっています。

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

変更分類と対象サービス(重要な日付を含む):

  • Maintenance(新規顧客の利用停止、既存顧客は継続利用可、AWSは運用・サポート継続) ・Amazon Chime SDK SIP Media Application ・Amazon WorkSpaces Secure Browser ※新規顧客は 2026-10-29 以降にこれらのサービスを開始できなくなります。

  • Sunset(サービス終了の告知、移行期間あり) ・Amazon Managed Blockchain — サポート終了: 2027-09-29 ・Amazon DevOps Guru — サポート終了: 2027-09-30 ・AWS Backint Agent for SAP ASE — サポート終了: 2027-09-29 ・AWS Infrastructure Composer(独立コンソール) — サポート終了: 2026-12-07 ※各サービスの製品ページとドキュメントに移行計画と推奨代替が掲載されています。

  • End of Support(既にサポート終了、利用不可) ・Amazon Mechanical Turk — サポート終了日: 2026-09-29(以降利用不可)

推奨対応:AWSは影響を受ける顧客向けに移行ガイドを用意しており、サポートチームによる支援が可能です。公式のAWS Product Lifecycleページおよび各サービスの製品ページ/ドキュメントを確認し、代替サービスの選定、データエクスポート、運用変更の計画を早めに行ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: これらのサービスを現在利用中のクラウドエンジニア、SRE、プラットフォーム/アプリケーション開発チーム
  • 利用シーン: チャット/音声のSIPメディア連携、WorkSpaces内でのセキュアブラウザ利用、ブロックチェーンネットワーク管理、アプリケーションの運用監視(DevOps Guru)、SAP ASE向けバックアップエージェント、インフラ設計ワークフロー(Infrastructure Composer)、人力タスクの自動化(Mechanical Turk)の各ユースケース
  • 運用影響: 新規導入の可否、長期的なサポート可否、データ移行やインテグレーションの更新が必要になる可能性が高い
  • ビジネス影響: サービス終了に伴う機能喪失や移行コストが発生するため、影響範囲を早期に特定して代替策を評価する必要あり

技術的な注意点 ​

  • IAM権限: 移行作業やデータエクスポートに必要なIAM権限(サービス固有のAPI呼び出しやS3への書き出し権限等)を事前に確認・付与してください
  • リージョン制限: 元記事では個別リージョン情報は記載されていません。各サービスの製品ページでリージョン対応状況を確認してください
  • データ保持・移行: データのエクスポート/バックアップ方針を早期に決定し、スナップショットやエクスポート手順、互換フォーマットを確認してください(例: Managed Blockchainの台帳データやBackintのバックアップファイル)
  • エンドポイント/API: サービスのAPIエンドポイントや署名方式、SDKの互換性が変わる可能性があるため、統合しているシステムの修正が必要になる場合があります
  • SLA/サポート: Maintenance移行中のサービスは既存顧客向けにサポート継続がありますが、将来的な機能追加や改善は制限される可能性があります。Sunsetではサポート終了日に向けて段階的に機能制限や運用変更が行われることがあります
  • コスト: 代替サービスや移行作業にはコストが発生します(移行工数、運用コスト、場合によっては新サービスの料金体系)。移行前に総所有コスト(TCO)を見積もってください
  • タイムライン管理: Sunset / End of Support の各終了日をプロジェクト計画に組み込み、十分なバッファ(テスト/移行期間)を確保してください
  • ドキュメント参照: 各サービスの製品ページとAWS Product Lifecycleページ、AWSサポートが公開する移行ガイドを必ず確認してください

参考情報 ​


[RDS] Amazon RDS for PostgreSQL announces Extended Support minor versions 13.23-rds.20260514, 12.22-rds.20260514 and 11.22-rds.20260514 ​

概要 ​

Amazon RDS for PostgreSQL がマイナー版の Extended Support を提供開始しました(13.23-rds.20260514、12.22-rds.20260514、11.22-rds.20260514)。主要バージョンの標準サポート終了後も、最大で追加3年間の重要なCVEsとバグ修正を受けられます。

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

今回のリリースは Amazon RDS Extended Support による RDS for PostgreSQL のマイナー版(13.23-rds.20260514、12.22-rds.20260514、11.22-rds.20260514)の追加です。Extended Support は主要バージョンの標準サポート終了後に、重大なセキュリティ脆弱性(CVE)や重要なバグに対する修正を最大3年間提供するもので、通常の機能追加やマイナーな改善は対象外です。ユーザーは以下の方法でデータベースを新しいマイナーバージョンに切り替えられます:Amazon RDS Blue/Green Deployments(最小ダウンタイムでの切替)、インプレースアップグレード、スナップショットからのリストア。AWS マネジメントコンソールまたは AWS CLI を使って作業可能で、アップグレード前には互換性テストとバックアップ/スナップショット取得を推奨します。RDS 側で“-rds”サフィックスの付いたバージョンは AWS がセキュリティ修正や一部のバグ修正をバックポートしていることを示します。

影響範囲・利用シーン ​

  • 対象ユーザー: PostgreSQL を RDS で運用するDBA、SRE、アプリケーションオーナー
  • 利用シーン: 主要バージョンのアップグレード計画を立てる猶予期間が必要な場合(規制対応、互換性検証、リライト・移行作業の準備)
  • 運用効果: 重大なセキュリティ修正が継続提供されるため、即時のメジャーバージョンアップを迫られずに安定運用できる
  • 可用性・移行策: Blue/Green Deployments を使えばダウンタイムを最小化して移行でき、スナップショットからの復元でロールバックやテスト環境の再現が容易になる

技術的な注意点 ​

  • サポート範囲: Extended Support は重大な CVE と重要バグへの修正が対象であり、機能追加や非重大バグの修正は含まれない点に注意
  • アップグレード方法: Blue/Green Deployments(最小ダウンタイム)、インプレースアップグレード、スナップショットからの復元のいずれかを使用。事前に互換性テストを推奨
  • IAM権限: DB の変更やスナップショット操作に必要な RDS 権限を付与する必要あり(例: rds:ModifyDBInstance、rds:RestoreDBInstanceFromDBSnapshot、rds:CreateDBInstance 等)
  • リージョン制限: 記事ではリージョン制限は明示されていないが、実際の利用可否はコンソールまたはドキュメントでリージョンごとに確認すること
  • コスト: Extended Support 自体の課金の有無は記事で明記されていないため、導入前に料金ページや AWS サポートへ確認してください。アップグレード作業や Blue/Green デプロイでは一時的に追加リソースが発生する可能性あり
  • 互換性: マイナーバージョン内の更新だが、アプリケーション互換性や拡張モジュール(拡張機能や拡張モジュールのバージョン)との整合性確認が必須
  • ロールバック: インプレースアップグレードはロールバックが困難な場合があるため、スナップショット作成や Blue/Green の利用でロールバック手順を確立すること

参考情報 ​


[RDS] Amazon Aurora now supports PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 ​

概要 ​

Amazon Aurora PostgreSQL互換エディションがPostgreSQLの最新マイナーバージョン(18.6、17.11、16.15、15.19、14.24)をサポートしました。これらにはコミュニティのバグ修正とAurora固有の改善が含まれ、CVEへの対処も含まれます。

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

サポート追加の対象は PostgreSQL 18.6、17.11、16.15、15.19、14.24 の各マイナーバージョンです。各バージョンにはPostgreSQLコミュニティで報告されたバグ修正とセキュリティフィックス(CVE修正)が含まれており、Aurora側でも互換性や性能・安定性に関する調整が行われています。運用者はスケジュールされたメンテナンスウィンドウ中に自動マイナーアップグレードを有効化して一括で反映できます。大規模環境では AWS Organizations の Upgrade Rollout Policy を利用して段階的にアップグレードを実行し、優先度の低い環境で検証を行った後に本番へ展開することが推奨されています。

運用面・機能面では、AuroraはフルPostgreSQL互換性を保ちつつ、スケールトゥゼロを含むサーバーレスコンピュート、Aurora Global Databaseによるリージョン間レジリエンシー、I/O集約ワークロード向けのAurora I/O-Optimizedオプション、継続バックアップや強化されたセキュリティ機能を提供します。アップグレード前にはリリースノートと互換性(拡張モジュール、カスタム拡張、SQL互換性)を確認し、スナップショット取得とステージング環境での動作確認を行ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: DBA、SRE、プラットフォーム/インフラ運用チーム、セキュリティチーム
  • 利用シーン: セキュリティ脆弱性(CVE)対応の適用、コミュニティのバグ修正反映、PostgreSQLマイナーバージョン準拠を必要とする環境の保守
  • 運用効果: 自動マイナーアップグレードとOrganizationsのロールアウト方針により大規模環境で段階的・検証済みのアップデート運用が可能となり、セキュリティリスク低減と安定性向上が期待できる

技術的な注意点 ​

  • IAM権限: DBクラスタ/インスタンスの変更には rds:ModifyDBCluster、rds:ModifyDBInstance、rds:RebootDBInstance 等の適切な権限が必要です。Organizationsポリシー利用時はOrganizations管理権限も必要になります。
  • ダウンタイム/再起動: マイナーアップグレードはクラスタの書き込みノードの再起動を伴う場合があり、短時間の中断が発生する可能性があります。フェイルオーバー構成やメンテナンスウィンドウでの実施を検討してください。
  • 拡張機能互換性: 使用中のPostgreSQL拡張(例: PostGIS、pg_cron 等)が新しいマイナーバージョンでサポートされるか事前に確認してください。拡張のバージョン互換性は動作に影響します。
  • バックアップ/スナップショット: アップグレード前に自動バックアップとは別にDBクラスタのスナップショットを取得してロールバック手順を確立してください。
  • リージョン制限: 新しいマイナーバージョンはすべてのAWSリージョンで同時に利用可能とは限りません。利用前に対象リージョンでのサポート状況を確認してください。
  • 自動マイナーアップグレード設定: 自動マイナーアップグレードを有効化すると指定のメンテナンスウィンドウ中に自動で適用されます。段階的展開にはOrganizationsのUpgrade Rollout Policyと組み合わせてください。
  • コスト: マイナーアップグレード自体に追加料金は通常発生しませんが、アップグレード検証のためのスナップショット保存、ステージング環境利用、I/O-Optimizedオプション使用時のI/O課金などでコストが増える可能性があります。

参考情報 ​


[Bedrock] Amazon Bedrock expands Claude model availability to India, South Korea, and Singapore ​

概要 ​

Amazon BedrockがAnthropicのClaudeモデル(Opus 5、Sonnet 5、Haiku 4.5)のリージョン提供を拡大しました。これにより、インド、韓国、シンガポールでインフェレンスを現地処理できるようになり、データ主権や低遅延を必要とするユースケースに対応します。

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

提供モデルとリージョンの主な内容:

  • インド: Claude Opus 5、Claude Sonnet 5、Claude Haiku 4.5が利用可能。インド向けのリージョナルエンドポイントはムンバイとハイデラバードのRegion間での「geographic cross-Region inference」を通じて提供され、インド国内での処理が行われます(これによりin-countryでの推論が可能)。既存のグローバルなクロスリージョン推論も引き続き利用可能です。
  • 韓国(ソウル ap-northeast-2): Claude Opus 5、Claude Sonnet 5がbedrock-runtimeエンドポイントでin-region(リージョン内)推論として利用可能。
  • シンガポール(ap-southeast-1): Claude Sonnet 5がbedrock-runtimeエンドポイントでin-region推論として利用可能。 運用面: Amazon Bedrockは、呼び出したリージョン内で推論リクエストとデータを処理し、その処理は当該リージョンの外に出ません(ただしインド向けは国内の2つのRegion間での地理的クロスリージョン処理を利用)。最新のモデル別リージョン対応状況はAmazon Bedrockユーザーガイドの「Regional availability by models」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制対応が必要な金融、ヘルスケア、公共部門の顧客、データ主権を重視するエンタープライズ、低遅延なLLM推論を求める開発者
  • 利用シーン: 国内データ処理が必須のコンプライアンス対応アプリ、低遅延チャットボットやリアルタイム分析、地域ごとの法令に基づくデータレジデンシー要件を満たす用途
  • 運用効果: データが呼び出したリージョン内で処理されるため、データ越境リスクを低減しコンプライアンス対応が容易に。現地リージョンでの推論によりレイテンシが改善し、ユーザー体験が向上する。インド向けの地理的クロスリージョン構成は可用性向上に寄与(ただし国内Region間のデータ移動が発生)

技術的な注意点 ​

  • エンドポイント: in-region推論はbedrock-runtimeエンドポイントを利用します
  • IAM権限: Bedrockのモデル一覧取得・呼び出し等のAPI呼び出しに必要なIAM権限(例: bedrock:InvokeModel等)を事前に設定してください
  • モデル差分: モデル(Opus 5 / Sonnet 5 / Haiku 4.5)ごとに性能・コスト特性が異なるため、本番導入前にベンチマークとプロンプト最適化を行ってください
  • リージョン制限: 提供状況はリージョン・モデルごとに異なります(本記事時点: インドはOpus 5/Sonnet 5/Haiku 4.5、韓国はOpus 5/Sonnet 5、シンガポールはSonnet 5)。最新の対応状況は公式ドキュメントで確認してください
  • データ転送・コスト: インドではムンバイとハイデラバード間の地理的クロスリージョン処理が行われるため、リージョン間トラフィックや追加コストの可能性、料金体系の違いに注意してください。in-region呼び出しは遅延・データ転送コストの観点で有利な場合があります
  • コンプライアンス: データ主権要件を満たすために、どのリージョンで処理されるか、ログやメタデータの保管先も含めて設計・監査してください
  • 特記事項: 注意点がない場合は "特になし" ではなく、上記の項目を参照してください

参考情報 ​


[Msk] AWS Transform now supports Apache Kafka migration assessments for Amazon MSK ​

概要 ​

AWS Transformのエージェント型移行アセスメントが、オンプレのApache KafkaクラスターからAmazon MSKへの移行評価に対応しました。数分で互換性チェック、MSK Expressのブローカー推奨、TCO試算や移行手順を生成できます。

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

AWS Transformのエージェント型(agentic)移行アセスメントは、自然言語チャットまたはAWS Transform MCPサーバを通じてKafkaワークロードを解析し、移行に最適な設計とコスト見積りを自動生成します。入力はKafkaクラスターのインベントリファイルのアップロード、あるいはチャットでのクラスター記述で開始でき、エージェントが以下を自動実行します: クラスタトポロジー・バージョン・設定・認証方式(TLS/SASL 等)・Quota制限のMSK互換性チェック、MSK Express向けの適切なブローカーサイズ(right-sizing)推奨、ブローカー稼働時間・ストレージ・データ受信・AZ間転送などを分解したコスト予測(TCO)作成。さらに、リージョン間の価格比較や保持期間・構成のwhat-ifシナリオを設定して複数案を比較でき、ステークホルダー向けの移行ビジネスケースと実行可能な次のステップ(マイグレーション手順の推奨)を短時間で提供します。Amazon MSK向けの移行アセスメントは、AWS Transformが提供されている全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド移行担当者、SRE/運用チーム、アーキテクト、意思決定者
  • 利用シーン: オンプレApache KafkaからAmazon MSKへの移行判断、移行コスト算出、設計検討(トポロジー/ブローカーサイズ/認証・Quota整合性)
  • 運用効果: 手作業で数週間かかる評価工程を数分~数時間に短縮し、移行ビジネスケースの迅速化と意思決定の加速を実現

技術的な注意点 ​

  • IAM権限: AWS Transform実行、S3等へのインベントリアップロードや読み取りに必要な権限を事前に付与してください
  • リージョン制限: AWS Transformが提供されているリージョンで利用可。特定リージョンでの可用性は事前に確認してください
  • コスト: AWS Transformの利用や、検証用に作成するMSKインスタンス/データ転送には課金が発生する可能性があります。TCO試算は見積りであり実コストと差異が出る場合があります
  • データとセキュリティ: アップロードするインベントリには構成・認証情報のメタデータが含まれる可能性があるため、機密情報の取り扱い方針を遵守してください
  • 入力フォーマット: インベントリファイルはAWS Transformがサポートするフォーマットに従ってください。フォーマット詳細はドキュメントを参照してください
  • 精度と検証: エージェントが提供する互換性チェックやサイズ推奨は推奨値です。最終的な設計・パフォーマンス評価はステージング環境での検証を推奨します
  • MSK Express注意: MSK Expressは低レイテンシ/短保持のユースケース向けの選択肢です。スループットや保持要件によっては標準MSKが適切な場合があります

参考情報 ​

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