社内で「ドメイン駆動設計入門」の輪読会を主催して大満足

読書 輪読会 技術書

はじめに

社内有志メンバーで「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」の輪読会を行いました。
一人での読書であったり、ABDは何回かやってきましたが、輪読会という形式は初めてでした。
もともとは会社の分報でいつものごとく雑に募集してみたら多すぎず少なすぎずの人数になりそうだったので、開催して進めてみた次第です。 f:id:ohshige:20200420095830p:plain:w500

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

この本は、PHPerKaigi 2019のPHPer チャレンジで1位だったりCMでもおなじみの @nrslib さんの著書です。
ブログもいつも読ませていただいて、それを元に大幅にボリュームアップしたということで、買って読まなくてはと思っていました。

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

  • 作者:成瀬 允宣
  • 発売日: 2020/02/13
  • メディア: 単行本（ソフトカバー）
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

輪読会

DDDをしっかりと実践できたことがなく、周りにもそういうメンバーはいませんでした。
そういう状況であるなら、1人で読み、1人でフムフムと言っていても仕方がないのではないかと感じて、皆で読んで議論することがとても効果的な読書法なんじゃないかと思い、輪読会を主催することにしました。

ABDにしかなかった理由は、一応章ごとに独立してるとは言え、前半で出てきた用語がわからないと後半は理解しにくくなるかもしれないと感じていたからです。

結果的に、ありがたいことに、6人でやることになりました。
やり方としては、全15章＋APPの章立てのところを2〜3章ずつ全6回に分け、週に1回の会を設け、その会までに該当の章を全員が読んでくるようにしました。
当日は、担当者がファシリテーターとなり、その章の簡単なまとめと議論の進行などを行う形式にしました。
全6回で6人いるので、1人1回はファシリテーターをすることになります。

輪読会というと、1人が読み込む人となり会当日に他のメンバーにプレゼンをする形式もあるかと思いますが、そのような形式はとらずに、必ず全員が事前に読んでくるようにしました。
理由としては、本書がコードも結構載っていて意外と分量が少なく苦にならないのではないかということと、プレゼン資料を作る時間が勿体ないということと、議論メインにするために前提条件を揃えたかったということがあります。

やってみて

集まったのは、新卒1年目から社内では中堅と呼ばれるメンバーまでで、扱う業務も一部異なっており、議論は全体を通してかなり盛り上がりました。
同じ年次のメンバーだけでやるより、かなり効果的な会になったのではないかと思います。

中堅メンバーは色々な経験をしている分、本書で出てきた表現に関して「わかるわかる」と頷きつつ、それがすべて正しいかったわけではないと理解しつつも、若手が業務になぞらえて話題を提供したときには過去の経験の話をする場面も多々ありました。

若手メンバーとしては、本の内容だけだとどうしても机上の話になってしまいがちなところを、中堅メンバーの実業務での経験も交えた話が加わることで現実感が増し、想像もしやすかったということがありました。
逆に、中堅メンバーとしては、これまでの自分の仕事や考えがすべて正しいわけではないと考えているときに、本書の説明を読んで、「あれは正しかったんだ」「あれはこうすれば良かったんだ」と物思いに耽る場面もありました。

本書のような設計や、他にもアーキテクチャ、思想などの話は、原理原則とは異なり、全てを無条件に受け入れられるわけではありません。
そのため、1人で読んでいるだけだとモヤモヤしたまま終わってしまっていたかもしれないところを、声に出して議論できた点はとても有意義でした。
意見が異なっていたり、同じ意見であったり、過去の経験からの補足を聞けたり、新鮮な意見を聞けたり、大満足でした。

コロナの影響で外出自粛で在宅勤務となり面と向かって輪読会はできなくなりましたが、オンラインで続けることができていて、幸か不幸か読書の時間も確保しやすくなりました。
さらに、とても良い会だったので、次の課題図書も決めて第2回が開催されることが決まりました。
オンラインかオフラインかはコロナ次第ですが、良い本で良い知識をどんどん吸収し、いろいろなことに生かしていきたいと思います。

さいごに

