Skip to content

2026年03月19日

[Rds For Sql Server] Amazon RDS Custom for SQL Server adds ability to view and schedule new operating system updates

概要

Amazon RDS Custom for SQL Serverで、RDS提供エンジンバージョン(RPEV)に対するOSアップデートを確認・即時適用・次回メンテナンスウィンドウへスケジュールできる機能が追加されました。APIおよびイベント通知で更新の把握と適用が可能です。

変更内容・新機能の詳細

RDS Custom for SQL ServerはRPEV(RDSが提供するエンジンバージョン:SQL ServerをプリインストールしたAMI)向けに、新たにOSアップデートの可視化とスケジュール適用の機能を提供します。顧客はDescribePendingMaintenanceActions APIで保留中のメンテナンス(OSアップデート)を確認でき、RDSイベント(RDS-EVENT-0230)をサブスクライブして新しい更新の通知を受け取れます。ApplyPendingMaintenanceAction APIを用いることで、検出した更新を即時適用するか、インスタンスの次回メンテナンスウィンドウに適用するようスケジュールできます。これにより、OSパッチの監視と適用をAPIベースで自動化・運用管理できます。機能はRDS Custom for SQL Serverが利用可能な全リージョンで提供されます。

影響範囲・利用シーン

  • 対象ユーザー: RDS Custom for SQL Serverを利用するデータベース管理者、SRE、運用チーム
  • 利用シーン: OSセキュリティパッチやOSレベルのバグ修正の確認・適用、パッチ適用の自動化ワークフローへの組み込み
  • 運用効果: アップデートの事前把握とスケジュール適用により、ダウンタイム計画の最適化やセキュリティ対応の迅速化が可能

技術的な注意点

  • IAM権限: DescribePendingMaintenanceActionsおよびApplyPendingMaintenanceActionの呼び出しに必要なrds:DescribePendingMaintenanceActions / rds:ApplyPendingMaintenanceAction等の権限を付与してください
  • リージョン制限: 記載のとおり、RDS Custom for SQL Serverが提供されているリージョンで利用可能です。未対応リージョンでは利用不可です
  • メンテナンスウィンドウ: スケジュール適用は「次回メンテナンスウィンドウ」に限定されます。インスタンス毎に設定されたウィンドウを事前に確認してください
  • ダウンタイム/再起動: OSアップデートは再起動を伴う場合があります。適用に伴う停止時間や接続影響を考慮して運用設計してください
  • コスト: 機能自体に追加料金は通常発生しませんが、再起動に伴う可用性低下や運用作業コストの影響があり得ます
  • 互換性/テスト: OSアップデートがSQL Serverアプリケーションやカスタムドライバに影響を与える可能性があるため、本番適用前に検証環境でのテストを推奨します
  • 通知設定: RDSイベントサブスクリプション(RDS-EVENT-0230)で通知を受け取る設定を行うと即時検知が可能です
  • API自動化: CI/CDや運用スクリプトからDescribe/Apply APIを呼び出して、定期的なチェックや自動スケジュールを実装できます

参考情報


[Bedrock] Minimax M2.5 and GLM 5 models now available on Amazon Bedrock

概要

Amazon BedrockにGLM 5とMiniMax M2.5のサポートが追加され、長文コンテキストやエージェント志向の複雑なワークフローに強いフロンティアクラスの大規模言語モデルが利用可能になりました。両モデルは選択されたAWSリージョンで提供されています。

変更内容・新機能の詳細

GLM 5はGLM 4.5のエージェント中心の系譜を継ぐフロンティアクラスの汎用LLMで、マルチステップ推論、数学(AIMEスタイルの問題を含む)、高度なコーディング、ツール拡張ワークフローを意識して設計されています。長いコンテキスト長をサポートし、複雑なエージェント実装やエンタープライズ用途の長時間の状態保持に向いています。MiniMax M2.5は“エージェントネイティブ”に設計されたモデルで、効率的な推論、タスク分解、現実世界の時間・コスト制約下での複雑ワークフロー完遂を重視しています。高い推論スループットと、トークン効率を改善する強化学習(RL)による最適化を組み合わせることで、主要なプロプライエタリ・フロンティアモデルと同等かそれ以上のタスク完了速度を目指しています。両モデルはAmazon Bedrockのモデルカタログに追加されており、BedrockのAPI経由で呼び出してツール連携やチェーン化されたエージェント設計に組み込めます。利用可能リージョンは限定されているため、導入前にドキュメントで対応リージョンを確認してください。

