AWS What's New Digest

Appearance

2026年02月25日 ​

[Compute Optimizer] AWS Compute Optimizer now applies AWS-generated tags to EBS snapshots created during automation ​

概要 ​

AWS Compute Optimizerが、未アタッチのEBSボリュームをスナップショット化して削除する際に作成されるスナップショットへ、自動的にAWS生成タグを付与するようになりました。これにより、Compute Optimizerの自動化で作成されたスナップショットの識別・追跡が容易になります。

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

変更点の概要:

  • Compute Optimizerが未アタッチのAmazon EBSボリュームを削除する前にスナップショットを作成するケース（手動操作またはAutomationルールによる自動化のいずれでも）で、作成されるスナップショットにAWS生成のタグ aws:compute-optimizer:automation-event-id が付与されます。
  • このタグの値は、スナップショットを作成したAutomationイベントの一意の識別子に紐づきます。これにより、どの自動化イベントがスナップショットを作成したかが追跡可能になります。 技術的なポイント:
  • タグキー: aws:compute-optimizer:automation-event-id（AWSが生成）。
  • 適用タイミング: Compute Optimizerがスナップショットを作成する処理の実行時に自動で付与。
  • 利用方法: EC2コンソール、AWS CLI（DescribeSnapshotsのタグフィルタなど）、Resource Groupsやタグベースの検索/レポートでフィルタ可能。
  • 可用性: AWS Compute Optimizer Automationが利用可能な全リージョンで有効（記事公開時点）。
  • セキュリティ/管理: aws: プレフィックスのタグはAWS生成の予約名前空間であり、ユーザー側で同じキーを作成・上書きすることはできません。
  • スナップショットの暗号化や課金挙動には変更なし。スナップショットは通常通り保存され、ストレージ料金が発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/インフラエンジニア、SRE、コスト管理/ガバナンス担当者
  • 利用シーン: Compute Optimizer Automationで未アタッチEBSを削除する前のバックアップ（スナップショット）を作成した履歴を追跡・監査するとき
  • 運用効果: 自動化で作成されたスナップショットを容易に識別できるため、不要スナップショットのクリーンアップ、課金分析、監査証跡の整備がしやすくなる
  • 自動化設定確認: どのAutomationイベントがスナップショットを生成したかを突き合わせできるため、自動削除ルールの影響範囲把握が容易になる

技術的な注意点 ​

  • IAM権限: Compute Optimizerがスナップショット作成・タグ付与を行えるように、サービス側の実行ロール（サービスリンクドロール）や必要なEC2/EBS操作権限が適切に設定されていることを確認してください。
  • リージョン制限: AWS Compute Optimizer Automationが提供されているリージョンで利用可能です。未提供リージョンでは適用されません。
  • コスト: 作成されたEBSスナップショットは通常のスナップショットストレージ料金が発生します。自動化ルールによるスナップショット作成頻度と保存期間を見直してください。
  • タグ取り扱い: aws: プレフィックス（例: aws:compute-optimizer:automation-event-id）はAWS生成の予約タグです。ユーザーによる同名タグの作成や上書きはできません。
  • スナップショット属性: 暗号化の有無やコピーの挙動は元のボリューム設定に依存します。タグの追加は暗号化やスナップショット内容には影響しません。
  • 検索/自動化連携: DescribeSnapshotsやタグベースのフィルタで該当タグを用いて検索・レポートや、他ツール（Lambda/Inventory/Scripts）からの連携が可能です。
  • 自動化ポリシー確認: 自動削除ルールを設定している場合、スナップショット作成→削除のフローと保持期間を事前に検証してください。

参考情報 ​

[Cloudtrail] AWS Observability now available as a Kiro power ​

概要 ​

AWS Observability が Kiro Power として提供開始され、Kiro 内でAIエージェント支援のワークフローを使ってインフラ／アプリの障害調査や観測性改善を迅速化します。CloudWatch、Application Signals、CloudTrail、AWS Documentation の4つの MCP サーバーをパッケージ化しています。

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

本パワーは、Kiro Powers の形式で提供される事前検証済みのModel Context Protocol（MCP）サーバー、steeringファイル、hooks のセットです。パッケージには次の4種類の MCP サーバーが含まれます：

  • CloudWatch MCP サーバー：メトリクス・ログ・アラーム等の観測データを供給
  • Application Signals MCP サーバー：APM 情報（パフォーマンス指標、トレースなど）を供給
  • CloudTrail MCP サーバー：セキュリティ分析・コンプライアンス向けのイベント／監査ログを供給
  • AWS Documentation MCP サーバー：操作手順やドキュメント参照の文脈を提供