ドメイン駆動設計入門はかなり読みやすく、わかりやすく、とても勉強になりました。
翻訳本にありがちなぎこちない日本語や理解できない謎のジョークは、もちろん一切出てこないので、それもありがたいです。
他にも、強強な方々が日本語で素晴らしい本を書いていただけるととてもありがたいですね。

CloudWatch Alarm と Slack の連携は SNS + Lambda ではなく SNS + AWS Chatbot が簡単で管理も楽

AWS CloudWatch Alarm Chatbot Slack

CloudWatch AlarmはCloudWatchのメトリクスを監視し、それが事前に決めた条件を満たすと通知してくれる便利なサービスです。
例えば、CPU利用率が80%を超えたら通知するといったことができます。

CloudWatch Alarmでの通知にはSNS(Simple Notification Service)のトピックを指定することができ、そのトピックと連携することが様々な通知を実現できます。

通知の方法としてよくあるのはSlackへの通知です。
CloudWatch Alarmによる監視の結果をSlackへ通知するようにすることで、異常にすぐに気が付きます。

そんなSlackとの連携ですが、調べるとよく出てくるのが、サブスクライバーとしてLambdaを使い、LambdaからSlackにIncoming Webhookを用いて情報を送るというものです。
Lambdaの関数を作る際に指定できるテンプレート（設計図）にも「cloudwatch-alarm-to-slack-python」というものが用意されており、これらを使えば簡単に作成し設定することはできます。

ですが、より簡単な方法があります。
それがAWS Chatbotを使う方法です。
aws.amazon.com

AWS Chatbotは現在ベータ版ではありますが、コードを一切書かずに、SNSをトリガーにしてSlackに通知するということがとても簡単に実現できます。

まずは、チャットクライアントとしてSlackを選択して「クライアントを設定」を押します。
f:id:ohshige:20200413170453p:plain:w500

そうすると、ブラウザでログインしているSlackのワークスペースについて権限を求められるので、ワークスペースと内容をしっかりと確認しつつ許可します。
f:id:ohshige:20200413170600p:plain:w500

これでChatbotとSlackの連携は完了です。
あとは、「新しいチャネルを設定」から、CloudWatch Alarmが通知しているSNSトピックとSlackの好きなチャンネルを組み合わせるだけで、CloudWatch Alarm + SNS + Chatbot + Slackの連携は完了です。

Lambdaで設定する場合は、テンプレートをそのまま使うにしてもWebhook URLの設定などが必要ですし、何よりLambda自体の管理が必要になってくるので、少し煩わしいです。
それに比べてChatbotを使う場合は、コードを一切書く必要がなく、メンテナンスも基本的に不要なので、管理もとても楽です。

ただ、Chatbotの場合は通知の内容や表現方法を変更することができないので、CloudWatch Alarmからの情報をいい感じに組み立てて独自のやり方と見せ方で通知したいという場合には向いていません。
また、現時点でベータ版なので今後どうなるかわかりませんし、AWSのGoのSDKでのサポートがまだであるためには現時点ではterraformで利用することもできません。
github.com

これらの違いを比べて、どちらを使うか決めればよいかと思います。

AWS の CloudWatch Logs は CloudWatch Logs エージェントではなく 統合 CloudWatch エージェントを使ってインストールする

AWS CloudWatch CloudWatch Logs

表題の通りで、それだけなのですが、一応続けます。

AWSにはCloudWatch Logsというサービスがあり、AWS上のあらゆるリソースであったり、EC2インスタンス、さらにはオンプレサーバーから、ログを収集して保存や監視を行うことができます。
特にEC2インスタンスからログを収集することで、ログの分析も容易になるので便利です。

さて、そんなCloudWatch Logsのインストール方法ですが、情報を探そうと検索すると、公式ではないブログなどでは、基本的に「CloudWatch Logs エージェント」をダウンロードしそれを使ってインストールする方法がたくさん紹介されています。
ですが、実はこの方法はすでに非推奨となっています。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_GettingStarted.htmldocs.aws.amazon.com

