実質1ヶ月勉強して、AWSデベロッパーアソシエイト試験（以下、DVA）を受験し、なんとか合格できました。
備忘録を兼ねて、やったことや振り返りなどを以下にまとめます。

受験の動機

クラウドに興味があり、まずはAWSから、と思ったのと、AWSを用いた開発に必要な機能概要を一通り押さえておきたいと思ったため。
あとは、会社の勉強会の最終ゴールだったということもあり。

業務経験と勉強期間

• AWS業務経験：なし
• 勉強期間：実質約1ヶ月

レガシーな案件への参画ばかりでAWSの業務経験はゼロ。
昨年、会社の月1勉強会に参加し、なんとなく主要な製品や特長を把握できたかな、というレベル。
受験直前1ヶ月は平日2～3時間、休日4,5時間勉強にあてました。

やったこと

1. 情報収集（1日）

まずはAWS公式サイトで試験範囲の確認を行い（試験範囲はコチラ）、ネットで受験された方々の勉強方法を検索してスケジュールをたてました。

2. Udemyの某DVA試験対策動画（英語）を見る＆ハンズオン（約2週間）

試験範囲の内容を自分でいちいち調べるより、試験用にまとめられた動画を見たほうが手っ取り早そうと思ったのと、Udemyの新春セールで1,200円と激安だったので購入して一通り視聴しました。
動画内でハンズオンもやっていて実践も積みたかったので、そちらもできる限り実施。
英語の勉強にもなり、よかったです笑
（日本語版のDVA対策試験動画もあったので、そちらでもよかったかもしれませんが。）

3. Udemyの某DVA試験対策問題集（英語）を解く（約2週間）

Udemyの某DVA試験対策問題集（英語；2と同一の講師の方のもの）を2周。
問題読解には、Google翻訳のお力を借りました。
解説とリンク先のページも読んで、なぜその選択肢が正解 or 不正解なのか?理解できるよう努めました。

4. AWSサービス別資料、各製品ページなどを読んで知識の穴埋めをする（約2週間;3と並行）

AWSサービス別資料と各製品ページ（概要、特徴、よくある質問など）を読んで知識の穴埋めを実施。
あとは、会社の勉強会の資料やホワイトペーパーにもザっと目を通したり。
問題の解説を読む、だけでは断片的な理解となってしまっていましたが、これらに一通り目を通すことで体系的に理解することができました。

5. 模擬試験、サンプル問題を解く（前々日）

模擬試験は、過去に受験された方によればなるべく早く受けたほうがよいとのことでしたが、受験料がかかる上、スコアはわかっても回答は公開されていないので、正解率が上がってきてからと思い、かなり引っ張りました。
20問、制限時間30分で、結果は65%。このままいくと不合格な点数でしたが、これ以上延ばしてもおそらく変わらない、不安な箇所を重点的に見直してとりあえず受けてみよう、と受験を決意。

サンプル問題も合わせて解きました。全10問で正答率70%（こちらもボーダーの72％には届いてなかったです。）

6. 試験申し込み（前日）

前日に申し込みました。申込は「AWS認定試験に備える」から。
自分の場合、CBT試験は人が少ない朝一の時間に受けるのが常なのですが、何か制限でもあるのか?、午後の時間しか空いておらず、止む無くそこで受けることに。

7. 不安の残る問題の見直しと直前見直しノートまとめ（前日）

問題集で不安の残る問題を一通り見直し、その内容をもとに、スプレッドシートで試験当日の直前見直しノートを作成。
まとめる中でより理解を深めることができた気がします。

試験当日

身分証明書2点（ひとつは顔写真付き）を忘れず持参。
電車遅延も考慮し、早めに家を出て、会場近くのカフェにて直前見直しノート（タブレットを使用）などで、最後の追い込みをかけました。
その後、試験開始30分前に会場到着。余裕をもって会場入りできたので、焦らずに試験開始できてよかったです。
真冬日かつ試験会場がそれほど暖房が効いていなかったので、コートも羽織ったまま試験室入りしました（暑くなったら脱げばいいだけなので）。

試験の流れ

1. 注意事項を読んで、「同意する」にチェックを入れて開始。

試験官の方によれば、「同意しない」にチェックを入れてしまうと、その場で終了となり、受験料もかえってこないのだとか。うっかり間違えないよう注意しましょう！

2. 問題を解く（65問；140分）

次の問題にうつる際に多少のローディング時間がありましたが、それ以外は他のCBT試験（HTML5やLPICなど）と大差ない感じで、全問見直し、フラグを立てた問題だけ見直しも可能でした。

内容は対策問題よりも難しく感じ、正直落ちたな、と思いましたが、難しい問題はとりあえず何かを選んで再度考えることにし、1時間くらいで一通り解き終え、あとはギリギリまで粘って選択肢を吟味しました。

時間切れまで1分のところで、耐えきれず（？）、試験終了のボタンをクリック。

3. アンケート実施

制限時間5分（たぶん）、10問程度のアンケートに答えます。
これまで受けたCBT試験では、試験問題修了 → 結果表示 → アンケートばかりだったので、一瞬焦りました（結果はこの後に出ます）。
簡単な内容なので、1分程度で終了。

4. 試験結果表示

3のアンケート終了後にようやく結果が表示されます。

なんと、「合格」の2文字が！

場所はたしか、画面左方の真ん中くらい。
合否の文字はとても小さい＆全く強調されておらず周りと同化してしまっているので、見逃さないよう注意！
この時点ではスコアはまだわかりませんでした。

5. スコアレポートの受信

これまで受けたCBT試験と違って、テストセンターでは結果の用紙は発行されませんでした。
全然手ごたえなかったので、見間違いじゃないかとソワソワ・・・。

5営業日後までにメールにてスコアをお知らせ、とのことでしたが、試験終了約4時間後に「aws training and certification」より、スコア確認できました。

結果は748/1000。
720/1000がボーダーなので、かなりギリギリ汗
それでも、正式に合格を確認できたので、ほっと一安心。

反省

DVAは、他のアソシエイトレベル試験と違い、日本語版の対策問題集が少ない、ということで、学習方法の選定に苦労しました。
学習方法を公開してくださった過去の受験者の皆さまに感謝！

Udemyの動画はよくまとまっていて勉強になりましたが、20時間ほどあったので、効率を考えると、AWSサービス別資料、各製品ページをサク読みしてから問題集実施でもよかったのかな、と。

せっかく会社で勉強会に参加していたので、もっといろいろ聞いておくべきでした。

模擬試験、サンプル問題はやはり遅くとも受験1週間前にはやっておいたほうがよかったな、というのが正直なところ。

試験は24時間前までなら受験日時変更可能なようなので、とりあえず申し込んで、無理そうなら別日に変える、としたほうが好みの時間を選択できて、ベターなコンディションで受けられてなおよかったと思います。

今後やりたいこと

AWSを用いて、WEBサイト構築。
試験を通じて、実際にAWSなどクラウドを使ったお仕事への興味が強くなりました。
ひとまずは個人で実施予定ですが、できることなら業務でもAWS使いたい！

そして、せっかくなので、アソシエイト試験3冠とりたい！
並行して、ソリューションアーキテクト、SysOps試験の勉強も進めようと思います。

最後に

ここまでお付き合いいただき、ありがとうございました！
少しでも、今後受験される皆様のお役に立てれば幸いです。

参考

今回試験を受験するにあたり、以下の皆さまの学習方法等を参考にさせていただきました！

• 業務で開発経験なしでも取れるAWS 認定デベロッパーアソシエイトの勉強法 | スクショはつらいよ
• 10日間でAWS認定デベロッパー アソシエイトに合格した話 | 林檎のまるかじり
• AWS認定（2）デベロッパー（アソシエイト）に合格するまで | テクニカルタイムアウト
• AWS認定デベロッパーアソシエイトを取得したので初学者が突破するための対策方法を教えます。 | ひろまるブログ
• AWS Developer Associate試験に挑戦してきました | Developpers.IO
• AWS認定Associate3冠取得達成したので自分はどう勉強したのかを放流する | Qiita
• AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる | Qiita
• AWSの資格って？資格の種類・難易度について解説します | ProEnfineer

1ヶ月勉強して、AWSデベロッパーアソシエイト試験（以下、DVA）を受験し、なんとか合格できました。
備忘録を兼ねて、やったことなどを以下にまとめます。

受験の動機

クラウドに興味があり、まずはAWSから、と思ったのと、AWSを用いた開発に必要な機能概要を一通り押さえておきたいと思ったため。

業務経験と勉強期間

• AWS業務経験：なし
• 勉強期間：約1ヶ月

これまでレガシーな案件への参画ばかりでAWSの業務経験は全くなく、AWS = クラウドサービスの中でいちばんメジャーなんだな～ということを知っていたくらいのレベル。
平日2～3時間、休日4,5時間勉強にあてました。

やったこと

1. 情報収集（1日）

まずはAWS公式サイトで試験範囲の確認を行い（試験範囲はコチラ）、ネットで受験された方々の勉強方法を検索してスケジュールをたてました。

2. Udemyの某DVA試験対策動画（英語）を見る＆ハンズオン（約2週間）

試験範囲の内容を自分でいちいち調べるより、試験用にまとめられた動画を見たほうが手っ取り早そうと思ったのと、Udemyの新春セールで1,200円と激安だったので購入して一通り視聴しました。
動画内でハンズオンもやっていて実践も積みたかったので、そちらもできる限り実施。
英語の勉強にもなり、よかったです笑
（日本語版のDVA対策試験動画もあったので、そちらでもよかったかもしれませんが。）

3. Udemyの某DVA試験対策問題集（英語）を解く（約2週間）

Udemyの某DVA試験対策問題集（英語；2と同一の講師の方のもの）を2周。
解説とリンク先のページも読んで、なぜその選択肢が正解 or 不正解なのか?理解できるよう努めました。

4. AWSサービス別資料、各製品ページを読んで知識の穴埋めをする（約2週間;3と並行）

AWSサービス別資料と各製品ページ（概要、特徴、よくある質問など）を読んで知識の穴埋めを実施。
問題の解説を読む、だけでは断片的な理解となってしまっていましたが、これらに一通り目を通すことで体系的に理解することができました。

5. 模擬試験を受ける（前々日）

過去に受験された方によればなるべく早く受けたほうがよいとのことでしたが、受験料がかかる上、スコアはわかっても回答は公開されていないので、正解率が上がってきてからと思い、かなり引っ張りました。
結果は65%。このままいくと不合格な点数でしたが、これ以上延ばしてもおそらく変わらない、不安な箇所を重点的に見直してとりあえず受けてみよう、と受験を決意。

6. 試験申し込み（前日）

前日に申し込みました。申込は「AWS認定試験に備える」から。
自分の場合、CBT試験は人が少ない朝一の時間に受けるのが常なのですが、何か制限でもあるのか?、午後の時間しか空いておらず、止む無くそこで受けることに。

7. 不安の残る問題の見直しと直前見直しノートまとめ（前日）

問題集で不安の残る問題を一通り見直し、その内容をもとに、スプレッドシートで試験当日の直前見直しノートを作成。
まとめる中でより理解を深めることができた気がします。

試験当日

身分証明書2点（ひとつは顔写真付き）を忘れず持参。
電車遅延も考慮し、早めに家を出て、会場近くのカフェにて直前見直しノートなどで、最後の追い込みをかけました。
その後、試験開始30分前に会場到着。余裕をもって会場入りできたので、焦らずに試験開始できてよかったです。
真冬日かつ試験会場がそれほど暖房が効いていなかったので、コートも羽織ったまま試験室入りしました（暑くなったら脱げばいいだけなので）。

試験の流れ

1. 注意事項を読んで、「同意する」にチェックを入れて開始。

試験官の方によれば、「同意しない」にチェックを入れてしまうと、その場で終了となり、受験料もかえってこないのだとか。うっかり間違えないよう注意しましょう！