Kiro エージェントは、これらの MCP サーバーと steering ガイドを組み合わせることで、アラーム対応、異常検知、分散トレーシング解析、SLO コンプライアンス確認、セキュリティ調査といった包括的なトラブルシューティングワークフローを即時に実行できます。エージェントは調査対象に応じて必要なコンテキストのみを動的にロードするため、不要な情報の読み込みを抑えてMTTRの短縮を図ります。

さらに、コードベースやインストルメンテーションを解析する「自動ギャップ分析」機能を搭載し、未ログ化エラー、相関IDの未付与、分散トレーシング未導入などのパターンを検出して具体的な改善推奨（例：ログポイント追加、トレース挿入、ヘッダ伝搬）を提示します。8本の steering ガイド（インシデント応答、アラート設計、パフォーマンス監視、セキュリティ監査、ギャップ分析等）を同梱し、Kiro IDE または Kiro Powers ウェブページからワンクリックで導入可能です。各 MCP サーバーは AWS の各サービスがそのリージョンでサポートされているかに依存して機能します。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE、運用チーム、セキュリティ／コンプライアンス担当者
  • 利用シーンまたは効果: インシデント対応（アラート受領→原因特定→対応手順提示）、パフォーマンス劣化の根本原因分析、セキュリティ侵害調査、SLO 監視とレポーティング、自動ギャップ分析による観測性の継続的改善
  • 運用効果: MTTR の短縮（対象コンテキストのみを動的ロードして無駄な調査時間を削減）、観測性の欠落ポイントを自動検出してプロアクティブに改善可能
  • 導入影響: Kiro IDE 内で迅速に組み込めるため導入障壁は低いが、AWS リソースへの読み取り権限やコードリポジトリ参照権限が必要になるため組織のアクセス方針に影響あり

技術的な注意点 ​

  • IAM権限: CloudWatch、CloudWatch Logs、X-Ray、CloudTrail 等の読み取り系 API 権限（例: cloudwatch:GetMetricData, logs:FilterLogEvents, xray:GetTraceSummaries, cloudtrail:LookupEvents）や、必要に応じてS3/Logs等へのアクセス権を付与する必要があります
  • リージョン制限: Kiro Power のインストールは全リージョンで可能だが、各 MCP サーバーの機能は対象となる AWS サービスが当該リージョンで利用可能であることに依存します
  • コスト: 本パワー自体の料金記載はないが、CloudWatch Logs Insights クエリ、CloudWatch メトリクス取得、X-Ray トレース保存/クエリ、CloudTrail データ取得などの AWS サービス利用料が発生します。ギャップ分析でリポジトリ走査やログクエリが増えると追加コストがかかる点に注意してください
  • データアクセス／プライバシー: Kiro のエージェント／MCP サーバーにログやトレースを供給するため、機密ログや個人情報を含むデータの取り扱いポリシーを事前に確認してください。社内ルールやコンプライアンス要件に基づくアクセス制限が必要です
  • Kiro 要件: Kiro IDE または Kiro Powers の利用環境（エージェント実行環境、ネットワーク接続）が前提です。Kiro 側のバージョン互換性やプラグイン許可設定を確認してください
  • ギャップ分析の前提: 自動検出はソースコードおよびビルド成果物／メタデータに依存します。実行にはリポジトリアクセスやビルド情報の提供が必要となるため、CI/CD 連携やソース権限の準備が必要です

参考情報 ​

[General] Announcing AWS Elemental Inference ​

概要 ​

AWS Elemental Inferenceが一般提供（GA）になりました。ライブ／オンデマンド映像をエンコードと並行して自動的にモバイル向け縦型クリップやハイライトをリアルタイム生成するマネージドAIサービスです。

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

Elemental Inferenceは放送事業者や配信者向けのフルマネージドAIサービスで、ライブおよびオンデマンド映像を1回処理して複数フォーマット向けに最適化（同時にメイン放送と縦型動画の生成など）できます。ローンチ時点で提供される主なAI機能は（1）縦型ビデオクロップ：横長放送をTikTok/Instagram Reels/YouTube Shorts等に適した縦型フォーマットへ自動変換、（2）高度なメタデータ解析：ハイライトとなるキーモーメントを検出してクリップ化する機能です。エージェント的（agentic）AIアプリケーションとして設計されており、プロンプト入力や常時の人手介入を必要とせずにプラットフォーム毎の最適化を自動化します。ベータテストでは、複数のポイントソリューションを組み合わせるワークフローに比べてAI駆動のライブ映像ワークフローで34％以上のコスト削減が報告されています。サービスはライブ処理（リアルタイム）とオンデマンド処理の両方をサポートし、既存の映像配信パイプラインに組み込んで並列処理が可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 放送局、スポーツ中継制作会社、ストリーマー、メディア企業、ソーシャルメディア向け短尺動画を大量に作る制作チーム
  • 利用シーンまたは効果: ライブ試合中の自動ハイライト生成と即時SNS配信、既存番組を同時に縦型コンテンツへ変換してモバイル視聴者を増やす用途、人的リソースを増やさずに大量のクリップをスケール生成
  • 運用効果: 手作業や複数ツールの連携を減らし制作コストと時間を短縮（ベータで34％以上の節約事例あり）。リアルタイム配信中にバイラル瞬間を即時取得・配信できるため収益化/視聴獲得の機会増加
  • 導入負荷: 既存の配信ワークフローへ組み込む際はAPI/エンコーディング連携や処理遅延／コストの評価が必要

