Skip to content

2026年08月29日

[Ec2] Amazon EC2 C8gn instances are now available in AWS Europe (Paris) region

概要

Amazon EC2のGraviton4搭載C8gnインスタンスがAWS Europe (Paris) リージョンで利用可能になりました。C7gn比で最大約30%の計算性能向上と最大600 Gbpsのネットワーク帯域を提供します。

変更内容・新機能の詳細

C8gnは最新世代のAWS Graviton4プロセッサを採用したネットワーク最適化インスタンスです。第6世代のAWS Nitro Cardsを搭載し、ネットワーク帯域は最大600 Gbps(インスタンス内最大値)、EBS向け帯域は最大120 Gbps、インスタンスサイズは最大48xlargeまで(最大メモリ384 GiB)をサポートします。C8gnはC7gn(Graviton3ベース)に対して最大で約30%のコンピュート性能向上を実現するとされ、ネットワーク仮想アプライアンス、データ分析、CPUベースのAI/ML推論などネットワークおよびCPU集約型ワークロードのスループット向上とコスト最適化に寄与します。さらに、EFA(Elastic Fabric Adapter)は16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xlでサポートされ、低遅延でクラスター性能を高める構成が可能です。今回のリリースではAWS Europe (Paris) リージョンでの利用開始がアナウンスされており、既に多くのリージョンで展開されています。導入時はARM64向けのAMIsやライブラリ対応(バイナリ再ビルドやARM向けパッケージ使用)を確認してください。

影響範囲・利用シーン

  • 対象ユーザー: ネットワーク仮想アプライアンス運用者、データ分析者、CPUベースのAI/ML推論担当者、SRE/インフラエンジニア
  • 利用シーン: 高スループットが求められるネットワーク集約型アプリケーション、分散分析パイプライン、複数ノードで低遅延通信を必要とするクラスター(EFA活用)
  • 運用効果: ネットワーク帯域と計算性能の向上によりスループット改善とインスタンス台数削減によるコスト最適化が期待できる(ただし価格差は要確認)
  • リージョン: 今回の追加により Europe (Paris) で利用可能。既存でC8gnが未対応のリージョンは引き続き存在する可能性あり(要リージョン確認)

技術的な注意点

  • AMI/アーキテクチャ: Graviton4はARM64(aarch64)アーキテクチャのため、x86向けバイナリはそのままでは動作しません。ARM対応のAMIs(Amazon Linux 3等)またはアプリの再ビルドが必要です
  • EFA/ネットワーク: EFAは16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xlでサポート。高性能クラスタ用途ではこれらサイズの利用を検討してください
  • ドライバ/ENA: 高速ネットワーキングを活用するためにENAドライバや関連カーネルモジュールが必要です。使用するAMIが最新ドライバを含むことを確認してください
  • EBS最適化: 最大120 GbpsのEBS帯域が利用可能ですが、実効スループットはEBSボリュームの種類や設定(プロビジョンドIOPS、スループット最適化)に依存します
  • IAM権限: インスタンス起動、EFA設定、ネットワーク関連リソースの作成には適切なEC2/IAM権限が必要です(例: ec2:RunInstances, ec2:CreateNetworkInterface, iam:PassRole など)
  • リージョン制限: 今回は Europe (Paris) に追加。C8gnは既に多くのリージョンで展開されていますが、利用前に対象リージョンでの提供状況を確認してください
  • コスト: Graviton4により性能/コスト比が改善する可能性がありますが、料金はリージョン・サイズ・購入オプション(オンデマンド、リザーブド、Savings Plans等)で異なります。移行前にコスト試算を実施してください

参考情報


[General] Amazon Bedrock AgentCore Memory now supports fine-grained access control

概要

Amazon BedrockのAgentCore Memoryが細粒度アクセス制御(FGAC)に対応しました。AgentCore GatewayとCedarポリシーを使って、ユーザー/テナント単位のメモリ(Memory)データ隔離と操作ごとの権限制御をインフラ層で強制できます。