現在推奨されているのは、統合CloudWatchエージェントを使ってログを収集する方法です。
CloudWatch Logsを使おうとしている場合は、高確率でCloudWatchエージェントを使ったカスタムメトリクスの収集もしていると思うので、CloudWatch Logs エージェントなるものを使わなくとも設定を書き換えるだけでCloudWatch Logsが使えるようになるという優しい設計です。
これに気づいたのは最近なんですけど...

具体的にどうやって設定するかというと、CloudWatchエージェントの設定ファイルにはlogsセクションというものが用意されており、そこにこれまでのCloudWatch Logsエージェントの設定ファイルに書いていたものをほぼ同じ形で書くだけです。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssectiondocs.aws.amazon.com

CloudWatch LogsエージェントではなくCloudWatchエージェントのlogsセクションを使うにあたって、2つ注意することがあります。

1つ目は、公式サイトでも紹介されているように、タイムスタンプ形式で使用できる記号に差異があります。
もし移行など古い設定を参照することがあるなら注意した方が良いです。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-logs-timestamp-differencesdocs.aws.amazon.com

2つ目は、公式サイトのどこにも明示的には載っていないのですが、なぜかタイムスタンプ形式を表すフィールド名が datetime_format から timestamp_format に変更されているということです。
こちらも移行などで古い設定を参照することがあるなら注意した方が良いです。
私は、この違いにPullRequestのレビューで気づきました。

長々と書きましたが、CloudWatch Logsを利用する場合は、これまで通りCloudWatch Logsエージェントを使うのではなく、統合CloudWatchエージェントを使った方が推奨されているし楽だよ、というお話でした。

ウイルスから世界を救うボードゲーム「パンデミック」は採用や研修に使えるかもしれない

ボードゲーム

はじめに

久しぶりのボードゲーム紹介です。

今回は今のご時世に合った「パンデミック」というボードゲームです。
これはウイルスの広がっている世界で協力して治療薬を発見することで世界を救うことを目標した協力ゲームです。

コロナの影響で外出がなかなかできないので、そういうときは家族や同居人とボードゲームをして過ごすのはどうでしょうか。

パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム

パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム

  • 発売日: 2013/08/01
  • メディア: おもちゃ＆ホビー

パンデミック

hobbyjapan.co.jp

パンデミックとは、伝染病や感染症が世界中に流行することを表す用語。
このゲームは、世界中に拡大しようとする感染症の根絶を目的とし、プレイヤー同士が協力し合って、4種類の病原体すべてのワクチンを発見するという、多人数協力型ゲームだ。

このように紹介されているように、このボードゲームは珍しい*1協力ゲームという形式です。
そのため、プレイヤー間で争うのではなく、システムに勝つにはどうすればいいのかというプレイングになります。

ゲームの目的はウイルスが蔓延して世界が滅亡する前に4種類の治療薬を発見するというものです。
感染者が増えすぎるとアウトブレイクが発生してしまうので治療をし、ただ治療を進めるだけでは根絶できないので治療薬の発見に勤しみ、そのために世界中を駆け回る必要があるために研究拠点を築き、と、様々な選択肢がある中で何を優先すべきかを考えて協力してゲームを進めていく必要があります。

さらに、このゲームには「科学者」「研究員」「衛生兵」「通信司令員」「作戦エキスパート」などのキャラクターが存在し、それぞれは異なる能力を持っています。
プレイヤーはいずれか1つのキャラクターを担当し、その能力を存分に発揮できるようなプレイを目指します。

採用や研修に利用できるかも？

ボードゲーム自体がアイスブレイク等に利用できるということは、前に紹介しました。 ohshige.hatenablog.com

今回のボードゲームは協力ゲームであり戦略もかなり必要になってくるため、採用や研修時のグループディスカッションの代わりとして利用できるかもしれません。

どういう点で利用できると考えているのか、いくつか紹介します。

理解力

まず、単純なボードゲームではなくルールも多少複雑であるため、最低限の理解力が必要になります。
ルールをしっかりと把握できているかといった判断が可能かもしれません。
もちろんルールをしっかりと伝えられないと意味が無いので、提供側のわかりすい説明が必須になります。

リーダーシップと議論