影響範囲・利用シーン

  • 対象ユーザー: 機械学習エンジニア、SRE、生成AIアプリ開発者、エンタープライズアプリケーション担当者
  • 利用シーン: 長い会話履歴や状態を必要とするエージェント、複雑なマルチステップ推論を要する自動化(計画・デバッグ・最適化)、高度なコード生成・検証、数学的問題解決や研究用途
  • 運用効果: より高速でトークン効率の高い推論によりエージェントレスポンスの改善とコスト効率化が期待できる。長コンテキスト対応によりセッション継続や履歴保持が容易になり、複雑なワークフロー自動化の実現が促進される
  • 導入制約: モデルは選択されたリージョンでのみ利用可能なため、リージョンでの可用性確認とデータ主権要件の検討が必要

技術的な注意点

  • IAM権限: Bedrockの呼び出しに必要なIAMポリシー(bedrock:InvokeModel など)を付与する必要があります
  • リージョン制限: GLM 5およびMiniMax M2.5は“select AWS Regions”で提供されており、すべてのリージョンで利用できるわけではありません。導入前に公式ドキュメントで対応リージョンを確認してください
  • コスト: 高性能モデルかつ長コンテキスト運用は推論コスト(トークン課金やリクエスト課金)に影響します。スループット向上がコスト効率に寄与する一方、長いコンテキストはトークン消費を増やすため設計での最適化が必要です
  • コンテキスト長: GLM 5は長コンテキストをサポートするよう設計されていますが、実際の最大トークン長やパフォーマンス特性はモデル仕様・リージョンによって異なるため事前に検証してください
  • 互換性・統合: Bedrockの既存API/SDKを通じて利用します。ツール呼び出し(tool-augmented workflows)やエージェントフレームワークとの統合設計を行う場合、APIの入出力フォーマットとレイテンシ特性を考慮してください
  • 性能留意点: MiniMax M2.5はRLによるトークン効率最適化と高スループットを謳っていますが、特定ワークロードでの性能は実測ベンチマークに依存します。プロダクション導入前にスループット、平均レイテンシ、品質評価を行ってください
  • データ保護: Bedrock経由で送る入力データはAWSのデータ処理方針に従います。機密データを扱う場合は暗号化・PII対策・リージョン選定を検討してください
  • モデル名: Bedrockでの呼称はドキュメントを参照のこと(例: "GLM-5" や "MiniMax-M2.5" など)。モデルIDやパラメータはドキュメント/コンソールで確認が必要です

参考情報


[Ec2] Amazon EC2 High Memory U7i-6TB instances now available in Asia Pacific (Malaysia)

概要

Amazon EC2のHigh Memory U7i-6tbインスタンス(u7i-6tb.112xlarge)がアジアパシフィック(マレーシア)リージョンで利用可能になりました。6TiBのDDR5メモリと448 vCPU、最大100 GbpsのEBS/ネットワーク帯域、ENA Expressを備え、SAP HANAや大規模インメモリDB向けに設計されています。

変更内容・新機能の詳細

u7i-6tb(u7i-6tb.112xlarge)はAWSの第7世代High Memoryインスタンスの一つで、カスタム第4世代Intel Xeon Scalableプロセッサ(Sapphire Rapids)を採用しています。主なスペックは6 TiB DDR5メモリ、448 vCPU、最大100 GbpsのEBS帯域(データ読み込み・バックアップの高速化)、最大100 Gbpsのネットワーク帯域、およびENA Expressのサポートです。これにより大量のメモリを要求するトランザクション処理やインメモリデータベースのスループットをスケールできます。特にSAP HANA、Oracle、SQL Serverなどのミッション・クリティカルなインメモリDBのワークロードに最適化されています。導入時はOS/カーネルやENAドライバー、データベース側の巨大ページ(hugepages)設定やメモリ割当て調整が必要になる場合があります。