変更内容・新機能の詳細

FGACはAgentCore GatewayをOAuth(JWT)認証で構成し、AgentCore Memoryコネクタを通してMemoryデータプレーンへのアクセスをCedarポリシーで制御できる仕組みです。AgentCore MemoryコネクタはMemoryの操作(記事によれば12種類の操作)をCedarのアクションとして公開し、各リクエストの属性(例: 呼び出し元のID、トークン請求情報、actorやnamespace等)をポリシー条件で参照できます。これにより「各ユーザーは自分のactorのデータのみ参照可能」「トークンのclaimに基づくnamespace制限」「特定ユーザーに対するMemory操作(読み取り/書き込み/削除など)の許可/拒否」といったルールをアプリケーションコードではなくインフラ(Gateway+Cedar)側で暗号的に検証されたIDをもとに一貫して適用できます。導入にはAgentCore GatewayのOAuth/JWT設定、Identity Provider側でのトークン設計(必要なclaimの付与)、およびCedarポリシーの作成が必要です。開始手順はAgentCore Developer Guideの「Fine-grained access control for Memory」に記載されています。

影響範囲・利用シーン

  • 対象ユーザー: Bedrockを使って会話メモリやユーザー固有の状態を保持するアプリ開発者、SRE、セキュリティチーム
  • 利用シーンまたは効果: マルチテナント環境でのメモリ隔離(ユーザー毎/テナント毎のデータ分離)、権限に応じたMemory操作の制御、アプリケーションコードの簡素化(認可ロジックをインフラへ移行)
  • 運用効果: 認可ロジックの一元管理によりバグと漏洩リスクを低減、監査可能なポリシー運用によりコンプライアンス対応が容易化
  • セキュリティ: JWTによる暗号的なID検証とCedarによる細かな条件付けで最小権限の強制が可能

技術的な注意点

  • IAM権限: AgentCore GatewayとMemoryコネクタの作成・設定、Cedarポリシーの管理に必要なIAM権限を付与する必要があります(具体的な権限はドキュメント参照)。
  • リージョン制限: 記事に明示的なリージョン情報はありません。利用可能リージョンは開発者ガイド/コンソールで事前確認してください。
  • 認証設定: AgentCore GatewayをOAuth(JWT)で構成するため、IdP側で必要なclaim(例: user_id / tenant_id / namespace派生用claim)を付与するトークン設計が必要です。
  • Cedarポリシー: Memoryコネクタが公開する12のアクションとリクエスト属性を用いてポリシーを作成します。条件式でトークンクレームやactor/namespace属性を参照する実装が必要です。
  • 互換性: 既存のアプリケーションはインフラ側で認可を移行する際にトークン形式やAPI呼び出しの微調整が必要となる場合があります。
  • コスト: AgentCore GatewayやBedrockの利用に伴う通常のサービス料金が発生します。トラフィック増やGatewayの管理単位によって追加コストが発生する可能性があるため事前に試算してください。

参考情報


[General] Amazon Bedrock AgentCore Memory now supports flexible namespace variables

概要

Amazon Bedrock の AgentCore Memory が柔軟なネームスペース変数をサポートしました。アプリケーション固有の次元(組織、テナント、チーム、環境など)で長期メモリをスコーピングでき、重複する戦略や組み込み変数の濫用を避けられます。

変更内容・新機能の詳細