また、協力ゲームであるためリーダーのようなポジションが必要になってきます。
しかし、リーダーが奉行として指示を出し、周りがそれに従うだけでは駄目で、自分の意見もしっかりと発言しなくてはいけません。
今は何を優先してどうするべきであるかを議論し、とるべき行動を決定します。

性格

人となりもわかるかもしれません。
確率を綿密に計算し効率でものごとを決定するような効率タイプなのか、リスクヘッジに重きをおく慎重タイプなのか、リスク覚悟でハイリターンを求めるギャンブラータイプなのか、プレイヤーの性格が出ます。

このように、理解力、リーダーシップ、性格などが表れるため、採用や研修の場に有効なボードゲームです。

さいごに

御託を並べてはいますが、普通におもしろいので採用や研修関係なく是非やっていただきたいです。

*1:「協力ゲーム」という形式は実際は特に珍しくも無いのですがボードゲームをやりなれていないと珍しいかも？

脳内ミルクボーイで AWS ソリューションアーキテクト アソシエイト (SAA-C01) に合格することができた

AWS 資格

はじめに

実務として約1年間AWSを触ってきて、ある瞬間に「そうだ、資格をとろう」と思い立ち、しかも現行の試験がもうすぐ終わってしまうということでそれまでに頑張って取ろうと決意しました。
その結果、無事に合格したのでそれについて書きます。

f:id:ohshige:20200319182652p:plain:w300

前回のブログも試験に向けた自分用のメモだったわけです。ohshige.hatenablog.com

ただ、今回のブログでは、読むのは「脳内ミルクボーイ」の項目だけで十分かもしれないです。

脳内ミルクボーイ

この話を書きたいがための今回のブログと言っても過言では無いので結論として先に書きます。

問題を解くときのコツとしてミルクボーイネタが使えるのではないかと思ってはいたのですが、実際の本番の試験の際も脳内でミルクボーイのネタが流れていました。

こんな感じです↓

私「うちのオカンがね、使いたいAWSのサービスがあるらしいんやけど」
脳「そーなんや、どんな特徴ゆうてたかってのを教えてみてよ」
私「高い耐久性と可用性のあるところに大量のPDFデータを保存したいって言うねんな」
脳「おー、S3やないかい。その特徴はもう完全にS3やがな」
私「S3なぁ」
脳「すぐ分かったやん、こんなんもー」
私「でもこれちょっと分からへんのやな」
脳「何が分からへんのよー」
私「いや俺もS3と思うてんけどな」
脳「いやそうやろ？」
私「オカンが言うには、保存してからしばらくしたら滅多にアクセスしなくなるからコスト効率を良くしたいって言うねんな」
脳「あー、ほな単なるS3と違うかぁ。S3は標準的なストレージでお安いけどもアクセス頻度もそこそこある場合により適してんのよあれ」
私「そやねん」
脳「ほなもう一度詳しく教えてくれる？」
私「保存してから30日間は頻繁にアクセスするけどそれ以降は滅多にアクセスしないらしいねん」
脳「ほなS3やないかい。ほんで、S3にライフサイクルポリシー設定して30日後に S3 Glacier に移行するパターンやと俺は睨んでんのよ。俺の目は騙されへんよ」
私「まあねー」
脳「S3 Glacierは標準のS3よりも低コストで大量のデータを長期間アーカイブすることに適してんのよあれ」
私「分からへんねんでも」
脳「何が分からへんのこれで」
私「俺もS3とGlacierの組み合わせと思うてんけどな」
脳「そうやろ」
私「オカンが言うには、滅多にアクセスしなくなるけど必要になったらすぐに取り出せなあかんって言うねんな」
脳「ほなGlacierちゃうやないかい。Glacierの取り出しオプションには[迅速][標準][大容量]の3つがあって、最速の迅速読み取りでも数分はかかんねん。せやから必要なったらすぐに取り出すユースケースには適してないんや」
私「そやねんそやねん」
脳「ほなGlacierちゃうやないかい。ほなもうちょっとなんかゆうてなかった？」
私「重要なデータだから30日経ったあとでも耐久性はしっかりしてないとあかんらしいねん」
脳「S3標準 - 低頻度アクセス (S3標準 - IA) やないかい。移行後も高い耐久性が必要で低頻度アクセスでしかも即時取り出しが必要ならS3標準-IAしかないねん」
私「そやねんそやねん」
脳「Glacierと違て必要に応じてすぐ取り出せるねん」
私「せやねん」
脳「S3 1ゾーン - 低頻度アクセス (S3 1ゾーン - IA) もあるけども、それは他と違ってひとつのAZにデータを保存するからコスト削減できる分、多少アベイラビリティを犠牲にしなあかんねん」
私「そやねんな」
脳「ほな、S3にライフサイクルポリシー設定して30日後にS3標準-IAに移行するで決まりやな」

