Reach Over The Sky, Tear The Sky

結論 結論から言うと API Gateway でした。 ACMで発行したSSL/TLS 証明書を シームレスに他のAWSプロダクトで利用することが可能なのですが、その時に内部動作としては規定のアカウントIDでCloudFrontディストリビューションが生成され、そのディストリビューションに対して証明書が適用されるようです。 直面した問題 AWSでのシステム運用にあたり、それなりの数のドメインを運用しているのですが、基本的にはACMにて発行した証明書を利用しています。 以前はメール認証しかできず、きちんと環境を整えてあげないと自動更新に失敗することもあり、DNS認証の同一ドメインの証明書を別に発行し、そちらに切り替える作業を行なっていました。 ACMで発行した証明書はAWSコンソール上から簡単にELBやCloudFrontといったAWSプロダクトに利用することが可能なのですが、証明書を削除する際には全てのインスタンス・ディストリビューションから利用を解除する必要があります。 「あとはどの子（インスタンス）が使っているのかな〜？」と確認したところ、 arn:aws:cloudfront::969236854626:distribution/ABCDEFGHIJKLMN のようなCloudFrontディストリビューションが利用していることがわかりました。 969236854626 の部分が自分のAWSアカウントIDになりますが、私が利用しているアカウントのIDは全然違います。 対策 「えっ…？」と思いましたが調べたらすぐに解決。 答えはこちらに書いてありました。 エッジ最適化のカスタムドメイン名を作成する方法 - Amazon API Gateway  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-edge-optimized-custom-domain-name.html API Gatewayにカスタムドメインを割り当ててHTTPSを利用させたい場合に、AWSは特定のIDでCloudFrontディストリビューションを内部的に自動で作成し、そのディストリビューションに証明書を関連づけるのでした。...

とてもお久しぶりです。 恵比寿のITベンチャーでサービス運営やっています。 仲間募集中です。ご興味ある方はTwitterなどでご連絡ください。 今回はAWSを使って、わりと便利なソーリーサーバを構築しましたというお話です。 構成は下の図のようになっています。 通信フローとしては、まずエンドユーザがELBにアクセスします。 このELBは既存のWebサービスやWebサイトをバランシングしていたものです。 諸事情によりメンテナンスしたり、ドメインを畳むことになったという話を想定しています。 そのELBに接続されていたWebサーバやアプリケーションサーバの代わりにソーリーサーバを接続します。 するとエンドユーザはソーリーサーバにアクセスしてきますよね。 ソーリーサーバはリクエストを受けたら、各ドメインに対応させたいCloudFrontへリクエストをパスします。 CloudFrontはS3のコンテンツを返すのですが、このS3に静的なソーリーページを格納しておきます。 それにより、ドメインにアクセスしてきたエンドユーザにソーリーページを見せることができます。 ポイントはソーリーサーバとCloudFrontですがやってることは簡単です。 まず、ソーリーサーバはただのNginxです。 proxy_pass を使って、特定ドメインに来たリクエストを対応するCloudFrontのドメインへパスします。 その設定は、/etc/nginx/conf.d/virtual.conf に書きました。 server {          listen 80;         server_name example.com;         if ($http_x_forwarded_proto != https) {          ...

先日、Apacheで配信していたWebサイトをS3＋CloudFrontの環境に移行しました。そのときにやったことを備忘録としてまとめました。 個人的にハマって悩んだところや大事だなと思ったところは太字にしています。 0. 前提条件 一通り構成を組んだ後でのテストでは、キャッシュがしぶとくてコンテンツ更新後の状況が再現できないことがあるので、Invalidationしまくったり、ブラウザキャッシュを削除しまくったりする必要がある。 適当なテストドメインを用意できると良い。 たとえば、 www.example.com について構築しようとしているのであれば、 www2.example.com などをテスト用として確保するとよい。 phpやrubyは動きません、 Javascriptは動きます、Basic認証はできません 、会員登録はできません（phpやrubyが必要なページは動かない）、などの制約事項があるので、 非Techの関係者にネゴっとく 必要がある。 1. S3の基本的な設定 なんでもいいのでバケットを作る。 バケット直で自分が持っているドメインを紐付けようと思うなら、ドメイン名と全く同じバケット名（www.example.comのサイトを作りたい場合は、バケット名をwww.example.comにする。ドットは入力できないとエンジニアの直感でなんとなく思いがちだけど、普通に入力できる…。）にする必要がある が、多分不要。（未検証、今回はドメインと同じバケット名にしました…。） 静的ウェブサイトホスティングを有効にする。 インデックスドキュメントはindex.html（他任意のファイル名でもOK）、エラードキュメントはerror.html（他任意ry）にする。 バケットに、html, access-logs, cf-logs のディレクトリを作成する。htmlがコンテンツ置き場、access-logがS3が直接ロギングするログ置き場、cf-logsがCloudFrontがロギングするログ置き場にする。 コンテンツを突っ込んでみて、静的ウェブサイトホスティング用のURLにアクセスして、コンテンツが表示されるかを確認する。 2. CloudFrontの基本的な設定 基本的にはググって出てくるサイトを参考にしてよい。 A...