【AWSがベアメタルインスタンスを提供していなかった理由】

「AWSがベアメタルインスタンスを提供していなかった理由」


Nitro System (ニトロではなくナイトロと読む)と呼ばれる仕組みがキーだったらしい。

きっかけは、AWS が Mac OS のインスタンスを提供していること。それを可能としている仕組みが Nitrro であり、Mac OS は Mac mini 上で稼働していることがAWSの説明にかかれていたことだ。

Mac OS は仮想環境での提供は認めていなかったはずなので、ベアメタルとして提供する必要があるのだろう。　では、Nitroとは？　と思ったところ。。。

このシステムのおかげで、EC2の仕組みを維持しつつ、ベアメタルサーバが提供できるようになったという。
その結果として、VMware Cloud on AWS が可能になり、さらに、MacOSインスタンスも提供するようになったようだ。

詳細はよくわからないので推測だが。。。

この Nitro Sysytem とは、従来のAWS用ハイパーバイザが「担ってきた機能」をハイパーバイザ(ユーザ向けのサーバでもある)とは別ハードで行うためのものであるようだ。　この「担ってきた機能」というのはおそらく、サーバがAWS独特のインフラ(ストレージやネットワーク)にアクセスするための機能なのだろう。

AWSはストレージはEBSであるし、ネットワークもおそらく独自のものがあるのだろう。　これらにIOするための機能を従来はハイパーバイザに組み込んでいたため、(ベアメタルを提供するために)ハイパーバイザを外すと、AWSインフラへのアクセス機能が失われてしまう。　ということなのであろう。
従来
【VM】→【HV】→【AWSインフラ】

Nitro System
【VM】→【新HV】→【Nitro System】→【AWSインフラ】

Nitro に処理を分離させる意義は、ハイパーバイザ自身が直接AWSインフラと会話しなくて済むことであろう。　おそらく、NitroがサーバのIO要求をフックし横取りする形で、AWSインフラへのIO処理を代行するのであろう。　

これによって、ハイパーバイザ自身は普通のIO要求を出せばよくなり、それゆえにハイパーバイザーの変更(例えば、VMware vSphere への変更)が可能になったり、ベアメタルインスタンスの提供が可能になったりした(サーバ上のOSは普通にIO要求をすればいいから)のだろう。

この結果として、VMware Cloud on AWS の様な、非AWSハイパーバイザを EC2 の上で動かすことができたり、MacOS インスタンスのような Mac mini server の上で動く市販OSを AWS EC2 の枠組みの中に取り込むことができるようになったのだろう。

AWSのしがらみを回避する苦肉の策といってしまえばその通りだ。　当初は仮想化絶対だったからそれでもよかったが、特殊な環境を作ったためにハイパーバイザも特製になって、その結果、汎用的なOSの採用が難しくなって。。。その問題解決のために Nitro が必要になった。　

でも技術的には面白い。

● AWS の Mac インスタンス
仮想でなく、Mac mini で動作するハードであり、Nitro System を活用していると書かれている。
https://aws.amazon.com/jp/ec2/instance-types/mac/

● AWS Mac インスタンスの仕組みの解説
https://www.publickey1.jp/blog/20/macawsmac_minithunderboltaws_reinvent_2020.html

● AWS Nitro System の解説
https://www.sbbit.jp/article/cont1/34457

● AWS Nitro System の解説
https://www.publickey1.jp/blog/18/aws_nitro_system.html