2. 問題を解く（65問；140分）

次の問題にうつる際に多少のローディング時間がありましたが、それ以外は他のCBT試験（HTML5やLPICなど）と大差ない感じで、全問見直し、フラグを立てた問題だけ見直しも可能でした。

内容は対策問題よりも難しく感じ、正直落ちたな、と思いましたが、難しい問題はとりあえず何かを選んで再度考えることにし、1時間くらいで一通り解き終え、あとはギリギリまで粘って選択肢を吟味しました。

時間切れまで1分のところで、耐えきれず（？）、試験終了のボタンをクリック。

3. アンケート実施

制限時間5分（たぶん）、10問程度のアンケートに答えます。
これまで受けたCBT試験では、試験問題修了 → 結果表示 → アンケートばかりだったので、一瞬焦りました（結果はこの後に出ます）。
簡単な内容なので、1分程度で終了。

4. 試験結果表示

3のアンケート終了後にようやく結果が表示されます。

なんと、「合格」の2文字が！

場所はたしか、画面左方の真ん中くらい。
合否の文字はとても小さい＆全く強調されておらず周りと同化してしまっているので、見逃さないよう注意！
この時点ではスコアはまだわかりませんでした。

5. スコアレポートの受信

これまで受けたCBT試験と違って、テストセンターでは結果の用紙は発行されませんでした。
全然手ごたえなかったので、見間違いじゃないかとソワソワ・・・。

5営業日後までにメールにてスコアをお知らせ、とのことでしたが、試験終了約4時間後に「aws training and certification」より、スコア確認できました。

結果は748/1000。
720/1000がボーダーなので、かなりギリギリ汗
それでも、正式に合格を確認できたので、ほっと一安心。

振り返り

DVAは、他のアソシエイトレベル試験と違い、日本語版の対策問題集が少ない、ということで、学習方法の選定に苦労しました。
学習方法を公開してくださった過去の受験者の皆さまに感謝！

Udemyの動画はよくまとまっていて勉強になりましたが、20時間ほどあったので、効率を考えると、AWSサービス別資料、各製品ページをサク読みしてから問題集実施でもよかったのかな、と。

試験は24時間前までなら受験日時変更可能なようなので、とりあえず申し込んで、無理そうなら別日に変える、としたほうが好みの時間を選択できて、ベターなコンディションで受けられてなおよかったと思います。

今後やりたいこと

AWSを用いて、WEBサイト構築。
試験を通じて、実際にAWSなどクラウドを使ったお仕事への興味が強くなりました。
ひとまずは個人で実施予定ですが、できることなら業務でもAWS使いたい！

そして、せっかくなので、アソシエイト試験3冠とりたい！
並行して、ソリューションアーキテクト、SysOps試験の勉強も進めようと思います。

最後に

ここまでお付き合いいただき、ありがとうございました！
少しでも、今後受験される皆様のお役に立てれば幸いです。

参考

今回試験を受験するにあたり、以下の皆さまの学習方法等を参考にさせていただきました！

• 業務で開発経験なしでも取れるAWS 認定デベロッパーアソシエイトの勉強法 | スクショはつらいよ
• 10日間でAWS認定デベロッパー アソシエイトに合格した話 | 林檎のまるかじり
• AWS認定（2）デベロッパー（アソシエイト）に合格するまで | テクニカルタイムアウト
• AWS認定デベロッパーアソシエイトを取得したので初学者が突破するための対策方法を教えます。 | ひろまるブログ
• AWS Developer Associate試験に挑戦してきました | Developpers.IO
• AWS認定Associate3冠取得達成したので自分はどう勉強したのかを放流する | Qiita
• AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる | Qiita
• AWSの資格って？資格の種類・難易度について解説します | ProEnfineer

1ヶ月勉強して、AWSデベロッパーアソシエイト試験（以下、DVA）を受験し、なんとか合格できました。
備忘録を兼ねて、やったことなどを以下にまとめます。

受験の動機

クラウドに興味があり、まずはAWSから、と思ったのと、AWSを用いた開発に必要な機能概要を一通り押さえておきたいと思ったため。

業務経験と勉強期間

• AWS業務経験：なし
• 勉強期間：約1ヶ月

これまでレガシーな案件への参画ばかりでAWSの業務経験は全くなく、AWS = クラウドサービスの中でいちばんメジャーなんだな～ということを知っていたくらいのレベル。
平日2～3時間、休日4,5時間勉強にあてました。

やったこと

1. 情報収集（1日）

まずはAWS公式サイトで試験範囲の確認を行い（試験範囲はコチラ）、ネットで受験された方々の勉強方法を検索してスケジュールをたてました。

2. Udemyの某DVA試験対策動画（英語）を見る＆ハンズオン（約2週間）

試験範囲の内容を自分でいちいち調べるより、試験用にまとめられた動画を見たほうが手っ取り早そうと思ったのと、Udemyの新春セールで1,200円と激安だったので購入して一通り視聴しました。
動画内でハンズオンもやっていて実践も積みたかったので、そちらもできる限り実施。
英語の勉強にもなり、よかったです笑
（日本語版のDVA対策試験動画もあったので、そちらでもよかったかもしれませんが。）

3. Udemyの某DVA試験対策問題集（英語）を解く（約2週間）

Udemyの某DVA試験対策問題集（英語；2と同一の講師の方のもの）を2周。
解説とリンク先のページも読んで、なぜその選択肢が正解 or 不正解なのか?理解できるよう努めました。

4. AWSサービス別資料、各製品ページを読んで知識の穴埋めをする（約2週間;3と並行）

AWSサービス別資料と各製品ページ（概要、特徴、よくある質問など）を読んで知識の穴埋めを実施。
問題の解説を読む、だけでは断片的な理解となってしまっていましたが、これらに一通り目を通すことで体系的に理解することができました。

5. 模擬試験を受ける（前々日）

過去に受験された方によればなるべく早く受けたほうがよいとのことでしたが、受験料がかかる上、スコアはわかっても回答は公開されていないので、正解率が上がってきてからと思い、かなり引っ張りました。
結果は65%。このままいくと不合格な点数でしたが、これ以上延ばしてもおそらく変わらない、不安な箇所を重点的に見直してとりあえず受けてみよう、と受験を決意。

6. 試験申し込み（前日）

前日に申し込みました。申込は「AWS認定試験に備える」から。
自分の場合、CBT試験は人が少ない朝一の時間に受けるのが常なのですが、何か制限でもあるのか?、午後の時間しか空いておらず、止む無くそこで受けることに。

7. 不安の残る問題の見直しと直前見直しノートまとめ（前日）

問題集で不安の残る問題を一通り見直し、その内容をもとに、スプレッドシートで試験当日の直前見直しノートを作成。
まとめる中でより理解を深めることができた気がします。

試験当日

身分証明書2点（ひとつは顔写真付き）を忘れず持参。
電車遅延も考慮し、早めに家を出て、会場近くのカフェにて直前見直しノート（タブレットを使用）などで、最後の追い込みをかけました。
その後、試験開始30分前に会場到着。余裕をもって会場入りできたので、焦らずに試験開始できてよかったです。
真冬日かつ試験会場がそれほど暖房が効いていなかったので、コートも羽織ったまま試験室入りしました（暑くなったら脱げばいいだけなので）。

試験の流れ

1. 注意事項を読んで、「同意する」にチェックを入れて開始。

試験官の方によれば、「同意しない」にチェックを入れてしまうと、その場で終了となり、受験料もかえってこないのだとか。うっかり間違えないよう注意しましょう！

2. 問題を解く（65問；140分）

次の問題にうつる際に多少のローディング時間がありましたが、それ以外は他のCBT試験（HTML5やLPICなど）と大差ない感じで、全問見直し、フラグを立てた問題だけ見直しも可能でした。

内容は対策問題よりも難しく感じ、正直落ちたな、と思いましたが、難しい問題はとりあえず何かを選んで再度考えることにし、1時間くらいで一通り解き終え、あとはギリギリまで粘って選択肢を吟味しました。

時間切れまで1分のところで、耐えきれず（？）、試験終了のボタンをクリック。

3. アンケート実施

制限時間5分（たぶん）、10問程度のアンケートに答えます。
これまで受けたCBT試験では、試験問題修了 → 結果表示 → アンケートばかりだったので、一瞬焦りました（結果はこの後に出ます）。
簡単な内容なので、1分程度で終了。

4. 試験結果表示

3のアンケート終了後にようやく結果が表示されます。

なんと、「合格」の2文字が！

場所はたしか、画面左方の真ん中くらい。
合否の文字はとても小さい＆全く強調されておらず周りと同化してしまっているので、見逃さないよう注意！
この時点ではスコアはまだわかりませんでした。

5. スコアレポートの受信

これまで受けたCBT試験と違って、テストセンターでは結果の用紙は発行されませんでした。
全然手ごたえなかったので、見間違いじゃないかとソワソワ・・・。

5営業日後までにメールにてスコアをお知らせ、とのことでしたが、試験終了約4時間後に「aws training and certification」より、スコア確認できました。

結果は748/1000。
720/1000がボーダーなので、かなりギリギリ汗
それでも、正式に合格を確認できたので、ほっと一安心。

振り返り

DVAは、他のアソシエイトレベル試験と違い、日本語版の対策問題集が少ない、ということで、学習方法の選定に苦労しました。
学習方法を公開してくださった過去の受験者の皆さまに感謝！

Udemyの動画はよくまとまっていて勉強になりましたが、20時間ほどあったので、効率を考えると、AWSサービス別資料、各製品ページをサク読みしてから問題集実施でもよかったのかな、と。

試験は24時間前までなら受験日時変更可能なようなので、とりあえず申し込んで、無理そうなら別日に変える、としたほうが好みの時間を選択できて、ベターなコンディションで受けられてなおよかったと思います。

今後やりたいこと

AWSを用いて、WEBサイト構築。
試験を通じて、実際にAWSなどクラウドを使ったお仕事への興味が強くなりました。
ひとまずは個人で実施予定ですが、できることなら業務でもAWS使いたい！

そして、せっかくなので、アソシエイト試験3冠とりたい！
並行して、ソリューションアーキテクト、SysOps試験の勉強も進めようと思います。

最後に

ここまでお付き合いいただき、ありがとうございました！
少しでも、今後受験される皆様のお役に立てれば幸いです。

参考

今回試験を受験するにあたり、以下の皆さまの学習方法等を参考にさせていただきました！

• 業務で開発経験なしでも取れるAWS 認定デベロッパーアソシエイトの勉強法 | スクショはつらいよ
• 10日間でAWS認定デベロッパー アソシエイトに合格した話 | 林檎のまるかじり
• AWS認定（2）デベロッパー（アソシエイト）に合格するまで | テクニカルタイムアウト
• AWS認定デベロッパーアソシエイトを取得したので初学者が突破するための対策方法を教えます。 | ひろまるブログ
• AWS Developer Associate試験に挑戦してきました | Developpers.IO
• AWS認定Associate3冠取得達成したので自分はどう勉強したのかを放流する | Qiita
• AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる | Qiita
• AWSの資格って？資格の種類・難易度について解説します | ProEnfineer

キーワードをメモしてみました。

Dynamodbとは

Nosqlのデータベース。AWSのフルマネージドサービス
Nosqlの範囲は、キーバリュー型・ドキュメント型・カラム型

テーブル構造>アイテム

パーティションキー
ソートキー（オプション）
アトリビュート
※パーティションキー、またはパーティションキー＋ソートキーで一意となる。
※パーティションキーによって、データどこのパーティションに登録されるかが決まる。

レプリケーションは３つ。クロスリージョン

DynamoDB Transactions

BachGetItemなどで、複数itemの操作をした時の動きを決めることができる。
一つでもエラーであれば、ロールバックするのかどうか。

ローカルセカンダリインデックス