開発者はメモリリソース上に最大5つのキー(柔軟なネームスペース変数)を定義でき、各キーは複数の戦略(strategy)から参照可能です。戦略側ではネームスペースのテンプレート内でこれらのキーを参照し、実行時に CreateEvent API のペイロードで値を渡します。AgentCore Memory は長期メモリ抽出時にテンプレートへ値を代入(サブスティテューション)して、最終的なネームスペースを生成します。この仕組みにより、マルチテナントや階層構造が複雑なアプリケーションで、メモリの組織化・分離・アクセス制御をきめ細かく設計できます。柔軟なネームスペース変数は、AgentCore Memory が一般提供されているすべての AWS リージョンで追加料金なしで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: マルチテナントSaaS開発者、プラットフォーム/アーキテクト、AIエージェントを組み込むアプリケーション開発チーム
  • 利用シーン: テナント単位・組織単位・チーム単位・環境(prod/stage)単位で長期メモリを分離したい場合、または単一の戦略定義を複数コンテキストで使い回す場合
  • 運用効果: 戦略の複製やカスタムフラグ管理を減らし、メモリ隔離のポリシー設計と運用が単純化される。アクセス制御やデータ分離の実装が容易になり、バグや誤用のリスクを低減できる
  • スケーラビリティ: 同一メモリリソースで最大5キーを定義し複数戦略で共有できるため、戦略管理数を増やさずに多様な分離軸をサポート可能

技術的な注意点

  • IAM権限: メモリリソースの作成/更新と CreateEvent API 呼び出しに必要な権限を付与する必要があります(メモリリソース編集権限、AgentCore イベント作成権限など)
  • リージョン制限: AgentCore Memory が一般提供されているリージョンで利用可能。未対応リージョンでは使用不可です
  • コスト: 追加料金は発生しません(記事時点)が、関連する読み書きやストレージ、API 呼び出しに伴う通常の料金は適用されます
  • 上限/制約: 1つのメモリリソースにつき最大5つのキー。キーは複数戦略で参照可能だが、キー名・テンプレートの設計により意図しないネームスペース衝突が発生する可能性があるため命名規則を策定してください
  • API/実装: 値は CreateEvent API のペイロードで指定します。サブスティテューションは長期メモリ抽出時に行われるため、既存に保存された過去の抽出に対する遡及的な置換は行われません(新しい抽出に対して適用されます)
  • 互換性/移行: 既存のネームスペース設計は従来どおり動作します。柔軟変数を導入する際は既存戦略とのマッピングとテストを行い、意図しないアクセス経路が生じないことを確認してください

参考情報


[General] AWS Transform now in scope for FedRAMP Class C

概要

AWS TransformがFedRAMP Class C(旧Moderate)適合サービスとしてUS East (Ohio) リージョンで対象になりました。これにより、FedRAMP Class C準拠が求められるワークロードでAWS Transformを利用できます。

変更内容・新機能の詳細

AWS Transformはエージェント的(agentic)なマイグレーションおよびモダナイゼーションサービスで、大規模なインフラ移行から継続的なテックデット解消までを自動化・統合し、従来数年かかっていた移行計画を数ヶ月に短縮することを目的としています。今回の発表は、同サービスが米国政府のクラウドセキュリティ基準であるFedRAMPのClass C(以前のModerate)コンプライアンス範囲に追加されたことを意味します。適用開始リージョンはUS East (Ohio)(us-east-2)で、これによりそのリージョンで提供されるAWS Transformの機能群に対してFedRAMP Class Cに基づくセキュリティ評価・継続的監視の枠組みが適用されます。ユーザーは、FedRAMP対象のシステム(FISMA/連邦データ分類に準拠するシステム)をTransformで構築・移行・モダナイズすることが可能になります。ただし、FedRAMP準拠はクラウド事業者側のサービスが認可対象に含まれることを示すものであり、最終的な認可(ATO: Authority to Operate)や顧客側の統制実装は共有責任モデルに基づき顧客側の対応が必要です。

影響範囲・利用シーン

  • 対象ユーザー: 連邦政府機関および連邦政府向けのシステムを扱うクラウドエンジニア、セキュリティ/コンプライアンス担当者、SRE、SI(システムインテグレーター)
  • 利用シーン: FedRAMP Class C(Moderate)に準拠が求められるシステムのクラウド移行、アプリケーションのモダナイゼーション、大規模インフラ削減やテックデット解消の自動化
  • 運用効果: 移行およびモダナイゼーションの期間短縮、手動作業と文脈喪失の削減、FedRAMP対応サービスを用いた構築により審査・監査準備の負担軽減が期待できる
  • リージョン: 本対応は現時点でUS East (Ohio) リージョン(us-east-2)のみが対象。その他リージョンでの適用は未保証