技術的な注意点 ​

  • IAM権限: 利用にはElemental Inference用のIAM権限やサービスリンクドロールが必要になる可能性が高く、詳細は公式ドキュメントで事前に確認してください
  • リージョン制限: 現時点でのGA対応リージョンは US East (N. Virginia) (us-east-1), US West (Oregon) (us-west-2), Asia Pacific (Mumbai) (ap-south-1), Europe (Ireland) (eu-west-1) です
  • サポート機能／制約: 提供機能は縦型クロップとメタデータベースのハイライト検出が中心。対応コーデック／解像度や入力フォーマット、同時スループット上限はドキュメントで確認してください
  • レイテンシ／品質: エンコードと並行処理するため低遅延だが、処理追加によりエンドツーエンドの遅延やネットワーク負荷が増す可能性があります。遅延要件のあるライブ用途は検証が必要です
  • コスト: AI処理の追加コストが発生します（ベータでは複数ソリューション対比でコスト削減効果が示された事例あり）。使用量（処理時間・出力数）に基づく課金モデルが想定されるため見積もりが必要です
  • 運用上の注意: 自動生成されたクリップは品質やコンプライアンス（肖像権・権利処理・コンテンツモデレーション）を確認するワークフローを組み込むことを推奨します

参考情報 ​

[RDS] Amazon RDS Snapshot Export to S3 now available in AWS GovCloud (US) Regions ​

概要 ​

Amazon RDS のスナップショットを Apache Parquet 形式で S3 にエクスポートする機能が AWS GovCloud (US) リージョンで利用可能になりました。分析や機械学習、データ保管用途で既存のスナップショットを直接 Parquet に変換して S3 に配置できます。

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

本機能は RDS スナップショット（手動スナップショット、自動システムスナップショット、AWS Backup スナップショットを含む）から直接データを Apache Parquet 形式で S3 に出力します。エクスポート処理はスナップショット上で実行され、稼働中データベースのパフォーマンスに影響を与えません。出力された Parquet データは Amazon Athena、Amazon SageMaker、Amazon Redshift Spectrum、Apache Spark などでそのまま分析・学習処理に利用できます。操作は RDS コンソールから数クリック、または AWS SDK/CLI から StartExportTask 等の API を呼ぶことで開始できます。サポート対象は Amazon Aurora (PostgreSQL-Compatible / MySQL)、Amazon RDS for PostgreSQL、Amazon RDS for MySQL、Amazon RDS for MariaDB のスナップショットです。GovCloud (US) リージョンでの利用が新たに可能になったため、政府機関や規制対応が必要なワークロードでも利用しやすくなっています。

影響範囲・利用シーン ​

  • 対象ユーザー: ガバメント/規制準拠が必要な組織、SRE、データエンジニア、データサイエンティスト
  • 利用シーン: スナップショットからのバルクデータ抽出による一括分析、長期保存データのフォーマット変換、機械学習用データセット作成
  • 運用効果: 本番データベースへの影響を避けつつスナップショットから直接 Parquet を生成できるため、分析基盤へのデータ投入が簡素化され、ETL 工数と本番負荷を軽減できる

技術的な注意点 ​

  • IAM権限: エクスポート開始には rds:StartExportTask 等の RDS 権限と、S3 に書き込むための IAM ロール（RDS が信頼できるロール）およびバケットへの PutObject 権限が必要です
  • KMS/暗号化: 暗号化されたスナップショットをエクスポートする場合は適切な KMS キーと RDS に対する KMS 権限（kms:Decrypt 等）が必要です
  • リージョン制限: 本リリースは AWS GovCloud (US) リージョンでの提供開始を通知するもので、利用可能リージョンは限定されています。S3 バケットは同一リージョン内に作成することを推奨します
  • コスト: S3 保存料金、スナップショットエクスポートに対するデータ処理/エクスポート料金（リージョンの料金表を確認してください）、および後続分析サービス（Athena/SageMaker/Redshift Spectrum 等）の利用料金が発生します
  • サポートDB/互換性: Amazon Aurora (PostgreSQL-Compatible, MySQL)、RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB のスナップショットが対象です。その他のエンジンは対象外の可能性があります
  • 操作方法: コンソール、AWS CLI、SDK からエクスポートタスクを作成可能。既存の AWS Backup スナップショットもサポートされます
  • パフォーマンス: エクスポート処理はスナップショット上で実行されるため稼働中 DB の性能に影響を与えない設計ですが、大量データのエクスポートは時間がかかるため運用上のスケジュール設計が必要です