影響範囲・利用シーン

  • 対象ユーザー: 大規模インメモリデータベース(SAP HANA、Oracle、SQL Server等)を運用するデータベース管理者、アーキテクト、SRE/運用チーム
  • 利用シーン: 大量のメモリを必要とするトランザクション処理、高速なデータロード/バックアップ、高スループットな分析処理やキャッシュ用途
  • 運用効果: 単一インスタンスで数TiBクラスのメモリを確保できるため分散化コストや複雑性を低減し、データベースのレスポンス改善と運用容易性の向上が期待できる

技術的な注意点

  • リージョン制限: 本発表はアジアパシフィック(マレーシア)リージョンでの提供開始を告知。他リージョンでの利用可否はリージョンごとに確認してください
  • インスタンス仕様: 6 TiB DDR5メモリ、448 vCPU、最大100 Gbps(EBS/ネットワーク)、ENA Express対応(ENA ExpressはOS/ドライバーのサポートが必要)
  • OS/カーネル/ドライバー: 大容量メモリやENA Expressを活用するために最新のカーネルやENAドライバー、必要に応じてHugePages設定やNUMA/メモリ割当て最適化を行ってください
  • ライセンス: 商用DB(Oracle、SQL Server等)はライセンス条件がインスタンスサイズやコア数で変わるため、ライセンス契約を事前確認してください
  • パフォーマンス設計: EBS帯域・IOPSやネットワーク帯域はワークロードに合わせてボリュームや設定を設計する必要があります(EBSスループット上限に依存)
  • コスト: 大容量インスタンスのためオンデマンド/リザーブド/スポット料金ともに高額。EBS転送や高速ストレージの利用で追加コストが発生します。総所有コスト(TCO)を評価してください
  • IAM権限: 起動/管理に必要なEC2関連権限(インスタンス作成、EBSボリューム割当、ENI/ネットワーク設定等)を事前に確認してください
  • バックアップ/スナップショット: 大容量メモリを扱うDBではスナップショット作成時のI/Oやバックアップウィンドウに注意。EBSスループットがボトルネックになる可能性があります

参考情報


[Bedrock] NVIDIA Nemotron 3 Super now available on Amazon Bedrock

概要

Amazon BedrockでNVIDIA Nemotron 3 Super(オープンなハイブリッドMixture-of-Expertsモデル)の利用が開始されました。エージェント型ワークロードや長時間のマルチステップ推論に適した、高速かつコスト効率の良い推論をマネージドAPI経由で利用できます。

変更内容・新機能の詳細

NVIDIA Nemotron 3 SuperはMixture-of-Experts (MoE)アーキテクチャを採用したオープンモデルで、重み(weights)、データセット、トレーニングレシピが公開されています。特に複数のエージェントが関与する長期の推論タスクや高度な推論・推論チェーン(multi-step reasoning)向けに設計されており、コンテキストを保持しつつ精度を維持することを狙っています。Amazon Bedrock上では、インフラ管理やモデルホスティング不要で単一のフルマネージドAPIを通じてNemotron 3 Superへアクセスできます。Bedrockはサーバーレス推論、ビルトインのセキュリティ制御、そしてOpenAI API仕様との互換性を提供しているため、既存のOpenAI互換クライアントやワークフローへの統合が容易です。利用可能リージョンは限定されているため、デプロイ前に対応リージョンを公式ドキュメントで確認してください。

影響範囲・利用シーン

  • 対象ユーザー: AIエンジニア、研究者、SRE、プロダクト開発チーム(マルチエージェントや長期推論を必要とする開発者)
  • 利用シーン: マルチエージェント対話システム、複雑なワークフローの自動化、長期コンテキストを伴う意思決定支援、チェーンオブソート推論や複数ステップのタスク完了
  • 運用効果: サーバーレスでスケールするマネージドAPIによりインフラ運用負荷が低減され、OpenAI互換APIにより既存コードの移行コストが小さくなる。MoEの特性により同等精度をより低コストで達成できる可能性がある