パーティションキーは変更できないが、
ソートキーの代わり、第二のソートキーとして検索に使用できる。
※テーブルをもう1つ作るようなイメージ（非同期なのでレイテンシーに影響なし）

グローバルセカンダリインデックス

これは上記と異なり、パーティションキーの代わり
※テーブルをもう1つ作るようなイメージ（非同期なのでレイテンシーに影響なし）

メンテナンスフリー

OS、DBバッチ適用などなど。
⇒セキュリティ・耐久性・可用性・性能・拡張性

バーストキャパシティ

パーティションごとのキャパシティのうち、利用されなかった分を過去399秒分までリザーブ。
バースト時に使用される。

オートスケーリング

パーティション内のスループット

設定したキャパシティはパーティション数で割ったキャパシティを各キャパシティで利用できる。
⇒Adaptive capacity
　あるパーティションに負荷が集中した場合に、
　余力のあるパーティションのキャパシティを集中したパーティションにもっていく

DynamoDB on-demand

lambdaのように、使った分だけ課金される。【(*´ω｀)これ助かるわー】
⇒どれだけ負荷があるか予測しづらいのに、設定するのきついのですよ。。

NoSQLのデータモデリング

・ユースケースの理解
・アクセスパターンの理解
　⇒どういう検索を決めてから、テーブル設計を行う。
・Data-modeling
・Review->Repet->Review

・検索条件を決めてから、テーブルを設計する

データモデリング参考

https://aws.amazon.com/jp/blogs/news/webinar-bb-dynamodb-advanced-design-pattern-2018/
https://www.slideshare.net/AmazonWebServicesJapan/db-20190905

非正規化

各テーブルで重複データをもっていい。
テーブルの結合等ができないため。

Dynamodb API

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html
⇒アプリケーションから直接低レベルAPIにリクエストを行うのではなく、
　プログラミング言語にAWS Software Development Kit（SDK）の
　いずれかを使用することが推奨されている。

アクセス方法

①SDK

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Programming.SDKOverview.html

②低レベルAPIを直接呼ぶ

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Programming.LowLevelAPI.html

グローバルセカンダリインデックス　オーバーローディング（GSIの多重定義）

テーブル当たりデフォルト最大20まで
⇒めっちゃいい！GSIを作りすぎると、データ量も増えてコストに影響すると思っていた。
　カラムを縦持ちすることでこのようなことができる。

★GSI作成数による鼓す津増加やGSIが検索要件に応じて増えてしまうことを回避

https://dev.classmethod.jp/cloud/aws/basic-of-gsi-overloading/

とりあえず、この動画をみよう

https://www.youtube.com/watch?v=16RYHfe89WY

AmplifyのStorageと認証まわり

はじめに

サーバーレスWebアプリ開発を進めてくなかで、AmplifyのStorageと認証まわりの理解が進んできて、完全に理解したなと思ってJAWS-UG浜松で発表しようとしたら全然できませんでした。
できなかったというか、話し始めようとしたら話せるほど自分のなかで整理できてないことに気付いてギブアップしました。発表内容はこれだけじゃなかったとはいえ、まぁ失礼な話ですよね。本当すみません。
リベンジすべく、整理するために記事を書きます。

Guest許可と認証ユーザーのみ

AmplifyのStorageをセットアップする際の質問のなかに以下のような質問があって、選択できます。

? Who should have access: (Use arrow keys)
  Auth users only 
  Auth and guest users 

• Auth user only
  Storageへアクセスするためにユーザー認証(ログイン)が必要。
• Auth and guest users
  ユーザー認証していない状態でもStorageへアクセスできる。

ファイルアップロード(put)

Amplifyを利用してファイルをS3にアップロードするJavaScriptのコード例

  :
import { Storage } from 'aws-amplify';
  :
      Storage.put(filePath, image).then(result => {
        console.log(result);
      }).catch(err => console.log(err));

例えばfilePath = "a/b/c/test.jpg"とした場合、
resultには key : a/b/c/test.jpg のような結果(要はS3 Object key)が返ってきます。
そしてバケットには以下のようにpublic/a/b/c/test.jpgとしてファイルがアップロードされます。

publicが先頭についてますが、これはアクセスレベルです。

AmplifyのStorageには3つのアクセスレベルがあります。

• public : 全員が読み書きできる。
• protected : 全員が読めるが、書けるのは自分だけ。
• private : 自分しか読み書きできない。

protectedの場合は以下のように書きます。

      Storage.put(filePath, image, {
          level: 'protected'
      }).then(result => {
        console.log(result);
      }).catch(err => console.log(err));

privateの場合は、protectedをprivateにすればいいだけです。

protectedやprivateの場合、アップロードされるパスの先頭には、アクセスレベルに続きCognito Identity IDが付きます。

なお、Guestでprotectedやprivate指定した場合、以下の例外とともに HTTP403(Forbidden(閲覧禁止))が返ってきました。
AWSS3Provider - error uploading AccessDenied: Access Denied

ファイルダウンロード(アドレス取得)(get)

Amplifyを利用してS3にあるファイルの参照URLを取得するJavaScriptのコード例

      Storage.get(s3key).then(result => {
        this.imageURL = result;
      }).catch(err => console.log(err));

s3key = "a/b/c/test.jpg"このように、s3keyにはアクセスレベル名やCognito Identity IDを付けないことに注意。

resultに以下のようなURLが取得できます。
https://sample-vue-project-bucket-work.s3.ap-northeast-1.amazonaws.com/public/a/b/c/test.jpg?X-Amz-Algorithm=xxx&X-Amz-Credential=xxx&X-Amz-Date=xxx&X-Amz-Expires=900&X-Amz-Security-Token=xxx&X-Amz-Signature=xxx&X-Amz-SignedHeaders=host
後ろに認証のための色々なパラメータが付いてますね。これがないとアクセスが拒否されます。
また、デフォルトで900秒(15分)という有効期限も付いています。

任意の有効期限を指定することもできます。

      let s3key = "a/b/c/test.jpg"
      let dataExpireSeconds = (30 * 60);
      Storage.get(s3key, { expires: dataExpireSeconds }).then(result => {
        this.imageURL = result;
      }).catch(err => console.log(err));

適切な認証パラメータではなかったり、有効期限が切れた後にgetすると、HTTP403(Forbidden(閲覧禁止))とともにエラーが返ってきます。

<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
  <RequestId>D43YC2E5080A822C</RequestId>
  <HostId>
    w7zzd5NRpm8Ih0DN3hmjZT8sDQT5hcV7FhqbUaW6ZG7SpsepV3UspzDUMDVKRkPesaUpyUSEGC0=
  </HostId>
</Error>

<Error>
  <Code>AccessDenied</Code>
  <Message>Request has expired</Message>
  <X-Amz-Expires>900</X-Amz-Expires>
  <Expires>2020-01-26T03:07:16Z</Expires>
  <ServerTime>2020-01-26T03:20:13Z</ServerTime>
  <RequestId>9F14A2CA61AE75F2</RequestId>
  <HostId>
    wru7usdhgiI2MXWsdFGh59x8JYl1TbOzPDMs2L5LZ/IwDD9tueInxK7bfh/rKftjJZCCf9CY7SE=
  </HostId>
</Error>

AmplifyのAuthによる認証

ゲストを許可した場合は不要ですが、そうではない場合は認証をパスした状態でputやgetをする必要があります。

ユーザーにサインインしてもらう

Amplifyを利用した一般的な実現方法としては、AmplifyのAuthの基本機能を利用して、ユーザーにアカウントを作ってもらったうえでサインインしてもらう形になるかと思います。

こんな感じの画面でユーザー登録や認証の基盤を構築することがサクッと実現できちゃいます。
AmplifyでAuthをセットアップをする手順などの詳細は、この記事では割愛します。

プログラムで自動的に認証する

ユーザーがログインしなくてもサービスを利用できるようにしたい場合、一般的にはゲストを許可する設定でセットアップして、ゲストとして処理してあげればいいと思います。
ただ、あえてゲストは利用せず、サービス側が予め用意したアカウントで自動的(ユーザーに意識させず)に認証をパスするということもできます。
細かな手順などはこちらの記事に書いてありますので、やはりこの記事では割愛します。
Cognitoユーザーを作成したうえで、JavaScriptで自動的にログインをします。

あとがき

まずは何か動くものを作る。座学よりも効率的に学ぶことができると思っています。
それを人に説明しようとした場合、やはりある程度は整理してまとめるという作業が必要になってきますね。改めて実感しました。
これからはちゃんと準備してから話をしようと思います。

さて今回はStorage観点での認証の話でしたが、次は認証そのもの、その中でも特にソーシャルログインについて学びたいと考えています。
アカウント作成って心理的ハードルが高く、また、手間がかかると思っていて、とはいえユーザー毎の情報を保護することも必要だと思ってます。
多少でも心理的ハードルを下げ、また、ユーザー認証の手間を少なくしてくれるソーシャルログインは、サービスにとって必須の機能ではないでしょうか。と、思うわけなんです。

Lambda(Python)でGoogle Vision APIを利用して日本語文字検出する

はじめに

サーバーレスWebアプリ Mosaicを開発して得た知見を振り返り定着させるためのハンズオン記事を書き連ねていて、合計17記事を予定して現在13記事、あと4記事なのですが、少し飽きてきてしまいました。
飽きてきたというか、新しい機能の実装にも着手したくなってきてしまって。
で、着手してしまったわけです。文字検出の機能追加に。

文字検出？文字認識？OCR(Optical Character Recognition)って言うみたいですね。
AWSのRekognitionでも文字検出できるみたいなのですが、残念ながら日本語非対応らしく。(2020年1月現在)
しかしGoogleのVision APIは日本語もサポートしているということで、こちらを利用することにしました。

Cloud Vision API 有効化

ということで、早速やってきましょう。
Google Cloud Platform もしくは Google Developpers のコンソール > APIとサービス にアクセス。
https://console.cloud.google.com/apis
https://console.developers.google.com/apis

画面上部にある「＋APIとサービスを有効化」ボタンを押下。

Cloud Vision API を探して、有効化。

認証情報として、サービスアカウントを追加しますが、こちらの記事と重複しますので、ここでは割愛します。

Lambda(Python3)でGoogle Vision APIを利用する

サービスアカウントでGoogleのAPIを呼ぶために必要なライブラリのインポートについても、先ほど同様、こちらの記事を参照ください。

ローカル画像ファイルをVision APIに渡して、顔とテキストを検出するコードは以下のような感じです。

lambda_function.py

  : 
def detectFacesByGoogleVisionAPIFromF(localFilePath, bucket, dirPathOut):
    try:
        keyFile = "service-account-key.json"
        scope = ["https://www.googleapis.com/auth/cloud-vision"]
        api_name = "vision"
        api_version = "v1"
        service = getGoogleService(keyFile, scope, api_name, api_version)

        ctxt = None
        with open(localFilePath, 'rb') as f:
            ctxt = b64encode(f.read()).decode()

        service_request = service.images().annotate(body={
            "requests": [{
                "image":{
                    "content": ctxt
                  },
                "features": [
                    {
                        "type": "FACE_DETECTION"
                    }, 
                    {
                        "type": "TEXT_DETECTION"
                    }
                ]
            }]
        })
        response = service_request.execute()

    except Exception as e:
        logger.exception(e)

def getGoogleService(keyFile, scope, api_name, api_version):
    credentials = ServiceAccountCredentials.from_json_keyfile_name(keyFile, scopes=scope)
    return build(api_name, api_version, credentials=credentials, cache_discovery=False) 

このサンプルコードでは、FACE_DETECTIONとTEXT_DETECTIONを指定しています。
それ以外にもLABEL_DETECTION, LANDMARK_DETECTION, LOGO_DETECTION などが指定できますが、指定するとその分料金が加算されてきます。なので、目的が文字検出だけの場合にはTEXT_DETECTIONだけ指定するなどしたほうがいいですね。