参考情報 ​

[Deadline Cloud] AWS Deadline Cloud now supports running tasks together in chunks ​

概要 ​

AWS Deadline Cloudで、複数のタスクを「チャンク（塊）」としてまとめて実行できる機能が追加されました。短時間タスクやノードの起動に時間がかかる環境で、実行時間とコストを削減できます。

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

ジョブ作成時に、実行するタスクをまとめる「チャンクサイズ（タスク数）」を手動指定するか、チャンクの目標実行時間（target run time）を指定できます。目標実行時間を指定した場合は、ジョブの進行に合わせてチャンクあたりのタスク数を動的に調整し、目標時間に近づけるように実行効率を改善します。短時間で終わる多数のタスクや、ノード起動にオーバーヘッドがあるワークロードでは、タスク単位の起動/終了オーバーヘッドを削減することで総実行時間とコストを低減できます。設定はジョブ作成時に行い、コンソール／API／SDKから利用可能な想定です。本機能はAWS Deadline Cloudがサポートされているすべてのリージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: VFX/レンダーエンジニア、CG制作チーム、レンダーファーム運用者
  • 利用シーン: 短時間で完了するレンダータスクのバッチ実行、ノード起動に時間がかかる環境での実行、スポット/一時インスタンスでの効率的なジョブ処理
  • 運用効果: タスク起動・終了のオーバーヘッド削減による総ジョブ実行時間短縮とコスト削減、リソース利用率の向上

技術的な注意点 ​

  • IAM権限: ジョブ作成／更新を行うIAMユーザー／ロールにDeadline Cloudのジョブ管理権限が必要です（コンソール操作やAPI呼び出し権限を確認してください）。
  • リージョン制限: AWS Deadline Cloudがサポートされているすべてのリージョンで利用可能と発表されていますが、利用前に対象リージョンでのサービス提供状況を確認してください。
  • コスト: チャンク化により短時間タスクのオーバーヘッドが減りコスト低減が期待できます。ただし、チャンク単位での失敗時は複数タスクを再実行する可能性があり、再実行コストや処理遅延の影響を考慮してください。
  • リトライ／フェイルオーバー: チャンク単位での実行になるため、失敗時のリトライ粒度が変わります。アプリケーション側でタスクの冪等性やチェックポイント機構を検討してください。
  • パフォーマンス/メモリ: 1チャンクあたりの同時実行タスク数が増えると、ワーカーノードのCPU／メモリ使用量が高まる可能性があります。ノードのスペックとチャンク設定のバランスを確認してください。
  • 設定運用: 手動のチャンクサイズとターゲット実行時間は運用方針によって使い分けます。ターゲット実行時間はジョブ進行に応じて動的にタスク数を調整するため、実行時間のばらつきがあるタスク群に有効です。

参考情報 ​

[Ec2] Amazon EC2 R7a instances are now available in the Asia Pacific (Hyderabad) Region ​

概要 ​

Amazon EC2 R7a インスタンスが AWS アジアパシフィック（ハイデラバード）リージョンで利用可能になりました。4th Gen AMD EPYC（Genoa、最大3.7GHz）を搭載し、R6a 比で最大50%の性能向上をうたっています。

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

R7a は R 系列の新しいインスタンスタイプで、4th Gen AMD EPYC（コード名 Genoa）プロセッサを採用しています（最大周波数 3.7 GHz）。AWS の発表では、R6a と比較して最大50%の性能向上を示しています。購入形態は Savings Plans、Reserved Instances、On‑Demand、Spot の各オプションが利用可能です。利用や起動は AWS マネジメントコンソール、AWS CLI、AWS SDKs 経由で行えます。R7a は x86_64 アーキテクチャ（AMD EPYC）で動作するため、既存の x86 向け AMI やソフトウェアとの互換性が高く、メモリ集約型ワークロード（データベース、インメモリキャッシュ、分析ジョブ、リアルタイム処理、ML 推論など）で有利です。Nitro ベースのインスタンスであるため、ENA（強化ネットワーキング）や NVMe ベースの EBS 最適化などの機能を利用できます。なお、性能向上はワークロード依存のため、本番導入前に十分なベンチマーク（アプリケーションレベルの負荷試験）を推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、SRE/運用チーム、DB 管理者、データ分析者
  • 利用シーン: メモリ集約型データベース（Postgres、MySQL、Aurora 等）、インメモリキャッシュ（Redis、Memcached）、大規模分析／ETL ジョブ、ML 推論ノード
  • 運用効果: 同等ランタイムでの性能向上によりインスタンス台数削減やレスポンス改善が期待できる（ただしワークロード依存）
  • コスト: より高性能だが価格差があるため、Savings Plans / Reserved / Spot の組合せでコスト最適化が可能
  • リージョン影響: 現時点では Asia Pacific（Hyderabad）リージョンでの利用開始 — 他リージョンでの利用可否はリージョンごとに確認が必要

