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…ふむ、君に決めた！
　　　　　　　

それはまた、別のお話で。