Amazon Web Services ブログ
【開催報告＆全資料まとめ＆QA公開】Amplify Meetup #02
新年明けましておめでとうございます！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉（@kimyan_udon2）です。私は年始早々、厳かな気持ちでこのブログを書き始めたのですが、気づけば2月に突入しておりました。皆様いかがお過ごしでしょうか？
年をまたいで2020年11月27日に「Amplify Meetup #02」を開催しました。「Amplify Meetup」はAWS AmplifyのユーザーとAWS Amplifyに興味のあるエンジニアのみなさんでLTなどを通して盛り上がるコミュニティーイベントです。タイトルに「#02」とありますように、今回は第2回目の開催となります。第1回目の盛り上がりも開催報告ブログにまとまっております。継続して開催できたのは、ひとえにご参加いただいた皆様のおかげです。皆様ありがとうございます！
おさらい：「Amplify Meetup」とは？
「Amplify Meetup」はAWS Amplifyに興味のあるすべてのエンジニアのためのコミュニティイベントです。また「AWS Amplify」はセキュアでスケーラブルなモバイル・ウェブアプリを構築するための開発プラットフォームです。
Amplify Meetupを通してAWS Amplifyの知見を共有して、日本語の情報を増やしていきましょう！今後Amplify MeetupではAWS Amplifyに関する情報交換と、AWS Amplifyの日本コミュニティを盛り上げることができるような、様々なイベントを開催予定です。
Amplify Meetupは次回も開催予定ですので、ぜひ皆様ふるってご参加ください。AWS Amplifyなどの、AWSでのフロントエンド関連のイベントを告知するconnpassグループでメンバー登録すると、イベント開催の通知を受け取ることができます。今回のLTでone more thingとしてご紹介したAWS Amplify JapanコミュニティーSlackでも告知いたしますので、ぜひこちらにもご参加ください！
第2回のおしながき
今回も第1回に引き続き、AmplifyユーザーによるオンラインLT会を開催しました！Amplifyを本番環境で利用されているユーザーの方々に、Amplifyの良さ、運用のコツ、工夫したところなどについてざっくばらんにLTしていただきました。
今回も登壇者に質問できるようにしました。かなり多くの質問をいただき、すべての質問をご紹介することができなかったので、今回は紹介しきれなかった質問を回答とともに掲載しております（登壇者の皆様、ご協力ありがとうございました！）。また、前回と同様に当日の盛り上がりは、ぜひTwitterハッシュタグ「#AWSAmplifyJP」をチェックしてみてください！
さて、第2回目は以下のような内容で開催しました！ご参加叶わなかった方も、こちらの資料やTwitterのハッシュタグなどで雰囲気を感じてみてください。
- 「Amplify でちょっと大きめのサービスをつくってみた話 」田中 優位 さん（株式会社イオレ サービス運用・開発部 シニアエンジニア）
- 「Amplify と React / ReactNative でマルチプラットフォームアプリを1ヶ月で作る」宮近 雄宇 さん（フリーランス）
- 「コーポレートサイトを静的化して Amplify Console にデプロイする」加藤 尋樹 さん（株式会社はてな）
- 「AWS Amplify 関連のアップデート振り返り」じゃが（アマゾンウェブサービスジャパン株式会社）
LTのご紹介とQ&A
「Amplify でちょっと大きめのサービスをつくってみた話 」田中 優位 さん（株式会社イオレ サービス運用・開発部 シニアエンジニア）
イオレさんでは「らくらく連絡網.app」という連絡特化型の連絡網アプリでAWS Amplifyをご活用いただいています。今回はこのアプリの開発を通して、従来の技術スタックとAmplifyを比較しながら「実際に大規模サービスでAmplifyって使えるの？」という点に切り込んでLTしていただきました。
実際に大きなサービスでAWS Amplifyをご活用いただいているという点はとても説得力がありますね！また、スライドの最後に「機械（AWS Amplify）に任せるところは任せ、人間らしく生活しよう」という言葉があり、Amplifyおじさんとしては感無量です。
質問と回答（回答：田中 優位 さん）
Q: Amplify の学習をどうしたのか知りたいです（全登壇者に対して。。）公式ドキュメントやチュートリアルはあるけど、日本語の解説記事が少ないのかなとおもうんですが、、
基本的には Amplify 公式ドキュメントを指針にして簡単なチュートリアルを手始めに、不明点はググったり、実際に手を動かしながら学習していきました。最もお勧めする学習法は、amplify コマンドを叩く前のフォルダ・ファイルとコマンドを叩いた後のフォルダ・ファイルを実際に比較してみることです。
Amplify は言ってみれば CloudFormation とそのリソースに関わるファイル一式を生成してくれるジェネレータなので、具体的にコマンドの生成物を調べると挙動や意図が掴めます。少し面倒に感じるかもしれませんが、こうした scaffold 系のフレームワークは内部挙動をいかに把握するかが理解の鍵になりますので、この方法をお奨めしたいと思います。
Q: APIのロジックを記述する際、VTLとLambdaをどのように使い分けていますか？
私たちのケースでは Mutation 系は Lambda-backed の AppSync (@function を利用)、Query 系は amplify が生成したリゾルバをそのまま使うことが基本スタイルになりました。なぜなら Mutation 系はビジネスロジックで権限を判定して成否を決める必要があり、こうしたビジネスロジックは AppSync のリゾルバのレベルで記述するにはやや複雑であること、また、共通化がややしづらいためです。
Pipeline リゾルバを駆使して書くことも検討しましたが実際にやってみると VTL のデバッグし辛かったり CloudFormation テンプレートが複雑になりがちということもあり Mutation 系はシンプルに @function で組み立てる方式に自然と統一されていきました。
Q: Amplify で作ったアプリの構成図の生成方法はありますか？
AWS Perspectiveを利用すると、構築中のサービスの構成を可視化することができます。
Q: 実環境を用いたe2eテストは、ネイティブアプリでのお話なんでしょうか。それともWebもでしょうか
発表では E2E と言ってしまいましたが、厳密にはクライアント側をエミュレートした形で API を叩いています。テスト用の amplify env を用意し amplify push でデプロイ後、シナリオに沿って API を叩くといった流れを CI で自動化して実行しています。
Q: Amazon Pinpointをどのようにサービスに活用されているか知りたいです。
Amazon Pinpoint は現状ではユーザーの利用状況、DAU, MAU の確認、OS・機種別の統計情報の取得・分析に利用しています。データの格納がほぼリアリアイムに行われ、古いセグメント情報が残ったままにならない点や他の AWS サービスとの連携のしやすさを評価し AWS Pinpoint を採用しました。
Q: DDBのデフォルト値がないと困る理由がわからなかったので詳しく知りたい
例えば User テーブルに新しく attrA 属性（値は 0,1,2 などを取る）を追加してこの属性で検索をしたいようなケースになります。DynamoDB テーブルはキー以外はスキーマレスですので、蓄積済みのレコードには attrA のデータが存在しません (empty)。この場合でもテーブルにインデックスは追加できますが、属性追加後に新しく追加したレコードに対してのみ検索が有効となり、蓄積済みのレコードに対しては検索できずヒットもしません。これをヒットさせられるようにするには、まだ attrA が無い既存のレコードに対しても値を設定する必要があります。
Q: DynamoDBの構成変更は、DBアクセスの1回のデータ量を減らして、回数を増やしたということでしょうか？
はい。方法の一つは、取得件数 (limit) を少なくし、回数を増やすという対応をしました。また、その他の方法として、AWSJSON の配列型で子属性データを持っていたテーブルの設計を見直し、@connection を用いて Relational なモデル設計に変更して取得データそのものを削減するという対応も行いました。
Q: AppSyncのパフォーマンス分析＆チューニングとかどうしました？
負荷テストを実施し、サーバ側は CloudWatch メトリクスを参考に、クライアント（アプリ）側は Profiler を用いました。このテストは最もパフォーマンスが懸念される機能にスコープを絞った上で、仕様上見込まれる最大データ件数のテストデータを実環境に用意して行いました。AppSync のチューニングは SDK レベルで修正することも検討しましたが、今後の SDK アップデートに支障がでることが予想されたため、データ取得件数の制限することで回避しました。
Q: Androidが遅いのってamplify-androidですか？それともandroid-mobile-sdk？（名前忘れた）ですか？
AWS Mobile SDK for Android です（開発時、Amplify Android は出たばかりで production-ready ではありませんでした）。SDK 内部で利用しているライブラリ Apollo client の Object Mapper が遅かったと記憶しています。
Q: Storageとの連携など、他のAWSサービスとの連携を行う実装の難易度はどうでしたか？
Storage は Amplify の storage 機能で S3 バケットを作成しましたが、サービス仕様にフィットさせるため Presigned URL を利用するケースなどがあり、幾分カスタマイズが必要になりました。もちろんカスタマイズといっても基本的に AWSの各サービスの設定を CloudFormation で記述しているだけですので、各 AWS サービスの使い方さえ決めてしまえば後は単に CloudFormation で書き換えるだけの世界になります。
Q: Amplifyで規模が大きいサイト、システムを作る場合のコスト感を伺いたいのですが、実際、既存のサイトと比較してどの程度だったのでしょうか。
開発コストに関して、学習コストはある程度かかります。特にCloudFormationに関しては慣れというか、試行錯誤が必要かとおもいます。Amazon DynamoDBを使ったことがない方はインデックスの貼り方やリレーションの作り方にも慣れが必要かと思います（慣れてしまえば圧倒的に開発スピイードが上がります）。
運用コストに関しては、大きな規模のサービスでもサーバー調達が必要なく、オンデマンドのコストの計算になるので、サービスの成長に合わせて最小限のコストしかかかっていないという状況です。
Q: アクセスが集中したときにパフォーマンスの変化などありましたか？
A: 突発的なアクセス急増（スパイク）には注意が必要でした。特に DynamoDB のキャパシティはオンデマンド設定だとしてもキャパシティが実際にスケールするまでにタイムラグがあるからです。こうしたスケーリング最中はパフォーマンスの劣化というよりは、そうしたスロットリングが起こるケースを想定して、アプリケーションを設計（リトライ可能にするために処理を冪等にするか、エラーで失敗させる＝ All or Nothing にするか）が重要でした。
参考: 読み込み/書き込みキャパシティーモード – Amazon DynamoDB
Q: ローカルでも同じ環境を持てるっと言うのは、具体的にどういうことでしょうか?
A: 開発者個々人が自前のPC環境で本番環境と同じサーバ構成・サーバ性能を再現し開発時に利用できるという意味でお話させて頂きました。Amplify では amplify env checkout コマンドで自分用の環境に切り替えたり、共通の開発サーバ環境に切り替えることができますが、その際に作成される環境は、個人用であって他の共同利用環境でも基本的には同じ環境になります。
Q: DynamoDB、AppSyncの問題点としてリレーションの多いデータで苦労しませんでしたか？ElasticSearch or RDBを併用せずに作れましたか？
A: 私も当初そのような懸念を抱いていましたが、 リレーションや単純な属性の検索に関しては @connection や @key でほぼ解決できることが分かりました。ElasticSearch が必要になるケースは今のところ全文検索（部分一致を必要とするコンテンツに対する検索など）と局所的かと思います（実際、ElasticSearch は現在本番導入していません）。
ただ、リレーションが多くなると @conneciton などの属性が多くなるため AppSync が生成するリゾルバファイルが最大バイトサイズを超過してしまうなど別の問題が発生します（これに関してはリゾルバ内のコメント行を削除したカスタムリゾルバを配置することで解決しました）。リレーションに関しては現在のところ @connection, @key で基本的な 1:1, 1:n, n:n 関連を問題なく設計・実装できるため現状 RDB は利用していませんし、今後も主DBとしては利用する機会はあまりないだろうと考えています。
参考: API (GraphQL) – Data access patterns – Amplify Docs
Q: AWSアカウントの分け方、環境差分の管理が知りたいです、あとgitはCodeCommitですか？
環境毎に AWS アカウントを分けています（開発、ステージング、本番）が、開発ではエンジニア個々人の環境やテスト環境も入っているため、アカウント毎のクォータに引っかかる事があり（CloudFormation スタック数など）クォータ引き上げが必要になることがあったのと、amplify delete など全滅系コマンドが実行されてしまうリスクや IAM アカウントの権限設定などが複雑になる可能性があるので、今から始める方は 1 Amplify 環境 = 1 AWS アカウントにする事を強くお奨めします。沢山 AWS アカウントが出来て管理が煩雑になるように思えますが、実際はその逆でシンプルになります。
環境差分については CloudFormation テンプレート内で切り分けする手法を用いています。Conditions に各種環境を示す値を定義し（例: IsProduction, IsStaging, IsTest など）、Resource の Condition でこの環境を示す値を参照させてリソースの作成や設定値を切り分けます。参考 (https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html) その他、あまり実施したことはありませんが API では env 変数を利用して処理を分岐させたりもします。
（AWSJじゃがより）2020/12/23現在、Amplify ConsoleではクロスアカウントのCode Commitリポジトリの利用に対応しておりません。そのためマルチアカウントでAmplify Console をお使いいただく場合は、1) GitHubなどAWS外部のリポジトリを利用する、または 2)アカウントごとにリポジトリを作成し、メインのアカウントのリポジトリにgit pushした際に他のアカウントのリポジトリに変更内容をコピーするようなAWS Lambda関数を用意する、必要があります。
Issue : https://github.com/aws-amplify/amplify-console/issues/917
Q: DynamoDBがリクエスト、ReadとWriteの内訳しりたい
アプリケーションやサービスの仕様次第だと思われますが、基本的には Read が主です。ただ、DynamoDB のトリガー (Stream) や Lambda の非同期呼び出しなどを使って他のテーブルにデータをコピーする処理などメインスレッドとは別にバックグラウンドで動作する処理では Write が比較的大きな比重を占めています。
Q: AppSyncとAPI Gatewayをどのように使い分けてますか？
自分たちも使い話はじめはどちらが良いのかと考えておりましたが、結果的には98%ぐらいはAppSyncを使うことにしています。Cognitoの認証をした上で、認証後に叩くAPIはGraphQL API(AppSync)で実装しています。一部認証前の段階でREST APIにしたほうが取り回しがしやすい部分があり、REST API (API Gateway)として実装しています。
Q: インフラ0人とのことですが、監視などは何を使っていますか？サービス断のときに24時間電話連絡いく、などやるとしたら人数すくないなと思いました
CloudWatch Dashboardを活用しており、サービスの状態が一目でわかる状態になっています。また、CloudWatch Alarmも利用して、以上が起きた際にアラートを飛ばす仕組みになっています。このように自動化を行うことで、アプリ開発から運用まで、一つのチームで完結した体制を整えています。インフラチームにはアカウントの払い出しやIAMのセットアップ作業をサポートしていただきました。
「Amplify と React / ReactNative でマルチプラットフォームアプリを1ヶ月で作る」宮近 雄宇 さん（フリーランス）
フリーランスとして様々なお客様のDX支援をなさっている宮近さんからは、React NativeとAWS Amplifyでストリーミングアプリを制作された際のお話をLTしていただきました！
LTでは「技術的お砂場」として、React NativeとAmplifyの素振りもかねて作り始めたストリーミングアプリに1ヶ月でどんどん機能が追加されていくストーリーを追体験できました！これは、まさに私がAWS Amplifyで得られる価値としてお話している「小さく初めて大きく育てるビジネスを展開するお客様に最適です！」を実践なさっている例だと感じ、とてもうれしかったです。
AmplifyとReact/ReactNativeでマルチプラットフォームアプリを1ヶ月で作る
質問と回答（回答：宮近 雄宇 さん）
Q: Amplify の学習をどうしたのか知りたいです（全登壇者に対して。。）公式ドキュメントやチュートリアルはあるけど、日本語の解説記事が少ないのかなとおもうんですが、、
情報源としてはやはり公式Docが一番ですね。ざっと読むときは機械翻訳で十分です。いつの間にか重要な情報がサラっと追加されていたりするので、不定期に読み返したりもします。
またAmplifyに限らずですが、内部向けのクリティカルではない何かのシステムを作ることで、技術の習得、評価を行っています。限りなく本番っぽい素振りをすることで、Docに出てこないハマりポイントなどをあぶり出しています。
Q: サービス開発に利用されたReact Nativeは一から環境を用意されたのでしょうか。それともReactNative expoを活用されたのでしょうか。
React Nativeが初めてだったので、当初は何も考えず簡単そうに見えたExpoを採用しました。ところが利用するライブラリの都合でejectすることになりました。今では素のReact Native環境しか使っていません。
ビルドやリリースの柔軟性のことを考えると、個人的にはExpoは使わないほうがよいと考えています。Expoは各ネイティブを隠蔽してくれますが、まだデメリットのほうが多いと感じています。
Q: FCM使うならFirebaseに寄せる、という人が多いんではないでしょうか？？Analyticsとかとあわせて
Androidで通知が必要という時点でFCMは必ず使うことになります。Amazon Pinpointを使う場合でもFCMの設定が必要です。他に選択肢がないというのは、ボトルネックでもあります。
Q: 各ネイティブの知識が必要な場面は、どんなのがあったか気になります
やはりビルド、リリース周りですね。AndroidではGradle、iOSでは証明書関連とfastlaneの知識があるとトラブル解決に役立ちます。
Q: 当時はPinpoint撃沈したとのことですが、今は克服したのですか？
しました。コツはiOSの証明書にp8キーを使うことと、 横着せずにドキュメントを読むことでした。
Q: AWSのサービスは数が多くて何が何をできるのかを勉強するのにいい資料とかはありますでしょうか？Amplifyはそれらを簡単に管理＆設定＆作成できるものと思っていますが、基本的な各サービスが良く分かっていないです
基本的なサービスをあまり意識せず利用できるのがAmplifyの良い点だと思います。なので当初はあまり気にしないで、気になった時点でCloudFormationを見ながらこれとこれがこうつながっているのか、というところから紐解いていくのがよいかもしれません。
（AWSJ木村より）AWS初学者向けに「何から始めれば良いのか？」をまとめたブログがありますので、是非こちらをご一読ください！
Q: ロギングは何か実装しましたか？
一通りCloudWatchに吐かせています。
Q: Ampilfy CLIでCloudFormationを更新すると自作したCloudFormationが上書きされる認識なんですが、どのように対処されていますでしょうか。
おっしゃるとおり、上書きされると認識しております。ただ、ソースコードはgitで管理されていると思いますので、うかつにpushしないなど、そういう認識を持ちながらやっています。
Q: FirebaseとAmplifyで比較したことがあったら知りたいです
実はFirebaseはそんなに使ったことがないのですが、Firestoreが便利だという印象でした。ただ、Amplify（AppSync）でもsubscriptionができたりDataStoreができたりと、あまりどっちかというのはなく、むしろお客様のご要望で変わってきます。
Q: CloudFormationの勉強をするのに、何か参考にしたリソースがあれば教えていください！
AWSの公式ドキュメントにすべて例文が載っているので、都度AWSの公式ドキュメントとにらめっこして勉強しました。
Q: 1日スプリントはエキサイティングな感じがしますが、1週間スプリントなどと比べて気をつけていることなどはありますか？
「宵越しのタスクは持たない」につきます。そうするために適切なバックログの粒度になるよう、気をつけています。
Q: CloudFormationの知識がなくても出来るのがAmplifyの良いところな認識です、カスタマイズするとAmplify CLIで更新できなくなるかと思ってました。
見通しの良さのためにCLIが吐いたCFnに追記することもありますが（HostingにWAFつける場合など）基本的にはCustomResourcesに書いたほうがいいと思います。
Q: CodeBuildのどこらへんが好きですか？ｗ
開発者は初めて見たCI/CD環境を親だと思ってしまうものです。
「コーポレートサイトを静的化して Amplify Console にデプロイする」加藤 尋樹 さん（株式会社はてな）
株式会社はてなの加藤さんからは、はてブでバズったコーポレートサイトをAmplify Consoleにデプロイされた際のお話をLTしていただきました！
Amplify Consoleを余すところなくご利用いただいており、これからご利用いただく方々の参考になる内容ばかりでした！また、移行時の検討内容ももちろんですが、AWS Amplifyに対する好感として「名前が好き」と挙げていただいていたのが印象的でした☺️
コーポレートサイトを静的化してAmplify Consoleにデプロイする
質問と回答（回答：加藤 尋樹 さん）
Q: Amplify の学習をどうしたのか知りたいです（全登壇者に対して。。）公式ドキュメントやチュートリアルはあるけど、日本語の解説記事が少ないのかなとおもうんですが、、
私たちの場合は公式のドキュメントが一番の情報源でした。AWSにいくらか慣れていることもあって、それほど困る感じではなかったと思います。
Q: CDKとCloudFormationsの使い分け方はなんでしょう
基本的に最近はCDKで作る感じです。cdk synthesize コマンドでCloudFormationテンプレートが出力されるので、それを利用しています。
また、難しいところですが、IaCにどれだけロジックを書くかという議論があるかと思いますが、あまりロジックを書かない方が目的にかなうという場合であれば、CloudFormation、単に快適に書きたいという感じだとCDKを使うのが良いかなと思っております。
（AWSJ木村より）これは好みの問題になるかなと思います。改めて、AWS CloudFormationはあるべき状態を定義することでAWSの環境構築を自動化するためのツールで、AWS Cloud Development Kit（CDK）はそのあるべき状態の定義をプログラミング言語によって可能にするツールです。CDKも最終的にはCloudFormationテンプレートを出力します。あるべき状態をJSON/YAMLで記述したいか、プログラミング言語で記述したいか、というのが使い分けのポイントになってきます。
Q: アクセス解析は何か使っています？
Google Analyticsを使っています。
Q: コーポレートサイトだと管理画面など必要になる気がしたんですが、良い感じに対応する方法なにかありませんか・・・！
アクティブに更新がある部分は「はてなブログMedia」を利用しています。ブログにはRSSがあるので、それをAWS AmplifyのAPIでJSONにするところを用意しており、それでまかなっています。
社内の方々が（gitの）Pull Requestを送ってくれて、それをマージするので事足りているので、意外と管理画面なくやれています（AWSJ木村より：発表での質問回答では「資本金の変更などを取締役がPR出してくれる」とのことでした。）。
また、re:Invent 2020でAmplify Admin UIが出たので管理画面も簡単になりそうですね。
Q: はてなさんのコーポレートサイトの記事よみました！あれでもAmplifyがSSR対応する前の記事だったような
ありがとうございます。コーポレートサイトは静的化されているのでSSRは使用していません。
Q: はてなのコーポレートサイトにアクセスする人ははてなの採用者ページにアクセスしたい人が多いでしょうか？
必ずしもそうとは限りませんが、採用に関心を持っていただけている場合も多くあると思います。
Q: 京都のWebコミュニティのトレンド気になりました
トレンドは最近はちゃんと把握していないですね……。
「AWS Amplify 関連のアップデート振り返り」じゃが（アマゾンウェブサービスジャパン株式会社）
AWSJのじゃが（永山）からは、AWS Amplifyのアップデートをお話ししました。
（常に最新情報を追いかけられている方には、11月末までの最新アップデートから1ヶ月半で多くの機能追加がされていることが分かる資料となっております）
Amplify Updates at Amplify Meetup #02
質問と回答（回答：じゃが）
Q: ロードマップはどこかに公開されていますか？ & Amplifyがこれから目指していく方向を教えて欲しい。
例えばAmplify CLIであればProjects · aws-amplify/amplify-cli で進行中のプロジェクトを参照することが可能です。ただしAmplify JavaScriptはじめ、基本的には公開されておりません。
Q: SSRがレンダリングサーバー側でハンドリングする必要があるということがよくわかりませんでした。。JWTがサーバーサイドに渡るのでそれを検証すればよい？？
Amplify JavaScriptライブラリはこれまで、ブラウザ・レンダリングサーバー間でJWTをやり取りする仕組みがありませんでした。今回SSRに対応したことで、Amplify JavaScriptライブラリはJWTをCookie経由でレンダリングサーバーに受け渡せるようになりました。レンダリングサーバーは受け取ったJWTを用いて、APIサーバーなどにリクエストを行います。詳しいディスカッションについてはGitHubのissueをご参照ください。
Q: JagaさんにAmplifyの相談をしたいんですがどうすれば & 技術支援ってどうやったらしてもらえるのでしょうか？
Online Ask An Expertでは、オンラインでAWSの技術者と技術相談を行うことが可能です。ぜひご活用ください。
また、担当営業とすでにコミュニケーションいただいている方は、Amplifyの技術相談がしたいと営業までお伝えください。
Q: Amplify コミュニティ、Discordに英語でのコミュニケーションの場は有るのですが、気軽に日本語で相談できるSlackなりDiscordなりのコミュニティの場ってないでしょうか？？
日本向けAmplify Community Slackが立ち上がりました！ご興味のある方はこちらの招待リンクからご参加ください。
さいごに
LTのご紹介では簡単にLTの紹介と私の感想を書きましたが、ぜひ各登壇者のスライドをご覧いただければと思います。今回は質問とその回答も掲載しておりますので、AWS Amplifyを実際に使ってみる際にはこちらもご活用ください。第1回同様、こんなにアツいイベントにできたのは、ひとえに参加者と登壇者の皆様のおかげです。皆様本当にありがとうございました！
また繰り返しになりますが、Amplify Meetupは次回も開催予定ですので、ぜひ皆様ふるってご参加ください。AWS Amplifyなどの、AWSでのフロントエンド関連のイベントを告知するconnpassグループでメンバー登録すると、イベント開催の通知を受け取ることができます。今回のLTでone more thingとしてご紹介したAWS Amplify JapanコミュニティーSlackでも告知いたしますので、ぜひこちらにもご参加ください！
そして「ぜひ登壇したい！」という方も随時募集しておりますので、ぜひ、下記の運営チームやお近くのAWSスタッフにお声がけください。これからも皆さんと共にAmplifyを育てていきたいです！みなさんもAmplifyポーズで、Let’s Amplify！
運営メンバーのご紹介
永山 大輔（じゃが） @jagaimogmog
普段はStartup Solutions ArchitectとしてStartupのお客様の技術支援を担当。AWS AmplifyとChime SDKがお気に入り。
吉田 祐樹 @yshd
Application Development Consultantとしてアジャイルやクラウドネイティブアプリ開発の支援をしています。
明日楽をするために今頑張るのがモットー。
塚田 朗弘 @akitsukada
Startup Solutions Architect。AWS Amplify が好き。
本寺 広海 @moaible
AWS Amplifyとウサギが好きなApp Devコンサルタントです。
Wachi, Daijiro @watilde
Developer Relations Engineer (Mobile/Web) です。
執筆者
木村 公哉（Kimura, Koya）@kimyan_udon2
香川県出身のソリューションアーキテクトです。普段はISV/SaaSなお客様の技術支援を担当しています。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。最近結婚しました。