技術的な注意点

  • リージョン制限: FedRAMP Class Cの適用はUS East (Ohio)(us-east-2)のAWS Transformに限定されています。別リージョンでは同等のコンプライアンス範囲がない可能性があります
  • IAM権限: Transformを利用するためのIAMロール/ポリシー、クロスアカウントアクセス、サービスリンクロールなどの権限設定が必要です。最小権限の原則を適用してください
  • 共有責任: FedRAMPの適用はAWSが提供するサービスに関する評価を示すもので、顧客側の設定・データ保護・運用制御は顧客責任です。顧客は自らのセキュリティコントロール(OS/アプリ設定、暗号化鍵管理、ネットワークACL、監査ログ保持等)を実装・証明する必要があります
  • 監査・連続監視: FedRAMPは継続的監視を要求します。CloudTrail、AWS Config、Amazon CloudWatch等のログ・監視設定、監査証跡の保存ポリシーを整備してください
  • コスト: AWS Transformの利用や移行作業、追加のログ保存や監視のためのサービス利用は追加コストが発生します。見積りとコスト管理を事前に行ってください
  • コンプライアンス準備: ATO取得や既存のセキュリティ文書(SSP: System Security Plan等)の更新が必要になる場合があります。組織のコンプライアンス担当と連携してください
  • 依存サービス: Transformが利用するバックエンドサービス(EC2、S3、IAM、VPC、KMS等)がFedRAMPの要件を満たしているか確認し、必要に応じて構成を合わせてください

参考情報


[Ec2] Amazon EC2 P6-B300 instances are now available in additional AWS Regions

概要

Amazon EC2のP6-B300インスタンスが新たにアジアパシフィック(Hyderabad)と南米(Sao Paulo)リージョンで利用可能になりました。大規模なトレーニングや推論向けに強化されたGPUメモリと高帯域ネットワークを備えたインスタンスです。

変更内容・新機能の詳細

P6-B300は8基のNVIDIA Blackwell Ultra GPUを搭載し、合計で2.1 TBの高帯域GPUメモリ、4 TBのシステムメモリ、EFAを介した最大6.4 Tbpsのネットワーク(ノード間通信向け)、および300 Gbpsの専用ENAスループットを提供します。P6-B200世代と比較して、ネットワーク帯域が2倍、GPUメモリ容量が1.5倍、FP4精度でのGPU TFLOPSが1.5倍(スパース性は考慮しない数値)に向上しており、トリリオンパラメータ級のファウンデーションモデル(FM)や大規模LLMの学習・デプロイに適しています。現在、p6-b300.48xlargeサイズとして、US West (Oregon)、AWS GovCloud (US-East)、US East (N. Virginia)、Asia Pacific (Hyderabad、Seoul)、South America (Sao Paulo)で利用可能です。大容量GPUメモリと高帯域により、より大きなモデルを単ノード/分散トレーニングで扱え、学習時間短縮とトークン処理スループットの向上が期待できます。

影響範囲・利用シーン

  • 対象ユーザー: 大規模モデル(トリリオンパラメータ級)を研究・運用するMLエンジニア、データサイエンティスト、AIインフラ担当者
  • 利用シーン: 大規模分散トレーニング(EFAを用いた高性能通信)、単ノードでの大モデル学習やメモリ集約型推論、低レイテンシ/高スループットが求められる推論サービス
  • 運用効果: 学習時間の短縮、ノード間通信ボトルネックの低減によるスケール効率向上、より大きなモデルを単一インスタンスや少数ノードで扱うことによる運用単純化

