料金体系
AWS Lambdaは非常にきめ細やかな料金体系となっています。100ミリ秒単位のコンピュート時間と個々のリクエストに対する課金となっています。リクエスト数とはイベントが発生してLambdaファンクションが起動される回数のことです。コンピュート時間とはLambdaファンクションが起動してから終了するまでの時間となっています。100ミリ秒ごとの単価はメモリサイズによって異なっています。
以下の表は、料金表のページに記載のものを転記したものです。
| メモリ（MB） | 1か月の無料利用枠の秒数 | 100ミリ秒単位の価格（ドル） |
|---|---|---|
| 128 | 3200000 | 0.000000208 |
| 192 | 2133333 | 0.000000313 |
| 256 | 1600000 | 0.000000417 |
| 320 | 1280000 | 0.000000521 |
| 384 | 1066667 | 0.000000625 |
| 448 | 914286 | 0.000000729 |
| 512 | 800000 | 0.000000834 |
| 576 | 711111 | 0.000000938 |
| 640 | 640000 | 0.000001042 |
| 704 | 581818 | 0.000001146 |
| 768 | 533333 | 0.000001250 |
| 832 | 492308 | 0.000001354 |
| 896 | 457143 | 0.000001459 |
| 960 | 426667 | 0.000001563 |
| 1024 | 400000 | 0.000001667 |
なお、この表における価格はおおよその価格になります。
Lambdaファンクションに設定可能なメモリ量に応じて価格が変動します。メモリは最小128MBであり、64MB単位で設定することが可能で、最大で1024MB＝1GBとなっています。また、100ミリ秒以下の実行時間の場合、100ミリ秒に切り上げられます。
非常にややこしく勘違いしがちなのですが、単価としては1GBのファンクションを1秒間実行するにあたり$0.00001667となっています。つまり512MBのメモリ設定で1秒動かした場合は512／1024＝0.5ということで$0.00001667＊0.5＝$0.000008335となります。上記の表ではさらにミリ秒にしていますので10で割る必要があります。従って正確な値は$0.0000008335です。上記の表では$0.000000834となっていて四捨五入されています。これがおおよその価格であると述べた理由です。そして、実際に金額を計算する際は1GB、1秒あたりに換算して算出されます。
無料枠
その他のサービスと同様にAWS Lambdaにも無料枠が存在します。リクエスト数と実行時間それぞれで無料の範囲が定められています。リクエスト数のほうは月間100万リクエストまでは無料となっています。実行時間は前出の表のとおり、単価と同様にメモリの容量ごとに利用可能な無料枠が変動する設定となっています。
こちらについても単価と同様、1GBのファンクションが基準です。つまり、1GBのファンクションが40万秒まで無料で実行できるということです。従って仮に128MBのファンクションであれば、40万秒＊1024／128（＝8）の320万秒（約889時間）が無料枠となります。
料金の計算例
このとおりAWS Lambdaの料金は少し難しいところがありますので実際に計算例を示します。「512MBのメモリを割り当て、3,000,000回実行し、毎回の実行時間が1秒間だった場合」について実際に計算を行います。なお、すべて小数点第二位で四捨五入をしています。
まず、毎回の実行時間が1秒なので総実行時間は300万秒になります。次にファンクションのメモリが512MBと基準となる1GBの半分です。従って単価は半分になりますが、一方で無料利用枠は倍になります。従ってこの場合は以下のような計算になります。
300万秒 - 80万秒(40万秒 * 2) = 220万秒
$0.00001667 * 0.5(512/1024) * 220万秒 = $18.34
リクエストに対する課金額は、無料枠超過分が200万回で$0.2／100万回なので$0.4となります。従ってこの場合の課金額は以下のようになります。
$18.34 + $0.4 = $18.74
プレビュー時点での制限
さて、これまでAWS Lambdaについて紹介してきましたが、実は現時点ではまだプレビューの状態で提供されています。2014年11月の発表時はLimited PreviewでありAWSアカウントを持っていても別途サインアップが必要でしたが、2015年1月15日よりサインアップは必要なくなりAWSアカウントを持っていれば誰でも使えるようになりました。ただし、依然としてPreviewというステータスは変わらず、利用可能なリージョンも限られています。本記事執筆時点ではUS East（Northern Virginia）、US West（Oregon）と Europe（Ireland）リージョンでのみ利用可能です。
ユースケース
さて、ここまでAWS Lambdaの機能面に関する説明をしてきましたが、実際にどういったユースケースで活かせるのかをいくつか見ていきます。
イメージリサイズ、サムネイルの生成
1つ目のユースケースは、イメージのリサイズとサムネイルの生成です。
例えばユーザからの画像のアップロードを受け付けるようなシステムの場合、従来であればAPIサーバなどを用意して一度そのサーバで画像ファイルを受け取り、必要に応じてリサイズやサムネイルの生成を行ってAmazon S3のバケットに保存する、といった実装が必要でした。仮にAmazon S3のバケットに直接アップロードできるようにした場合は、そのバケットを常に監視し、新しいイメージファイルが増えていたらそのファイルに対して処理を行うといった仕組みを「自前」で実装する必要がありました。それがAWS Lambdaを使うことで非常に簡単になります。
以下の図のようにAmazon S3の特定バケットにイメージファイルがアップロードされると、そのイベントに応じてリサイズやサムネイル生成を行うLambdaファンクションが実行されます。つまり自前で実装する必要があるのは、リサイズやサムネイル生成の処理そのものだけとなります。
ログの監査と通知
もう一つのユースケース例として、AWSのAPIの監査ログ取得サービスであるAWS CloudTrailと連携させた例をあげてみます。
AWS CloudTrailではAWSのAPIコールを全て監査ログとして保管します。マネージメントコンソール上での操作も裏側ではAPI呼び出しが行われているため、AWS CloudTrailで監査ログとして残すことが可能です。この監査ログはAmazon S3上で保管されるため、Amazon S3にAWS CloudTrailのログが出力されたら、その内容を分析し、怪しい行動や異常があった場合は管理者に通知するという利用方法が考えられるでしょう。こちらも全てを自前で実装しようとすると非常にコストがかかりますが、AWS Lambdaを利用するとログの分析ロジックのみにフォーカスすることが可能となります。
ページの都合上、今回は2種類のユースケースしか挙げていませんが、その他にもAmazon S3に動画ファイルをアップロードすると、Amazon Elastic Transcoder（動画の変換サービス）を利用してデバイス向けの動画ファイルが自動生成されるようにしたり、モバイルアプリケーションにカスタムイベントを発行させてLambdaファンクションとして処理を実装することで、サーバーレスなモバイルアプリケーションバックエンドを実現したりすることが可能になります。イベントドリブンな処理を簡単に実現するAWS Lambdaのユースケースはこれだけにとどまらないでしょう。