技術的な注意点

  • IAM権限: Bedrockの呼び出しには専用のIAM権限(例: BedrockのInvoke/Describe系アクションやリソースポリシー)が必要です。運用前に最小権限を検討してください。
  • リージョン制限: Nemotron 3 Superは限定されたAWSリージョンで提供されます。利用前に公式ドキュメントで対応リージョンを必ず確認してください。
  • コスト: サーバーレス推論の課金は呼び出し/推論時間/モデル別料金に依存します。MoEは計算効率が高い一方で、長いコンテキストや高スループットではコストが増加する可能性があるため、想定ワークロードでのコスト試算を推奨します。
  • レイテンシ/スループット: MoE特有のルーティングやエキスパートロードによるレイテンシ変動やコールドスタート影響が出る可能性があります。SLA/パフォーマンス要件に合わせて負荷試験を行ってください。
  • カスタマイズ/ファインチューニング: モデル本体やレシピがオープンである一方、Bedrock上でのファインチューニングやカスタムモデルのホスティング可否・手順はドキュメントで確認してください(Bedrockの提供機能による制約あり)。
  • セキュリティ/コンプライアンス: Bedrockはアクセス制御・ログ管理・暗号化等の機能を提供しますが、企業ポリシー(データ主権、監査要件等)に合わせた設計を行ってください。

参考情報


[ECR] Amazon ECR now supports pull through cache for Chainguard

概要

Amazon ECRのPull Through CacheがChainguardのレジストリを上流ソースとしてサポートしました。これによりChainguard由来のコンテナイメージをECR上にキャッシュし、可用性・セキュリティ機能(スキャンやライフサイクル適用)を利用できます。

変更内容・新機能の詳細

今回のアップデートで、ECRのPull Through CacheルールにChainguardの公開レジストリを上流(upstream)として設定できるようになりました。Pull Through Cacheとは、指定した外部レジストリからイメージをプルした際にECRにキャッシュし、以後のプルをECRのプライベートリポジトリ経由で行える仕組みです。Chainguardを上流にすることで、ユーザーは追加の同期ワークフローや外部ツールを導入せずに、ChainguardイメージをECR側で頻繁に同期・キャッシュさせることが可能になります。キャッシュされたイメージにはECRの機能(イメージスキャン、ライフサイクルポリシー、アクセス制御など)を適用でき、スケールやセキュリティ運用の一元化が図れます。仕様上は上流レジストリからの同期頻度を高める仕組みがサポートされており、アップストリームの更新を比較的短い遅延で反映できます。サービスは、Amazon ECRのPull Through Cacheがサポートされているすべてのリージョンで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: コンテナ運用者、プラットフォームエンジニア、セキュリティチーム
  • 利用シーン: Chainguardが公開するベースイメージやミニマルイメージを企業内のプライベートECRにキャッシュして利用する場面(CI/CD、ワークロードデプロイ、エッジ環境向け配布など)
  • 運用効果: 外部レジストリ依存を低減し可用性を向上、ECRの脆弱性スキャンやライフサイクルポリシーで供給側のセキュリティ管理を一元化できる
  • スケーリング効果: 大規模なフェッチ要求や複数リージョンでの配布時にオリジン負荷を削減し、レイテンシを改善できる
  • セキュリティ効果: ChainguardイメージをECR上でスキャン/アクセス制御できるため、ソフトウェアサプライチェーン管理が容易になる

技術的な注意点

  • IAM権限: Pull Through Cacheルールの作成・管理にはECRの操作権限が必要(例: ecr:CreatePullThroughCacheRule等)。実運用前に必要なIAMポリシーを確認してください
  • リージョン制限: Chainguard向けPull Through Cacheは「Amazon ECRのPull Through Cacheがサポートされているリージョン」で利用可能です。リージョンによって未サポートの場合がありますので事前確認を推奨します
  • コスト: キャッシュされたイメージのストレージ費用、イメージスキャン利用時のスキャン料金、及び初回同期や頻繁な同期によるデータ転送費用が発生する可能性があります
  • 同期挙動: 上流での削除やタグ更新が即時に反映されるわけではなく、ECR側の同期/キャッシュポリシーやライフサイクルによる管理が必要です
  • ネットワーク要件: 初回のフェッチや定期同期ではECRからChainguardの上流レジストリへアクセスするためのアウトバウンド接続が必要です
  • 既存ワークフローへの影響: キャッシュ後はイメージ参照をECRのエンドポイントへ切り替えることで運用負荷を下げられますが、タグ運用やイメージの整合性(ダイジェスト vs タグ)を設計しておくことを推奨します

参考情報


[S3] Amazon S3 Access Grants are now available in the AWS Asia Pacific (New Zealand) Region

概要