他のパターンでも、こんな感じで「こうだろうか？」「いやこういう条件あるから違うな」みたいなことを繰り返して解いていました。

これがやりたかっただけ。書きたかったこと終わり。

続きを読む

AWSのサービスや用語や仕組みについてややこしい部分を自分用メモとして残すだけ

AWS

自分用メモとしてややこしかったりする部分を比較などして残すものです。

EC2

インスタンスの種類

リザーブドインスタンス：
「１年間」「３年間」と期間を決めてEC2インスタンスを予約することで安く使える。
スケジュールドリザーブドインスタンス：
日次、週次、月次と３パターンのスケジューリングされた買い方ができ、月一回だけバッチ処理で利用したいなどの要望に利用できる。
スポットインスタンス：
オンデマンド価格より低価で利用できる未使用の EC2 インスタンスで、供給と需要に基づいて徐々に調整される。

テナンシー

ハードウェア専有インスタンス（Dedicated Instance）：
それを利用している AWS アカウントが起動した別のインスタンスが動作することはあっても、他の AWS アカウントの起動したインスタンスが動作することはない。
Dedicated Host：
他の AWS アカウントのインスタンスはもちろん、利用者の AWS アカウントの別のインスタンスが起動されることもない。

CloudWatch

メトリクス

標準メトリクス：
CPU利用率、通信トラフィック、ディスクIOバイト数、ステータス、etc...
カスタムメトリクス：
メモリ使用率、ディスク使用率、etc...

S3

使い分け

S3 スタンダード：
デフォルトで99.999999999%の耐久性。
S3 標準低頻度アクセス（Standard-Infrequent Access）：
スタンダードと同等の耐久性で安価。ただし、読み込みにも課金されるのでアクセス頻度が低い場合が適している。
S3 Glacier：
最も安価。データの取り出しに時間がかかりいくつか種類がある。
「迅速」は緊急時に少数のファイルを1〜5分で復元可能。「標準」は取り出しに3〜5時間かかる。「大容量」は取り出しに5〜12時間かかるが最も安価。データ保存後に編集不可にするためにValut Lockという設定が可能。
S3 低冗長化ストレージ（Reduced Redundancy Storage）：
耐久性は99.99%で低め。非推奨。
S3 1ゾーン低頻度アクセス（One Zone-Infrequent Access）：
1つのAZのみにデータを保存する分安くなる。データへのアクセス頻度が低く、高い耐久性を必要とせず、かつ必要に応じてすぐに取り出したい場合に適している。
低頻度アクセスのログデータなどはOne Zone-IAで良いがマスターデータなどはより耐久性の高いStandard-IAが良い。

S3暗号化キーの方式

SSE-S3：
Amazon S3管理キーでサーバー側の暗号化を使用する（AES-256暗号化方式）
SSE-KMS：
AWS KMS管理キーを使用したサーバーサイド暗号化の使用
SSE-C：
顧客提供のキーを使用してサーバー側の暗号化を使用する

補足

S3バケットのデフォルト暗号化を有効化することで、ログの暗号化も実施され、後から変更も可能。

ELB

オプション