featuresに指定できるものや返されるjsonの詳細についてはここでは書きません。Cloud Vision API ドキュメントを参照ください。料金の詳細についてはこちら。

本当はGoogle Driveにアップロードしたファイルに対してVisionしたかった

のですが、できませんでした。

test.py

        imageUri = "https://drive.google.com/uc?id=" + fileID
        service_request = service.images().annotate(body={
            "requests": [{
                "image":{
                    "source":{
                      "imageUri": imageUri
                    }
                  },
                "features": [
                    {
                        "type": "FACE_DETECTION"
                    }, 
                    {
                        "type": "TEXT_DETECTION"
                    }
                ]
            }]
        })
        response = service_request.execute()

こんな感じでイケると思ったのですが、以下のようなエラーが返ってきてしまい、色々試したのですが結局できませんでした。

response.json

{"responses": [{"error": {"code": 7, "message": "We're not allowed to access the URL on your behalf. Please download the content and pass it in."}}]}
{"responses": [{"error": {"code": 4, "message": "We can not access the URL currently. Please download the content and pass it in."}}]}ass it in."}}]}

Visionを呼び出すことは出来てるのですが、VisionからWeb上の画像(imageUri)にアクセスできてないみたいですね。S3のPublicバケット上の画像の直リンクを指定してもダメでした。謎です。誰か教えて下さい。

動作確認

TEXT_DETECTIONでは、textAnnotationsとfullTextAnnotationという2つの要素が得られます。
textAnnotationsで検出された領域をブルー、fullTextAnnotationで検出された領域をグリーンで囲った結果は以下のような感じでした。

まずまずの結果が得られていると思うのですが、日本語だからかどうなのか、ブルーの方は若干1文字の範囲がズレているような印象を受けますね。

また、下の画像のように1文字1文字が独立しているような場合に弱そうです。これも日本語特有の問題なのか、はたまた違ったfeaturesだったら検出できるのか、その他パラメータで調整できるのか、深追いはしていませんがとにかく期待した結果は得られていません。
将来的にAPIの学習が進んでこの画像にある文字が漏れなく検出できる日がくることを祈るしか無いのが辛いところです。

AWSのRekognitionが文字検出で日本語をサポートしたあかつきには、まずはこの画像で評価をしようと思っています！

あとがき

記事としてまとめることは大切なことだし必要なことだと分かっているのですが、、やっぱり何か新しい機能を作っている時が一番楽しいですね。
その流れでこのVision APIの記事もサラサラと書くことができました。
記事の作成を後回しにすると面倒になってしまうので、記憶の新しいうちに、そしてテンションが高いうちに、さっさと書いてしまうことは大切なことかもしれないなと思った次第です。

今作ってるMosaicというサーバーレスWebアプリ、基本的にはAWSのインフラを利用しているのですが、ゆくゆくはGCPで同じものを構築するということもやりたいと思っています。2020年内には。
インフラはどちらかに統一して構築したほうが良いだろうなと思いますが、RekognitionやVisionAPIのようなWebAPIサービスは、どちらでも良いというか、やりたいことが実現できる方を選択することになりますね。
どちらもAPIを呼ぶだけなので大した事はなく、結局何のシステムもそうなのかもしれませんが、部品を組み合わせて作っている、プラモデルのような、そんな感じがより強くします。
全てを知っておく必要はないと思いますが、1つにこだわりすぎるのも良くないと思いますね。

機械学習された高精度のサービスをこんなに簡単に利用できるのは喜ばしい限りなのですが、それが期待する結果を返してくれなかった場合に手詰まりになってしまうのは辛いところですね。とはいえ、この先の研究分野で何かできるかというと手も足も出ないわけで、いつの日か学習が進んで期待する結果が出てくるのを正座して待つしかできないワタシです。

AWS認定クラウドプラクティショナーに合格したので、勉強方法や感想をかんたんにまとめます。

受験結果

合格（755/1000）

事前知識

およそ1ヵ月前にMicrosoftのAzure Fundamentals試験(AZ-900)に合格していました。

使用した教材

①AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー
②Udemy この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）

勉強期間

・およそ1ヵ月（時間にすると35～40時間くらい）

勉強方法

まずは①のテキストを2周読みました。
1週目は流し読み。2周目はアウトプットとしてQiitaに自分用メモとしてテキストの内容をまとめながら読みました。
その後、もう1つのアウトプットとして②の模試を解きました。
②の模試は最初買うつもりがなかったんですが、①のテキストだけでは学習した内容に自信が持てなかったことと、定価3,600円が割引で1,400円くらいになっていたので買いました。
②の模試は合計7回分（基礎2回、応用3回、難易度高2回）あるのですが基礎と応用を解きました。
1周目はどれもこれも4～5割くらいしか正解しなくて「これはヤバい」と焦りました（このとき試験の1週間前）。
けっきょく②の模試を正解した問題も含めて解説をしっかり読みながら3周して最終的には7割～9割正解するようになりました（この時点で試験1日前（汗））。
②の模試は受講生からのレビューでは「問題が難しすぎる」という声が散見しますが、自分が実際に試験を受けた感想としてはこれくらいの問題でちょうどよかったと思います。
解説も丁寧で詳しいのでこの模試を解いておいてよかったです。
①のテキストだけだと危なかったかも・・・。

感想

試験の問題の当たりはずれはあるでしょうが、思っていたよりも相当難しかったです。MicrosoftのAZ-900試験よりも難しかったんじゃないかなと思います。受けながら途中で「あー、やっちまったかも」と思いました。
②の模試の応用レベルの問題も普通にでていました。逆に言うと、②の模試の問題とよく似た問題も数問でていました。
①のテキストだけだったら厳しかったかもしれないです、
①のテキストを章立てとか太文字とか関係なく隅から隅までばっちり覚えていて7割とれるかどうかという感じだと思いました。
試験の内容は完全な知識問題。「AWSのサービスの名前とその特徴」だとか「こういうことをしたいときAWSのどのサービスを使うか」という感じで。覚えていたら解けるし、覚えていなかったらまったく解けない。
AZ-900のときは実際にAzureを動かして試験にのぞんでその内容が問われたりとかありましたが、今回はAWSのアカウントは作りましたがほぼ触っていませんでした。
試験の合否には関係ありませんが、AWSをほぼ触っていないというのが今回の反省点です。
（試験に受かるための勉強に終始してしまった。）

おまけ

試験が終わったあと合否結果を見る前に9問のアンケートに答える時間が非常にもどかしかったです。
早く結果知りたいのにー、と思いながら焦りながらアンケートに答えていました。
あとブラウザで「合格」って見ていても試験が終わった後レポートをもらえるわけじゃないし、受験結果がAWSのサイトの受験履歴に表示されるまでに時間差があったんで「え？ほんまに受かったん？あれ？見間違い！？」っていささか不安になりました（笑）

参考

https://aws.amazon.com/jp/blogs/devops/auto-scaling-aws-opsworks-instances/

AWS OpsWorksインスタンスの自動スケーリング

• AWS OpsWorksは、アプリケーションの構成と管理に役立ちます。 EC2インスタンスのグループ（スタックおよびレイヤーと呼ばれる）を作成し、マウントするボリュームや、ライフサイクルイベント（起動/シャットダウンなど）に応じて実行するChefレシピなどの構成に関連付けます。このサービスは、インスタンスのプロビジョニングと管理プロセスを合理化し、ChefとEC2を使用してユニフォームフリートを簡単に起動できるようにします。

Auto ScalingとOpsWorksの統合

• Auto Scalingグループ
  ：このグループは、EC2インスタンスのプロビジョニングとリリースを担当します。

• 起動設定
  ：Auto Scalingグループがインスタンスを起動するために使用する設定テンプレート。

• OpsWorksスタック
  ：Auto Scalingグループによってプロビジョニングされたインスタンスは、このスタックに登録されます。

• IAMインスタンスプロファイル
  ：このプロファイルは、OpsWorksに登録する許可をインスタンスに付与します。

• Lambda関数
  ：この関数は、OpsWorksスタックからのインスタンスの登録解除を処理します。

• SNSトピック
  ：このトピックは、Auto Scalingがインスタンスを終了した後に登録解除Lambda関数をトリガーします。

手順

Step 1: Create an IAM instance profile
Step 2: Create an OpsWorks stack
Step 3: Create a Lambda function
Step 4: Create an SNS topic
Step 5: Create a launch configuration
Step 6. Create an Auto Scaling group

記事の趣旨

AWS CLIのコマンドをメモしていく．必要が生じたときに調べて埋めていくので内容は偏ります．

1. AWS CLIとは

コマンドライン上でAWS操作を可能とするツール．インストールとかの話は以前の記事のAWS CLIの項目を参照．以下に書き並べるリファレンスはこちらを参照してコピペしている．

2. 基本操作

認証情報などの設定

aws configure

この設定情報はwindowsの場合C:\Users\USERNAME\.aws\configというファイルに保存される．アクセスキーはIAMサービスからIAMユーザを選択，「認証情報」タグ内の「アクセスキーの作成」ボタンから作成可能．

$ aws configure --profile myprofile //myprofileというプロファイル名で新規作成．存在する場合は更新される．
AWS Access Key ID [None]: //内緒
AWS Secret Access Key [None]: //内緒
Default region name [None]: ap-northeast-1
Default output format [None]: json

以後，各コマンドに--profile myprofileというオプションを付与することで，この認証情報を用いて各種操作を実行できるようになる．

3. EC2関連のコマンド

インスタンスの一覧の表示

aws ec2 describe-instances

$ aws ec2 describe-instances --profile myprofile
{
    "Reservations": [
      //めっちゃ長いので省略
    ]
}

--flitersオプションに続けて使うことで対象を絞り込める．keyの種類はこちらを参照．

$ aws ec2 describe-instances --filters Name=instance-id,Values=tekitou --profile myprofile  //存在しないidを指定してみる
{
    "Reservations": []  //何も出てこない．
}

--queryを使って表示項目を絞り込むとわかりやすい．

$ aws ec2 describe-instances \
--query "Reservations[*].Instances[*].{NAMAE: InstanceId, BASHO: PublicIpAddress, JOTAI: State.Name}" \
--profile myprofile
[
    [
        {
            "NAMAE": //内緒,
            "BASHO": //xxx.xxx.xxx.xxx",
            "JOTAI": "running"
        }
    ]
]

インスタンスの停止・起動

• stop-instances
• start-instances

$ aws ec2 stop-instances --instance-ids //内緒 --profile myprofile
{
    "StoppingInstances": [
        {
            "CurrentState": {
                "Code": 64,
                "Name": "stopping"
            },
            "InstanceId": //内緒,
            "PreviousState": {
                "Code": 16,
                "Name": "running"
            }
        }
    ]
}

$ aws ec2 describe-instances \
--query "Reservations[*].Instances[*].{NAMAE: InstanceId, BASHO: PublicIpAddress, JOTAI: State.Name}" \
--profile myprofile //どうなったか確認してみる
[
    [
        {
            "NAMAE": //内緒,
            "BASHO": //xxx.xxx.xxx.xxx",
            "JOTAI": "stopped" //停止している
        }
    ]
]

$ aws ec2 start-instances --instance-ids //内緒 --profile myprofile //再度起動してみる
{
    "StartingInstances": [
        {
            "CurrentState": {
                "Code": 0,
                "Name": "pending"
            },
            "InstanceId": //内緒,
            "PreviousState": {
                "Code": 80,
                "Name": "stopped"
            }
        }
    ]
}

