S3イベント連携 with Lambda！AWSでサーバーレスに触ってみた #2

こんにちは。クラウドサービス部の小池です。

サーバーがない状態でどうやってシステムを構築するのか想像できない、実際に手を動かしてみないとピンと来ないという、スキルシフト仲間の声にお答えしたサーバーレス初心者向けの連載第2回です。

今回ご紹介するのは、「S3のイベント通知を使ってLambdaと連携する操作」と「Lambda関数の実行後にユーザにEmailで通知する機能の作成」です。

ここからは、AWSが公開しているハンズオン^※のセクション2をもとに実際に手を動かした結果や、前提知識が足りなくて迷ったところ、理解を深めるポイントを詳しく解説します。画面遷移は多少変わっていますが、ハンズオン手順の通りに構築は問題なくできます。

※ サービス連携の体験ハンズオン

「サーバーレス構築とは何なのか」について理解し、公式ハンズオンの隙間を埋める手がかりとして、この記事をご覧ください。

S3イベント連携 with Lambda

S3のイベント通知を使ったLambdaとの連携を実行していきます。

作業環境

Webブラウザ	Firefox
作業する リージョン	AWS東京リージョン[アジアパシフィック(東京) ap-northeast-1 ]
利用する サービス	AWS Lambda（イベント発生時にコードを実行）| AWS Amazon S3（拡張性と耐久性を兼ね揃えたクラウドストレージ）｜AWS Amazon SNS（サーバーレスアプリのための pub/sub メッセージングサービス）| AWS

S3とは

Amazon Simple Storage Service、略してS3（エススリー）は、AWSが提供する高度なオブジェクトストレージサービスです。何がすごいかと言うと、耐久率が99.999999999%（イレブン・ナイン）なのです。オンプレミスのストレージ保守と比較して、ほとんど壊れません！

また、利用した分だけ支払う従量課金で、利用容量に上限がない点も魅力的です。第1回の連載でご紹介した「WHY サーバーレス？」の理由のひとつがここにあると感じられます。

S3バケットの準備

ハンズオン手順に従い、汎用的なバケットをデフォルト設定で1つ作成します。サーバーレス構築と異なり特別なコツは不要で、ハンズオンではデフォルト設定のままとしています。

とはいえ、セキュリティやコスト観点から、自分が作成したリソースを後から追跡できるようタグを有効化したり、万が一に備えてアクセスログの記録を有効化したりすることをお勧めします。

バケット タイプ	汎用	選択
バケット名	rkoike-handson-backet ※ 冒頭部はユーザ固定読み替えしてください	入力
オブジェクト所有者	ACL無効（推奨）	デフォルト
ブロックパブリックアクセス設定	パブリックアクセスをすべてブロック	デフォルト
バケットのバージョニング	無効にする	デフォルト
タグの有効化	UserName	個人名入力
デフォルトの暗号化	Amazon S3 マネージドキーを使用したサーバー側の暗号化（SSE-S3）	デフォルト
アクセスログ記録	有効にする ※ 送信先は任意のバケット、プレフィックスなどもご随意に	選択

Lambda画面でのS3トリガー設定

マネージメントコンソールへの入力項目は、以下の通りです。

トリガーの設定	S3	選択
backet	s3/rkoike-handson-backet	先ほど作成したバケットを選択
イベントタイプ	すべてのオブジェクト作成イベント	デフォルト
再帰呼び出し	～了承する	チェック

S3イベントトリガーでLambda関数を動かしてみた

手元にあった、ChatGPTで生成した画像をS3バケットにアップロードしてみます。

すると、S3イベントを検知してLambdaが動き、ログに記録されました！
ふむふむ。ハンズオンに記載の通りですね。

SNSとは

SNSというと、一般的にはソーシャルネットワークサービスの略称で使われますが、ここでは違います。

AWSのサービスとして、Amazon Simple Notification Serviceの頭文字を取ってSNSと呼びます。SNSはその名の通り、通知を行うための仕組みで、アプリケーション間の連携（ファンアウト）や、対個人つまりモバイルアプリや各種携帯電話へのSMS通知のようなテキスト送信から、Email通知なども実装可能なサービスです。

SNS実装の準備

ここからは、SAA（AWS Certified Solutions Architect - Associate）の試験勉強で頻出の連携部分の実装です。自分でやってみるのは初めてで興味津々です。

SNSトピック作成時の入力項目は以下の通りとしました。ここでも、自分の作ったリソースを後から追跡するためにタグを有効化します。

タイプ	スタンダード	選択
名前	rkoike-email-topic ※ 冒頭部はユーザ固定読み替えしてください	入力
表示名	同上	入力
暗号化	暗号化しない	チェックしない （デフォルト）
アクセスポリシー	（特に設定しない）	デフォルト
データ保護ポリシー	（特に設定しない）	デフォルト
配信ポリシー（HTTP/s）	（特に設定しない）	デフォルト
配信ステータスのログ記録	（特に設定しない）	デフォルト
タグの有効化	UserName	個人名入力

続いてサブスクリプションを登録します。

トピックARN	トピックARN	（先ほど作成したSNS トピックを指定）	検索
プロトコル	Eメール	選択
エンドポイント	（自分のメールアドレス）	入力

この内容を入力してサブスクリプション作成ボタンを押すと、数分後には設定したメールアドレスに「AWS Notification - Subscription Confirmation」という件名のメールが届きます。

メールの本文中の「Confirm Subscription」をクリックしてメールアドレスを認証すれば、準備完了です。

Lambda実行後にEmailで結果を通知してみた

Lambda画面でSNSトリガーを設定します。

ソース	ソース	非同期呼び出し	デフォルト
条件	正常	選択
送信先タイプ	SNSトピック	選択
送信先ARN	（先ほど作成したSNS トピックのARN）	検索＋選択

再びS3バケットにファイルをアップロードしてみると、Lambdaの稼働ログがCloudWatchログに記録され、メール通知も来ました。

前出のアップロードログにLambdaメッセージが付加されたような形ですね。

S3とSNSのお財布事情

さて、ここまではハンズオン資料のおさらいとその結果の共有でしたが、実際利用するにあたって気になるのは、費用の問題ですよね。前回はLambdaについてまとめたので、今回はS3とSNSの費用をダイジェストしてみようと思ったのですが......。

S3 Standardは最小単位が0.025USD/GB、1,000リクエストあたり0.0047USD、SNSはEmail通知の場合USD2.00/10万通知、と、今回の検証のみの従量課金額はまたもや1円以下の世界でした。あまり試算の意味がありませんね。

実際にかかる費用は、連載第1回に記載したLambda同様に、扱うデータ量と処理内容、処理する頻度によると考えてください。

※ 参考：料金 - Amazon S3 ｜AWS

おわりに

さらに他のサービスとLambdaの連携を試して、Lambdaの可能性を広げてみましょう。次回は、SNS、SQS、Lambdaを連携させてファンアウトできるような仕組みを作ります。

Stay tuned for next time！

なお、ラックはセキュリティの会社ですが、筆者のようなスキルシフト中のエンジニアだけでなく、経験豊富なクラウド技術者やコンサルタントが多数在籍しています。AWSだけではなく、OCI、Azure、Google Cloudも取り扱い、クラウド移行からクラウドネイティブ支援、サーバーレス構築まで、幅広くサポートしますので、お気軽にご相談ください。

プロフィール