30歳からのプログラミング

30歳無職から独学でプログラミングを開始した人間の記録。

フロントエンドエンジニアがお世話になるであろう AWS のサービス群

備忘録として、記録していく。
ひとつひとつのサービスについて詳しく説明したりはしない。あくまでも概要や役割と、サービス間の関係について紹介するのみ。
そもそも AWS について詳しくない。フロントエンドエンジニアが必要に駆られて触っている、という感じなのでまだまだ初心者である。

S3

ストレージサービス。

純粋にストレージとして使うことも出来るし、コンテンツ配信のためにファイルを置くことも出来る。
単純にアセット(画像やJSファイルなど)を置いてもいいし、ホスティング機能を使ってS3をウェブサーバとして使うことも出来る。

他の AWS のサービスと連携して、ファイルの保存先として使うことも多い。
ログファイルもそうだし、AWS が提供するメールサービスのメールの受信先として、S3を設定することも出来る。

ファイルは、「バケット」という単位で管理する。
バケットに保存されているそれぞれのファイルのことを、「オブジェクト」と呼ぶ。

S3では、かなり細かくアクセス権を設定できる。コンテンツ配信に使うのでなければ、非公開にしておくべき。
詳細は以下を参照。
S3で誤ったデータの公開を防ぐパブリックアクセス設定機能が追加されました | DevelopersIO

CloudFront

CDNサービス。

「ディストリビューション」という単位で、設定を管理する。
ディストリビューション単位で、配信するコンテンツを設定する。

CloudFrontでは、大本のコンテンツを配信しているサーバを「オリジンサーバ」、ユーザーへの配信を行うサーバを「エッジサーバ」と呼ぶ。「エッジサーバ」は「エッジロケーション」と呼ばれることもある。
AWS再入門 Amazon CloudFront編 | DevelopersIO

CloudFrontを使うにはまず、ディストリビューションを作成する。色々と設定を行うが、そのときにオリジンサーバの指定も行う。
ディストリビューションが作成されると、xxxxx.cloudfront.netというドメインが生成される。
このドメインにアクセスすると、「オリジンサーバ」と同じ内容のコンテンツが「エッジサーバ」から配信される。

オリジンサーバには、先程紹介したS3を指定することも出来る。
S3に置いてあるコンテンツをCloudFront経由で配信する。この方法を使えば、SSL証明書を使ってHTTPS化することも出来る。

オリジンサーバにS3のコンテンツを指定したい場合、バケットそのものを指定するパターンと、S3のホスティングサービスが出力したURLを指定するパターンがあり、それぞれに特徴が異なるので留意する。
CloudFront + S3 で静的サイトを運用する際の注意点 - Qiita

オリジンサーバとしてバケットを指定する場合、バケットやオブジェクトに直接アクセスすることを禁止できるので、セキュリティ的にはこちらのほうが望ましいと思われる。
具体的にはまず、バケットのアクセス権の設定で、外部からアクセスできないようにする。
次に、ディストリビューションを作成するときの設定で、Restrict Bucket AccessYesに、Yes, Update Bucket Policyを有効にする。
こうすると、ディストリビューションからはバケットにアクセスできるようになり、そのためのバケット側の設定も自動的に行われる。
[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する | DevelopersIO

注意点としては、この方法でコンテンツを配信してもすぐには有効にならないこと。
ステータスコード307のリダイレクトが発生してしまい、正しく表示されない。
解消されるのを1時間ほど待つ必要がある。
Cloudfront,S3で307リダイレクトに苦しめられた - パパエンジニアのアウトプット帳

もうひとつの注意点としては、エラーページの設定。
ディストリビューション毎にエラーページを設定することができ、表示させるページをステータスコード毎に設定する。404が発生したときはこのページ、500が発生したときはこのページ、といった具合に。
だがS3は、コンテンツが見つからなかったときに何故か403を返すので、それに合わせた設定をする必要がある。

IAM

AWS の各種サービスを利用するための権限の設定。

「ユーザー」「ロール」「ポリシー」といった単位で管理する。

例えば、ルート権限(に相当するもの)で AWS にログインするのではなく、必要な機能へのアクセス権のみを持つユーザーを作成して、それでログインすることでセキュリティを高める。

また、CIサービスで AWS の操作(S3へのデプロイなど)を行うときも、適切な権限を設定してユーザーを作成し、そのユーザーのアクセスキーをCIサービスに登録する必要がある。

Route 53

DNSサービス。

ドメインの取得や管理を行う。もちろん、他社で取得したドメインも使える。
サブドメインの作成なども、ここで行う。

「ホストゾーン」という単位で管理する。

CloudFrontの設定画面でAlternate Domain Names(CNAMEs)にドメインを入力すると、そのドメインでコンテンツを配信できる。

ACM

SSL証明書の発行や管理を行う。

証明書を登録すると、CloudFrontCustom SSL Certificateで選択肢として表示されるので、それを選ぶとコンテンツをHTTPS化できる。

Lambda@Edge

Lambdaは、サーバーレスでコードを実行するためのサービス。
そしてLambda@Edgeは、CloudFrontのエッジサーバでLambdaを実行するサービス。
このサービスを使うことで、CloudFrontで配信しているコンテンツにアクセスがあった際に、任意の処理を差し込むことが出来る。

具合的には、ベーシック認証を設定したり、URLのリライトを行ったりすることが出来る。
Amazon CloudFrontとAWS Lambda@EdgeでSPAのBasic認証をやってみる | DevelopersIO
できた!S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法 | DevelopersIO

Lambda@Edgeを利用するにはまず、そのためのIAMロールを作成する必要がある。
必要なアクセス権を付与する他、「信頼されたエンティティ」にlambda.amazonaws.comedgelambda.amazonaws.comを設定する。

Lambda@Edgeを利用できるリージョンは今日現在では「バージニア北部」のみ、ランタイムはNode.js v6.10Node.js v8.10を利用できる

先程作成したロールを使ってLmabdaで関数を作成し、 「アクション」から「Lambda@Edge へのデプロイ」を選択すればよい。
[アップデート] Lambda@Edge が超簡単にデプロイ出来るようになったよ! | DevelopersIO