安否確認の仕組みを真面目に考えてみた

安否確認の基本要件

安否確認が必要になったら自動で発動すること

ユーザが一気に来ても耐えられる事

ユーザの事前登録(通知先、居所)が可能なこと

（出来れば）マルチテナントで複数社が相乗り出来ること

ユーザの管理そのものは管理者が行うこと

費用はなるべく安く！

安否確認の情報はなるべく本家に近いところから取得として...

地震速報(警報)に限定すれば3万円あれば十分

真面目に探すとサードパーティっぽいAPIはもっと安いので上限はこのくらい

ユーザの管理は色々面倒なので、Auth0あたりにまるっと任せる方針として

費用はMAU(月間アクティブユーザ)なので、ほぼ10ユーザのアクセスもないんじゃ無いかと想定。最大アクセスはユーザ管理したい全員なので...金額はpriceページでどうぞ

APIへのアクセスは常時実施する必要があるので、Fargateあたりで常駐させる前提

固定IPが必要な場合はNAT経由してと...

ユーザ情報、事前登録情報、警報情報はまるっとDynamoDBで管理

管理画面系はAPI Gateway & Lambda & S3で構築

安否確認とかトレーニングしないときの固定費がかかるのはこれくらい

ユーザ毎の費用は無視すると10万円いかない程度？

安否確認イベントが発生したら...

登録ページを用意(S3)

dynamodbにイベント情報を登録

fargateの通知taskを実行

戻りのURLはLambda@EdgeなURLにしてLambdaで直接DynamoDBに登録しつつ、集計

一定期間の間、定期的にLambdaで管理者への集計結果の通知メッセージ＆緊急対応が必要な人のリストを送信

イベント発生時の費用はこれくらいなので...たぶん通知にかかる費用が一番高そうな程度でだいぶ安い

ほぼ固定の費用はないし、リクエストの上限も無視出来る(Lambda@Edgeのリミットに引っかからなければ)

ということで実はAWSとかSaaS使えば安否確認の仕組みって実装コストの方が圧倒的に高いだけだって事に気がついた夜中の地震でした