技術的な注意点 ​

  • IAM権限: ec2:RunInstances、ec2:DescribeInstances、ec2:DescribeInstanceTypes 等の適切な権限が必要
  • リージョン制限: 本アナウンス時点では Asia Pacific（Hyderabad）リージョンでの追加提供。利用可否は各リージョンのドキュメントで確認
  • コスト: R7a は R6a より性能が高いが価格差があるため、TCO 比較（オンデマンド単価、リザーブド/Savings の割引）を事前に評価
  • インスタンス上限: アカウントごとの vCPU クォータが適用されるため、必要に応じてクォータ増加申請が必要
  • AMI/アーキテクチャ: x86_64（AMD）向け AMI を利用すること。arm64（Graviton）向け AMI とは互換性がない
  • ドライバー/OS: 最新の Linux カーネル／ENA ドライバー／NVMe ドライバーを推奨。古いカーネルでは最適な性能が出ない場合あり
  • 互換性検証: 本番移行前にアプリケーションレベルのベンチマーク（メモリ使用パターン、スレッド数、I/O パターン）で性能と安定性を確認
  • サービス連携: EBS、ENI、Placement Group、Auto Scaling 等の既存 EC2 機能と連携可能。特別な設定は不要だが構成次第でネットワーク／I/O 特性が変動する

参考情報 ​

[Ec2] Amazon EC2 C8i and C8i-flex instances are now available in Asia Pacific (Malaysia) and South America (Sao Paulo) regions ​

概要 ​

Amazon EC2のC8iおよびC8i-flexインスタンスが、アジアパシフィック（マレーシア）および南米（サンパウロ）リージョンで利用可能になりました。カスタムIntel Xeon 6プロセッサを搭載し、従来のIntelベース世代比で高い価格性能比と大幅なメモリ帯域幅向上を提供します。

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

C8iおよびC8i-flexはAWS専用のカスタムIntel Xeon 6プロセッサを採用しており、同等のクラウド上Intelプロセッサと比べて最大で高いパフォーマンスと最速のメモリ帯域幅を実現します。主な数値は以下の通りです：従来のIntelベースインスタンスに対して最大15％の価格性能向上、以前の世代に対して最大2.5倍のメモリ帯域幅、C7i/C7i-flex比で最大20％の総合性能向上。特定ワークロードではさらに大きな改善があり、NGINXで最大60％高速化、AIディープラーニングのレコメンデーションモデルで最大40％、Memcachedで最大35％の高速化が報告されています。C8i-flexは一般的なサイズ（large〜16xlarge）を提供し、リソースをフルに使い切らないアプリケーション（Web/APサーバ、データベース、キャッシュ、Apache Kafka、Elasticsearch、エンタープライズアプリ等）でコスト効率を高める“手軽な”選択肢です。C8iはメモリ集約型や継続的な高CPU使用率が必要なワークロード向けで、13サイズ（うち2つはベアメタル）を含み、最大サイズとして新しい96xlargeを提供します。購入はSavings Plans、オンデマンド、Spotで可能です。利用開始はAWS Management Consoleから行います。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドで高性能CPUと高メモリ帯域を必要とするクラウドエンジニア、SRE、データサイエンティスト、アプリケーションオーナー
  • 利用シーン: Web/アプリケーションサーバ、インメモリキャッシュ（Memcached等）、大規模検索（Elasticsearch）、ストリーミング/メッセージング（Kafka）、AI推論・レコメンドモデル、データベースの高スループット処理
  • 運用効果: 既存のC7i世代や他のIntelベースインスタンスからの移行でレイテンシ低下・スループット向上やコストあたり性能改善が期待でき、特にメモリ帯域依存のワークロードで効果が大きい

