![[レポート] 今年も AWS Nitro を深掘りする | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP302 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2021/11/eyecatch_reinvent2021_sessionreport.png)
[レポート] 今年も AWS Nitro を深掘りする | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP302 #reinvent
コンバンハ、千葉（幸）です。
AWS re:Invent 2021 の残照を追うが如く、以下セッションを視聴したのでレポートにまとめます。
| 項目 | 値 |
|---|---|
| セッションタイトル | Powering next-gen Amazon EC2: Deep dive on the Nitro System |
| スピーカー | Ben Serebrin |
| セッションレベル | Advanced - 300 |
| セッションID | CMP301 |
セッション概要はこちら。
The AWS Nitro System is a rich collection of building block technologies, including AWS-built hardware offload and security components, that is powering the next generation of Amazon EC2 instances with an ever-broadening selection of compute, storage, memory, and networking options. In this session, dive deep into the Nitro System, review its design and architecture, explore new innovations to the Nitro platform, and see how it has made the seemingly impossible, possible.
（機械翻訳）
AWS Nitro Systemは、AWSが構築したハードウェアオフロードとセキュリティコンポーネントを含む豊富なビルディングブロック技術のコレクションであり、コンピュート、ストレージ、メモリ、ネットワークのオプションをますます広げて、次世代Amazon EC2インスタンスを強化しています。本セッションでは、Nitro Systemを深く掘り下げ、その設計とアーキテクチャをレビューし、Nitroプラットフォームの新たなイノベーションを探求し、不可能と思われることを可能にした方法をご紹介します。
AWS re:Invent 2020 の同名のセッションレポートを以下に書きましたので、合わせてご覧いただくと理解が深まるかもしれません。
本エントリでは以下の書き分けをしています。
- 書き言葉：セッションの要約
- 話し言葉：筆者（わたし）によるコメント
セッションはすでに YouTube でも公開されていますので、イベントページからでなくとも視聴ができます。
セッションスライドやスクリプトが欲しい場合にはイベントページから確認しましょう。
先にざっくりセッションのまとめ
今回のセッションは以下のアジェンダからなります。
- Nitro overview
- Increasing breadth of offerings with Nitro
- Enhancing performance with Nitro
- Innovating for instance longevity
- Raising customer's security bar
AWS re:Invent 2020 のセッションと比べてボリュームが大きくなっていたかなという印象です。また、新し目のトピックである Xen on Nitro と Nitro TPM については厚めに取り上げられていました。
1. Nitro overview
例年お馴染みの Nitro の概要が紹介されます。基本的なコンポーネントの紹介が主なので、従来からセッションを視聴していた人はサラッと眺めましょう。
Nitro コンポーントのアーキテクチャ図の新しいものが提供されたのは嬉しいところです。
2. Increasing breadth of offerings with Nitro
Nitro によって広がった提案の幅、とでも訳せば良いでしょうか。
EC2 のインスタンスタイプがすごいペースで増えていますが、それを支えているのは Nitro だよ、という話です。
CPU、メモリ、アクセラレータなどさまざまな機能が Nitro でモジュール化され、その組み合わせによって様々な用途に適したインスタンスタイプが提供されています。
3. Enhancing performance with Nitro
Nitro によるパフォーマンスの向上、というテーマです。
モジュール化されたことによるネットワーク、ストレージ、ローカル SSD などの性能の向上が示されます。
また、ライフサイクルイベントのスピードアップということでメタルインスタンスのローンチ速度の向上、Nitro ファームウェアのアップデートが取り上げられます。
4. Innovating for instance longevity
インスタンスの寿命を伸ばすためのイノベーション、具体的には Xen on Nitro のテーマが取り上げられます。
古いインスタンスタイプをホストする物理ハードウェアの管理が問題となる中で、そこで使われていたハイパーバイザーXen を丸ごと Nitro でエミュレートして動かしてしまおう、というものです。
利用者側にインスタンスタイプの最新化を強制することなく継続利用を提供する試みです。以下エントリもあわせてご参照ください
5. Raising customer's security bar
カスタマーのセキュリティレベルを向上させる、というテーマで、Nitro TPM とセキュアブートが取り上げられます。
Nitro TPM が発表された際に以下のエントリを記載したのですが、そもそも TPM とはなんぞやというところが理解し切れていませんでした。
このセッションでは TPM 自体にもディープダイブされているので理解が深まりました。
……と、いうことでここからセッションレポート本文の開始です。
1. Nitro overview
Nitro とは何か
- 2017年11月にローンチ
- 2013年から開発されていた
- 専用ハードウェアとソフトウェア
- AWS 開発のカスタムハイパーバイザー
- 新たなインスタンスは Nitro を使用してローンチされている
Nitro を構成する 3 つのパーツ
- Nitro カード
- VPC ネットワーキング
- Amazon EBS
- インスタンスストレージ
- システムコントローラー
- Nitro セキュリティチップ
- マザーボードに統合されている
- ハードウェアリソースを防御
- ハードウェアの root of trust
- Nitro ハイパーバイザー
- 軽量なハイパーバイザー
- メモリとCPUの割り当て
- ベアメタルのようなパフォーマンス
Nitro のコンポーネントを深掘り
Nitro カード
- Nitro カード for VPC
- ENA コントローラー
- VPC データプレーン
- カプセル化やセキュリティグループ、帯域制限、ルーティング
- Nitro カード for Amazon EBS
- NVMe コントローラー
- Amazon EBS データプレーン
- 暗号化サポート、リモートストレージプロトコル NVMe
- Nitro カード for インスタンスストレージ
- NVMe コントローラー
- インスタンスストレージデータプレーン
- 転送中の暗号化、上限、ドライブのモニタリング
- Nitro カードコントローラー
- 受動的な API エンドポイントの提供
- Nitro カード、Nitro ハイパーバイザー、Nitro セキュリティチップのコーディネート
- ハードウェアのコントローラー
- root of trust
- 指標と証明の提供
これらの各機能が「Nitro カード」というコンポーネントでまとめて表されることもあります。
インスタンスのゲスト OS から EBS ボリュームやインスタンスストレージは通常の NVMe ストレージとして見えますが、それは Nitro カードが橋渡し役となってそれぞれのデータプレーンとやりとりすることで実現しています。
VPC においても同様の考え方で、ゲストOS は ENA ドライバー経由で Nitro カードと接続されており、VPC SecuriryGroup などの VPC 上で必要となる機能の提供を受けています。
Nitro セキュリティチップ
- 不揮発性ストレージへのすべてのI/Oを トラップ するカスタムマイクロコントローラー
- Nitroコントローラがハードウェアの監視、システムファームウェアの検証および更新のために使用
- シンプルなハードウェアベースの root of trust のビルディングブロック
Nitro ハードウェアの信頼の基点
- 全ての不揮発性ストレージへの書き込みアクセスはハードウェアでブロックされる
- レガシーな要素がなく、Nitro カードへのオフロードによるシンプルさ
インスタンスから物理ハードウェアへは手が出せない、ということですね。
Nitro アーキテクチャ全容
お待ちかねの新しい Nitro アーキテクチャ図が提供されました。
画面右側が物理ハードウェアであり、Nitro ハイパーバイザーによりインスタンスが稼働している様子が表されています。
ハードウェアは Nitro コントローラーと PCIe バスでつながっており、インスタンスはそこを経由して Nitro カード及び各種データプレーンとやり取りする、という様子が目に浮かびますね。
2. Increasing breadth of offerings with Nitro
Nitro のモジュールアーキテクチャ
先程見たような Nitro アーキテクチャの優れているところはさまざまなコンポーントを組み合わせることができ、プラグアンドプレイにより多様なシステム構成が可能である、とされます。
Nitro カードも様々な世代、速度があるそうです。
それらにより提供される様々なインスタンスタイプが紹介されます。
Nitro のモジュール性：CPUの選択
物理ハードウェアのメインボードが持つ CPU の種別ごとに以下が取り上げられました。
- M6i（Intel）
- M6g（Graviton）
- M6a（AMD）
Nitro のモジュール性：メモリ
モジュール化されているのは CPU だけでなく、メモリの拡張により大きなメモリサイズのインスタンスも提供されています。
X2i なんてインスタンスあったっけ？と思いましたが、以下のシリーズがありました。
- X2iezn（利用可能）
- X2idn（comming soon）
- X2iedn（comming soon）
Amazon EC2 X2i Instances – Compute –Amazon Web Services
Nitro のモジュール性：アクセラレータ
他にも GPU 、ML accelerators もモジュール化されたものとして紹介されています。Nitro はこういったコンポーネントをプラグアンドプレイで使用するとのこと。
3. Enhancing performance with Nitro
Nitro パフォーマンスの成長
Nitro のパフォーマンスのモジュール性
ここまで何度も Nitro アーキテクチャが出てきましたが、これで最後です。最後に取り上げられるのは Nitro コントローラーで、このコントローラーも複数世代、種類が用意されています。
ホストマシンは Nitro コントローラーに必要な機能をオフロードすることで CPU やメモリを自身のために最大限使用でき、各種パフォーマンスの向上に繋がってきました。
Nitro パフォーマンスの進化：ネットワーク
- Nitro カードのアップグレードにより帯域幅が向上
- カスタマーはドライバーのアップグレード無しで ENA パフォーマンスの向上を享受できる
Nitro パフォーマンスの進化：ストレージ
- ストレージ帯域幅は需要が大きい領域
- Nitro が提供するのは標準的な NVMe インターフェイスであるため、カスタマーからは隠蔽された状態でデザイン変更を繰り返すことができた
Nitro パフォーマンスの進化：ローカル SSD
- 低レイテンシとレイテンシのばらつきを抑えた新しいコンポーネント Nitro SSD
- 低遅延、低ジッターが求められるワークロード向け
セッションの中で「近日中に Nitro SSD に幾つかの機能が搭載される予定」というコメントがありました。2022年2月現在それに該当する発表はない（はずな）ので、これから発表されることでしょう。楽しみですね。
Nitro ライフサイクルイベントの加速
メタルインスタンスのローンチの加速
- メタルインスタンスはカスタマーにハードウェアへのダイレクトアクセスを許可する
- 独自のハイパーバイザーが必要なケース、ライセンス上の理由などで選択
- 従来のメタルインスタンスは起動までに数分かかる
- 需要の急増に対応するためにはマシンのウォームプールを常時稼働させる必要がありリソースの無駄遣い
メタルインスタンスを選択する必要があるカスタマーにとって、起動まで時間を要することが課題としてありました。
Nitro によってその速度は改善されており、今では多くの場合 1 分未満で起動するようになったとのことです。
Nitro ファームウェアアップデートの加速
- 定期的なソフトウェア更新により Nitro システムを最新の状態に保つ
- Nitro のアップデート中もインスタンスは稼働し続ける
- ゲストインスタンスへの影響を最小限にしシームレスにハイパーバイザーをリフレッシュ
- 中断時間は限りなく小さくなっており、C/M/R といった標準的なインスタンスでは一秒未満で済む
インスタンスが稼働し続けたままその基盤となるシステムに更新が入る、というのは驚きです。とは言えごく短時間のストレージ/ネットワークへのアクセスの中断が入るとのことだったので、それがどのタイミングで行われるのかが少し気になりました。
4. Innovating for instance longevity
ハードウェアより長生きするインスタンス
- 旧世代のインスタンスは引き続き多くのカスタマーに利用されている
- 数百万のインスタンスが Xen ハイパーバイザーと EOL のハードウェア上で稼働している
- M1.small は 2006年8月にローンチされ、それ以降もさまざまな種類が発表された
15年前に登場した M1 タイプをいまだに利用しているカスタマーもいるとのことです。
旧世代のインスタンスへの対応
- ハードウェアの老朽化、EOLを迎える問題がある
- 製造ラインが存在せず交換用のチップを用意できないものもある
- EC2 はカスタマーにインスタンスタイプの移行を強制したくない
「EC2」が主語になっているのがちょっとオシャレですね。
古いインスタンスへの革命的なソリューション
- Nitro ハイパーバイザー上で Xen をエミュレート
- Nitro システムにインターフェースとして機能するレイヤを追加し、OS やドライバからは従来と同じように見える
- カスタマーは再起動するのみでよく、アップグレードは必要ない
「ストレージを SRD に変更する（？）時にもストレージから見えるインターフェースは変更しなかった」という発言があり、SRD とはなんぞや？というのが気になりました。これは Scalable Reliable Datagram と呼ばれるネットワークプロトコルで、ストレージ関連では io2 Block Express volumes で使用されるようでした。
SRD については以下記事の説明が分かりやすかったです。
Xen on Nitro のカスタマーへのメリット
- セキュリティ
- 強力な分離とセキュリティアップデートを Nitro に収斂
- 安定性
- 新しいコンポーネントによるハードウェアのリフレッシュ
- メンテナンス頻度の軽減
Nitro が簡単にモジュール化でき、簡単にセキュリティ確保できるよう設計されていたため Xen on Nitro に舵を切ったとのこと。Xen と Nitro は同じセキュリティレベルをセットしているものの、Nitro の方がよりモダンでセキュリティレベルを保ちながらイノベーションを起こすことが容易である、とのことです。
新しいハードウェアへの移行
- 標準的なメンテナンスプロセス同様に、再起動スケジュールの2週間前に通知を行う
- Xen on Nitro への移行が一度で済むようにしており、一つのインスタンスで複数のメンテナンスは発生しない
通常のメンテナンスと同様に、再起動を行うだけで Xen on Nitro への移行が行われます。
旧世代のインスタンスをご利用でインスタンスのメンテナンス通知が届いたあなた、もしかしたらあなたのインスタンスは Xen on Nitro に移るのかもしれません。
5. Raising customer's security bar
ハードウェアとソフトウェアの防御レイヤ
- Nitro セキュリティチップ
- ファームウェアとソフトウェアを保護する
- Nitro ソフトウェアは署名され検証されている
- UEFI セキュアブートと Nitro TPM
- 仮想マシンとメタルインスタンスでバイナリをセキュアに保つ
Nitro セキュリティチップは AWS が責任を持つ領域のセキュリテイ向上に寄与し、UEFI セキュアブートと Nitro TPM は違ったメカニズムでカスタマーにセキュリティを提供するものである、とのことです。
セキュアインスタンスブート
- カスタマーはゲストイメージが改竄された場合の検知が必要でありイメージが変更されていない場合のみブートを許可する
- AMI は ハードドライブの初期コピー
- インスタンス起動時にブートドライブに AMI をコピーする
- これは 改竄不可のためセキュア
- 再起動時にはブートがインスタンスストレージから行われるため OS やバイナリがマルウェアに侵害されないようにする必要がある
AMI からのローンチ時には改竄されていないことが担保されるためセキュアであるものの、以降の起動時にはイメージが改竄されていないことを担保する手段が別途必要である、と理解しました。
このセキュアインスタンスブートをどう実現するか、がこの章のテーマです。TPM と UFEI セキュアブートについて取り上げられた後、まとめとしてセキュアインスタンスブートが再登場します。
TPM にディープダイブ
セキュアブートプロセスのコンポーネントである TPM （trusted platform module）について語られます。
- 標準化されたチップでほとんどの物理的なマシン、クラウドマシンに搭載されている
- 役割は小さく抑えられておりプラットフォームための小さな暗号化を行う
- Identity：
- TPM自身、及び搭載されたプラットフォームを識別するためのID
- TPM ベンダーにより発行される暗号化された署名のようなもの
- Secrets：
- ハードディスクやリモートボリューのストレージキーといったシークレットを保持可能
- 特定の条件を満たした時のみ提供する
- PCRs：
- Platform Configuration Registers
- システムブートの条件を評価するために用いられる
上記の画像では EC2 インスタンスのシンプルアイコン（オレンジの四角で線が飛び出ている）と同じものが使われているのがややこしいですが、ここでは TPM を表すアイコンとして使われているようです。
TPM の Platform Configuration Registers (PCR)
TPM のコンポーネントの一つである PCR について取り上げられます。
- TPM はバージョンが 1.x でも 2.0 でも 24 の PCR を持つ
- PCR はプラットフォームのブート時のログの暗号化ハッシュを保存するために用いられる
- 直接書き込みはできず、拡張のみができる
- レジスタに値が書き込まれると古い値を取得し、新たな拡張の値と連結してハッシュを生成し、新たな値となる
- 追記型のログとして機能し、過去の履歴を改竄できない
- システムリセットに伴い値はリセットされる
シークレットの保護に PCR を使用する
PCR が拡張型のログであることを利用し、暗号化キーを Seal（封印）することに用いる例が紹介されます。
- ブート時に同じシークエンスを辿るのであれば PCR の値は同一になる
- それを利用して TPM がシークレットをハンドリングするためのルールやポリシーを設定できる
- 例えばディスク暗号化キーを今の PCR 0 と PCR 2 の値で封印する、とすれば違ったシークエンスでブートされた状態ではそのキーを使用できない
「24 ある PCR は番号ごとに BIOS や OS など何を測定するかが決まっているので興味があれば調べてみてね（意訳）」という話があったので調べてみたところ、典型的な PC クライアントの割り当ての例、ということで以下が見つかりました。
物理的な TPM から Nitro TPM へ
Nitro TPM が Coming soon であることが述べられます。Nitro TPM は TPM 2.0 と同じように動作するものであり、EC2 インスタンスにおいて以下のユースケースを利用可能にするものだとされます。
- フルドライブ暗号化
- Microsoft BitLocker
- Linux Unified Key Setup (LUKS)
- DM-Verity
- Attestation
インスタンスからは TPM 2.0 のインターフェースとして見え、インスタンスのライフサイクルイベント（ハイバネーション、停止、起動など）に合わせて透過的に動作するとのことです。
UFEI セキュアブート
続いて UFEI セキュアブートについて取り上げられます。これは現時点では EC2 では対応しておらず、Nitro TPM の登場によって対応が予定されているものです。
EC2 のブートモードについて詳しく考えたことがなかったのですが、2021年3月に UFEI がサポートされ、現在では2種類存在するようでした。
- UFEI セキュアブートフローはブートローダーが既知の機関によって署名されたものであることを保証する
- 署名されたブートローダー（Grub2など）を UFEI に保管された証明書で検証
- 検証が失敗したらバックアップブートローダーにフォールバックするか停止する
EC2 インスタンスでは UFEI バイナリが EC2 自身から提供され不変である、とされています。
まとめ：セキュアインスタンスブート
ここまで見てきた TPM と UFEI セキュアブートを組み合わせてセキュアインスタンスブートが実現されます。
- ゲスト UEFI バイナリが EC2 により配置される
- UEFI セキュアブート
- UEFI がブートローダーのシグネチャを検証する
- もし検証が失敗したら他のブートローダーを検索する
- UEFI がブートローダーのシグネチャを検証する
- Nitro TPM により計測されたブート
- ブートローダーがカーネルを測定し PCR に書き込む
- OS が Nitro TPM ブートボリュームの暗号化キーを Unseal するよう試みる
- PCR がマッチしなければ Unseal できない
- ブート
質問タイム
字幕を見ながら自分なりに解釈しましたが自信はあまりないので雰囲気だけ掴んでください。
- インスタンスが物理マシンを移動した場合、Nitro TPM の暗号化ペイロードは追従するのか？
- はい。インスタンスが別のマシンで再起動しても、同じ暗号化アイデンティティを持ちます
- Nitro Enclaves の内部で GPU は利用できるのか？
- Nitro Enclaves はメインインスタンスから隔離された空間を提供しセキュアに維持するために使用される
- ソケットインターフェイスのみが唯一の出入り口である
- そのため Nitro Enclaves 自身に GPU が与えられるとは思わない
- メインインスタンスの一部であることには変わりなく、データのやり取りには責任を持つ必要がある
- Nitro TPM と Nitro Enclaves のユースケースの違いは
- どちらもセキュリティのレベルを上げるという似た目的を持っている
- Nitro TPM はブートフローのセキュアな実装をもたらすもので物理領域にも存在する
- 既存の技術をインスタンスの内部でも動作できるようにするもの
- Nitro Enclaves は新しいプログラミングモデルと少し違った形で行う
- 通常のセキュアブートではカーネルを起動させた後、すべてが安全でセキュアであるかはカーネルに依存することになり磐石とは言えない
- OS から隔離された空間の作成によりセキュアさを保つ
- attestation モデルにより隔離された空間のセキュアさが確立されるため、ゲスト OS の信頼性の磐石さを考慮しなくても良くなる
- 設計の切り口が異なる
- ホストを共有する複数のインスタンスがネットワークも共有することがどこで公開されているか（？）
- インスタンスタイプのテーブルを見ると同一ファミリー内でサイズが高くなるほど帯域幅が増えることが分かり、これが共有していることを示す
- 帯域幅のリミットが設けられているためホストを共有する隣人の影響を受けることはない
- 帯域幅なのか bps なのか？詳しくないがインスタンスの公平性を保つための複雑なリミッターがたくさんある
- Xen エミュレーションが行われる際にインスタンスタイプは変わるか
- 変わらない。ハードウェアが変わるだけ
- ハードウェアが Xen エミュレートされたものかどうか判別できるか
- 分かりません。エキスパートに聞いてみましょう
質問に出てきた Nitro Enclaves については以下をご参考ください。
終わりに
Nitro にディープダイブするセッションのレポートでした。
Nitro のアーキテクチャ図、Xen on Nitro、Nitro TPM と、これまでの同名セッションには無い切り口での情報が満載で大ボリュームでした。
セキュアブートなどこれまで意識したことが無い領域についても多分に触れられていたため読み解くのに苦労しましたが、そのぶん理解が深まった気がします。
Nitro TPM と UEFI セキュアブートについては 2021年12月23日にポストされた以下記事でも詳しく取り上げられていますので、あわせて読むことをお勧めします。
EC2 を利用する上でその土台の仕組みは知らなくても困らないのですが、一年に一回くらいは思いを馳せてみてはいかがでしょうか。
以上、 チバユキ (@batchicchi) がお送りしました。
![[Update] AWS Launches new version of Nitro System : Nitro v5 #reInvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_new-service.png)
![[レポート]ゼロ特権操作: データにアクセスせずにサービスを実行する #SEC327 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