クロスゾーン負荷分散：
各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンの登録されたインスタンスにリクエストを均等に分散します。クロスゾーン負荷分散が無効の場合は、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録されたインスタンスにのみリクエストを均等に分散します。
Connection Draining：
ロードバランサーがインスタンスの登録解除を報告するまで接続を保持する最大時間を指定できます。最大タイムアウト値は 1 ～ 3,600 秒の間で設定できます (デフォルトは 300 秒です)。
スティッキーセッション：
ロードバランサーがユーザーのセッションを特定のアプリケーションインスタンスにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じインスタンスに送信されます。

ストレージ

EBS vs EFS

Amazon EBS：
単一インスタンスから接続可。単一AZで冗長化。自動拡張不可。より安価。
Amazon EFS：
複数インスタンスから接続可。複数AZで冗長化。自動拡張可。

EBSの補足

Amazon Data Lifecycle Manager (Amazon DLM)を使用するとEBS ボリュームに保存されたデータをバックアップする自動化された手順です。Amazon DLM を使用してライフサイクルポリシーを作成し、スナップショット管理を自動化します。

データベース

Aurora：
（行指向データベース、）3AZにレプリケーション。
DynamoDB：
キーバリューストア、3AZにレプリケーション。
Redshift：
列指向データベース、単一AZのみ。

DynamoDBの補足

Amazon DynamoDB Accelerator (DAX) は、フルマネージド型高可用性インメモリキャッシュで、DynamoDB 用に特化しています。
DynamoDB ストリームは、DynamoDB テーブルの項目レベルの変更に対して時間順序のシーケンスをキャプチャし、その情報を最高 24 時間まで保存します。

Amazon Kinesis

Amazon Kinesisは主にストリーミングデータの収集・処理・リアルタイム分析に利用されます。

種類

Amazon Kinesis Data Streams：
ストリーミングデータをほぼリアルタイムで保存することができ、登録されたデータはEMRやLambdaなどで処理することができます。シャード単位で分割して並列処理を行うことができます。
Amazon Kinesis Data Firehose：
ストリームデータをS3やRedshiftに簡単に配信・保存できるサービスです。変換等も合わせて行ってくれる。
Amazon Kinesis Data Analytics：
ストリーミングデータに対してSQLクエリを実行しリアルタイム分析を行うサービスです。

AWS Storage Gateway

保管型ボリューム vs キャッシュ型ボリューム

保管型ボリューム：
新規にアップロードされたデータをローカルのディスクに保存した上で、非同期的にAWSへとバックアップを行います。ローカルサーバーをプライマリーストレージとして利用することが主な要件となります。
キャッシュ型ボリューム：
頻繁にアクセスされるデータはキャッシュとしてローカルのストレージゲートウェイに保持しながら、Amazon S3 をプライマリデータストレージとして使用できます。

AWS SQS

キューの種類

スタンダード (標準) キュー：
デフォルトのキュータイプ。できる限りメッセージの順序を保持し少なくとも 1 回は確実に配信されますが、複数のメッセージのコピーが順不同で配信される場合があり、全般的にメッセージが送信順に配信されるベストエフォート型の順序を提供します。
FIFO (先入れ先出し) キュー：
スタンダードキューを改良したもので、メッセージが送信または受信される順序は厳密に保持されます。また、メッセージは 1 回のみ配信され、コンシューマーが処理して削除するまで使用可能な状態で残り続けます。

補足

SQS 可視性タイムアウト：
この時間内に他のコンシューマーが同じメッセージを受信したり処理したりすることはできません。メッセージのデフォルトの可視性タイムアウトは 30 秒です。最小値は 0 秒、最大スケールは 12 時間です。

なんか似てるシリーズ

Opsworks vs Elastic Beanstalk

Opsworks：
Chef や Puppet のマネージド型インスタンスを利用できるようになる構成管理サービス。サーバーのパッチ適用、アップデート、バックアップが自動的に実行され、Chef サーバーが管理される。
Elastic Beanstalk：
Java、.NET、PHP、Node.js、Python、Ruby、Go、Docker で開発されたウェブアプリケーションとウェブサービスをデプロイし、自動的にデプロイメントの詳細を処理する。
WEBアプリケーションがホストされているインフラ管理にはElastic Beanstalk、インフラ環境そのものを自動で展開したり管理するためにはOpsWorksやCloudFormationが適しています。

色々