技術的な注意点 ​

  • IAM権限: EC2の起動（ec2:RunInstances）や関連リソース（VPC、サブネット、セキュリティグループ、IAMロール）に対する権限が必要です。Savings Plans購入や請求操作には追加の請求関連権限が必要です。
  • リージョン制限: 本記事時点ではアジアパシフィック（マレーシア）と南米（サンパウロ）で利用可能です。他リージョンでの利用可否は順次展開のためドキュメントで確認してください。
  • コスト: 公称では価格性能比が向上していますが、実際のコストはワークロード特性（稼働率、オンデマンド/Spot/Savings Plansの利用）によります。SpotやSavings Plansの活用で総コストを削減可能です。
  • AMI/ドライバ: Enhanced Networking（ENA）や最新のNVMe/EBSドライバ、カーネルのサポートが必要な場合があります。既存AMIを使う場合はAWSのインスタンスタイプ要件（ENA/ドライバ互換）を確認してください。
  • インスタンスサイズ/ベアメタル: C8iは13サイズ（うち2つはベアメタル）および新しい96xlargeを含みます。C8i-flexはlarge〜16xlargeの一般的なサイズを提供します。ベアメタルや大サイズ利用時はホストのリソース割当やライセンス要件を確認してください。
  • 互換性: アプリケーションのスケーリング特性（CPUバウンド／メモリバウンド）を評価し、C8i-flex（コスト効率重視、一般的サイズ）とC8i（メモリ集約、大規模サイズ）を使い分けてください。
  • その他: EBSスループットやネットワーク帯域の上限はインスタンスサイズに依存します。性能検証（ベンチマーク）を行ってから本番移行することを推奨します。

参考情報 ​

[Appconfig] AWS AppConfig integrates with New Relic for automated rollbacks ​

概要 ​

AWS AppConfigがNew RelicのWorkflow Automationと連携し、機能フラグや動的設定の段階的デプロイ中にアプリケーションの健全性が悪化した際に自動でインテリジェントにロールバックできるようになりました。これにより検知から復旧までの時間を秒単位に短縮できます。

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

今回の統合は、AppConfigのサードパーティ通知（third‑party alert）機能を活用して、New Relic側で定義したアラート条件に基づき自動的にロールバックを実行する仕組みを提供します。具体的には、AppConfigで機能フラグや動的設定を段階的（gradual）デプロイする際に、New Relic Workflow Automationが継続的にエラーレートやレイテンシ等の健全性指標を監視します。事前に設定した閾値を超える問題が検出されると、New Relicのワークフローが通知（例: webhook）を送信し、AppConfigの「元の状態へ戻す」アクションを即時トリガーします。これにより手動介入なしでデプロイを巻き戻し、顧客影響を最小化します。実装面では、AppConfigの既存のデプロイ戦略（段階的ロールアウト）とNew Relicのアラート／ワークフローを組み合わせて“クローズドループ”の自動運用を実現します。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE、DevOps、プラットフォーム/プロダクトエンジニア、機能フラグを運用する開発チーム
  • 利用シーン: 段階的デプロイ（機能フラグや動的設定）の間にエラー率やレイテンシ増大が発生した際の自動ロールバック
  • 運用効果: 問題検知から復旧までの時間を数分→数秒に短縮し、手動対応負荷の低減と顧客影響の最小化を実現

技術的な注意点 ​

  • IAM権限: AppConfigのデプロイ操作（例: デプロイ停止やロールバックを実行するための権限）を実行する役割に必要なIAM権限を付与してください。最小権限ポリシーは導入前に検討・確認することを推奨します。
  • リージョン制限: New Relic連携やAppConfigの拡張機能がすべてのAWSリージョンでサポートされているとは限りません。利用前に対象リージョンでの対応状況を確認してください。
  • コスト: 新しい連携自体で追加のAWS料金が発生する場合があります（AppConfigのホステッド設定バージョン作成やデプロイに伴う通常の課金）。また、New Relic側の監視やWorkflow Automationの利用料、API呼び出しやログ転送によるデータ転送料金が発生する可能性があります。

参考情報 ​

[Ec2] Amazon EC2 M8a instances now available in AWS Europe (Frankfurt) region ​

概要 ​

Amazon EC2の汎用インスタンス M8a が AWS Europe (Frankfurt) リージョンで利用可能になりました。5th Gen AMD EPYC（Turin）を採用し、M7a 比で性能と価格性能が向上しています。

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

M8a インスタンスは最大 4.5GHz の 5th Gen AMD EPYC（コードネーム Turin）プロセッサを搭載し、M7a インスタンス比で最大で約30%の性能向上、価格性能で最大約19%の改善を実現します。メモリ帯域は M7a 比で約45%増加しており、レイテンシに敏感なワークロードにも適しています。ベンチマークでは GroovyJVM で最大 60% 高速化、Cassandra で最大 39% 高速化を確認しています。M8a は SAP 認定済みで、12 サイズ（そのうち 2 サイズはベアメタル）を提供し、幅広いワークロードに合わせて柔軟に選択可能です。ハードウェア面では第6世代の AWS Nitro カードを採用しており、高スループット・高性能なネットワーク/ストレージ性能を提供します。購入は On‑Demand、Savings Plans、Spot で可能です。利用開始は AWS マネジメントコンソールまたは API/CLI から行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドインフラ担当者、SRE、アプリケーション開発者、データベース/キャッシュ運用者、SAP導入担当者
  • 利用シーン: 金融アプリケーション、ゲームサーバ、レンダリング、アプリケーションサーバ、シミュレーション/モデリング、中規模データストア、開発環境、キャッシュフリートなど高性能・高スループットを要求するワークロード
  • 運用効果: M7a 比でのCPU性能・メモリ帯域の改善により、レイテンシ低減とスループット向上が見込め、インスタンスサイズを最適化することでコスト対効果を改善できる

