Fedoraってバージョン上がるのが早い（約半年ごと）うえに、サーバを運用するうえで根幹に関わる部分に次々と新しい仕組みが導入されたりして、随時アップデートに追従していくならまだしも、3つ4つ以上前のバージョンとかを最新にアップデートするのにはかなり苦労したりするので、正直長く運用していくサーバのOSとしてはお勧めしづらい（そもそも枯れてないパッケージも多いし）のではありますが、yumでインストール出来るパッケージのバージョンが新しく種類も豊富なのでどうしても使っちゃいます。
（欠点というよりはそういうディストリなだけですね）

EC2とかだとAmazon Linuxを使うのが長く運用していくうえでは一番いいのかななんて思います。
yum使えるし、パッケージも比較的新しめだし。
ただ種類が少なく、少しでもマイナーなパッケージはほぼ入ってないのがつらいところです。
他のOSのリポジトリ等を使うと種類は増やせるらしいですが、そんな事するぐらいならFedoraでも…などと思ってしまいます。

でまぁFedora 16を使っちゃおうよと思って色々調べたんですが、Amazon公式AMIだとFedora Core 4, 6, Fedora 8しかなく、Fedora公式のFedora 16 AMIはEBS backedなのしか見つけれなくて。
（なんかFedora公式のはちょっと前はinstance storeなAMIもあった形跡はあるんですが…探し方が悪かったのかな）

なら独自にAMIを作るべということで調べたら、Fedora公式にEC2用AMIの作り方ズバリそのものの情報がありました。
http://fedoraproject.org/wiki/Cloud_SIG/EC2_Creation

リンク先を見ていただくと分かるとおり、かなり簡単な手順なんですが、少し説明が省かれていてハマる可能性があるところがあるので、自分がやった手順を残しておきます。
最終的にはi386なsmallインスタンス（ストレージはinctance store）で動作させる事を想定しています。

1. 作業用マシンの用意

今回はローカルのVirtualBoxでFedora 16をネットインストール（最小限）したものを用意しました。
後述するboxgrinderが動けば作業用マシンはどのOSでもいいような気はしますが、多分Fedora使ったほうが楽です。
ネットインストール（最小限）なので、networkサービスの起動や、SSHサーバのインストール・設定が必要です。
あと、作業用マシンの時計がズレてるとあとでS3にイメージをアップロードするときに失敗するので、ntpdを動かして時刻合わせしときました。
使い捨ての環境のつもりなので、細かい設定はせず、以降はrootで作業しています。

2. 作業マシンにboxgrinderをインストール

yum install rubygem-boxgrinder-core rubygem-boxgrinder-build

boxgrinderは各種仮想化技術（VMWare, VirtualPC, VirtualBox, EC2）に対する各種仮想アプライアンス（Fedora, CentOS, RHEL, Scientific Linux）の構築を便利にしてくれるソフトウェアです。
各種仮想化技術、各種仮想アプライアンスに対してプラグインという形で対応してるので、そのうち適用可能な環境は増えるんではないかと思います。
今回は、EC2用のFedora 16のイメージを作成するために使います。

3. boxgrinderの基本的な設定ファイルを用意

以下の内容で、/root/.boxgrinder/config にファイルを作成する。

plugins:
  s3:
    access_key: <アクセスキー>
    secret_access_key: <シークレットキー>
    bucket: <アップロードするS3のバケット名> # 存在してなければ自動で作られる
    account_number: <アカウント番号> # AWSにログインしたときにページの右上に表示されてる口座番号xxxx-xxxx-xxxx
    path: /images # 上で指定したバケット名にこの名前でサブディレクトリが作成されてこの中にイメージが置かれる
    cert_file: <cert-xxx.pemファイルへのパス>
    key_file: <pk-xxx.pemファイルへのパス> 

シャープ「#」から始まるコメントは説明のために追加したもので、実際に「#」でコメントを付けたものが動作するかは未確認です。
BG_CONFIG_FILE という環境変数を使うと、この設定ファイルの位置は自由に決めれるらしいです。

4. アプライアンス定義ファイルを作成して適当な箇所に設置

以下の内容で、fedora16.appl というファイルを作成する。
ファイル名はなんでもいいけど拡張子はboxgrinderにチェックされるので必ず.applにする事。

name: fedora16
summary: Fedora 16 Basic
os:
  name: fedora
  version: 16
hardware:
  partitions:
    "/":
      size: 10
packages:
  - @base
  - @core
  - yum
  - openssh-server
  - openssh-clients
  - system-config-firewall-base
  - sudo

書式からしてインデントが重要な意味を持つんじゃないかと思います。
各項目の説明
name: アプライアンスの名前。この名前をベースにしてS3上にイメージバンドルが置かれます。Fedora公式サイトでは大文字が使われてますが、後の処理でS3にアップロードするところでエラーになるので小文字だけにする必要がありました。
summary: アプライアンスの説明。多分適当でいいと思います。
os: osの指定。nameがディストリ名、versionがバージョン名です。boxgrinderはここを見てosを決定するので間違いないようにしなければなりません。
hardware: 色々設定出来るようですが、今回はルートパーティションに10GB確保する設定です。EC2のsmallインスタンス（instance store）向けの基本的な設定です。
packages: インストールするパッケージ名を列挙します。これがEC2用の最低限の設定かなと思います。（openssh-clientsとsystem-config-filewall-baseはいらないかも）初期パッケージを追加する際は、yum installで指定するパッケージ名を追加していけばいいだけです（例えば – httpd とか）。依存関係は多分自動的に解決してくれるハズ。

5. アプライアンスイメージを構築してS3にアップロード

boxgrinder-build /path/to/fedora16.appl -p ec2 -d ami -f

-pオプションと-dオプションは、まぁお察しの通りの意味です。
細かいことはよく分かりません。
-fオプションについてですが、boxgrinder-buildはデフォルトで前回の処理が途中で終わったことを検出した際、その続きから処理を行ってくれます。それを無効化するのが-fオプションです。
設定ファイルを色々いじりながら何回も試すときには-fを付けといた方が時間は掛かりますが混乱は少ないかと思います。
これだけで、ディスクイメージの構築から、AMI用のバンドル化、S3へのアップロード、AMIの登録までやってくれます。
まぁ、うまくいけばですが（汗
boxgrinder-buildがなんか不安定で、設定ファイルを全く変更してないのに、エラーで途中で止まってしまうことが多々あります。
しかもタイミングがマチマチ。
そういうときは-fオプションを省いて繰り返せばいいだけですが、不安なので-fは常に付けてました。
自分の場合は、多くて2回連続で謎のエラーが起きました。

6. インスタンス起動

あとはEC2の管理画面でAMIを選択しLaunch Instanceするだけです。
もちろんSSHで22番ポートを使うのでSecurity Groupで開けとかなければいけません。
あとログインユーザ名はec2-userになります。

色々突き詰めたいところは残ってるんですが、ここに至るのに紆余曲折あって力尽きました。
あとはたのんだ（ｶﾞｸﾘ