急なアクセスをCloudFrontに逃がす(案)

ほっとんど用途ないですが、こういうやり方もあるという程度のメモ。

急激なアクセス増加が見込まれる場合、BlogなどはS3に静的ファイルを配置して、S3直接もしくはCloudFront経由で配信することが有用ですが、都度S3にUploadする必要があります。
また、CloudFrontのカスタムオリジンにアクセス対象のサーバを設定して、DNSレコードをCloudFrontに向けておくこともいいですが、CloudFrontの料金が普段からかかってしまうのと、記事更新を即座に反映したい場合、CloudFrontのTTLを0や短い値にしておく必要があります。TTL0でもオリジンのデータ更新を確認し、更新されていない場合は実データのフェッチは行われません。

別ドメインを作って、それをCloudFrontのdistributionに向け、オリジンサーバにアクセス対象のサーバを設定すれば、アクセスが増えそうな箇所に露出する場合は、そちらのドメインをリンクに設定すれば良いのですが、もし、CSSやJSや画像などがフルパス指定されているような場合は、それらのリソース取得は直接オリジンサーバにアクセスが行ってしまいます。

そこで、かなりトリッキーですが以下のような構成を考えてみました。
Nginxでproxyをし、Nginxでコンテンツ中のドメインをCloudFront経由のドメインに変更して、CloudFrontへデータを流します。これで、使う時だけEC2インスタンスを起動し、ELBにぶら下げればアクセスのCloudFront経由で流せます。特定の時だけの使用であればTTLを長めに設定することも可能ではないでしょうか。ProxyはAMI化しておけばすぐに起動出来ます。
もっとコスト節約するのであればELBも都度起動して、distributionのOriginを都度切り替えるのもありかと思います。

Nginxの設定は

  server {
    listen       80;
    server_name  cfnotice.example.com;

    proxy_set_header X-Real-IP              $remote_addr;
    proxy_set_header X-Forwarded-Host       $host;
    proxy_set_header X-Forwarded-Server     $host;
    proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
    proxy_set_header Accept-Encoding        "";

    location / {
      sub_filter 'info.example.com' 'cfnotice.example.com';
      sub_filter_once off;
      proxy_pass http://upstream:80;
    }
  }

sub_filter moduleを使っています。
upstreamサーバがdeflateでコンテンツを返さないように「proxy_set_header Accept-Encoding "";」を設定します。また全てをreplaceするので「sub_filter_once off;」を設定します。

後は、cfnotice.example.comを露出させてやるだけです。

本当にどうにもならないときにしか使うことは無いと思います。CloudFrontの独自ドメインでもSSLふが使えるようになったのでSSLを使いたい場合も問題ありません($600/月かかります)
また、CloudFront経由だけProxyにアクセスさせたい場合は
https://forums.aws.amazon.com/ann.jspa?annID=910
で、CloudFrontが使うIPアドレスレンジが公開されていますが、常に最新の状態ではないのでお気をつけください。

• S3+CloudFront
• S3直
• 別ドメインを設定してCloudFront経由

これらが正当だと思います。