Amazon S3 Access Grants が AWS アジアパシフィック(ニュージーランド)リージョンで利用可能になりました。企業ディレクトリ(例:Microsoft Entra ID)や IAM プリンシパルと S3 データセットをマッピングして、企業アイデンティティに基づく自動的な S3 アクセス付与を可能にします。

変更内容・新機能の詳細

S3 Access Grants は、ディレクトリ上のユーザーやグループ(例: Microsoft Entra ID)や AWS IAM プリンシパルを、S3 上のデータセット(バケット、プレフィックス、オブジェクト単位の集合)にマップしてアクセス許可を付与・管理する機能です。これにより、個別のバケットポリシーや ACL を大量に管理する代わりに、企業のアイデンティティに基づいてスケール可能にアクセス権を付与できます。Access Grants はコンソール・API から作成・更新でき、組織内の既存の ID プロバイダと連携してエンドユーザーへ自動的に S3 へのアクセスを割り当てます。本リリースにより、この機能が AWS アジアパシフィック(ニュージーランド)リージョンでも利用可能になりました。地域別の完全な可用性は AWS Region Table を参照してください。

影響範囲・利用シーン

  • 対象ユーザー: クラウド/データプラットフォーム管理者、セキュリティ/IAM チーム、データサイエンティストやアナリスト
  • 利用シーン: 企業ディレクトリ(Azure AD/Microsoft Entra 等)と連携して、社員やチームに対して自動で S3 アクセス権を割り当てる(ハイブリッド環境やマルチアカウントでのデータ共有)
  • 運用効果: 権限管理の自動化により、許可設定の工数削減、人的ミスの低減、スケールしたアクセス制御の実現が可能になる

技術的な注意点

  • IAM権限: Access Grants の作成・管理には S3 の Access Grants に関連する API 操作の許可が必要です。具体的な IAM ポリシーは公式ドキュメントで確認してください
  • リージョン制限: 本発表で Asia Pacific (New Zealand) リージョンが追加されましたが、全リージョンで未対応の可能性があります。利用前に AWS Region Table で可用性を確認してください
  • コスト: 本機能自体の課金モデルは公式情報を確認してください。クロスアカウントアクセスやデータ転送、KMS(暗号化)などに伴う通常の料金が発生する可能性があります
  • 暗号化・KMS: 暗号化済みオブジェクトに対しては KMS キーのポリシーやキー許可設定も正しく構成する必要があります。Access Grants で付与しても KMS 許可がなければアクセスできません
  • 既存のアクセス制御との関係: バケットポリシー、ACL、オブジェクト所有権の設定や Service Control Policies (SCP) など既存の制約により、期待どおりにアクセスが付与されない場合があります。導入時に既存ポリシーとの整合性を確認してください

参考情報


[Ec2] Amazon EC2 M6in and M6idn instances are now available in Europe (London) Region

概要

Amazon EC2の第6世代ネットワーク最適化インスタンス M6in と M6idn が、AWS Europe (London) リージョンで利用可能になりました。高帯域・高IOPSを必要とするネットワーク集約型ワークロードのスケールに適しています。

変更内容・新機能の詳細

M6in/M6idn は 3rd Generation Intel Xeon Scalable プロセッサを搭載し、AWS Nitro System 上で動作するネットワーク最適化インスタンスです。最大200 Gbpsのネットワーク帯域(第5世代相当インスタンスの2倍)を提供し、EBS帯域は最大100 Gbps、最大400K IOPS を実現します。提供されるサイズはメタル含め10サイズで、最大128 vCPU・512 GiB メモリをサポートします。M6idn は最大7.6 TiB の高速・低遅延なインスタンスローカルストレージ(NVMe)を搭載しており、M6in/M6idn の 32xlarge と metal サイズは Elastic Fabric Adapter (EFA) をサポートします。典型的なユースケースとしては、高性能ファイルシステム、分散インメモリキャッシュ、キャッシュフリート、リアルタイム大規模データ解析、5G User Plane Function 等の通信系アプリケーションなど、ネットワーク性能とスループットを重視するワークロードが挙げられます。課金は Savings Plans、On-Demand、Spot で利用可能です。リージョン拡張により既存の複数リージョン(米国・欧州・アジア太平洋・カナダ・AWS GovCloud)でも利用可能になっています。