技術的な注意点

  • 利用可能サイズ: 現時点では p6-b300.48xlarge のみが公開されています
  • リージョン制限: 新規にHyderabad・Sao Pauloで利用可能になったほか、Oregon、GovCloud(US-East)、N. Virginia、Seoulでも利用可能。全リージョンで未対応の可能性があるため事前確認が必要です
  • AMI/ドライバ: EFA/ENAとBlackwell GPU用の最新CUDA、NVIDIAドライバ、libfabricなどが必要。AWS提供のDeep Learning AMIやコンテナを利用するのが簡便です
  • ネットワーク設定: 高帯域・低遅延を活かすにはCluster Placement GroupやEFAの有効化が推奨されます
  • フレームワーク互換性: FP4など新精度のサポートはフレームワーク/ライブラリ側の対応が必要(PyTorch/Transformerライブラリ、NVIDIAソフトウェアのバージョン確認)
  • スケーリング: 分散トレーニングではEFAとマルチノード設定(nccl、libfabric等)を適切に構成する必要があります
  • IAM権限: EC2インスタンス起動、EFA/ENIのアタッチ、VPC/サブネット/セキュリティグループの設定などの権限が必要です
  • インスタンス数上限/クォータ: デフォルトのクォータが低めに設定されている場合があるため、事前にQuota増加申請が必要になることがあります
  • コスト: 高性能インスタンスのため消費コストは高くなる見込みです。オンデマンド/スポット/リザーブドのコスト差を考慮し、予算・スケジューリング設計を行ってください

参考情報


[CloudWatch] Amazon CloudWatch agent adds support for journald logs

概要

Amazon CloudWatch エージェントが systemd journal (journald) のネイティブ収集に対応しました。ディスク上のログファイルを経由せずに journald から直接ログを CloudWatch Logs に送信できます。

変更内容・新機能の詳細

CloudWatch エージェントは Linux インスタンス上の systemd journal を直接読み取り、CloudWatch Logs に送信できるようになりました。これにより、/var/log のような従来のテキストログへ書き出す追加のエクスポート設定が不要になります。journald が保持する構造化メタデータ(例: systemd ユニット名、優先度、プロセス情報など)をそのまま残して収集でき、systemd ユニット、journal の優先度、journal フィールドマッチによるフィルタリングや、CloudWatch に送信する前の正規表現フィルタを適用できます。これらによりノイズの削減、ログ量制御、コスト最適化が可能です。利用には最新の CloudWatch エージェントへのアップデートと、エージェント設定ファイルに journald セクションを追加する必要があります。サポートはすべての AWS Commercial リージョンおよび GovCloud(US) リージョンで提供され、取り込まれたログは標準の CloudWatch Logs 課金対象となります。

影響範囲・利用シーン

  • 対象ユーザー: Linux(systemd)を利用するクラウドエンジニア、SRE、運用チーム、監視/ログ分析担当者
  • 利用シーン: Amazon Linux 2023 や他の systemd ベースのディストリでのシステムログ収集、インスタンスの起動/停止やサービス単位のログ監視、journald の構造化メタデータを利用した詳細なログ解析
  • 運用効果: ディスクへのログ書き出し不要で I/O・設定の手間を削減し、メタデータを保持したままログを収集してフィルタによりノイズと取り込むデータ量を減らしコストを抑制可能

技術的な注意点

  • IAM権限: CloudWatch Logs へ書き込むための権限(例: logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents など)が必要です。エージェントに適切な IAM ロール/ポリシーを割り当ててください。
  • インスタンス側権限/アクセス: journald を読み取るには root 権限または systemd-journal グループ等での読み取り権限が必要です。エージェントを特権で実行するか、適切なグループにユーザーを追加してください。
  • CloudWatchエージェントバージョン: journald サポートは新しいエージェントで有効になるため、エージェントを最新バージョンにアップデートしてください。バージョン依存の違いがあるためリリースノートを確認してください。
  • リージョン制限: すべての AWS Commercial リージョンおよび GovCloud(US) で利用可能とされています。特殊リージョンの対応状況は公式情報で確認してください。
  • コスト: 取り込まれるログは標準の CloudWatch Logs 課金対象です。フィルタリングや優先度指定で取り込み量を制御しないと料金が増加する可能性があります。
  • 対応 OS/環境: systemd を採用する Linux 環境で有効です。Windows や systemd を持たない環境では対象外です。コンテナや管理されたサービス上での利用方法は環境により異なります。
  • 設定/運用: 利用開始にはエージェント設定ファイルに journald セクションを追加する必要があります。正規表現フィルタやジャーナルフィールドマッチを用いて収集対象を限定してください。

