Nitro Systemとは、結局なんなのか

Nitro SystemはAmazon EC2の仮想化基盤を支える、AWS独自開発のハードウェアとソフトウェアの仕組みです。ホストプロセッサ上ではNitroハイパーバイザーが稼働し、その上にユーザーのVM（EC2）やアプリケーションが動作しています。

私が初めて Nitro Systemを認識したのはt3、c5のインスタンスが登場したタイミングでした。XenベースのインスタンスからNitroベースのインスタンスへは簡単に変更できないので、対応手順のブログを見ながら切り替え作業をした記憶があります。
また、当時は業務でお客様にEC2を提供する機会が多く、XenベースとNitroベースのインスタンスのスペック差からNitro Systemを意識するようになったのを覚えています。
しかし、Nitro Systemの情報は部分的にしか得られず、AWSがハードからカスタマイズしているのでEC2を起動しているサーバー内で通信速度が上がるようになっている、EBSの書き込み読み取り速度も上がる、程度の認識でした。

2025年になった現在、公開情報が増えた(と教えていただき感激した)ため、まとめます。

独自のチップを開発してきた歴史

AWSではさまざまな分野において独自のチップを開発してきました。
たとえば、下記です。

  • Graviton：コアコンピュート(EC2などの一般計算処理用)
  • Inferentia：機械学習「推論」処理用
  • Trainium：機械学習「学習（トレーニング）」処理用

その中でもAWSが最初に投資したのが Nitro System でした。

なぜAWSは独自のチップを作るのか？

理由は4つです。

  1. 自分たちのユースケースに特化した設計
    AWSは、自社のクラウド環境に最適化されたチップを設計することで、性能や電力効率を最大限に引き出しています。
    チップ設計には多大なコストと時間がかかることから、費用対効果のため幅広い市場で使える「汎用的な設計」が選択されることがほとんどです。しかしAWSは自社の用途に完全に絞り込んだ設計をすることで無駄な機能を排除しました。それにより、パフォーマンスと効率を極限まで高めているのです。
  2. スピードの向上
    AWSは、「チップの設計→製造→データセンターへ配備→お客様へ提供」までを全て自社で管理しています。このプロセスを持つことで、「コンセプトからデプロイまでの時間短縮」というユーザーへの提供スピードの強みを持てるのです。
    これが実現できているのはAnnapurna Labsの存在です。
    Nitro System の開発が始まったのは 2013年で、Annapurna LabsとAWSが協力し開発を行ないました。2015年にAWSがAnnapurna Labsを買収し、以降はAWS内製チップ開発チームとして機能しています。これにより、2017年にNitro Systemがc5インスタンスで初登場し正式リリースされるに至りました。
  3. イノベーション
    自社でチップを作ることで、従来の部門ごとの縦割りを打破できます。
    シリコン、マザーボード、ファームウェア、ハイパーバイザー、インフラすべてを1つの統合チームが設計・実装しているため、組み合わせ全体での最適化が可能となり、従来不可能だった革新が生まれています。
  4. セキュリティ
    NitroはAWSの運用環境に最適化されて設計されており、「そもそもアクセスできない」ことを前提としたゼロトラスト的なセキュリティモデルを実現しています。代表的な機能は下記です。
    • Hardware Root of Trust
      起動時にファームウェアが正しいことを確認できる仕組み
    • ファームウェアの起動時検証
      OSが立ち上がる前に、改ざんがないかチェック
    • 完全に閉じられたハイパーバイザー
      SSH及びリモート操作の不可、これによりAPI以外からの操作はできない
    • APIもすべて認証・認可・ログ付き
      全操作が追跡可能で、オペレーターでも顧客データにアクセスできない構造

Nitroが登場する前のシステム(Xen)

Nitroが登場する前、Xenというハイパーバイザーの上でカスタマーのインスタンスが動作していました。Xenは優秀で、代表的なものだけでも下記のような処理を行っています。

  • メモリ管理
  • CPUスケジューリング
  • デバイスのシミュレーション
  • ネットワークの中継（ENI接続 等）
  • セキュリティグループの適用
  • DNS・DHCP処理
  • フローログ（通信履歴の記録）
  • 帯域制限機能　等

また、完全なLinuxユーザースペースも持ち合わせていて、特権領域であるDom0が存在しています。これら全ての機能がホストCPUのリソースを消費していることが課題でした。言い換えると、EC2インスタンスの通信処理は全てソフトウェアで対応していたのです。
そのため、専用ハードウェアにこれらの処理を任せたいと考え、実現したのがNitro Systemです。