影響範囲・利用シーン

  • 対象ユーザー: ネットワーク集約型ワークロードを扱うクラウドエンジニア、SRE、データ基盤チーム、通信事業者(Telco)
  • 利用シーン: 高スループットのファイルシステム、分散キャッシュ(In-memory cache)やキャッシュフリート、リアルタイム大規模分析、5G UPF 等のネットワーク重視アプリケーション
  • 運用効果: ネットワーク帯域の増加(最大200Gbps)と高いEBS性能によりスループットとレイテンシが改善され、スケールアウト時のボトルネックを軽減できます
  • 導入判断: ローカルNVMe(M6idn)を有効活用できるワークロードや、EFAによる低レイテンシ通信を必要とする分散アプリケーションで特に有効
  • 購買/コスト影響: 高性能分だけインスタンスコストが上がる可能性があるため、Savings PlansやSpotの活用でコスト最適化を検討してください

技術的な注意点

  • IAM権限: インスタンス起動やEFA/ENI関連の操作には通常のEC2起動権限に加え、必要に応じてEFAやIAMロールの付与を確認してください
  • リージョン制限: 本アナウンスは Europe (London) リージョンへの追加を示しています。利用可能リージョンは記事内一覧を参照してください(東京等にも既に展開されているリージョンあり)
  • コスト: 高帯域・高IOPS性能はインスタンスコストおよびEBS使用量に影響します。EBSスループットやEFA利用時の別途料金、Spot/Savings Plansの利用可否を確認してください
  • EFA/ドライバ: EFA を利用する場合は対応AMI/カーネルとEFAドライバ(またはAWS提供の最適化AMIs)が必要です。EN A (Elastic Network Adapter) のサポートもOS側で要確認
  • インスタンスストレージ: M6idn のローカルNVMeはエフェメラル(インスタンス終了で消失)です。永続化する場合はEBSやS3への同期/バックアップ設計が必要です
  • EBS/ネットワーク設定: 最大EBS帯域やネットワーク帯域を活かすために、EBS最適化やネットワーク設定(ENI数、Enhanced Networking)を適切に構成してください
  • サイズ制約: EFAは32xlargeおよびmetalサイズのみサポートします。必要なvCPU/メモリ/ストレージ要件に合わせてサイズ選定してください

参考情報


[Ec2] Amazon EC2 C8a instances now available in the Asia Pacific (Tokyo) region

概要

Amazon EC2 のコンピュート最適化インスタンス C8a がアジアパシフィック(東京)リージョンで利用可能になりました。5th Gen AMD EPYC(コード名 Turin)を採用し、C7a 比で最大30%の性能向上と最大19%の価格性能改善を実現します。

変更内容・新機能の詳細

C8a インスタンスは最大 4.5 GHz の動作周波数を持つ 5th Gen AMD EPYC(Turin)プロセッサを搭載し、C7a に比べて最大で 30% 高い計算性能、最大 19% 良好な価格性能を提供します。メモリ帯域は C7a 比で約 33% 増加しており、レイテンシに敏感なワークロード(低遅延処理やスループット重視の演算)に適しています。Java ベースのアプリケーションでは GroovyJVM 実行時に最大 57% の高速化が報告されており、JVM ベースのレイテンシ改善効果が期待できます。インスタンスサイズは 12 種類(うち 2 種類はベアメタル)を用意し、Nitro System 上で動作します。想定されるユースケースはバッチ処理、分散分析、高性能コンピューティング(HPC)、広告配信、スケーラブルなマルチプレイヤーゲーム、動画エンコードなどの高い CPU 性能とメモリ帯域を必要とするワークロードです。課金・購入方法は Savings Plans、オンデマンド、スポットに対応します。実際の導入前には既存の C7a 等とのベンチマーク比較や AMI/ドライバの互換性確認を推奨します。

影響範囲・利用シーン

  • 対象ユーザー: クラウドエンジニア、SRE、HPC/バッチ処理担当、ゲーム/メディアワークロード担当者
  • 利用シーン: 低遅延かつ高スループットを必要とするコンピュート集約ワークロード(HPC、動画エンコード、広告配信、マルチプレイヤーゲーム、分散分析、バッチ処理)
  • 運用効果: C7a 比で高い単体性能とメモリ帯域によりレスポンス改善・スループット向上が期待でき、インスタンス台数削減やジョブ完了時間短縮による運用効率化が可能
  • コスト影響: 価格性能が改善(最大で約19%)しているため、同等性能をより低コストで実現できる可能性がある。ただし利用パターンにより Savings Plans/スポットの活用検討が必要
  • リージョン: アジアパシフィック(東京)リージョン(ap-northeast-1)で利用可能(AZ 配置はリージョン内で変動する可能性あり)