認証情報レポート：
IAMユーザーが最後にAWSサービスにアクセスした⽇付と時刻を表⽰する機能を提供してくれます。
AWS CloudTrail：
AWS アカウントのガバナンス、コンプライアンス、および運用とリスクの監査を行えるように支援する AWS のサービスです。コンソールでの操作と AWS API コールを記録します。
AWS Config：
AWS上のリソース状況のスナップショットを記録できる構成管理サービスです。
AWS Trusted Advisor：
AWS ベストプラクティスに従ってリソースをプロビジョニングするのに役立つ、リアルタイムガイダンスを提供します。
AWS Systems Manager：
AWS で利用しているインフラストラクチャを可視化し、制御するためのモニタリングサービスです。
Amazon Inspector：
自動的にアプリケーションを評価し、露出、脆弱性、ベストプラクティスからの逸脱がないかどうかを確認できます。
GuardDuty：
AWS 環境内のネットワークアクティビティとアカウントの動作を継続的にモニタリングすることによって、脅威を識別します。

独自ドメインを持たずともEC2とALBとACMを使ってオレオレ証明書でHTTPSを実現してみる

AWS ELB ACM

はじめに

AWSを使えば、EC2で簡単にWebアプリケーションを公開でき、ALBとACMを使えば証明書の発行から管理まで任せた上でHTTPS化することも簡単です。
これらに関するやり方を調べると、基本的に独自ドメインを使った方法が紹介されています。
お金やタイミングの問題から独自ドメインが用意できないものの、オレオレ証明書（自己署名証明書）で問題ないのでHTTPS化したいという場面があったので、独自ドメインの代わりにALBから払い出されるDNS名を使ってやってみました。

一部、以下の記事を参考にしました。
ozuma.hatenablog.jpakiyoko.hatenablog.jp

前提

EC2とALBは既に用意されているとします。

以降のEC2は Ubuntu Server 18.04 LTS (HVM) で、動作確認済みです。
また、ALBのDNS名は xxxxxxxxxx-9999999999.ap-northeast-1.elb.amazonaws.com であるとします。

オレオレ証明書の用意

EC2上で以下を実行します。

まず、秘密鍵を生成します。

$ openssl genrsa 2048 > server.key
（略）

続いて、秘密鍵から証明書署名要求ファイルを生成します。
入力は全てエンターで進むと紹介されていることが多いですが、今回は「Common Name」にALBのDNS名を登録しておきます。
これをしないとACMに証明書をインポートしても、ALBから選択できません。

$ openssl req -new -key server.key > server.csr
（略）
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:xxxxxxxxxx-9999999999.ap-northeast-1.elb.amazonaws.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

最後に、秘密鍵で証明書署名要求ファイルに署名してサーバ証明書を生成します。

$ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crt
Signature ok
subject=C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = xxxxxxxxxx-9999999999.ap-northeast-1.elb.amazonaws.com
Getting Private key

ACMに証明書のインポート

AWSコンソール上で、ACMを開き、「証明書のインポート」を選択します。
証明書本文、証明書のプライベートキー、証明書チェーンを入力するように促されるので、先程生成したファイル文字列をコピペします。

server.crtの中身を「証明書本文」にコピペします。

$ cat server.crt
-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----

server.keyの中身を「証明書のプライベートキー」にコピペします。

$ cat server.key
-----BEGIN RSA PRIVATE KEY-----
（略）
-----END RSA PRIVATE KEY-----

「証明書チェーン」は何もせずそのままで大丈夫です。

ALBのリスナーを設定

AWSコンソール上で、ALBを開き、リスナーを追加します。

プロトコルの設定でHTTPSを選択すると、「デフォルトの SSL 証明書」という項目が増えるので、「ACMから」を選び先程インポートした証明書を選択します。
証明書署名要求ファイルを生成する際にALBのDNS名を入力しないと、インポートした証明書が選択肢に出てきません。

確認

これで、 https://xxxxxxxxxx-9999999999.ap-northeast-1.elb.amazonaws.com にアクセスすると、初回は「この接続ではプライバシーが保護されません」と出ますが、良しなに許可してやると見れるようになります。