Linuxユーザースペースとは

Xenハイパーバイザーの管理領域（Dom0）上で動いていた LinuxベースのOSの通常のアプリケーション層のことです。
Xenはハイパーバイザーですが、自分自身ではすべての機能を直接持っていません。
ホストマシンの管理用にLinux OSを起動し、そこで各種処理を実行する仕様です。このLinux OSには、systemd、sshd、ユーザーレベルのツールやスクリプトなどがフルで存在しており、それらを「Linuxユーザースペース」と呼んでいます。

特権領域 Dom0 とは

Xenにおける最も重要な管理用の仮想マシンです。
Xenでは、すべての仮想マシンは「ドメイン」として扱われます。
その中でも Dom0 は唯一の特権を持つ管理用ドメインで、以下のような操作を担います。

  • 仮想マシンの起動／停止／管理
  • デバイスアクセス（NICやディスク等）の仲介
  • セキュリティポリシーの適用
  • コンソールやログイン処理など

LinuxベースのOSがDom0上で動作しており、そこから仮想マシン（DomU：一般ユーザー用VM）を管理します。
つまり、「Dom0」はハイパーバイザー上に存在する「管理者用のVM」であり、その中で動いているLinuxのユーザースペースが、間接的にユーザーのVM制御を担っていました。

Nitro System networking

最初にハードウェアへ処理を移管したのはネットワークでした。
VPCネットワークまわりの処理をXenから専用チップであるNitroカードに移し、処理効率と性能を大きく改善しています。

カードのインスタンス側には、PCIe風の接続部があり、そこから複数の仮想機能が提供されます。それぞれがインスタンス内の ENA（Elastic Network Adapter） として動作します。

ネットワーク側にはアダプタがあり、以下のような VPCの制御系処理をまとめて担当します。

  • ENIの接続
  • セキュリティグループの適用
  • フローログ
  • ルーティング
  • DNS
  • DHCP　など

この機能移管をした結果、ホストCPUの負荷が軽減され、ネットワーク処理が高速化かつ安定化しました。
また、最新のNitroカードではVPCで暗号化を有効にするだけ256ビットAESによる通信の暗号化を性能劣化なしに自動で実行できます。
そして、インスタンスから見えるのはENAのみです。

ENAは素晴らしい

ENAは最初、10Gbpsのネットワーク帯域から始まりました。その後25Gbps、100Gbps、そして200Gbpsとデバイスモデルとドライバーを変えずに帯域幅を増強しています。そのため、古いENAデバイスで動いていたAMIをそのまま使用しても、新しいENAデバイス上での動作が可能です。

HPC、機械学習ワークロードへの対応（EFA、SRDの登場）

HPC（高性能コンピューティング）や機械学習ワークロードでは、高帯域かつ低レイテンシが求められます。この要求に応えるため、EFA（Elastic Fabric Adapter） が開発されました。
名称はアダプターですが、通常のNICではなく「AWS独自の高速ネットワークアーキテクチャ」です。

EFAでは、AWS独自のプロトコルであるSRD（Scalable Reliable Datagram）を使用しています。SRDはUDPベースでありながら再送や順序制御などのTCPライクな信頼性を実現し、低レイテンシな通信が可能です。パケット単位でマルチパスルーティングを行い、輻輳やホットスポットの回避を行います。

下記の図であれば、従来のネットワークプロトコルでは左側のサーバーからスタートすると、右側のサーバーへと単一の経路を通って到達します。

この方式では輻輳や障害への反応が遅いという問題がありました。
SRDはこれに対して、サーバー間に存在する複数の経路を同時に使用します。輻輳を検出次第トラフィックを分散し、切り替えを実行します。
これにより、帯域幅を最大限活用しながらテールレイテンシを削減できるようになりました。

下記のグラフはX軸にCPUコア数、Y軸にスケーリング性能を示しています。

赤い線が理想値で、これは理論上の上限値となる、完璧なスケーリングの値です。
紫色の線は「EFAなし（SRD使用なし）」の値です。400コアあたりでスケーリングが頭打ちになり、やがて低下し始めます。
青色の線は「EFAあり（SRD使用あり）」です。EFAを使用することで、理論上の上限値に近い結果で線形にスケーリングを続けることができるようになります。
EFAの最初のバージョンでは、最大100Gbpsのネットワーク帯域をサポートしていました。次のバージョンでは200Gbpsの帯域に加え、レイテンシを30%削減しています。