参考情報


[Aurora] Amazon Aurora MySQL 3.13 (compatible with MySQL 8.0.45) is generally available

概要

Amazon Aurora MySQL互換エディションv3がMySQL 8.0.45に対応しました。コミュニティの修正とAurora固有の改善を含むマイナーリリースで、全リージョン(Aurora MySQL提供リージョン)で利用可能です。

変更内容・新機能の詳細

Aurora MySQL-Compatible Edition 3 (MySQL 8.0互換) が MySQL 8.0.45 をサポートするようになりました。今回のリリースは、MySQLコミュニティによるバグフィックスやセキュリティ修正に加え、Aurora側での最適化や安定性改善を含んでいます。アップグレードはスケジュールされたメンテナンスウィンドウ中に自動マイナーアップグレードを有効にして適用可能です。大規模運用向けには、AWS Organizations の Upgrade Rollout Policy を使ってクラスタ群をフェーズごとに順次アップグレードする運用が推奨されます。マイナーアップグレードは既存インスタンス上でのインプレース(ロール)アップグレード、またはスナップショットからのリストアによる方法のいずれでも実行できます。なお、本リリースはAuroraの他の機能(ゼロスケールのサーバーレス、Aurora Global Database、I/O-Optimizedストレージ、組み込みのセキュリティと継続的バックアップ)と組み合わせて利用できます。

影響範囲・利用シーン

  • 対象ユーザー: データベース管理者、SRE、アプリケーション開発チーム、AWSマネージドDBを利用する運用チーム
  • 利用シーンまたは効果: セキュリティ修正やバグフィックスを取り込みたい既存のAurora MySQLクラスタのマイナーアップデート。大規模環境ではOrganizationsのロールアウトポリシーで段階的なアップグレード(ノンピーク時適用やカナリア展開)が可能
  • 運用効果: 自動マイナーアップグレードとロールアウトポリシーにより、運用負荷を下げつつ段階的に安全にバージョンを上げられるため、ダウンタイム最小化とリスク管理が容易になる

技術的な注意点

  • IAM権限: クラスタの変更や自動アップグレード設定にはRDS/Auroraの変更権限が必要。Organizationsのロールアウトを使う場合はOrganizations関連の権限も必要
  • リージョン制限: 公開時点で「Aurora MySQLが提供されている全リージョンでサポート」とされているが、事前に利用リージョンのドキュメントで確認してください
  • コスト: エンジン自体のアップグレードに追加課金は通常発生しないが、スナップショット作成・ストレージ利用やリストア時の一時的なインスタンス利用でコストが発生する可能性があります
  • アップグレード方式: 自動マイナーアップグレード(メンテナンスウィンドウ中に適用)、インプレースアップグレード、スナップショットからのリストアのいずれかを選択可能。運用での段階適用にはOrganizationsのUpgrade Rollout Policyが有効
  • 互換性/互換性テスト: MySQL 8.0.45はマイナーリリースのため後方互換性が維持される想定だが、プラグインやサードパーティ製ライブラリ、レプリケーション設定(バイナリログオプション等)は事前に検証してください
  • バックアップ/ロールバック: アップグレード前にスナップショットやバックアップを必ず取得し、ロールバック手順(スナップショットからの復元)を確認してください
  • 運用上の注意: 大規模クラスタや高負荷ワークロードでは先にステージング環境でマイナーアップデート検証を行い、パフォーマンス変化やエラーを確認することを推奨します

参考情報

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