本稿は，http://www.monaka.org/blog/2014/02/04/how-to-build-ebs-image/ を要約したものです．
まくら
AWS EC2 は，プラットフォームとして Xen を採用しているので，Xen の mini-os を Amazon EC2 で動作させることができる．
これは，オレオレOSをクラウドOSとして運用するという，俺得的満足感が得られる，ということを意味する．
Amazon が提供していないカーネルを独自に EC2 で動作させるためには，どうやら EBS ボリュームを作らねばならないらしい．
私は，AWS の単なるユーザで，細かいところはあまり詳しくない．
よって，EBS ボリューム以外での起動方法もあるのかもしれないが…．
手順は本家ヘルプページに割と細かく説明されている．
解説ブログも，ググれば山盛り．
さすがは，みんな大好きAWS．
だがしかし，最近になって，AWS は，管理ツールを AWS-CLI というものに統合しようとしている一方，本家ヘルプページは，AWS-CLI への対応が十分にできていない．
そこで，本稿では，AWS-CLI で mini-os をブートさせるための手順を記す．
作業
概要
独自のカーネルをEC2上で動作させるためのイメージ(以下，オレオレイメージ)は，EBS のスナップショットから作るようになっている．
Xen ではおなじみの PV-GRUB が，オレオレイメージ中にある boot/grub/menu.lst を読み，
kernel (本稿の場合は mini-os)をロードしブートする．
手元環境でEBSを作ってアップロードすることもできるのかもしれないが(知らない)，ここでは EC2 上で t1.micro を立ち上げて作業する．
一連の作業時間は，1時間もかからない．t1.micro なら10円にも満たないような額だろう．
本稿では，ビルドは手元で行うことを想定している．ビルド環境さえもEC2上に立てるということも，もちろんできる．
その際の作業の読み替え箇所は，いちいち言及するまでも無いだろう．
手順0: ~/.aws/config
こんな感じ．
[default]
aws_access_key_id=ないしょ
aws_secret_access_key=ないしょ
region=ap-northeast-1
output=text
region が違うと，下記例示の image-id やらなにやら変更が要るかもしれない．
手順1: EBSボリュームへのアクセスを行う EC2 インスタンスの生成
EC2のインスタンスを立ち上げる．
$ aws ec2 run-instances --image-id ami-dcfa4edd --instance-type t1.micro --security-group-ids quick-start-1 --key-name monaka
--security-groups-ids や --key-name は，ご自分の環境に合わせて．
--image-id も，好みの環境があるなら，それで．
でも，本稿の例だと複雑なことはしないので，amiの選択に凝るのは時間の無駄かも．
結果はこんな感じ．
578606849602 r-351e1831
GROUPS sg-e242dbe3 quick-start-1
INSTANCES 0 i386 None False xen ami-dcfa4edd i-a3bec9a4 t1.micro aki-ec5df7ed monaka 2014-02-01T11:04:33.000Z None None /dev/sda1 ebs None paravirtual
MONITORING disabled
PLACEMENT ap-northeast-1b None default
SECURITYGROUPS sg-e242dbe3 quick-start-1
STATE 0 pending
STATEREASON pending pending
手順2: 諸々のファイルを入れるEBSボリュームの生成
$ aws ec2 create-volume --size 1 --availability-zone ap-northeast-1b
mini-os のサイズは1MB以下なのだが，EBSボリュームの最低サイズは1GB．無駄だがやむなし．
結果はこんな感じ．
ap-northeast-1b 2014-02-01T10:46:19.012Z 1 None creating vol-1cbb4b16 standard
手順3: EBSボリュームのEC2インスタンスへのアタッチ
$ aws ec2 attach-volume --volume-id vol-1cbb4b16 --instance-id i-a3bec9a4 --device /dev/sdh1
vol-1cbb4b16 は，手順2の結果で得られたもの．i-a3bec9a4 は，手順1の結果で得られたもの．
結果はこんな感じ．
2014-02-01T11:05:25.613Z /dev/sdh1 i-a3bec9a4 attaching vol-1cbb4b16
手順4: 作業用 EC2 インスタンスへの ssh ログイン
手順1で，インスタンスを立ち上げた直後は，サーバのFQDNが判らない．
そろそろインスタンスのプロビジョニングも終わっているはずなので，確認．
$ aws ec2 describe-instances --instance-ids i-a3bec9a4
結果はこんな感じ
RESERVATIONS 578606849602 r-351e1831
GROUPS sg-e242dbe3 quick-start-1
INSTANCES 0 i386 None False xen ami-dcfa4edd i-a3bec9a4 t1.micro aki-ec5df7ed monaka 2014-02-01T11:04:33.000Z ip-10-132-154-11.ap-northeast-1.compute.internal 10.132.154.11 ec2-54-199-18-76.ap-northeast-1.compute.amazonaws.com 54.199.18.76 /dev/sda1 ebs None paravirtual
BLOCKDEVICEMAPPINGS /dev/sda1
EBS 2014-02-01T11:04:36.000Z True attached vol-69bc4c63
MONITORING disabled
PLACEMENT ap-northeast-1b None default
SECURITYGROUPS sg-e242dbe3 quick-start-1
STATE 16 running
compute.amazonaws.com で終わっているのが，外向きのFQDN．
今回の場合は，ec2-54-199-18-76.ap-northeast-1.compute.amazonaws.com
なので，おもむろに ssh．
Amazon Linux の場合は，ログインユーザは ec2-user となる．
$ ssh ec2-user@ec2-54-199-18-76.ap-northeast-1.compute.amazonaws.com
サーバの公開鍵を受け入れるかどうかなど聞かれる．
結果は，こんな感じ．
The authenticity of host 'ec2-54-199-18-76.ap-northeast-1.compute.amazonaws.com (54.199.18.76)' can't be established.
RSA key fingerprint is e8:10:70:59:ce:4b:7b:59:97:92:35:d8:35:a7:3a:92.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-54-199-18-76.ap-northeast-1.compute.amazonaws.com,54.199.18.76' (RSA) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
See /usr/share/doc/system-release/ for latest release notes.
No packages needed for security; 170 packages available
Amazon Linux version 2013.09 is available.
[ec2-user@ip-10-132-154-11 ~]$
手順5: EBSボリュームのマウント
手順3では，EBSボリュームはアタッチしかしていない．
ここでファイルシステムを作成して，マウントする．
ファイルシステムの生成は，こんな感じ．
[ec2-user@ip-10-132-154-11 ~]$ sudo mkfs.ext2 /dev/sdh1
結果は，こんな感じ．
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
ファイルシステムはできたので，早速マウント．
[ec2-user@ip-10-132-154-11 ~]$ sudo mount /dev/sdh1 /mnt
特にメッセージの出力など無く，コマンドプロンプトに戻ってくる．
手順6: menu.lst の生成
PV-GRUB が読む menu.lst を，EBSボリューム(の中にあるファイルシステム)に置く．
エディタ使ってもいいけれど，この程度なら猫で十分．
[root@ip-10-132-154-11 ec2-user]# sudo -s
[root@ip-10-132-154-11 ec2-user]# cat > /mnt/boot/grub/menu.lst
default 0
title MiniOS test
root (hd0)
kernel /mini-os
[root@ip-10-132-154-11 ec2-user]# exit
sudo -s を使ったので，最後には exit で，ec2-user に戻しておいた．
手順7: mini-os のコピー
何らかの方法で行う．
ふつうは scp を使うと思う．
そして，EC2 インスタンス上の /mnt/mini-os に配置する．
ここでmenu.lst の記述に引っ張られて，うっかり，/mini-os に置いたりとかしないように．
手順8: スナップショットの生成
手順7までで，EC2インスタンスは用済みとなる．
だから，stop-insrance なり terminate-instance なりで落としてもよい．
けれども，最初の動作確認ができるまでは，立ち上げっぱなしのほうがよいかもしれない．
EC2の課金は1時間単位だけれども，1時間以内にn回立ち上げ直すと，n時間分の料金になる．
EC2のインスタンスにアタッチしたままでも，スナップショットは取れる．
そうでないと，スナップショットの意味が無い．
操作は，こんな感じ．
$ aws ec2 create-snapshot --volume-id vol-1cbb4b16
結果は，こんな感じ．
None 578606849602 None snap-940d6c7a 2014-02-01T11:24:16.000Z pending vol-1cbb4b16 1
手順9: スナップショットからオレオレイメージの生成
いよいよ佳境．スナップショットからオレオレイメージを生成する．
正直言うと，よく調べがついていないのだけれど，イメージの概要を示すjsonファイルが必要らしい．
短いものなので，これもテキストエディタを持ち出すまでもないはず．
$ cat > blockdevice.json
[
{"DeviceName":"/dev/xvda","Ebs":{"VolumeType":"standard","DeleteOnTermination":true,"VolumeSize":1,"SnapshotId":"snap-940d6c7a"}}
]
VolumeSize は，最初に 1GB で作ったから．SnapshotId は，手順8の出力と合わせる．
そして，イメージの登録を行う．
$ aws ec2 register-image --root-device-name /dev/xvda --name "Mini-os test" --block-device-mappings file://blockdevice.json --architecture x86_64
結果は，こんな感じ．
ami-ef650eee
手順10: オレオレイメージの起動
そして感動のフィナーレ．オレオレイメージの起動．
$ aws ec2 run-instances --image-id ami-ef650eee --instance-type t1.micro --security-group-ids quick-start-1 --key-name monaka
結果は，こんな感じ
578606849602 r-f17d65f5
GROUPS sg-e242dbe3 quick-start-1
INSTANCES 0 x86_64 None False xen ami-ef650eee i-b38630b4 t1.micro monaka 2014-02-01T11:46:28.000Z None None /dev/xvda ebs None paravirtual
MONITORING disabled
PLACEMENT ap-northeast-1b None default
SECURITYGROUPS sg-e242dbe3 quick-start-1
STATE 0 pending
STATEREASON pending pending
これだけだと，本当に立ち上がったのか判らない．
ログの取得は，こんな感じで行う．
$ aws ec2 get-console-output --instance-id i-b38630b4
i-b38630b4 は，オレオレイメージの run-instance の結果から引っ張ってくる．
mini-os 自身は小さいものの，mini-os の実行環境のプロビジョニングには，そこそこの時間がかかる．
遅い時は5分以上かかるので，気長に待つ．
どうせ1時間までは同じ料金だから．