ENA Express（マルチパス）

SRDは、EFAだけでなく汎用のENIネットワークにも拡張されました。
これがENA Expressと呼ばれる機能です。

通常のTCP通信はパケットの順序整合性を保つ必要があるため、1つのコネクションは1本の経路だけを使用します。そのため、以下のような課題が発生していました。

  • ネットワーク障害時は、コネクションの再確立を待つ必要があり遅延が大きい
  • 輻輳が発生するとパケットがドロップされ、TCPが通信速度を自動で下げる
  • 物理リンクの問題により、TCPが適切に処理できずパフォーマンスが低下

TCPの輻輳制御は多少のパケットロスには対応が可能です。しかしリンク断のような障害には弱く、コネクションタイムアウトを待ってから新しい接続を再確立し続行することになります。

そこでENA Expressでは、TCPトラフィックをNitroカードで一旦受け取り、SRDによって複数経路にパケットを分散させました。受信側でNitroカードがそれらを順序通りに再構成して、アプリケーションに渡す仕組みを採用しています。

その結果、アプリケーションやOS側では何の変更も加えないまま、SRDの利点とマルチパス通信の恩恵を受けることができるようになりました。
特に、次のようなワークロードで顕著な性能向上が見られます。

  • 分散ファイルシステム
  • インメモリデータベース
  • メディアエンコーディング処理

これにより単一フローの帯域幅が5Gbpsから25Gbps（5倍）に向上し、高負荷環境下でのインキャストベンチマークでは、最大85%の改善が見られました。

Nitro System storage

次にNitro Systemを適用したのはストレージの分野でした。
Nitroカードに移行し、NVMeデバイスセットを提供しています。NVMeは標準化されたドライバーを備えた非常に優れたプロトコルで、Nitroカードは片側にNVMeインターフェースを公開し、もう片側でそれをEBSのデータプレーンへと変換しています。
EBSボリュームで暗号化を有効化すれば、Nitroカード上で透過的に実行され、性能への影響は一切ありません。

そして、このストレージ処理でもSRDを使用しています。
ストレージへリクエストを送ると、そのリクエストはネットワーク上の複数のフローに分けてストレージサーバーへ送信されます。これにより、ストレージワークロードにおけるテールレイテンシを改善しています。2GbpsだったEBSの帯域は、2024年12月時点で最大100Gbpsの帯域と40万IOPSの提供が可能になりました。

ローカルストレージへの対応

また、Nitro Systemはローカルストレージにも対応しています。

SSDには、2つの重要な構成要素があります。
1つは、NANDフラッシュメモリです。ここにデータが保存されます。
しかし、このNANDには独特な性質があり、1バイトや1ビットだけを変更したい場合でも、直接書き換えることはできません。NANDではブロック単位での消去が必要であり、そのブロックサイズは残念ながら、通常メガバイト単位です。

この課題を解決するために存在するのが、2つ目の構成要素であるFTLで、以下のような機能を担っています。

  • 論理アドレスと物理アドレスのマッピング
  • ガベージコレクション（不要データの回収）
    • ファイルの変更時はファイル全体をコピーし変更したのち、古いデータを削除
    • 1バイトレベルの変更であってもメガバイト単位で実行
  • ウェアレベリング（書き込み寿命の平準化）
    • 書き込みを均等に分散（書き込み回数に上限があるフラッシュメモリの延命処理）

各SSDベンダーは独自にFTLを実装しています。
全て同じNVMe APIを使っていたとしても動作は少しずつ異なるため、予測できない動作が発生することが課題でした。（例：ガベージコレクションが悪いタイミングで走り、リクエスト処理が突如停止する　等）

このような不確実性に対応するため、FTLをNitroカード上に統合しました。

これにより、以下のような効果が得られています。

  • 最大60%のレイテンシ削減
  • 信頼性の向上
  • エフェメラルキー（短命鍵）による暗号化の適用

Nitroカード導入後のハイパーバイザー

ここまでの機能移行により、ネットワークとストレージ機能はNitroカードが処理を行うことでその結果、特権領域であるDom0やXenの負荷が大幅に軽減されました。

↓