技術的な注意点 ​

  • リージョン制限: この記事時点では AWS Europe (Frankfurt) (eu-central-1) で利用可能。ほかリージョンの対応状況はドキュメントで確認してください
  • IAM権限: RunInstances 等の標準的な EC2 起動権限が必要。ベアメタルや専用ホストの利用には追加の権限/設定を確認してください
  • AMI/ドライバ: 最新の Amazon Linux 2/2023 や主要 Linux ディストリビューションの最新 AMI を推奨。ENA（Enhanced Networking）や NVMe ドライバのサポート状況を確認してください
  • 互換性: SAP 認定は取得済みですが、SAP ワークロードでの正式サポート/設定は SAP のドキュメントと AWS の SAP ガイドを参照の上、検証を行ってください
  • サイズ/ベアメタル: 12 サイズ（うち2つはベアメタル）を提供。ベアメタルを選択する場合はホスト要件やライセンス（OS/ソフトウェア）の影響を考慮してください
  • ネットワーク/ストレージ制限: Nitro ベースで高性能だが、vCPU/ネットワーク帯域/EBS 帯域の上限はインスタンスタイプ毎に異なるため設計時に公式スペックを確認してください
  • コスト: M7a 比で最大19%の価格性能改善が報告されていますが、実際の課金はリージョン/サイズ/購入方法（On‑Demand/Savings Plans/Spot）により異なります。移行前にコスト試算を行ってください

参考情報 ​

[Ec2] Amazon EC2 I7ie instances now available in AWS Africa (Cape Town) region ​

概要 ​

Amazon EC2 I7ie インスタンスが AWS Africa (Cape Town) リージョンで利用可能になりました。大容量・高IO性能のローカルNVMeを備えたストレージ最適化インスタンスで、前世代（I3en）に対して計算・ストレージ性能と価格性能が向上しています。

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

I7ie は高密度ストレージ最適化インスタンスで、主な特徴は以下のとおりです。

  • プロセッサ: 5th Gen Intel Xeon プロセッサ（全コアターボ周波数 3.2 GHz）
  • 性能改善: I3en 比で最大40%の計算性能向上、最大20%の価格性能向上を想定
  • ローカルストレージ: 最大120 TB のローカル NVMe（インスタンスストア）をサポート
  • メモリ/vCPU: 前世代比で最大2倍の vCPU とメモリを提供するサイズがある
  • Nitro SSD: 3rd generation AWS Nitro SSD を採用し、リアルタイムストレージ性能が最大65%向上、ストレージI/Oレイテンシーが最大50%低下、レイテンシ変動が最大65%低減
  • ネットワーク/ストレージ帯域: 最大100 Gbps のネットワーク帯域、EBS 用最大60 Gbps を提供
  • サイズ: 9種類の仮想サイズで提供 これらにより、大規模データセットへ低レイテンシかつ高ランダムIO性能でアクセスするワークロードに適しています。EBS帯域やネットワーク性能はインスタンスタイプとリージョンの制約、選択するボリュームタイプやプロビジョニングによって実効値が変わります。

影響範囲・利用シーン ​

  • 対象ユーザー: データベースエンジニア、ビッグデータ／分析基盤担当者、SRE、ストレージ集約型アプリケーション開発者
  • 利用シーン: ローカルNVMe上での低レイテンシ大容量ランダム読み書きが必要な NoSQL データベース（例: Cassandra、HBase）、分散ファイルシステム／データレイクノード、ログ集約／タイムシリーズデータ処理、大規模キャッシュワークロード
  • 運用効果: データ局所性を活かした高速処理によりレイテンシとスループットが改善され、I3en 比で応答速度の安定化とスループット向上が期待できる
  • 導入制約: ローカルNVMeはインスタンスストア（揮発性）であるためデータ永続化戦略（レプリケーション、スナップショット、EBSバックアップ等）が必須です
  • リージョン影響: 本発表は AWS Africa (Cape Town) リージョンでの提供開始を示しており、利用可能リージョンは順次拡大する可能性があります