$ aws ec2 describe-instances \
--query "Reservations[*].Instances[*].{NAMAE: InstanceId, BASHO: PublicIpAddress, JOTAI: State.Name}" \
--profile myprofile //どうなったか確認してみる
[
    [
        {
            "NAMAE": //内緒,
            "BASHO": xxx.xxx.xxx.xxx,
            "JOTAI": "running" //起動してくれた
        }
    ]

4. VPC関連のコマンド

セキュリティグループのルールを追加・削除

• authorize-security-group-ingress
• revoke-security-group-ingress

--group-idもしくは--group-nameというオプションを用いることで対象グループを指定．設定情報は--protocol，--port，--cidr，--source-groupなどのオプションで指定可能．

$ aws ec2 authorize-security-group-ingress \
--group-id //内緒 \
--port 22 \
--cidr xxx.xxx.xxx.xxx/32 \
--protocol tcp \
--profile myprofile

// なんの反応もないが成功はしている，対象にsshできるようになっている

$ aws ec2 revoke-security-group-ingress \
--group-id //内緒 \
--port 22 \
--cidr xxx.xxx.xxx.xxx/32 \
--protocol tcp \
--profile myprofile

// こちらも同様，sshを試みるとタイムアウトした

目的

AWS IoTへのモノの登録を、AWS IoT Python SDKを用いて行います。
モノが大量になると、コンソールで毎回登録するのが大変なため。

補足

モノの登録と同時に下記のことを行います。

• 各種情報登録
  • "属性"に情報を登録
  • デバイスシャドウに情報を登録
  • モノを"モノのグループ"に追加
• 証明書の発行、アタッチ
  • デバイス証明書・キーを発行して保存
  • ポリシーを証明書にアタッチ
  • モノを証明書にアタッチ

実行

事前準備

• モノを所属させるグループを作成しておきます。（手順は割愛）
  

• 証明書にアタッチするポリシーを作成しておきます。（手順は割愛）
  

コード

import boto3
import json
import os

class AWSIoT():

    # 証明書、キーのファイル名
    FILENAME_PUBLIC_KEY = 'public_key.pem'
    FILENAME_PRIVATE_KEY = 'private_key.pem'
    FILENAME_CERT = 'cert.pem'

    def __init__(self, dirpath_cert):

        # 使用するクラスをインスタンス化
        self.client_iot = boto3.client('iot')
        self.client_iotdata = boto3.client('iot-data')

        # 証明書を保存するディレクトリ
        self.DIRPATH_CERT = dirpath_cert

        return


    def enroll_thing(self, thing_name, dict_attr, group_name, property_desired, property_reported, policy):
        '''
        AWS IoTにモノを登録する
        '''
        # AWS IoTにモノを登録（"属性"にモノの情報を登録）
        self.__create_thing(thing_name, dict_attr)

        # 登録したモノをグループに追加
        self.client_iot.add_thing_to_thing_group(thingGroupName=group_name, thingName=thing_name)

        # デバイスシャドウに情報を登録
        self.__update_shadow(thing_name, property_desired, property_reported)

        # デバイス証明書・キーを発行、保存
        response = self.__create_keys_and_cert(thing_name)

        # ポリシーを証明書にアタッチ
        self.client_iot.attach_policy(policyName=policy, target=response['certificateArn'])

        # デバイスに証明書を紐付け
        self.client_iot.attach_thing_principal(thingName=thing_name, principal=response['certificateArn'])

        return


    def __create_thing(self, thingname, dict_attr):
        '''
        AWS IoTにモノを登録（"属性"にモノの情報を登録）
        '''
        # 登録情報（属性）を生成
        attributePayload = self.__create_attribute_payload(dict_attr)

        # モノを登録
        self.client_iot.create_thing(
            thingName=thingname,
            attributePayload=attributePayload
        )

        return   


    def __create_attribute_payload(self, dict_attr):
        '''
        登録情報（属性）を生成
        '''
        attributePayload = {
                'attributes': dict_attr
        }
        return attributePayload


    def __update_shadow(self, thing_name, property_desired, property_reported):
        '''
        デバイスシャドウに情報を登録
        '''
        # バージョン情報をデバイスシャドウに書き込む形式に整形
        payload = self.__create_payload(property_desired, property_reported)

        # デバイスシャドウに情報を登録
        self.client_iotdata.update_thing_shadow(
            thingName=thing_name,
            payload=payload
        )

        return


    def __create_payload(self, property_desired, property_reported):
        '''
        バージョン情報をデバイスシャドウに書き込む形式に整形
        '''
        payload = json.dumps({'state': 
            {"desired": {"property": property_desired},
            "reported": {"property": property_reported}}})

        return payload


    def __create_keys_and_cert(self, thing_name):
        '''
        デバイス証明書・キーを発行、保存
        '''
        # 証明書、キーを発行
        response = self.client_iot.create_keys_and_certificate(setAsActive=True)

        # 保存先のディレクトリパスを生成
        dirpath_save = self.DIRPATH_CERT + thing_name + '/'

        # ファイルに書き込んで保存
        self.__write_to_file(dirpath_save, self.FILENAME_PUBLIC_KEY, response['keyPair']['PublicKey'])
        self.__write_to_file(dirpath_save, self.FILENAME_PRIVATE_KEY, response['keyPair']['PrivateKey'])
        self.__write_to_file(dirpath_save, self.FILENAME_CERT, response['certificatePem'])

        return response


    def __write_to_file(self, dirpath, filename, contents):
        '''
        ファイルに書き込み
        '''
        os.makedirs(dirpath, exist_ok=True)

        filepath = dirpath + filename
        with open(filepath, mode='w') as f:
            f.write(contents)

        return

実行

• 登録情報を定義
  • 今回は"ThingName"という名前のモノを登録します。
  • 属性には、'BuildingName'として'hogehoge_building'を、'Floor'として'6'を登録します。
  • デバイスシャドウには理想の気温と、現在の気温を登録します。

# モノの名前
thing_name = 'ThingName' 

# モノの属性（属性キー:値）
dict_attr = {'BuildingName':'hogehoge_building', 'Floor':'6'}

# モノを所属させるグループの名前
group_name = 'hogehoge_group'

# デバイスシャドウに登録する情報
temp_desired = 26
temp_reported = 22

# 証明書にアタッチするポリシー
policy = 'policy_thermometer'

# 証明書、キーを保存するディレクトリのパス
dirpath_cert = './cert/'

• クラスをインスタンス化して実行

awsiot = AWSIoT(dirpath_cert)
awsiot.enroll_thing(thing_name, dict_attr, group_name, temp_desired, temp_reported, policy)

結果

デバイスの登録が出来ました。
属性も正しく登録されています。

シャドウも正しく登録されています。（"delta"は自動で作成されます。詳細は割愛。）

証明書も正しく紐付けられていて、

証明書にはポリシーがアタッチされています。

あとがき

めちゃめちゃ初心者なので、本当に些細なことでもご指摘・コメントいただけますと幸いです。
Twitterやってます→@shin_job

https://docs.aws.amazon.com/ja_jp/codestar/latest/userguide/how-to-add-team-member.html

AWS CodeStar ロールとチームメンバーシップの利点

• チームメンバーの IAM でアクセス許可を手動で設定する必要はありません。

• チームメンバーのプロジェクトへのアクセスレベルを簡単に変更できます。

• ユーザーは、チームメンバーである場合にのみ、AWS CodeStar コンソールでプロジェクトダッシュボードにアクセスできます。

• プロジェクトへのユーザーアクセスは、ロールによって定義されます。

CodeStar と連携する Managedサービス

• コードはCodeCommit に。Git credentialsは IAM Userに。

参考

https://docs.amazonaws.cn/en_us/amazondynamodb/latest/developerguide/DAX.html#DAX.use-cases

Use Cases for DAX

• DAXは、マイクロ秒のレイテンシで、DynamoDBテーブルから最終的に一貫したデータへのアクセスを提供します。 Multi-AZ DAXクラスターは、1秒あたり何百万ものリクエストに対応できます。

• DAXは、次の種類のアプリケーションに最適です。

  • 読み取りに可能な限り速い応答時間を必要とするアプリケーション。一部の例には、リアルタイム入札、ソーシャルゲーム、取引アプリケーションが含まれます。
  • 少数のアイテムを他のアイテムよりも頻繁に読み取るアプリケーション。たとえば、人気のある商品の1日販売があるeコマースシステム

• 読み取り集中型であるが、コストに敏感なアプリケーション。

  • DynamoDBでは、アプリケーションが必要とする1秒あたりの読み取り数をプロビジョニングします。読み取りアクティビティが増加した場合、テーブルのプロビジョニングされた読み取りスループットを増やすことができます（追加費用がかかります）。または、アクティビティをアプリケーションからDAXクラスターにオフロードし、別の方法で購入する必要がある読み取りキャパシティーユニットの数を減らすことができます。

• 大量のデータに対して繰り返し読み取りが必要なアプリケーション。

  • このようなアプリケーションは、データベースリソースを他のアプリケーションから迂回させる可能性があります。たとえば、地域の気象データの長期にわたる分析では、DynamoDBテーブルのすべての読み取り容量が一時的に消費される可能性があります。この状況は、同じデータにアクセスする必要がある他のアプリケーションに悪影響を及ぼします。 DAXを使用すると、代わりにキャッシュされたデータに対して気象分析を実行できます。

• DAXは、次の種類のアプリケーションには理想的ではありません。

  • 強く一貫した読み取りを必要とする（または最終的に一貫した読み取りを許容できない）アプリケーション。
  • 読み取りにマイクロ秒の応答時間を必要としないアプリケーション、または基になるテーブルから繰り返し読み取りアクティビティをオフロードする必要のないアプリケーション。
  • 書き込み集中型のアプリケーション、または読み取りアクティビティをあまり実行しないアプリケーション。
  • DynamoDBで別のキャッシングソリューションを既に使用しており、そのキャッシングソリューションを操作するために独自のクライアント側ロジックを使用しているアプリケーション。

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-validate-template.html

テンプレートファイルの構文エラーを確認するには、aws cloudformation validate-templateコマンドを使用できます。

• 使い時
  • syntaxチェック
  • rollback したときに同じ状態になっているか確かめる

はじめに

AWSの認定試験を受験するにあたって、各AWSのサービスを幅広く理解する必要があったためサービスごとに抑えるべきポイント等をまとめてみました。

ちなみにAWS認定試験での勉強方法についてはこちらの記事で紹介しています。

• AWS 認定Developer Associateに合格するまで

今回はEC2についてアソシエイトレベルでまとめたものになります。

※情報は2019年12月31日時点のものになります。ご了承ください。

概要

• AWS上で起動する仮想サーバー
• 購入時に起動するインスタンスタイプを選択できる
• インスタンスタイプによって仮想サーバーのスペックが変わる(CPUやメモリなど)
• sshなどでログインする際にはキーペア(pemキー)が必要

料金

選択されたインスタンスタイプ、購入方法によって異なる
基本はインスタンスを起動させている時間(秒単位)に応じて料金が発生する

購入方法

購入方法は以下になります。

■オンデマンドインスタンス

• 割引なしでインスタンスを購入する方法
• 処理が中断して落ちない

■リザーブドインスタンス

• オンデマンドよりも安い値段でインスタンスを購入する方法
• 処理が中断して落ちる可能性がある

■ハードウェア占有インスタンス（Dedicated Instance)

• 独立したハードウェアを購入する方法 オンデマンドなどでは同じハードウェアで複数インスタンスが同居して購入される可能性がある
• 物理サーバーの選択は不可能

■専用ホスト（Dedicated Hosts）

• 独立したハードウェアを購入する方法
• 物理サーバーの選択は可能
• BYOL(Bring Your Own License)型のソフトウェアライセンスを持ち込める

■Saving Plan

• 1~3年で一定のCPU使用料で契約する方法

AMI

EC2を起動するためのテンプレートのようなもの
この事前にソフトウェアなどをインストールしたインスタンスを立ち上げたいときに便利

• AMIリストを取得するにはDescribeImagesを実行する
• 別のリージョンでAMIを使用する場合は、AMIを別のリージョンにコピーする必要がある
• AMIはS3に作成される