こうしてすべてのI/Oをオフロードしたことで軽量なハイパーバイザーの設計が始まりました。
Nitroハイパーバイザーは、メモリとCPUの割り当てだけを行います。
SSHもsystemdもなく、ネットワークスタックも存在しないこのハイパーバイザーは、非常に小さくリソースをほとんど使いません。この設計により、ベアメタルのようなパフォーマンスを得ることができています。同じサイズのベアメタルインスタンスと仮想化インスタンスを比較しても、基本的にはほとんど性能の差がありません。

さらに、Nitroセキュリティチップの追加も行われました。
マザーボードには、ファンの回転速度や温度を測定するための各種コンポーネントが搭載されていますが、これらが常に 最新のファームウェアで動作することを保証します。

  • マザーボード上の フラッシュデバイスの内容を測定・検証
  • 上記が期待された状態かどうかを確認
  • 必要に応じて 通常経路外安全に更新を実施

この仕組みによって、管理・セキュリティ・モニタリングの責務をNitroカード側に集約し、そのうえで、軽量なNitroハイパーバイザーへと切り替えることが可能になりました。

↓

↓

Nitro System security

AWSにおけるセキュリティは「責任共有モデル」に基づいており、AWSはクラウドそのもののセキュリティに責任を持ちます。具体的には、下記です。

  • ホストソフトウェア
  • 仮想化レイヤー
  • サービスを運用する施設の物理的なセキュリティ

利用ユーザーは下記が責任範囲ではあるものの混乱が生じているのが現状であり、AWSはこれを「お客様のコード」と「お客様のデータ」を保護するという観点で捉えています。

  • VPCなどへの適切な設定
  • EC2のようなサービスにおいては、必要なセキュリティ設定を行うこと
    • セキュリティグループなどの設定
    • オペレーティングシステムを最新の状態に保つ

Dimension 1

「一体誰から守っているのか？」の回答は次の2者です。

  • 他のクラウド利用者（テナント）
  • クラウドプロバイダー自身（＝AWS）

これをAWSは「第1の次元（Dimension 1）」と呼んでいます。
そしてNitroは、この外部アクセスからユーザーのコードとデータを守る仕組みを構築しています。これはNitroの設計における根本的な思想です。

  1. 実行環境の物理的分離
    「ユーザーのコードがホストCPU上で実行される場所」と「主にNitroカード上で動作しているAWSのコード」の間は物理的に分離されています。
    この分離により、AWS側からユーザーの実行環境に介入することが不可能になります。
  2. 起動時検証（Measured Boot）
    システムの起動時には、Nitroセキュリティチップを搭載したNitroカードがマザーボード上のファームウェアとサーバー上のコンテンツを測定・検証します。この検証に合格すると、サーバーのストレージがアンロックされ、インスタンスが実行可能になります。
  3. ダウンタイムなしのソフトウェア更新
    ハイパーバイザーのソフトウェアを、無停止でライブアップデートが可能です。アップデートされているソフトウェアは以下のプロセスを経て、本番環境へ展開されています。
    • 世界中に分散したグローバルな開発チームによって構築
    • 複数チームによるコードレビューと包括的なテスト
    • 自動ビルドパイプラインによる暗号署名
    • EC2のデプロイシステムによる展開とデプロイ時の常時モニタリング
    • 異常検知時の即時ロールバック

※ただし、以下のような場合はライブアップデートができません
① ホストサーバーの再起動やハードウェア交換が必要な場合
メモリ障害など、物理ホストそのものに問題発生していたり、Nitroセキュリティチップやネットワークカードなどのハードウェアコンポーネントの更新・交換が必要

② インスタンス自身に「再起動」が必要な更新（OSカーネルレベル等）
ホストOSカーネルや一部のブートローダ関連コードの更新が必要

③予防的な再配置
ホストの一部コンポーネントに「兆候あり」とAWSが判断し、インスタンスを他ホストに移す処理が必要 （※基本的にはライブマイグレーションで可能ですが、インスタンスタイプや状況によっては一時停止が必要）

  1. ハイパーバイザーへの直接アクセスは不可能
    Nitroでは、ハイパーバイザーに対するリモートアクセスが一切存在しません。SSHサーバーがそもそもなく、管理者によるログインもできません。
    唯一のインターフェースは、ユーザーデータやコンテンツにアクセスする手段を持たない認証・認可・ログ付きのAPIのみです。

Dimension 2