技術的な注意点 ​

  • IAM権限: RunInstances、DescribeInstances、CreateTags、EBS 操作（AttachVolume/DetachVolume など）を含む標準的な EC2/EBS 権限を確認してください
  • リージョン制限: 本記事時点では AWS Africa (Cape Town) にて利用可能。ほかのリージョンでの展開状況は公式ページで確認してください
  • ストレージ永続性: ローカルNVMe（インスタンスストア）は停止／終了でデータが消失します。データ永続化や障害対策（レプリケーション、定期スナップショット、外部バックアップ）を設計してください
  • ドライバ／互換性: 高速NVMeとENA（Enhanced Networking）を活用するため、最新のOSカーネルやNVMe/ENAドライバが必要になる場合があります
  • インスタンス上限: デフォルトの vCPU クォータやインスタンス上限に注意。必要に応じて Service Quotas で増加申請を行ってください
  • EBS/ネットワークの実効性能: 表示上の最大帯域（例: EBS 60 Gbps、ネットワーク 100 Gbps）はボリュームタイプ、I/O プロビジョニング、ネットワーク設定、インスタンスサイズに依存します。ベンチマークで実効性能を評価してください
  • コスト: 大容量・高性能のためインスタンス料金は上位となる可能性があります。I3en と比較すると価格性能は改善しているが、ワークロードごとにコスト試算（オンデマンド、Reserved/Save、スポット）を行ってください

参考情報 ​

[EKS] Amazon EKS Node Monitoring Agent is now open source ​

概要 ​

Amazon EKS Node Monitoring Agentがオープンソース化され、ソースコードの閲覧・カスタマイズ・コントリビュートが可能になりました。エージェントはノードレベルのシステム／ストレージ／ネットワーク／アクセラレータの問題を検出してノード条件として公開し、EKSの自動ノード修復に利用されます。

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

Amazon EKS Node Monitoring Agentはノード上で発生するシステム、ストレージ、ネットワーク、GPUなどアクセラレータに関する障害や劣化を継続的に監視し、それらをKubernetesのノード条件（Node Conditions）として公開します。公開されたノード条件はAmazon EKSの自動ノード修復機能（node repair）から参照され、必要に応じてノードの再起動や置換などの修復アクションをトリガーします。今回ソースコードがGitHubで公開されたことで、実装の透明性が向上し、プラットフォーム固有の要件に合わせたカスタマイズ、バグ修正や機能拡張への直接的なコントリビュートが可能になります。エージェントはAmazon EKSのAuto Modeに含まれ、またEKSアドオンとして全てのEKS提供リージョンで利用できます。導入・運用に際してはリポジトリ内のREADMEやドキュメントを確認し、クラスタのKubernetesバージョン／ノードOS／RBAC設定との互換性やリソース要件を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: EKSクラスタ管理者、プラットフォームエンジニア、SRE、Kubernetes運用チーム
  • 利用シーン: ノード異常の自動検出と自動修復の有効化、カスタム条件の追加による独自の障害判定ロジック適用、オンプレや特殊環境向けの拡張
  • 運用効果: 手動監視・修復の削減、障害検知から修復までの時間短縮、運用の自動化と可観測性の向上（実装を直接確認・変更できることで信頼性向上）
  • 開発効果: OSS化によりバグ修正や機能拡張へ組織外からの貢献が可能になり、要件に応じたフォーク／カスタムビルドの作成が可能

技術的な注意点 ​

  • IAM権限／RBAC: エージェントはクラスタ内部でノード情報やノード条件を読み書きするためのKubernetes RBAC（ServiceAccount、Role/ClusterRole、RoleBinding）が必要です。EKSアドオンとしてインストールする場合はEKS関連の操作権限（eks:CreateAddonなど）が必要になる場合があります。詳細はリポジトリとドキュメントで確認してください。
  • リージョン制限: 記事によればAmazon EKSが提供される全リージョンでEKSアドオンとして利用可能です。ただし導入前に対象リージョンでのアドオン提供状況をAWSコンソールやドキュメントで再確認してください。
  • コスト: ソフトウェア自体はOSSで無償ですが、実行に伴うノード上のCPU/メモリ使用や、エージェントがCloudWatch等へメトリクス・ログを送る構成にした場合の監視・ログ取得コストが発生する可能性があります。運用ポリシーに合わせて収集先と保持期間を設計してください。
  • 互換性・前提: Kubernetesのバージョン、ノードOS（例: Amazon Linux 2、Bottlerocketなど）、アクセラレータ（GPU等）ドライバの有無で動作や検出項目が変わる可能性があります。リポジトリのサポート対象やリリースノートで互換性を確認してください。
  • ライセンス・貢献: ソースコードはGitHub上で公開されています。採用前にライセンス（例: Apache-2.0等）を確認し、組織のポリシーに適合するか評価してください。
  • 運用上の注意: 本番導入前にステージング環境でノード条件の発報とEKSの自動修復の連携動作を検証し、誤検知による過剰な修復アクションを防ぐための閾値やフィルタリングを検討してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026