Amplifyで企業向けSaaS作ってみた
CTO/CPO�近藤 徳行
Agenda
1,事業（課題）説明
�2,スタートアップあるあるの問題に対するソリューションとしてのAmplify� 一人で複数環境のCI/CDとかできますか？��3,大手企業向けサービスあるある� IP制御及びアカウント管理のためのマルチCognitoUserPool設計 � AmplifyでVPCにDeploy� マルチAWSアカウント運用の必要性とAmplifyブランチ戦略＆Tips�
4,まとめ
1,事業説明：こんな業務ご存じですか？
○○さんのサービスを使いたいんでセキュリティの質問に回答してもらっていいですか？
もちろん、回答しますよ！
大きめ企業�（顧客候補）
SaaSプロバイダ�システムベンダ�（の営業さん）
1,事業説明
Excel形式でメールで来る、割とエグい内容と量のセキュリティに関する質問の依頼、回答の業務。質問する側の管理負荷も非常に高い。このセキュリティチェック業務を効率化するサービス。
お願いします！
1,事業説明
A社
B社
ベンダー①
ベンダー②
やらなければいけないこと
１、スタートアップあるある� 開発者は現状ひとり。で、企業向けSaaSを開発する��２、大手企業向けあるある� 大手企業がターゲットとなるため、セキュリティの基準は高い。� また、境界型防御でかっちり固めている企業も多く、サービスにアクセスで きるIPの制御などが機能性に求められがち。� アカウント管理をしっかりやられる企業も多い。� �そして、��３、セキュリティサービスを提供している以上、� 内部統制上問題ない構造を初期から目指したい。
注意書き
１，提示するアーキ図は抜粋です。
２，本プロダクトは来年リリースを予定している内容です。� そのため内容自体が今後変わることはあります。�３，実際に動いてます
Amplifyで企業向けSaaS作ってみた
2,スタートアップあるある 生産性向上
2,スタートアップあるある：開発ひとり
1,開発人員が少ない� かといって副業の人をたくさんアサインしても、� 基盤部分が入れ替わるフェーズも多かったため、生産性が出ない公算が高い
あれ、フレームワーク変わってね？
なんかLambda分割されてる？
ごめんて
2,スタートアップあるある：CI/CD苦手問題
2, CI/CDとか苦手。ビルドに習熟すればいいとは思うが、� 何せリリースまで時間がない。めんどい。� 「マージしたらビルド・デプロイしてくんねぇかな～」という熱い想い
2,スタートアップあるある：環境複数つくるのめんどい
3,環境が一つしかないので、開発環境使って顧客候補にデモしてもらっていた。� 環境を多重化して、デモ、開発など分けたい。� 長期的には、本番環境の分離。� でもverUpの時のメンテコストが上がらないようにしたい。
まぜるな�危険
2,スタートアップあるある
1,開発人員が少ない��2, 「マージしたらビルド・デプロイしてくんねぇかな～」という熱い想い�
3, CEOに安心してデモしてもらいたい（開発も安心したい）
��1人でも簡単にCI/CDを回せて複数環境分けて高効率で開発できるソリューションがほしい！！！
2,スタートアップあるある 生産性向上
2,Amplify導入による改善効果
課題①リソースに関してamplify-cliで対話的にcloudFormationで記述可能� →都度自分で構築しなくていいので工数削減に成功
課題②CI/CDフロー� →Javaのビルドで躓いてDockerImageを自作� (https://gallery.ecr.aws/v5a0p7x7/amplify-build-java11-gradle)� →その後は自動化できており、マージすることで環境に静的コンテンツから GraphQL、Lambdaまで自動Deployできている��課題③同一アカウント内の複数BackEnd環境� → amplify env コマンドの利用で１コマンドで環境作成可能� CEOは開発環境でデモしなくてよくなったよ！！！！！��上述の課題が解決したため、この部分に対しては、開発効率が大幅に改善。
3,大手企業向け対策①マルチUserPool戦略
課題：大手企業がターゲットとなるため、セキュリティの基準は高い。
また、境界型防御でかっちり固めている企業も多く、サービスにアクセスで きるIPの制御などが機能性に求められがち。
アカウント管理を重厚にしたい。
これを各企業ごと（テナント）に求める、、、だと？
＼(^o^)／ｵﾜﾀ
こんなん普通に実装してるだけで、ワイの工数余裕で消えるやで、、、
むしろ、書きたくない。絶対に書きたくないでござる（画像省略）
そうだ、Cognito UserPoolをテナントごとに分けよう！
各テナントごとに、UserPoolを分ける設計��1,Cognitoの機能によりIP制御等は可能��2,アカウントに関しても、UserPool内のアカウントを確認してもらい、� 不要なものを削除するなどすることで対応可能
�で、これら各UserPoolで認証した内容をフェデレーションし、AmplifyのIDPoolに連携。
3,大手企業向け対策①マルチUserPool戦略
3,大手企業向け対策②VPC利用
3,大手企業向け対策②VPC利用
製品の戦略上、顧客DBはVPC内に入れたい、、、�ということはLambdaもVPC内に入れたい、、��ってAmplifyでできるんでしたっけ？
できました！
関数名-cloudformation-template.json
�右記の通りですが、
VpcConfig内に
SecurityGroupIds
と
SubnetIds��を登録することでできました。��参考��If文いっぱい入っちゃってるのはこれを複数AWSアカウントでデプロイしているからです
3,大手企業向け対策③マルチアカウント戦略
内部統制上の理由により要求されます。��ただ、この部分に関してはどうやったかの前にまず、なぜこれがいるのか、�が、納得のために重要になるのでその説明にしばしおつきあいください。
20秒で内部統制
みなさんはお客さんだとします。
お客さんはベンダーに自社の大事なデータを預けています。
でもお客さんはベンダーの裏の裏まで見えません。
そのために、ベンダー内外にあやしい人がいてその人が悪さできると困ります。
20秒で内部統制
それらを防ぐため、定められたルール、プロセスがあり、そのとおりに運用している、ということが大事
このルール（線路）の基本構成要素がアカウントと権限
これらのルールを構成する要素でいちばん大事なのがアカウントと権限
�なぜなら、そもそもそこにアクセスできないから問題ない、というのは強力なロジックになります。（線路がないと走れない電車）
これらが正しく管理されることでより�安全な（リスクの低い）運用が可能。
3,大手企業向け対策③マルチアカウント戦略
前職でSOC的な資料を作っているとき、、社内監査的な人から聞かれたこと��ところでAWS商用環境にアクセスできるのはだれですか？（アカウント管理とその付与ルール）��退職者とかも居ると思うので定期的に棚卸していますか？（アカウントの棚卸）
3,大手企業向け対策③マルチアカウント戦略
（うっせぇわ）
大事ですよねー��弊社の場合開発AWSアカウントに副業の開発者に参加してもらっている時点でまあまあこの棚卸タスクがめんどい。��というかタスクの内容によっては副業開発者はほとんどの場合商用環境を触る必要がない。
仮に同一AWSアカウント上で実行する場合、IAMロールやポリシーで制御する必要があり、マジ私レベルのAWS使いには無理
（個人的に）ありそうな怖い話
例えば金曜の夜、この処理を今日中に動かさなきゃいけない開発案件があって、それが権限エラーで落ちています。��とりあえずつよつよ権限をつけて動かそう、後で適切な権限になおそう��動いた！マージ！！ おつかれさん！���まっさらな気持ちの月曜日が始まる
この時の設定が後のセキュリティインシデントを引き起こすことを知るものはいない、、���ええ！私はやる自信がありますとも！！！！！
なんでマルチアカウントにするのか
開発アカウントのアカウント管理、IAMロール、ポリシーはえてして荒れがち。��開発環境だけが入っているなら問題がないが、同環境に本番環境が同居している場合にこれに相当気を遣う。→私のような開発者には実質的に不可能
だから開発アカウントと商用アカウントをわけよう！！！！�そうすれば本番環境にアクセス可能なアカウントのみを監査対象にできるし、�変なIAMロールも作成されない�
いやでもそんなん工数的に無理ゲーでしょ、、？
もともとの弊社AWSアカウント
開発用のAWSアカウントが１つだけ
mitsucaru-dev
ControlTower導入
重厚なアカウントとかOU達がポチポチでできます。
Security OU��������
Log Account
mitsucaru (Master Account)
Audit Account
Sand box OU��������
mitsucaru-dev
Develop OUを作り、マスターアカウントに参加
（SandBox OUに素振り用のアカウントをつくって本番環境構築の準備してました）
Security OU��������
Log Account
mitsucaru (Master Account)
Audit Account
Sand box OU��������
Develop OU��������
mitsucaru-dev
mitsucaru-test
本番環境構築
Security OU��������
Log Account
mitsucaru (Master Account)
Audit Account
Sand box OU��������
Production OU��������
Develop OU��������
mitsucaru-dev
mitsucaru-pro
mitsucaru-test
別アカウントでどうやるの？
1, AmplifyをCloud9のamplify-cliからしれっと初期化 amplify init� これによりAmplifyにアプリケーションが一つできる
2, GitHubからブランチを参照してAmplifyでビルド� この対象バックエンドを先ほど作成したprodを選択することで、� 作成したアプリケーションにDeploy可能��永続層とVPCとSES以外は上記手順で適用完了。��Amplifyしゅごい
3,大手企業向け対策③マルチアカウントのDeploy
まとめ
Amplifyは生産性向上の為に取り入れたソリューションでしたが、�工夫次第で（内容次第ですが）企業向けSaaSを作ることのできるソリューションだと感じました。
Twitter�@tkykknd_
でAWSや開発中の�発見をつぶやいています。