0. はじめに
今年の7月にAWSアソシをギリで取得した初心者が、AWSでそれっぽいことをする奮闘記である。の続き。
https://qiita.com/haman/items/3ab610dd4f3c00584dd0
一応、成功ルート。
1. やりたいこと
これはおさらい。
情報流出を防ぐために、みんなで作るLambdaのPOST先をSlackだけにシステム的に絞りたい。
2. 失敗ルートを活かして
上の図のsomething new!のところは、既存のものではなかなか実現できなそう。
であれば、自分たちで作れば良い。
言葉にすると、
みんなで作成するLambdaとAPI-GW（UserLambdaとでも呼ぼう）の後ろに、
検疫所の役割を担うLambdaとAPI-GW（Post_Lambdaとでも呼ぼう）を準備する。
構成図にすると、こちら。
3. リサーチ＆トライ
そもそも出来るんだっけ？を調べる。
この記事を見るに、うん、出来そう。（実際はこんなに早くない、検索は相当してる。）
AWS Lambda関数の呼び出し方を改めて確認する(2)
UserLambda
UserLambdaは、自力でインターネットに出れないようにするために、
前回と同様に、VPCを設定しプライベートサブネット内に閉じ込める。
これで外部へはいけない。
※CloudWatch logsなどはエンドポイント経由でアクセスする。
通常、インターネットゲートウェイをVPCにアタッチして、外へ出ていけるけど、
今回UserLambdaが連携する先は、AWS内にあるサービスであるAPIGWのため、
APIエンドポイント({api-id}.execute-api.{region}.amazonaws.com)を配置して通信する。
インターネットゲートウェイは不要。
Post_Lambda
Lambda側はチェックして、基本はUserLambdaから渡された情報をバトンパスするくらい。
API-GWはリージョンAPIではなく、プライベートAPIを利用する。
インターフェイス VPC エンドポイントを介して公開された API エンドポイント。これにより、クライアントは VPC 内部で安全にプライベート API リソースにアクセスすることができます。プライベート API はパブリックインターネットからは分離されており、アクセス権限を付与されている API Gateway の VPC エンドポイントを使用してのみアクセスできます。
こちらの記事のこの画像がとても参考になった。わかりやっす。
https://cloudpack.media/52328
4. 小石につまづく
なんかうまくいかない…なぜ…。
こういう時は、くだらない理由ってのは分かっているけど、まぁ先に進まない。
数時間つまづいた…
① urllibの使い方を間違える
完全な思い込み。
ゴミ情報も一緒に送っていた。
② API-GWデプロイし忘れ
最終的な疎通検証で一向に変化がなく、通知されない！
なんでだ…………からの気づいた時のあのアハ体験。アドレナリン惜しまない。
このデプロイし忘れ、「あるある」なんだろうな。
5. さて、次はこっちへ
さて、この仕組みをみんなに使ってもらう必要がある。
正直、しんどい。
UserLambdaは下記のとおり「閉じ込め」がとても重要なんだけど、
この「閉じ込め」のための設定（VPCやサブネット等の設定）を
ミスる可能性があり、うまく機能してくれないという問題がある。
そして何よりも、設定すべき項目が多くて非常にダルい。
これはいけない。
UserLambdaは、自力でインターネットに出れないようにするために、
前回と同様に、VPCを設定しプライベートサブネット内に閉じ込める。
LambdaやAPI-GWをテンプレ化して、もっと簡単にこのUserLambdaを作れるようにしたい！
Lambda テンプレで検索すると、CloudFormation…ふむ、君に決めた！
それはまた、別のお話で。