ネットワーク

ネットワーク関連についてまとめます。

■プライベートIP

• EC2インスタンスを起動したサブネット内で割り当てられたIPアドレス
• 起動時に指定することができる

■パブリックIP

• AWSによって割り当てられるグローバルIPアドレス
• EC2インスタンスが停止→起動をすると新しいグローバルIPアドレスが割り当てられる
• EC2インスタンスが再起動してもグローバルIPアドレスは変わらない
• EC2インスタンスからインターネットにアクセスする場合はパブリックIPが割り当てられるように設定する必要がある

■Elastic IP

• AWSが用意したグローバルIPアドレス
• EC2インスタンスにアタッチする必要がある
• EC2インスタンスが再起動(停止→起動)しても同一のグローバルIPアドレスを利用できる

■ENI(Elastic Network Interface)

• 仮想ネットワークインターフェース
• 複数のIPアドレスが割り当てられる

プレイスメントグループ

EC2同士の通信を高速化できるEC2のグループ設定

• EC2インスタンスは同じアベイラリティゾーンである必要がある

セキュリティグループ

EC2インスタンスのアクセス制限を行う機能

• EC2インスタンスへのアクセスの許可のみを管理する（拒否の指定はできない）
• インバウンドが許可されると自動的にアウトバウンドも許可される
• デフォルト設定ではインバウンドの許可がされていない状態（つまり、すべてのインバウンドは拒否される）

インスタンスメタデータ

curlで取得できるインスタンスの情報

curl http://（IPアドレス）/latest/meta-data/instance-id

ストレージ関連

EC2のストレージ関連についてまとめます。

■インスタンスストア

EC2のローカルディスク

• EC2インスタンスが停止または削除されるとデータが削除される
• EC2インスタンスが休止中のときはデータが保持される
• インスタンスストアのデータを引き続き保持したい場合は、その時点のAMIを取得する方法が有効

■EBS(Elastic Block Store)

EC2にアタッチできるブロックストレージ

• EC2を停止してもEBSは削除されない
• 同じリージョンであれば同じEC2インスタンスに複数のEBSをアタッチできる
• 同じEBSを複数のインスタンスに同時にアタッチできない
• EBS-backedインスタンスはインスタンスの停止と再開ができるが、Instance store-backedインスタンスではできない
• ボリュームを暗号化できる
• EBSスナップショットでバックアップを作成できる

EBSのボリュームタイプについて

Provisioned IOPS SSD

• I/Oの負荷が大きくても耐えられる(データベース用途など)
• IOPSの性能を指定したボリュームを作成可能（追加料金）

汎用SSD

• コスパがいい汎用的なSSD

スループット最適化HDD

• 高いスループットが期待できるHDD

コールドHDD

• 性能は低いが安い
• 古いデータのバックアップなどに向いてる

マグネティック

• 旧世代のボリュームタイプ

※IOPSとスループットの違い

IOPSとは

• ストレージが1秒あたりに処理できるI/O（書き込み・読み込み）アクセスの数。
• 一般的にHDDは1分あたりの回転数(PRM)に制限があるためIOPSは低い

スループットとは

• 1秒間の最大データ転送量

EBS最適化インスタンス

EC2、EBS間の回線が専用回線で繋がっているインスタンス

ネットワークがボトルネックになっているときに有効

特定のインスタンスタイプでのみ対応しているので、すべてのインスタンスで利用可能なわけではない

ボリュームのディレクトリ

仮想化タイプ	使用可能	ルート用に予約済み	EBS ボリュームとして推奨	インスタンスストアボリューム
準仮想化	/dev/sd[a-z]/dev/sd[a-z][1-15]/dev/hd[a-z]/dev/hd[a-z][1-15]	/dev/sda1	/dev/sd[f-p]/dev/sd[f-p][1-6]	/dev/sd[b-e]
HVM	/dev/sd[a-z]/dev/xvd[b-c][a-z]	AMI による違い/dev/sda1 or /dev/xvda	/dev/sd[f-p] *	/dev/sd[b-e]/dev/sdb-h/dev/sdb-y/dev/sdb-i**

その他の豆知識

• OSを再起動させたい時はReboot(再起動)を行う
• EC2インスタンスを起動する際に実行したいシェルスクリプトを指定することができる(ユーザーデータという)
• セキュリティの修正プログラムは初期起動時に実施される

最近、AWS費用削減のため、Instance Schedulerを使ったRDSの自動起動・停止の仕組みを導入しました。
Instance Schedulerは、EC2とRDSインスタンスの起動および停止スケジュールを設定できるソリューションです。
今回は、RDSを自動起動・停止するために必要な一連の設定手順についてまとめていこうと思います。

なお、手順については、AWSナレッジセンターの下記記事を参考にさせていただきつつ、ところどころ必要に応じて変更しています。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/stop-start-instance-scheduler/

事前準備

Instance Schedulerを使うには、Instance Scheduler CLIのセットアップが必要になります。また、Instance Scheduler CLIの利用するにあたり、AWS CLIの認証情報が必要になりますので、AWS CLIの設定も合わせて行う必要があります。
※AWS CLIとInstance Scheduler CLIが設定済みの方は、事前準備はスキップして大丈夫です。

AWS CLIのセットアップ

こちらはAWSの日本語ドキュメントが充実しているので、そちらを引用させていただきます。

• AWS CLI バージョン 1 のインストール
  https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv1.html
• AWS CLIの設定
  https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration

Instance Scheduler CLIのセットアップ

下記ページにダウンロードリンクがあるので、こちらからパッケージ「scheduler-cli.zip」をダウンロードし、解凍します。
https://docs.aws.amazon.com/solutions/latest/instance-scheduler/appendix-a.html#install

解凍後、パッケージのディレクトリへ移動し、下記コマンドでインストールします。

.bash

# 解凍したパッケージのディレクトリへ移動
$ cd ~/Downloads/scheduler-cli

# インストール
$ python setup.py install

# scheduler-cliコマンドが使えることを確認
$ scheduler-cli --version
scheduler-cli v1.2.0

Instance Schedulerの設定

Instance Schedulerのスタック作成

それでは、ここからInstance Schedulerを設定していきます。
Instance Schedulerテンプレートが下記に用意されているので、下記ページにアクセスし、AWSコンソールにログインした上で「Launch Solution」をクリックして起動します。
https://docs.aws.amazon.com/solutions/latest/instance-scheduler/deployment.html#step1

デフォルトでは、バージニア北部（us-east-1）で開かれるので、右上のメニューから自身が利用したいリージョンに変更します。今回は東京（ap-northeast-1）で作成しますので、リージョン変更してから「次へ」をクリックします。

「スタックの詳細を指定」画面では、パラメータを選択・設定していきます。今回は下記のパラメータをデフォルト値から変更しています。

• スタックの名前：RDSInstanceScheduler
• Service(s) to schedule：RDS
• Create RDS instance snapshot：No
• Region：ap-northeast-1
• Default time zone：Asia/Tokyo
• Enable CloudWatch Logs：Yes
• Log retention days：7
• Started tags：state=started
• Stopped tags：state=stopped

「スタックオプションの設定」画面はデフォルト値のまま「次へ」をクリックします。

「レビュー」画面で設定内容を確認できまし。内容を確認し、問題がなければ、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「スタックの作成」をクリックします。

Instance Schedulerのスタック作成が完了すると、DynamoDBのインスタンススケジューラ構成テーブルが作成されます。このテーブルの中にインスタンスの起動する期間やスケジュール等の内容が保存されていて、scheduler-cliコマンドを使って必要な設定の作成・変更を行なっていきます。

今回は、月曜日から金曜日の7:30 〜 23:30の間、RDSインスタンスを起動するスケジュールを作成してみます。

インスタンスを起動する期間を作成・更新

期間では、インスタンスを起動しておく時間を定義します。「office-hours」という期間がデフォルトで作成されていますので、update-periodコマンドを使って、今回設定したい期間である「月曜日から金曜日の7:30 〜 23:30」へ変更します。なお、create-scheduleコマンドを使えば、好きな名称の期間を作成することもできます。

.bash

$ scheduler-cli update-period --profile cfn --stack RDSInstanceScheduler --region ap-northeast-1 --name office-hours --begintime 07:30 --endtime 23:30 --weekdays mon-fri
{
   "Period": {
      "Weekdays": [
         "mon-fri"
      ],
      "Endtime": "23:30",
      "Type": "period",
      "Begintime": "07:30",
      "Name": "office-hours"
   }
}

DynamoDBを確認すると、設定した期間に更新されていることを確認できます。

スケジュールを作成・更新

スケジュールは、RDSインスタンスにどのスケジュールを適用するかを識別するタグ値として使用します。
デフォルトで「uk-office-hours」というスケジュールが作成されていますので、それにならって、「jp-office-hours」というスケジュールを作成します。作成した後に設定内容を変更したい場合は、「update-period」コマンドを使って変更することができます。

bash

$ scheduler-cli create-schedule --profile cfn --stack RDSInstanceScheduler --name jp-office-hours --region ap-northeast-1 --periods office-hours --timezone Asia/Tokyo
{
   "Schedule": {
      "RetainRunning": false,
      "Enforced": false,
      "Hibernate": false,
      "Name": "jp-office-hours",
      "UseMetrics": false,
      "StopNewInstances": true,
      "Periods": [
         "office-hours"
      ],
      "UseMaintenanceWindow": false,
      "Timezone": "Asia/Tokyo",
      "Type": "schedule"
   }
}

DynamoDBを確認すると、新しいスケジュールが作成されていることが確認できます。

スケジュールのタグ付け

作成したスケジュールを停止したいRDSへタグ付けすれば、スケジュール通りに起動・停止するようになります。
対象のRDSのタグに下記の通り登録します。

• Schedule：jp-office-hours

RDSが停止している間は、下記のように停止中を意味するタグが付けられます。

• Schedule：stopped

RDSが起動している間は、下記のように起動中を意味するタグが付けられます。

• Schedule：started

Opsworksで作成したLinuxインスタンスがデータベースに接続するには、適切なドライバーパッケージをインストールするよう、アプリケーションサーバーの [Recipes] タブを編集すること

参考

https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workingapps-connectdb.html

アプリケーションのデータベースサーバーへの接続

AWS OpsWorks スタックにより 2 つの方法でアプリケーションにDBサーバーへの情報が提供されます。

• Linux スタックでは、AWS OpsWorks スタックにより、各組み込みアプリケーションサーバーインスタンスに、アプリケーションがデータベースサーバーへの接続に使用できる接続データを含むファイルが作成されます。

• AWS OpsWorks スタックでは、各インスタンスにインストールされるスタック設定およびデプロイ属性に接続情報が含められます。

  • カスタムレシピを実装してこれらの属性から接続情報を取得し、任意の形式でファイルに配置することができます。詳細については、「アプリケーションへのデータの引き渡し」を参照してください。

重要

Linux スタックでは、Amazon RDS サービス Layer をアプリケーションと関連付ける場合は、次の手順に従って、関連付けたアプリケーションサーバー Layer に適切なドライバパッケージを追加する必要があります。

1. ナビゲーションペインで [Layers] をクリックし、アプリケーションサーバーの [Recipes] タブを開ます。

2. [Edit] をクリックして 適切なドライバパッケージを [OS Packages] に追加します。 たとえば、Layer に Amazon Linux のインスタンスが含まれている場合は [mysql] を、Layer に Ubuntu インスタンスが含まれている場合は [mysql-client] を指定する必要があります。

3. 変更を保存してアプリケーションを再デプロイします。

はじめに

この記事では、いかにして私が2週間ほどの勉強期間でデベロッパーアソシエイトの認定を合格したのかを紹介いたします。

動機

今までの業務ではAWSを主に分析やETL処理といった用途で扱ってきたが、新しい業務ではAWSの基本的なサービスを抑える必要がありました。