Nitro Systemにおけるセキュリティの「第2の次元（Dimension 2）」では、ユーザーのワークロードを「信頼できる部分」と「それ以外」に分離するという考え方が採用されています。
この分離によって、以下のようなリスク低減が可能になります。

  • オペレーターによる誤操作・不正アクセスの制限
  • アプリケーションのバグを起因とするデータ漏洩の抑制

この分離が有効な例として、署名に使う秘密鍵を保護するケースがあげられます。
EC2インスタンス上で脆弱性のあるアプリケーションを動作させてしまった際、悪意あるコードによって鍵が読み取られてしまうリスクがあります。このような場面で役に立つのが、Nitro Enclavesです。

Nitro Enclaves とは

Nitro Enclavesは、EC2インスタンス内に作られる完全に隔離されたミニVMです。
「インスタンスの中にもう1つ、鍵付きの密室を作る」ような処理で、特徴は以下の通りです。

  • 永続ストレージなし（データは揮発性）
  • SSHなどの外部アクセス不可
  • 親インスタンスからも内部参照不可
  • 通信はごく限定された経路のみ

つまり、EC2のroot権限を使用しても中身は見えず、触れません。
EC2とEnclaveの間には限定された通信路だけがあり、限られたデータのやり取りのみが許されます。

Enclaveの利用には下記手順が必要です。

  1. Enclaves対応のEC2インスタンスを用意する（m6i, c6iなど）
  2. 専用のCLIやAPIを用いて、Enclaveを明示的に作成・起動する
    例) nitro-cli run-enclave –enclave-cid <CID> –memory <MB> –cpu-count <N>
  3. アプリケーションから、Enclaveに対して秘密鍵や処理対象データを送る

Enclaveは起動時に「認証報告書」という情報を生成し、中にはそのEnclaveで使われている公開鍵が含まれます。
この仕組みを使うことで、以下のような安全な流れが可能になります。

  1. 認証報告書を検証して「本物のEnclaveである」ことを確認
  2. 公開鍵でデータを暗号化し、Enclaveに渡す
  3. Enclaveにて復号を実施

この分離が活きる代表的なケースが、秘密鍵（署名用）・PII・機密アルゴリズムなど、本当に保護すべき資産のEnclaveへの格納です。
たとえアプリケーション側にバグがあったとしても、秘密鍵がEnclave内にあれば、外部からアクセスされることはありません。

セキュリティの「第2の次元」とは、こうした信頼性の分離を通じて、アプリケーションの欠陥や運用者の誤操作から最も重要なデータを隔離・保護するアプローチを意味します。

その他機能

  • UEFI Secure Boot（セキュアブート）
    通常、EC2インスタンスは AMI を元に起動されます。
    AMIは不変な起動イメージとして機能しますが、その中身が改ざんされていない保証は別問題です。
    そこで、オンプレミス環境などで「セキュアブート」を使っていたユーザーから、AWS上でも同じように整合性を確認しながらブートしたいというニーズが寄せられていました。
    この機能では、ブートローダーやOSカーネルの整合性チェックを行い、それをUEFIの変数に保存された値と比較します。そレガ一致した場合にのみ、システムはブートを続行します。
    この仕組みにより、たとえば以下のような攻撃を防ぐことが可能になります。
    • 再起動後にも残存するマルウェアや不正なブートローダー
    • 外部から書き換えられたOSイメージの起動
  • TPM（Trusted Platform Module）のサポート
    AWSでは、EC2インスタンスに対して標準的な TPM 2.0 インターフェースを提供しています。これは、インスタンスが起動するたびに「その起動プロセスの測定情報」をTPMに記録する機能です。
    ここでいう「測定」とは、OSのブートローダーやカーネルなど、インスタンスが起動する過程で読み込まれるソフトウェアの状態（ハッシュ値）をTPMに「記録する」ことを意味します。
    このとき、TPMには次のような情報が拡張（extend）されて保存されます。
    • 起動時のソフトウェアの整合性情報（ハッシュ）
    • インスタンスのプラットフォームID（CPUモデル、起動時構成 など）

      TPMに記録された測定値は、下記のように暗号的に安全なデータ生成に活用されます。
    • ドライブ暗号化ツールの鍵の復号に使う（例：LUKS, BitLocker）
    • 特定のインスタンス構成でのみ復号可能なデータを作る

      こうした使い方によって、「信頼できる構成で起動されたときにだけ、データの復号を許す」というセキュリティ制御の鍵になります。これはユーザーが開発したカスタムアプリケーションでも利用可能です。

