😺
個人開発でAWSのインフラ考えたんですが、これでどうですかね？何点ですか？
多分一番安い構成で月5000円くらいだと思う。
invokeとかあたりが、AWSに依存してるのが少し嫌だけど、仕方ない。
lambdaはAPIサーバーのdockerイメージをそのまま実行します。
今、余計なもの入ってて、イメージサイズが1.3GBとかになってて、さすがにこれは軽量化しないとダメだと思うけど。
lambdaに認証サーバーや決済サーバーとか複数あって、それらを1つのDBに接続してるけど、スキーマで分離してるので、今後、DB自体を分割とかもできます。
RDSとRedisをプライベートサブネットに配置してるけど、これは必要あるのか謎
NATとか使いたくないから、コスト増えるなら普通にパブリックで問題ない。
あとAPI Gateway側で全体のレート制限とかできるからそれでWAF外すのありかも。
IPのレート制限とかはできないけど。
そしたら安くて月3000円くらいに抑えられると思う
Discussion
前提の共有が不足しすぎていて点数をつけるのは難しい。
個人開発だからコレでいい、悪い、って話ではないし、システム開発における評価は万能なものもないし、そもそも機能の内容とか想定負荷とか何もないのにいい悪いの話はできない（はず）
図の手抜きかどうかはわからないけど、サブネットは両方とも複数に分割してあってゾーンを分けてあるかとか、CloudFront の後ろに WAF があるんじゃないかとか、誰がどの視点で点をつけるかにも左右されそう。
個人的にはこの図と内容を持ってこられたらいったん話を聞き直して、評価可能なレベルになるまでやり直し、という感じ。
想定負荷とかわからないです。
とりあえず利用者増えてもスケールアップできるようにみたいな感じです。
RDSとRidisは使用状況調べて負荷が多かったら手動でスケールアップみたいな。RDSに関しては自動的にとかは無理な気がする。lambdaに関しては自動でやってくれると思うけど。
コスト抑えたいのでAZは1だけです。でも中身lambdaくらいだし、たぶん2つとかにしても、費用はほとんど変わらない気がするから増やしてもいいかも
Cloudfrontの前にWAFはないですね。静的サイトダウンロードするくらいだし、キャッシュでなんとかしてくれそうだし、レート制限とか要らないじゃないかって思ってますが、この辺は手抜きです
優先するのをコストに置くのか、スケールにおくのか、によってもずいぶん変わる。
優先内容によって、どれを諦めているのか、次に改善するのはどこなのか、を理解しているのかどうかによっても変わる。
それらを明確に共通認識にするための説明が必要だって話。
個人開発だから、でこの共通認識は作れないから。
個人開発だけどすぐスケールが必要な大人気サービスになるぜって自信があるものを作るのと、細々とやりつついざってときには対応が可能なものを作るのと、いざって時にごたついてもいいからとにかくコストを抑えたい、では全然話が違うということ。
事業ユースに耐えられるセキュリティを担保するのかしないのか、障害対策をどの程度検討しておくか、によっても違うので、評価する側とされる側の認識合わせがまず大事だってこと。
初期コストは高くて月1万くらいが限界です。
その中でスケールアップを可能な限り容易にするみたいな感じですかね
細々とやりつついざってときには対応が可能なものを作るです。
事業ユースとか障害対策とかは実務経験ないしわかりません。
一般人向けを想定してます
そういう頭の中だけにあって共有されていない事項を整理して、ここまで想定している、ってのを書いて初めて他人に評価をもらうことができる。
実務経験の有無はシステム開発をするにあたって評価の対象にはならないけど、図表自体の評価には関係する。
何もわからないのにここまで書けてすごいね、という人もいるだろうし、この図面自体のダメさ加減にダメ出しをする人もいるかもしれないし、どういう前提条件でどういう評価をして欲しいのか、を明確にしないと期待する成果は得られない。
システム開発を理解していない人事なら図が書けるだけで採用するかもしれないけど、実務経験のある人間からしたら考慮事項を共有できない（誰でも書ける上に机上の空論な）資料が出てくる時点で不採用にするかもしれない。
ここから、ブラッシュアップして成長していく人間と、ごみを出してすいませんって記事を消しにくる人間といるので、後者じゃないといいなと思う。
ゴミだと思ってないので消さないです。
あなたならどう評価しますか？
まだ考慮事項があったら共有します。
前述のとおり前提が異なると評価の内容も価値も変わってしまうので、俺がこの記事の図面に対して点をつけても価値がないよ？というのを置いておくとして、甘口で評価して40点、辛口なら20点ってところ。
システム開発のプロの末席にいる者として、個人開発かどうかに関わらず以下の点で採点したい。
システム開発は要件定義｛要求｝があって初めてスタートするので、何を作るか、それで何を目指しているのか、どのくらいアクセスがあるのか、どういう機能が（アプリケーション的に）いるのか、開発環境から本番環境までどのように作るのかなどが明確じゃない図面には価値がない（見る意味がない。見てもわかんないし）
コストを最優先するならAWS利用自体が考慮外になりうる。Vercel など無料で使える範囲のSaaSは多数あり、前述の要件が固まっていないならMVPレベルとしてお金をまったくかけない、を優先してもいい。
少し譲ってAWS利用を前提としてコストを下げるなら、RDSの選定は時期尚早かもしれないし（MySQL on EC2のほうがコストは遥かに安い）、 Lambda によるサーバーレスベースなら Aurora Serverless v2 は利用状況に応じて検討があってもいい。
これらの選択肢についても前提の段階、もしくは図の説明時に選定理由を説明できなくてはならない。
個人開発だからって理由でセキュリティを後回しにして、問題が起きた後で右往左往するのはよくあるケース。
個人開発だからこそできる限りのセキュリティ対策を図面で表現できる力がエンジニアには求められる。
パブリックサブネットとプライベーサブネットの利用可否がセキュリティ面にどう影響するのか、がわからない時点でダメだし、図の価値が（セキュリティ的には）ないに等しい。
DBをパブリックにもっていくなんてとんでもない。
CFr って意外とコストがかかるので、それこそ個人開発なら無料で抜ける範囲で CloudFlare を考慮にいれることもできる。
AWS前提でコストも意識してどうにかするならエンタープライズ契約でごにょごにょできないと辛いので、コストだスケールだって言うならこのあたりはてんでダメ。
Lambda を使うのがスケールだと万が一思っていたなら根本から検討し直す必要があるかもしれない。
今回に限らず、図というのは見る人に何かを伝えるための補足するもの、であるべき。
テキストによる前提の共有、できる限り正しい図、必要な補足、が揃って初めて価値がでる。
が、書かない人、書けない人も多い中で、図を書いて記事を書いただけでも価値がある、という評価はあっていいので、甘口で40点、辛口で20点、（書いたから）という評価にした。
AWSの図面を引くのにアイコンセットを利用しない点は評価から除外した。
AWSの人が評価するならそれだけでマイナス10点ｗ