そこで、AWSの勉強の１つのマイルストーンとして認定試験の合格とし、勉強をはじめました。

経歴

私は業務でデータエンジニア、データサイエンティストといった職種の業務を担当することが多く、触ったことがある AWSサービスはかなり偏っておりました。
(もちろん他のAWS認定資格は持ち合わせておりません)

ちなみに勉強を始める以前に使ったことのあるサービスは以下になります。

• S3
• AWS Athena
• EMR
• EKS
• AWS QuickSight
• AWS CodeBuild
• AWS Glue
• AWS ECS

分かる人はわかるかもしれませんがこの中で認定試験で頻出するサービスはS3とCodeBulidくらいで、正直0からのスタートといっても過言ではありませんでした。

特にDeveloper Associateの問題で頻出のLambdaはDynamoDBすらも触ったことがありませんでした。

勉強方法

1. 対策本を読む

まずはAWSのサービスの全体像を抑えるために認定試験の対策本を読書いたしました。

読んだ本は以下になります。

AWS認定アソシエイト3資格対策~ソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーター~
https://www.amazon.co.jp/dp/4865941991

サービスごとにポイントが解説されているため、知識を整理しやすかったです。

2. サービスごとのポイントを自分なりに整理してアウトプットする

対策本を読むことである程度知識をインプットできたので、次にアウトプットを行いました。

自分なりに各サービスのポイントをまとめてノートのようなものを作成いたしました。

そのときの成果物が以下になります。

• 【AWS認定試験対策】EC2のポイントまとめ

• 【AWS認定試験対策】ネットワークのポイントまとめ(Qiitaにて執筆中)

• 【AWS認定試験対策】DBサービスのポイントまとめ(Qiitaにて執筆中)

• 【AWS認定試験対策】Code3兄弟のポイントまとめ(Qiitaにて執筆中)

• 【AWS認定試験対策】Lambdaのポイントまとめ(Qiitaにて執筆中)

• 【AWS認定試験対策】その他サービスのポイントまとめ(Qiitaにて執筆中)

3. 模擬試験を受験する

本番の試験問題の雰囲気を知ることと自分が今何が苦手なのかを知ることを目的として、模擬試験を受験いたしました。上司の進言で他のアソシエイトレベルの模擬試験も受験することをすすめられたのでアソシエイトレベルのものをすべて受験いたしました。

そのときの結果がこちらです。合格ラインは72%です。

• Developer - Associate：70%(不合格)
• Solution Architect - Associate：75%(合格)
• SysOps Administrator - Associate：75%(合格)

自分が受験するデベロッパーアソシエイト以外が合格という結果でした。

ちなみに模擬試験では問題の正答が公表されておらず、自分がどの分野(セキュリティの分野やデプロイメントの分野など)でどのくらい正答したのかがわかります。

このとき、私はスクショを撮ってどの問題を誤答したのか分析して復習しました。

たしか、ElasticBeanstalkのデプロイメント方式を全然理解できていなかったり、Lambdaのリトライ方式について把握し切れていなかったことがわかり急いで勉強した記憶があります。

4. 問題集を解く

最後に以下のサイトの問題集を解いて仕上げました。

https://aws.koiwaclub.com/

誤答したらなぜ間違えたのかすぐにフィードバックされるのがよかったです。

試験本番

試験は約60問を120分間で解きます。

つまり、2分で1問のを解くということになりますが、すべて選択問題であるためそんなに時間に迫られたといった印象はありませんでした。

私は3周見直しをして60分余り、これ以上やっても結果が変わらないと判断し終了しました。

結果

合否の結果は試験終了直後にPCの画面に表示されます。

結果は合格でした。

数時間するとAWSの認定アカウントにスコアが載ります。

私の結果は1000点中、805点でした。(合格ラインは720点)

感想

当初の狙い通り、認定資格の合格を目標とすることでAWSの基本的なサービスのポイントを抑えられた実感があります。

以前はちんぷんかんぷんだった同僚の技術的な話にも少しずつついていけるようになりました。

また、自分の使っているサービスでも改めて客観的に勉強してみることで新たな気付きにつながりました。

例えば、以前はこうやってETL処理基盤を構築したけど今思えば密結合だよな。。。だとか考えられる幅が変化しました。

しかし、認定資格を合格したからといってどんどん新しい業務ができるようになった！！というわけではありませんでした。

やはり、サービスを「知っている」と「触ったことがある」の違いはとても大きいように感じます。

ですので、認定合格した際には是非知らなかったサービスを自分の手で触ってみることをおすすめいたします。

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/applications-lifecycle.html

アプリケーションバージョンライフサイクルの設定

• Elastic Beanstalk は、新しいアプリケーションバージョンを作成するたびにアプリケーションのライフサイクルポリシーを適用し、ライフサイクルポリシーが適用されるたびに、最大 100 個のバージョンを削除
• デフォルトでは、Elastic Beanstalk はデータの損失を防ぐため、アプリケーションバージョンのソースバンドルを Amazon S3 に残します。ソースバンドルを削除すると、領域を節約できます。

アプリケーションバンドル

ソースバンドルの要件

• 単一の ZIP ファイルまたは WAR ファイルで構成される (WAR ファイル内に複数の ZIP ファイルを含めることが可能)

• 512 MB 以下

• 親フォルダまたは最上位ディレクトリを含まない（サブディレクトリを除く）

欲しいのはEBSじゃなくてエフェメラルなディスク

AWS BatchでEBSを使う方法なら、どこにでも書いてある。でもインスタンスストレージは？　2020年1月25日調べでは、どうやらどこにも書いてない。
エフェメラルなディスクが欲しいときにEBSを使うと、アホな管理の手間が発生するし、おそらくはインスタンスストレージのほうが速い。

結論

1. BatchのCompute environmentで、Instance typesにc5dなどのインスタンスストレージつきのを選ぶ

2. ジョブが走るコンテナ内でlsblkする

c5d.4xlargeの場合、ログはこうなる：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
/dev/nvme2n1 259:0 0 372.5G 0 disk
/dev/nvme1n1 259:1 0 22G 0 disk
└─/dev/nvme1n1p1 259:5 0 22G 0 part
/dev/nvme0n1 259:2 0 8G 0 disk
├─/dev/nvme0n1p1 259:3 0 8G 0 part /etc/hosts
└─/dev/nvme0n1p128 259:4 0 1M 0 part

どう見ても/dev/nvme2n1がインスタンスストレージ。これを直にマウントしようとしても、コンテナ内のファイルシステムからでは見つからない。ファイルシステムから見えないものが、なぜかlsblkでは見えるのだ。この盲点を発見するまで、地獄めぐりをさせられた。

3. Job definitionのLinux Parametersでデバイスをマッピング

ホストもコンテナも、パスは/dev/nvme2n1でOK。パーミッションは当然全部加える。privilegedもオン。

4. ジョブの最初に走るbashスクリプトの冒頭で、フォーマットしてマウント

mkfs.ext4 -E nodiscard /dev/nvme2n1
mkdir $HOME/scratch_dir
mount -o discard /dev/nvme2n1 $HOME/scratch_dir

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-available.html
RHEL/CentOS はないがWindowsはある。

参考

https://dev.classmethod.jp/cloud/aws/emr-dynamo/
https://cloud-textbook.com/8/#emr
https://cloud-textbook.com/8/#kinesis
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-amazon-kinesis

Amazon Elastic MapReduce (EMR) とは

AWS 上で Hadoop や、Hive や、Apache Spark を簡単に使う仕組み。 何ができるかと言うと、Hadoop や Spark を使って、ビッグデータの分散処理が行える。 Hadoop は、複数マシンにデータを分散させて MapReduce ができる仕組み。 Hive は Hadoop を SQL で操作可能にする仕組み・ Spark は MapReduce 部分の代替品でオンメモリにより高速化するのが狙い。 向き不向きはあるものの、一般的には Amazon Redshift の方が高速かつ高額という評価らしい。

Amazon Kinesis Data Analytics は、

ストリームデータを SQL で処理することができる。 分析結果を S3 や Redshift に格納することができる。 また、SQL で一定条件のものを抽出し、再度 Kinesis Streams に流して、Lambda で処理し、通知したり DynamoDB や RDS に反映させたりすることができる。

※https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-amazon-kinesis より

https://aws.amazon.com/jp/about-aws/whats-new/2019/05/aws-codecommit-now-supports-the-ability-to-make-an-initial-commit/

CloudFormation スタックに AWS CodeCommit リポジトリを作成する際に最初のコミットを作成できる

• README ファイルやサンプルコードなど、新しく作成した CodeCommit リポジトリに追加したいコンテンツを含めた ZIP ファイルを作成できるようになった。

AWS::CodeCommit::Repository

{
  "Type" : "AWS::CodeCommit::Repository",
  "Properties" : {
      "Code" : Code,
      "RepositoryDescription" : String,
      "RepositoryName" : String,
      "Tags" : [ Tag, ... ],
      "Triggers" : [ RepositoryTrigger, ... ]
    }
}

参考

https://cloud-textbook.com/8/#guardduty

GuardDuty

ログを分析し、異常と思われる挙動がある場合警告を行う仕組み。例えば以下のような警告例がある。2018/1 時点、EC2 と IAM のみが警告対象。

Inspector

EC2 の脆弱性自動チェックサービス。対象範囲はネットワーク・OS・ミドルウェアで、あらかじめ AWS が CVE などを元に準備したチェック項目に従い、不正アクセスができたりしないかなどを実際にチェックする。EC2 に専用のエージェントをインストールする必要あり。対象 OS は Windows または Linux 系 OS。EC2 以外に対して脆弱性チェックを行うことはできない。自作の Web アプリケーションの脆弱性チェックをしてくれるわけではない。

Macie

S3 や CloudWatch にあるデータについて、不審と思われるアクションが行われた場合に通知する仕組み。 「不審」とは、例えば
- 通常とは異なる IP アドレスから大量のダウンロードがあった
- 通常機密コンテンツにアクセスしないユーザーが大量のソースコードをダウンロードした
など。なお、できることは通知のみで、遮断・保護はできない (検知したら Lambda 起動はできるので即時に権限変更やユーザ削除などはできなくはないが、実質的には難しいのでは?)。

参考

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/what-is-cloudsearch.html

Amazon CloudSearch とは

• Amazon CloudSearch はクラウドにおける完全マネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易に設定、管理、拡張縮小できます。

• Amazon CloudSearch を使用して、ウェブページ、ドキュメントファイル、フォーラムの投稿、製品情報など大規模なデータコレクションを検索できます。検索機能を迅速に追加できます。検索の高度な知識を習得したり、ハードウェアの準備、設定、およびメンテナンスについて考える必要はありません。データやトラフィックの変動に伴い、Amazon CloudSearch はニーズに合わせてシームレスにスケーリングします。

Fn::Base64
組み込み関数 Fn::Base64 は、入力文字列の Base64 表現を返します。この関数は通常、UserData プロパティを介して Amazon EC2 インスタンスにエンコードされたデータを渡すために使用されます。

参考

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html

NoEcho

パラメータ値をマスクして、コンソール、コマンドラインツール、または API に表示されないようにするかどうか。NoEcho 属性を true に設定すると、CloudFormation は、スタックまたはスタックイベントを記述するすべての呼び出しに対して、アスタリスク (*****) としてマスクされたパラメータ値を返します。

重要

AWS CloudFormation テンプレートに直接機密情報を埋め込むよりも、以下のいずれかを実行するように強くお勧めします。

• NoEcho プロパティを使用してパラメーター値を難読化 することにより、スタックを作成または更新するたびに入力パラメーターを使用して情報を渡す。

• スタックテンプレートで動的なパラメータを使用して、Systems Manager パラメーターストアや Secrets Manager など、CloudFormation の外部で保存および管理される機密情報を参照する。

参考

https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workingstacks-commands.html