技術的な注意点

  • IAM権限: インスタンス起動には ec2:RunInstances などの標準的な権限が必要。専用のベアメタルや専有ホスト利用時は追加ポリシーが必要になる場合あり
  • リージョン制限: 発表時点で Asia Pacific (Tokyo) に追加されたため、他リージョンでは未提供の可能性あり。利用前に各リージョンの可用性を確認してください
  • AMI/ドライバ: Nitro、ENA(Enhanced Networking)や最新の NVMe/EBS ドライバに対応した AMI(最新の Linux カーネル推奨)を使用してください。古いカーネルやドライバでは性能が出ないことがあります
  • パフォーマンス最適化: CPU ピンニング、NUMA トポロジー最適化、JVM チューニング(ヒープ、GC、JIT オプション)やスレッド設定の調整を検討してください。ベンチマークで C7a との比較検証を行ってください
  • インスタンス制限: 新しいインスタンスタイプはアカウントごとの上限が低い場合があります。大量導入前にクォータ(インスタンス上限)の引き上げ申請を行ってください
  • コスト: Savings Plans、オンデマンド、スポットが利用可能。長期使用なら Savings Plans、バッチや柔軟なジョブはスポットの組合せでコスト削減可能

参考情報


[Inspector] Amazon Inspector expands agentless EC2 scanning and introduces Windows KB-based findings

概要

Amazon Inspectorがエージェント不要のEC2スキャン対象を拡大し、Windowsの脆弱性通知をKB(Knowledge Base)単位で集約するKBベースのファインディングを導入しました。これにより、エージェントをインストールしないまま幅広いソフトウェアとWindows OSの脆弱性を検出・優先付けできます。

変更内容・新機能の詳細

・エージェントレス拡張: EC2上のエージェント不要スキャンの検出範囲が拡大され、WordPress、Apache HTTP Server、Pythonパッケージ、Ruby gemsなどのアプリケーションや、Windows OSの脆弱性をエージェントをインストールせずに検出可能になりました。追加の設定は不要で、既存のInspector設定に対して自動的に新しいソフトウェアカテゴリのファインディングが配信されます。 ・Windows KBベースのファインディング: Windowsの脆弱性は個々のCVEではなく、MicrosoftのKB(パッチ)単位で集約したファインディングとして提供されます。各KBファインディングには、そのKBに含まれるCVEのうち最大のCVSSスコア、EPSSスコア、既知のエクスプロイト有無を表示し、該当するMicrosoft KB記事への直接リンクが含まれます。これにより「どのパッチを適用すべきか」「その優先度はどうか」が分かりやすくなります。 ・既存データの取り扱い: 現在Inspectorが出しているCVEベースのWindows OSファインディングは自動的にKBベースファインディングへ移行され、ユーザー側での追加アクションは不要です。 ・可用性: これらの機能はAmazon Inspectorが利用可能なすべてのAWSリージョンで利用可能となっています。 ・運用面のメリット: KB単位での集約によりパッチ適用の指示が明確になり、脆弱性の優先順位付けと修復作業の効率化が期待できます。また、エージェントレススキャンにより、エージェント導入が難しいシステムや短期間でのスキャン実施が容易になります。

影響範囲・利用シーン

  • 対象ユーザー: セキュリティチーム、IT管理者、クラウド運用者
  • 利用シーンまたは効果: エージェントを導入できない/したくないEC2インスタンスの脆弱性検出、Webアプリケーション(WordPress/Apache)や言語パッケージ(Python/Ruby)の脆弱性検出、Windowsのパッチ運用をKB単位で効率化
  • 運用効果: Windowsの関連CVEをKBで一括管理できるためパッチ対象特定・優先順位付けが容易になり、修復工数と誤対応を削減可能
  • 運用影響: 既存のCVEベースの通知やSIEM/自動化ルールはKBベースのファインディングに合わせてルールやマッピングを更新する必要が生じる場合があります

