
あけましておめでとうございます。

[PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/)を使ってこのブログを計測したところ、画像の最適化とキャッシュを提案されたので、年末年始は[AWS Lambda](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html)を使って画像の最適化を試していました。

## はじめに

やりたかったことは、ブログで使う画像を最適化してサイズを小さくすることです。

ブログの画像ファイルは全て S3 から配信しているので、特定の S3 バケットに画像がアップロードして、それを Lambda 関数で最適化して他のバケットにアップロードすると言った、よくあるユースケースを実現してみました。

![](https://docs.aws.amazon.com/lambda/latest/dg/images/s3-admin-iser-walkthrough-20.png)

出来上がったものは、下のリポジトリにおいてあります。

- <https://github.com/mitsuruog/s3-image-optimizer>

正直なところ下の AWS 公式チュートリアルを少し改造しただけなので、これをそのまま使うよりはチュートリアルで自分で試して見た方がいいと思います。

- <https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html>

## カスタマイズした点

カスタマイズした点について少し触れておきます。

### 環境変数の利用

Lambda 関数の設定画面から環境変数を設定することができたので、一部の変数を実行時に渡すようにしました。
Lambda 関数の中では`process.env`にアタッチされるので、次のように利用できます。

```javascript
const DEFAULT_DST_BUCKET = process.env.DST_BUCKET;
```

### 画像へのキャッシュの指定方法

S3 にアップロードされた画像にキャッシュを指定するには、S3 オブジェクトの**メタデータ**を使って HTTP ヘッダーを追加します。
AWS-SDK の`S3.putObject`を見ると、`CacheControl`と`Expires`を使うことで、キャッシュ関連の設定を渡すことができます。

次のように設定してみました。

```javascript
s3.putObject({
  Bucket: YOUR_TARGET_BUCKET_NAME,
  Key: "image.png",
  Body: data, // image data
  ContentType: "image/png",
  CacheControl: "max-age=86400", // 86400s => 1day
  Expires: new Date(new Date().getTime() + 86400 * 1000), // 現在日時より1日後
});
```

- [Class: AWS\.S3 — AWS SDK for JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property)

S3 バケットのメタデータを確認すると、次のように表示されます。(上の値と違いますが。。。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/lambda-s3-01.png)

### 画像をアップロード時に「public」設定にする

これも`S3.putObject`の`ACL`を使って設定を渡すことができます。

```javascript
s3.putObject({
  Bucket: YOUR_TARGET_BUCKET_NAME,
  Key: "image.png",
  Body: data, // image data
  ContentType: "image/png",
  CacheControl: "max-age=86400", // 86400s => 1day
  Expires: new Date(new Date().getTime() + 86400 * 1000), // 現在日時より1日後
  ACL: "public-read",
});
```

> 次の値が設定できるようです。
>
> - "private"
> - "public-read"
> - "public-read-write"
> - "authenticated-read"
> - "aws-exec-read"
> - "bucket-owner-read"
> - "bucket-owner-full-control"

## 結果

結果どれくらいサイズが小さくなったかというと。。。

「**22.3MB => 16.2MB**」

うん、微妙。ちょっと減りました。
画像最適化をもう少し強くするともう少しサイズは減るかもしれません。

## さいごに

Lambda の動作確認にちょうどいい感じだったので、正月休みに画像の最適化用の Lambda 関数を作ってみた話でした。
出始めの頃と比べると GUI でできる範囲が増えたので楽でした。

> こちらは GUI の Designer で確認することができる、関数の概要図です。わかりやすい。
> ![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/lambda-s3-02.png)

もう少しいいものがあるので、自分で試さない場合はこのあたりもチェックしてみてください。

- <https://github.com/sourcey/s3-image-optimizer>
- [kraken.io(有料)](https://kraken.io/)


AWS Lambdaを使ってS3にアップロードしたイメージを最適化する

よく忘れるシリーズ。

AWS の特定の S3 バケットにだけアクセスできる IAM ユーザーを作る方法です。



## 想定される用途

自分の場合、最近のフロントエンドは SPA を作ることが多いので、フロントエンドのコードを Webpack で bundle にビルドして S3 へデプロイします。

この辺りは CI サービスを利用して自動化しているのですが、その時に AWS の IAM を作成し、そのアクセスキーを使って特定の S3 バケットにデプロイするようにします。

> 特定のバケットにだけアクセスできるようにしているのは、不慮の事故で他の S3 バケットに影響を及ぼさないためです。

## IAM ユーザーの作り方

IAM ユーザーの作り方は至って単純で、AWS のコンソールにログインして IAM ユーザーを作成すればいいです。

ところが、**特定の S3 にのみアクセスできる**ようにするためには、**カスタムポリシー**を作成して IAM ユーザーに適用する必要があります。
しかしまぁ、フロントエンドエンジニアの自分としては、AWS のポリシーの JSON を触る機会などあまりないので、その書き方を毎回すっかり忘れるわけです。

というわけで、今回はこの面倒な JSON を忘れないようにするのがこの記事の目的です。

特定の S3 バケットにのみアクセスできるようにするには、次のような JSON をポリシーに設定します。

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
          "arn:aws:s3:::<bucket-name>",
          "arn:aws:s3:::<bucket-name>/*"
      ]
    }
  ]
}
```

- `<bucket-name>`の部分には、アクセスを許可したい S3 バケット名を指定してください。
- `<bucket-name>/*`となっているのは、サブディレクトに対してもアクセスを許可するための設定です。

このポリシーを設定した IAM ユーザーのアクセスキーを、CI サービスで使えば特定の S3 バケットに対してデプロイできるようになります。

## まとめ

AWS の特定の S3 バケットにだけアクセスできる IAM ユーザーを作る方法でした。

CI 周りの設定はプロジェクトを初期構築するときにやるので、次やろうとした時には大抵忘れています。
なので、備忘も兼ねて記事にしてみました。

特定のS3バケットにだけアクセスできるIAMユーザーを作る

小ネタです。  
最近、真面目に aws を触っていて、今更ながら[Amazon Web Services クラウドデザインパターン 設計ガイド 改訂版](http://www.amazon.co.jp/gp/product/4822277372/ref=as_li_tf_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4822277372&linkCode=as2&tag=mitsuruog-22)を読み始めました。

本書を読んでみると、AWS について初めて知る機能も多く、本当に AWS を利用してシステム構築するためのバイブルのような本だなと感じました。  
(もっと早く読んでいれば・・・)

今回は、その中で S3 上のセキュアな環境下にある任意のオブジェクトに対して、「期限付き URL(pre-signed URL)」を発行してアクセスさせる方法を試してみました。



## やってみる

では、早速やってみます。  
私は noder なので、node.js 版の aws sdk を利用して行います。

まず、S3 上に「Bucket」を作成して、任意のファイルをアップロードしておきます。

S3 上にアップロードしたファイル(オブジェクト)には、
アクセスするための一意な URL が付与されていますが、今の状態では外部からアクセスできません。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/aws-s3-pre-signed-url_01.png)

確認してみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/aws-s3-pre-signed-url_02.png)

では、aws sdk を利用して「期限付き URL」を発行してみます。

```js
var AWS = require("aws-sdk");
var s3 = new AWS.S3();

var params = {
  Bucket: "<Bucket名>",
  Key: "<アクセスするオブジェクト>",
  Expires: 60, //sec
};

s3.getSignedUrl("getObject", params, function (err, url) {
  console.log("The URL is", url);
});
```

これをコンソール上で実行すると期限付き URL が発行されます。  
デフォルトでは URL の有効期間が 15 分なので、`Expires`に有効期限(sec)を指定することもできます。

では、生成された期限付き URL でアクセスしてみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/aws-s3-pre-signed-url_03.png)

ファイルの中身についてアクセスできました。

## さいごに

S3 上に静的コンテンツを配置して、任意のユーザーに限定公開できるので、
ユーザーへ期限付き URL を配布してパスワードの再入力など、特定の業務フローに組み込むことで効果を発揮しそうだと思いました。

AWS について、もっと学習しないとなーと思います。

### 参考

- [[AWS]S3 の期限付き URL を生成する[node] ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/node-pre-signed-url/)
- [S3 の事前署名付き（期限付き）URL を生成する | cloudpack 技術情報サイト](http://blog.cloudpack.jp/2014/07/08/aws-s3-url-with-expiration-using-php-ruby/)
- [Uploading Objects Using Pre-Signed URLs - Amazon Simple Storage Service](http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html)

期限付きURLを発行してセキュアなS3のオブジェクトにアクセスしてみる

最近は、WebAPI や AWS のようなクラウドサービスが普及してきて、バックエンドのサーバーがなくても、Web サービスが公開できるようになってきました。

今回は AWS の**S3 にある Static Website Hosting 機能**を使って AngularJS で作成した SPA(Single page application)をホスティングさせてみました。

割と S3 でのサイト公開は簡単なので楽勝かと思いきや・・・  
いろいろまじめに考えると手こずるものですね。



## S3 での SPA 公開

S3 でのサイト公開は非常に簡単です。次の 3 ステップで即公開できます。  
(「S3 サイト公開」などで検索するといくつか記事がヒットすると思いますので参考にしてください。)

- S3 上に Bucket を作成する。
- AngularJS で作成した SPA をアップロードする。
- Bucket の Static Website Hosting を ON にする。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-1.png)

Static Website Hosting を ON にすることでアクセス可能な URL が取得できます。  
アクセスした際に「`AccessDenied`」エラーになる場合は、アップロードしたファイルの`Permissions`が**Everyone アクセス可能**になっていないことが多いです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-2.png)

しかし、この**Everyone アクセス可能**状態はあまりいい状態ではありませんので、CloudFront を利用します。  
(後で紹介しますが、S3 は CloudFront 経由のアクセスのみ有効にする設定を推奨します。)

> S3 の Everyone アクセス可能は Apache の設定漏れで、ファイル一覧が見えてしまっている感覚に似ていて落ち着きません w

他にも、S3 で公開した場合に問題になりそうな部分について紹介します。

## S3 での SPA 公開で問題になりそうなところ

S3 の Static Website Hosting 機能はお手軽で非常に魅力を感じるのですが、Web アプリケーションを想定した場合、次のような問題がありそうです。

- アクセスを`HTTPS`に限定できない。
- URL に「`/`」を指定した場合、S3 上のフォルダを参照してしまいエラーとなる。(結果「`/index.html`」まで含める形に・・・)
- 「`/`」以外の URL(「/hoge」とか)でアクセスした場合に`403(access denied)`エラー(2015/01/20 追記)
- 他にもあった気がするが、忘れた。

という訳で S3 のみのお手軽ホスティングは、コーポレートサイトのような静的コンテンツ向きな気がします。

## CloudFront の利用

そこで利用するのが CloudFront です。いろいろ探していたら、こちらの記事が参考になりました。ありがとうございます！

[[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/cloudfront-s3-origin-access-identity/)

手順としては次のような形です。

- CloudFront 上に Distributions を作成
- Origin Domain Name に S3 の Bucket を指定
- Restrict Bucket Access で「Yes」を設定して S3 へのアクセスを制限

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-3.png)

これで CloudFront 経由で S3 へアクセスすることができますが、SPA をホスティングするに当たって追加で以下の設定をしました。

### General > Default Root Object

`Default Root Object`に「index.html」を設定します。これで「`/`」でアクセスした際に、エラーにならず「`index.html`」を呼び出すことができます。

しかも、デフォルトの(\*.cloudfront.net)ドメインであれば SSL 証明書までついてきます。  
まじで至れり尽くせりです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-5.png)

### Behaviors > Viewer Protocol Policy

新しい Behavior を作成して`Viewer Protocol Policy`にて`Redirect HTTP to HTTPS`を選択します。これで HTTP でアクセスされた場合に、HTTPS にリダイレクトすることが可能です。  
(あまりこだわりなければ`Path Pattern`は`Default (*)`1 つで事足りるはず。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-4.png)

## CloudFront 利用上の注意点

CloudFront を利用すると幸せになれるのですが、1 点注意点があります。それは**キャッシュ**です。

CloudFront の本質は CDN なので、コンテンツをキャッシュします。しかもデフォルトでは**24h キャッシュを保持**するので、S3 上にアップロードしたファイルは最大 24h 変更されません。

### Invalidations を利用して Cache をクリア

CloudFront には Invalidations というキャッシュクリアをする仕組みがあるので、これを使って CloudFront に対してキャッシュのクリアを指示します。  
(ただ、5〜10 分くらいかかります。リアルタイムではないです。)

CloudFront で Distributions を選択すると「`Invalidations`」というタブがあるので、ここで「`Create Invalidation`」ボタンをクリックします。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-6.png)

クリアするファイルを指定する必要があるので、例えば「`/index.html`」とか入力します。  
私の場合、フロントのリソースは結合＆minify＆バージョニングして最適化してしまうので、普段は`index.html`だけで十分です。

あとはキャッシュがクリアされるまで気長に待ちましょう。

## まとめ

「S3 ＋ CloudFront」を使うことでお手軽に AngularJS で作成した Web アプリケーションをホスティングすることができました。しかも勝手にスケールするし、クラウドサービス偉大過ぎます。

### しかし、上には上がいる！

今回の「S3 ＋ CloudFront」はまだ**大関**構成なようですね。個人的には頑張ったと思うのですが。。。orz  
こちらの記事を読むと、この上の「S3 ＋ CloudFront ＋ Route53」**横綱**構成があるようです。

[AWS における静的コンテンツ配信パターンカタログ（アンチパターン含む） ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/static-contents-delivery-patterns/)

もっと稽古します。

> (2015/01/20 追記)  
> `/`以外の URL でアクセスした場合に`403(access denied)`エラーになるのですが、CloudFront Distributions の Error Pages 設定で、403 エラーの場合のエラーページを`/index.html`にすることで回避することができましたー。  
> うぇーーーーい！！って無理矢理感が半端ない w

Tag: s3

AWS Lambdaを使ってS3にアップロードしたイメージを最適化する

特定のS3バケットにだけアクセスできるIAMユーザーを作る

期限付きURLを発行してセキュアなS3のオブジェクトにアクセスしてみる

AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話