Nitro System による EC2 インスタンス起動の流れ

① EC2コントロールプレーンから起動リクエストを送信

ユーザーが StartInstances などのAPIを呼び出すと、まずEC2のコントロールプレーンが受け取ります。このコンポーネントは、認証やインスタンスタイプ、AZ、Placement Groupなどをもとに、最適なホスト候補を選定します。

② Nitro Controllerにリソース割り当てを依頼

次に、コントロールプレーンはNitro Controllerに「このインスタンスをホストする準備をしてほしい」と依頼します。

③ Nitro Hypervisorがインスタンスの“殻”を作成

Nitro Controllerは、選ばれたNitro Host上のNitro Hypervisorに対し、指定されたvCPU数とメモリ量でインスタンスの「シェル（空の仮想マシン）」を用意するよう指示します。

④ Nitroカードにデバイス接続を指示

次に、Nitro Controllerは、Nitro Cards（VPC・EBSなどを担当）に対して、「このインスタンスにENA（Elastic Network Adapter）やEBSボリュームをアタッチしてくれ」と指示を出します。

⑤ Nitroカードがネットワーク・ストレージを直接接続

Nitroカードは、ネットワークとストレージの仮想デバイスをインスタンスに直結します。この構造により、I/O処理にハイパーバイザーが関与しない設計が実現されています。

⑥ 最終的な「起動」コマンドを発行

コントロールプレーンが「準備完了」と判断したら、Nitro Controllerに「インスタンスを起動してOK」と命令を出します。

⑦ インスタンスが起動し、ユーザーのOSが立ち上がる

Nitro Hypervisor が仮想マシンを起動。ファームウェアがアタッチされた EBS ボリュームを検出し、ユーザーのOSがブートされます。ここで、インスタンスが稼働状態に入り、ユーザーはアクセス可能になります。

この構成図は、ベアメタルインスタンスでも大きな差がありません。

Nitro System による EC2 インスタンス起動の流れ （ベアメタルの場合）

こちらも同様に、コントロールプレーンがあり、Nitroカードがあり唯一の違いは、Nitroハイパーバイザーが存在しないという点です。
その理由は、VPC、ネットワーク、EBSのすべての機能が、すでにNitroカード内に含まれているからです。つまり、ベアメタルであれ仮想インスタンスであれ、同じインスタンス、同じI/Oデバイスが利用され、見た目も使用感も変わりません。

Nitro System の拡張性

Nitro System の真の強みは、Linux や Windows にとどまらず、macOS を搭載したインスタンス（Mac mini）にまでその仕組みを拡張できることにあります。

たとえば、iOS や macOS 向けアプリの開発・ビルド・署名を行う開発者にとって、
オンデマンドで使える Mac インスタンスは非常に魅力的な存在です。
ですが、ここで注目したいのは「Macが使えるようになった」こと自体ではありません。

AWS はこれを実現するために、以下のような仕組みを採用しています。

  • Nitro Controller をそのまま活用
  • Thunderbolt to PCIe Bridge を用いて、Mac mini を Nitro に接続
  • Mac mini を EC2 の VPC 内に組み込む

この構成により、Mac であっても API 経由の起動・停止、セキュリティグループ、VPCルーティング、IAM連携など、他のEC2インスタンスと同様の操作性と拡張性がそのまま提供されます。
公式でも以下のように説明されています。

“And now we have an instance that looks and feels like any other, but is running in your VPC with the benefits of EC2.”

では、macOS を搭載した物理Macにも関わらず、なぜ他の EC2 と「モニタリング機能が同一」なのでしょうか？
その理由は、Mac mini であっても Nitro Controller によって完全に制御されているためです。たとえば以下のような機能が、他のインスタンスと同様に Mac インスタンスでも利用できます。

  • CloudWatch によるリソースメトリクス（CPU、ネットワーク、ストレージ）の取得
  • CloudTrail による API 操作ログの記録
  • ステータスチェック（ハードウェア障害やネットワーク異常の検出）
  • 通知や自動再起動などのイベント処理

つまり、Nitro System に統合されたマシンであれば、OSが何であっても運用面の共通化が可能になるのです。

参考資料

AWS re:Invent 2024 – Dive deep into the AWS Nitro System (CMP301)：https://www.youtube.com/watch?v=YKZbNcOU77c

ホワイトペーパー：https://a.co/hYWhsH9

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

PAGE TOP