技術的な注意点

  • IAM権限: Inspectorを使用するための適切なIAM権限およびサービスロール(Inspectorでのスキャン実行権限や読み取り権限)を事前に確認してください
  • エージェント: Windows向けの新しい脆弱性検出はエージェント不要ですが、特定の詳細検査やカスタム要件には従来のエージェントベースの手法が必要なケースがあるか確認してください
  • リージョン制限: 記事の範囲では『Amazon Inspectorが利用可能な全リージョン』で提供されていますが、自アカウントのリージョンで有効化されているか確認してください
  • コスト: Inspectorの利用には料金が発生する場合があります。スキャン対象の量や頻度によってコストが変動するため、事前にInspectorの料金ページを確認してください
  • 既存CVEファインディングの扱い: 既存のWindows CVEベースのファインディングは自動でKBベースに移行されますが、通知形式やID(CVE→KB)変更に伴う自動化フローやダッシュボードの影響を確認し、必要に応じて更新してください

参考情報


[Config] AWS Config launches 75 new managed rules

概要

AWS Configは75件の新しいマネージドルールを追加しました。セキュリティ、耐久性、運用性などのユースケースをカバーし、アカウント単位や組織単位での有効化・管理が可能になりました。

変更内容・新機能の詳細

今回追加された75のマネージドルールは、AWS Amplify、Amazon SageMaker、Amazon Route 53、App Mesh、CloudTrail、S3、RDS、Lambdaなど幅広いサービスを対象としています。ルールはAWS ConfigコンソールやAPIから検索・発見・有効化・管理でき、組織全体へ適用するための「Organization managed rules」やConformance Packに組み込んでマルチアカウントガバナンスとして配布できます。ルールの例としては、証明書の透明性ログ設定、Amplifyのビルド設定確認、App Meshのヘルスチェック設定、ターゲットグループのプロトコル暗号化確認、SageMakerのジョブでの転送中暗号化や分離(isolation)チェック、タグ付け遵守、スナップショットのIAM認証有効化などがあり、セキュリティ(暗号化、認証、ログ)、運用(ヘルスチェック、ビルド設定)、管理(タグ付け、説明の有無)に関する統制を強化します。各ルールの詳細な説明と利用可能リージョンはConfigのマネージドルールドキュメントに掲載されています。加えて、これらのルールは既存の自動修復(Remediation)アクションやConformance Packと組み合わせることで、検出から自動対応までのワークフローに組み込めます。

影響範囲・利用シーン

  • 対象ユーザー: セキュリティ/ガバナンスチーム、クラウド運用(SRE/CloudOps)、クラウドアーキテクト、データサイエンス/機械学習チーム
  • 利用シーン: マルチアカウント環境での準拠性チェック(暗号化、タグ付け、ログ設定など)、サービス別のベストプラクティス適用チェック(Amplify、SageMaker、AppMesh等)、Conformance Packを使った組織全体ポリシー配布
  • 運用効果: カスタムルール開発の削減、検出範囲の拡大によるガバナンス強化、ルールを起点とした自動修復ワークフローの構築で運用負荷低減

技術的な注意点

  • IAM権限: AWS Configルールの作成/管理にはconfig:PutConfigRule、config:PutOrganizationConfigRule、config:PutConformancePack等の権限、組織単位で配布する場合はOrganizationsの管理アカウント権限や委任管理者設定が必要です
  • リージョン制限: 各ルールのサポートはリージョン依存です。利用前にマネージドルールのドキュメントで対応リージョンを確認してください
  • コスト: Configのルール評価ごとに課金されます。ルールを多数有効化すると評価コストが増加します。Conformance Packや自動修復により追加のリソース(Lambda実行、SSM操作等)が発生するとそれらにも別途コストがかかります
  • 既存リソースへの影響: 一部ルールは初回評価で多数の準拠違反を報告する可能性があるため、通知や自動修復をすぐに有効化する前にスコープを限定して試験的に展開してください
  • 自動修復連携: マネージドルール自体は自動修復アクションを必ず含むわけではありません。自動修復を行う場合は、AWS ConfigのRemediation(managed/unmanaged)設定を別途用意する必要があります
  • Conformance Pack: 新ルールはConformance Packに追加可能で、テンプレート化して組織全体に配布できます。Conformance Pack配布は管理者/委任管理者権限が必要です

参考情報

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