Linux ベースのスタックでのみ、任意のスタックに対して以下のスタックコマンドを実行できます。

Install Dependencies

インスタンスのパッケージをインストールします。Chef 12 以降、このコマンドは使用できなくなります。

Update Dependencies

(Linux のみ。Chef 12 以降、このコマンドは使用できなくなります。) 定期的なオペレーティングシステム更新とパッケージ更新をインストールします。詳細はインスタンスのオペレーティングシステムによって異なります。詳細については、「セキュリティ更新の管理」を参照してください。

参考

https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workinginstances-os.html

• スタックのインスタンスは、Linux または Windows を実行できます。

• Linux インスタンスと Windows インスタンスを混在させることはできません。

• どのスタックでも、時間ベースの自動スケーリングを使用できます。Linux スタックでは、負荷ベースのスケーリングも使用できます。

• AWS OpsWorks スタックを使用して Amazon EC2 インスタンスを作成するだけでなく、AWS OpsWorks スタックの外部で作成された インスタンスを Linux スタックに登録することもできます。

  • これには、Amazon EC2 インスタンスと、独自のハードウェアを実行するインスタンスが含まれます。

参考

https://aws.amazon.com/jp/blogs/devops/use-a-creationpolicy-to-wait-for-on-instance-configurations/

creation policyとは

• AWS CloudFormationスタックでAmazon EC2インスタンスをプロビジョニングする場合、ソフトウェアパッケージのインストールやbootstrap処理など、追加のアクションを指定してインスタンスを設定できるようにするもの。

• 通常、CloudFormationは、インスタンスが正常に作成された後、（たとえ内部でinitスクリプトが完了していなくても）スタックの作成を続行する。

• CreationPolicyを使用するとアクションが完了した後にのみ、CloudFormationがスタックの作成を続行できるように設定が可能。

  • つまり、スタックの作成が成功後にアプリケーションが準備完了であることを確実にするためにCreationPolicyを使用する。

• CreationPolicyは、CloudFormationが指定された数のシグナルを受信するまでインスタンスを待機するようCloudFormationに指示する。このポリシーは、CloudFormationがインスタンスを作成するときにのみ有効となる。

  • 下記の例の場合、5分後に3つの信号が受信されない場合、CloudFormationはスタックの作成をすぐに停止し、Auto Scalingグループに作成に失敗したというラベルを付ける。したがって、インスタンスとアプリケーションをデプロイするのに十分な時間を与えるタイムアウト期間を指定する。

"AutoScalingGroup": {
  "Type": "AWS::AutoScaling::AutoScalingGroup",
  "Properties": {
    ...
  },
  "CreationPolicy": {
    "ResourceSignal": {
      "Count": "3",
      "Timeout": "PT5M"
    }
  }
}

リソースのシグナリング

• プロビジョニングしているインスタンスから信号を簡単に送信できる。これらのインスタンスでは、EC2ユーザーデータスクリプトのcfn-initヘルパースクリプトを使用して、アプリケーションをデプロイする必要がある。 cfn-initスクリプトの後に、次の例のように、cfn-signalヘルパースクリプトを実行するコマンドを追加する。

"UserData": {
  "Fn::Base64": {
    "Fn::Join" [ "", [
      "/opt/aws/bin/cfn-init ",
      ...
      "/opt/aws/bin/cfn-signal -e $? ",
      "  --stack ", { "Ref": "AWS::StackName" },
      "  --resource AutoScalingGroup " ,
      "  --region ", { "Ref" : "AWS::Region" }, "n"
    ] ]
  }
}

• CloudFormationにシグナルを送るとき、どのスタックとどのリソースにシグナルを送るかを知らせる必要がある。この例では、cfn-signalコマンドは、インスタンスをプロビジョニングしているスタック、リソースの論理ID（AutoScalingGroup）、およびスタックが作成されているリージョンを指定する。

• CreationPolicy属性とcfn-signalヘルパースクリプトを使用すると、アプリケーションが正常にデプロイされたときにのみスタックが正常に作成されるようにすることができる。

2020年1月26日現在の内容です。

Webサイトにアクセスする際、IPアドレスを用いるが、IPアドレスは数字で構成されているので覚えにくい。
ドメイン名を用いることでWebサイトのアクセスを簡単にすることができる。

• IPアドレス：93.184.216.34
• ドメイン：example.com

用語説明

ドメイン

インターネット上に存在するコンピューターやネットワーク識別するための名前

ドメイン名はピリオドで区切られた構造をしている
例：www.example.co.jp

jp　→　トップレベルドメイン
co　→　第2レベルドメイン
example　→　第3トップレベルドメイン
www　→　第4トップレベルドメイン

ドメイン名全体はICANNが管理していて、さらにレジストリがトップレベルドメインをそれぞれ管理している。
販売はレジストラとリセラが行う。

	役割	具体的な組織
ICANN	ドメイン全体を管理	ICANN
レジストリ	・トップレベルドメインを管理 ・レジストラに卸す	JPRS(.jp) Verisign(.com/.ne) Public Interest Registry(.org)
レジストラ	・一般消費者に販売 ・リセラに卸す	お名前.com ゴンベエドメイン
リセラ	一般消費者に販売	Yahoo!ドメイン ムームードメイン VALUE-DOMAIN

DNS(Domain Name System)

• ドメイン名の管理システム
• ドメイン名をIPアドレスに変換する
• ネームサーバーとフルリゾルバの2つから構成されている

ドメイン名でWebサイトを見るためには、ドメインとサーバーのIPアドレスをDNSで紐付ける必要がある

ネームサーバー

• ドメイン名とそれに紐づくIPアドレスが登録されているサーバー(電話帳のイメージ)
• ドメイン名の階層ごとにネームサーバーが配置され、そのネームサーバーが配置された階層のドメインに関する情報を管理する

フルリゾルバ

• ドメインに紐づくIPアドレスを問い合わせると、各ネームサーバーに確認し、問い合わせたIPアドレスを返すサーバー(秘書のイメージ)

リソースレコード

DNSのドメイン名とIPアドレスの紐付け1つ1つ（データ）のこと

リソースレコードのタイプ	内容
Aレコード	ドメインに紐づくIPアドレス
NSレコード	ドメインのゾーンを管理するネームサーバー
MXレコード	ドメインに紐づくメール受信サーバー
CNAMEレコード	ドメインの別名でリソースレコードの参照先
SOAレコード	ドメインのゾーンの管理情報

ゾーンファイル

リソースレコードの集合体(DB)

Route 53

AWSのDNSサービス
ネームサーバーの役割を果たす

特徴

• 高可用性(SLA(Service Level Agreement)100%)
• 高速(エッジロケーション(Route 53を提供している場所)の中で最も近いロケーションから応答を返す)
• フルマネージドサービス(DNSサーバーの設計・構築・維持管理が不要)

特徴

• ホストゾーン
  • DNSのリソースレコードの集合(ゾーンファイルのイメージ)
• レコードセット
  • リソースレコードのこと
• ルーティングポリシー
  • Route 53がRecord Setに対してどのようにルーティングを行うか決める
• ヘルスチェック
  • サーバーの稼働状況をチェック

ルーティングポリシー

シンプルルーティングポリシー

• レコードセットで事前に設定された値に基づいて、ドメインへの問い合わせに応答する
• 最初によく使用される

加重ルーティングポリシー

• 複数エンドポイント毎に設定された重み付けに基づいて、ドメインへの問い合わせに応答する
• 提供リソースに差がある場合や、ABテストに使用

レイテンシールーティングポリシー

• リージョン間の遅延が少ない方のリソースにルーティングする
• マルチリージョンにリソースが存在する場合に使用

位置情報ルーティングポリシー

• クライアントの位置情報に基づいて、ドメインへの問い合わせに応答する
• コンテンツのローカライズや、地域限定配信に使用

フェイルオーバールーティングポリシー

• ヘルスチェックの結果に基づいて、利用可能なリソースにルーティングする
• 障害発生時にSorryサーバー(サービスが停止していることを利用者に知らせるサーバー)に簡単に切り替えられる

ドメインの購入

購入先を選ぶポイント

• 価格(1年目だけでなく、2年目以降の価格もチェック)
• 管理画面の使いやすさや設定変更の速さ
• 無料オプションの充実度

おすすめは「お名前.com」

• 国内最大のレジストラ
• 580種類以上のドメインの取り扱い
• 累積登録実績2000万件

「お名前.com」のトップページから「その他のドメインを検索」をクリック

ドメイン名を入力し、購入可能なドメインを選択する
内容に問題がなければ、メールアドレス・パスワードを入力し、「次へ」をクリック

「お名前ID」は後で使用するので保存しておく
会員情報を入力し、「次へ進む」をクリック

クレジットカード情報を入力し、「申込む」をクリック
レンタルサーバーの申込み画面が表示されるので、「申込まない」をクリック

ドメインの申込みが完了したことを確認

ドメインの契約自動更新をOFFにする
「ドメインの設定をする方はこちら」をクリック

会員ID,パスワードを入力し、ログイン

「ドメイン設定」をクリック

「ドメイン自動更新設定」をクリック

対象ドメインにチェックをして、「確認画面へ進む」をクリック

自動更新設定申込内容が「解除する」であることを確認し、「規約に同意し、上記内容を申し込む」をクリック
変更手続きの確認画面が表示されるので、「解除する」をクリック

ドメインの自動更新が解除されていることを確認

ビジネスでドメインを利用する際、自動更新をOFFにしたほうが良い　
　　　　　　　　　　　　　　　↓
個人のクレジットカードを登録していた場合に登録者が転職等で不在となり、それによりドメインの更新が漏れたり、クレジットカードの有効期限切れ等でドメインが解除される可能性があるため

登録手順

1. ドメインのネームサーバーをRoute 53に変更
   • Route 53でホストゾーンを作成
   • ネームサーバーをお名前.comからRoute 53に変更
2. ドメインに紐づくIPアドレスを登録
   • Route 53でレコードセットを作成

ホストゾーンの作成

AWSコンソールからRoute 53を検索し、クリック

DNS管理の「今すぐ始める」をクリック

「ホストゾーンの作成」をクリック

作成したドメイン名を入力し、「作成」をクリック

ホストゾーンが作成されたことを確認

EC2インスタンスが起動中で、Elastic IPの紐付けがされていることを確認

ターミナルからSSHでEC2にログイン
ssh -i test-ssh-key.pem ec2-user@18.176.65.9

作成したドメインのネームサーバーを確認

[ec2-user@ip-10-0-10-10 ~]$ dig test-aws-domain.work NS +short
dns2.onamae.com.
dns1.onamae.com.

お名前.comで購入したドメインはデフォルトでネームサーバーがお名前.comと紐付いている

ネームサーバーをお名前.comからRoute 53に変更

お名前.comにログインする

「ドメイン設定」をクリック

「ネームサーバーの変更」をクリック

対象のドメイン名、「他のネームサーバーを利用」にチェックを入れる

Route 53で作成されたネームサーバーを入力し、「確認画面へ進む」をクリック
値の末尾にあるドット(.)は入力しない

内容を確認し、「設定する」をクリック

申込みが完了したことを確認
変更の反映には24〜72時間かかる場合がある

ドメイン名にEC2インスタンスのIPアドレスを紐付ける(Aレコードの追加)

Route 53　→　ホストゾーンから対象のホストゾーンを選択し、「レコードセットの作成」をクリック

値にEC2インスタンスのElastic IPアドレスを入力し、「作成」をクリック

Aレコードが追加されていることを確認

ネームサーバーの変更が反映されていることを確認

[ec2-user@ip-10-0-10-10 ~]$ dig test-aws-domain.work NS +short
ns-1469.awsdns-55.org.
ns-1664.awsdns-16.co.uk.
ns-388.awsdns-48.com.
ns-870.awsdns-44.net.

ドメイン名をブラウザで開き、ページが表示されていることを確認

参考

AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得