AWSアカウントを手に入れたら最初にやること＋クリスマスへの怨嗟+α


本記事は[「Develop fun!」を体現する！ Works Human Intelligence Advent Calendar 2022][22]の12月25日の記事です。

ウッチャバラヌッポキバッキャロかーい！
どうもクラウドアーキテクチャチームの齋藤です。

**皆さんそろそろ1年もあけるし、「なんか新しいことやろ！！！！！」と思っていることかと思います。**
どうでもいいですが僕は声優をはじめたり、ラノベを書き始めたりしました。
ラノベはVtuberに動画にして紹介してもらえましたし、声優はなんか国民的アニメでナレーションやっている最強の方に弟子入りしました。
（開発以外は出来る子とよく言われます）

ですがまぁしかし、**Qiitaを見ているような方は当然エンジニアリングでなんかしようと思ってますし、そのためのインフラ調達はAWSで済ませますよね？**


そしたらまぁ何はともあれAWSアカウントを手に入れてみるわけですが、こいつらそのまま使っときゃいいの？料金とか攻撃対策とか後々チームで開発するようになった時のためにやることとか、なんかないの？と疑問になりますよねー。なります。

というわけで、なんかプロジェクト始めよーと思ってAWSアカウントを手に入れたアカウント管理者が最初にやっとくとよさそうなことをまとめました。

といっても基本はすでに**AWS Hands-on for Beginners - Security**という素晴らしいまとめが存在するので、これをベースにまぁもう少しだけ気を回しておいてもいいんじゃないのみたいなレベルの話です。

なお、[アカウント作成から教えろって場合はこれみてください。][16]

# 基礎知識

[AWS Hands-on for Beginners - Security][0]
まず動画をみて、その後対応した項目を参照していく形で進めてください。

## IDアクセス権管理
はい。アカウントを入手するとさいしょからrootユーザーという最強のユーザーを持っています。

あまりに最強で危険なのでこちらは普段は使いません。
[「最小権限の原則」][1]に基づいて、普段使うユーザーは必要な範囲に権限を落としたものを使用すべきです。
だからrootユーザーのアクセスキーは削除しましょう。ここまではいいです。

その運用を実現するために新しくIAMユーザーを作りましょう。
 
**というのがもう罠です。**

いいですか？
ユーザーなんて作ってアクセスキー発行したりしたらそれがずっと残って流出したら乗っ取られるわけですよ？
開発者がそんなもん持ったらいつかgitでコミットしてパブリックに大公開とかヤラカスに決まってるでしょ？
それを対策するためにアクセスキーローテーションなんてするのも面倒です。
それに、IDPWの対策だけでは不十分だからMFA導入しようとか言い出したらMFA登録しなきゃ有効化されない権限とかつくらなきゃいけないし、ユーザー側もまずユーザー発行してもらってIAM開いてMFA登録してアクセスキーをローカルで安全に保管して...みたいなことしなきゃいけないし、それをしてもらうための手順も作って共有しなきゃいけないし、なによりユーザーなどというものを管理したらアカウントが複数存在したらそれぞれ別に管理しなきゃいけなくなるんですよ？
**チョーめんどい。**

どうせ将来的にクリデンシャル管理しなきゃいけないものなんていっぱい出てくるんですから、[IdPとの連携を見越して][2] **SSOを最初から導入し、すべての開発者はIAMユーザーではなくSSOでコンソール操作を行うようにしましょう。**
SSOなら最初のログインの流れでMFAを強要できますし、MFAポリシーもいらないし、都度有効時間のあるアクセスキーが発行されるので流出耐性も高いです。
ユーザーの名前はメールアドレスとかがいいと思います。
後でCloudTrailとか設定したときに、誰の操作かっていうのを確認すると同時に連絡先もわかって楽。

実際AWSの[ファンデーショナルテクニカルレビュー][5]なんかでもIAMユーザー周りは厳しく見られるんですけど、**めんどくさかったのでIAMユーザー全部削除してSSOに置き換えて乗り切った過去があります。**
（上司にIAMユーザー全部消しましょって提案したら「えぇ……」って反応されたのが懐かしいです）

これFTR通す以外にもメリットがいろいろあって、例えばインスタンスへのSSH用経路の保護とかキー管理とかも全部不要になってセッションマネージャーにまとめて置き換えられてチョー便利でした。
また、AWS権限のない人間にインスタンス情報魅せるための情報の外だし機能とか、ログファイルのダウンロード機能開発とかもあったんですけど、SSOで権限付与すればいいじゃんで全部終わるんですよね。
メンバーのAWSリテラシーも向上して色々楽になるし、**まじSSO便利だからおすすめ。**

[AWS IAM アイデンティティセンター][3] (AWS SSOの後継サービス)
[Azure IdPとマルチアカウントの連携・アカウント側でのアクセス権限管理][2]

自身のSSOユーザーにアタッチする権限はAWS Hands-on for BeginnersのIDアクセス権管理(2)の動画と同じものにしておけばひとまず後続の作業も問題無いでしょう。

**ちなみに、SSOを有効化する際は[AWS Organization][6]を有効化して将来的にマルチアカウントになることも視野に入れておきましょう。**
たくさんのAWSアカウントを同時に管理しなければならない場合にも、AWS Organizationを有効化しておくことで組織下のすべてのアカウントにSSOできるようになったりするので、楽楽ちんちんです。

## 請求データの確認とアラート

AWSはお金かかりますからね、コストがかかってることを察知するために請求アラートは必要です。
ってじゃあそれどこに飛ばすの？？？個人に飛ばして責任押し付けるの？？もちろんチーム単位で飛ばしたいですよね。

はい。つまり、まずここで作るのは **Amazon SNS > トピック** です。
[Amazon SNS][4]

目的別に作成したトピックに開発関係者のメールアドレスを登録しておき、コスト等の通知をSNSトピックに紐づけるようにするのが良いでしょう。
メールの配信先が増えたとしても、トピックを指定しておけばここに追加するだけで複数の通知をまとめて管理できます。
（どうでもいいですが、Googleのメーリングリスト宛にSNSトピック設定してもサブスクリプション確認のメールを受信できなかったんですけどなんでですかね？）

一応、SNSトピックを編集する権限はアカウント管理者以外のメール送信先を管理する人（チームリーダーとか）とかに振りたいという話もでてくるとおもうので、ここでSSOユーザー用のポリシーも作っておくとなお良しかもですね。

あとはAWS Hands-on for Beginnersの請求データの確認とアラートの動画を参考にSNSトピックを対象にアラートを飛ばすように設定してください。
必要に応じて以下もやっとくといいでしょう。

Cost & usage reports : s3に使用料のレポートを定期的に保存
Budgets : 予算設定とそれに対してのアラート発行
Budgets reports : 予算についての定期的なレポート送信

ちなみに上記の設定はアカウント単位でやったほうが責任範囲がしっかりしてていいよねーとか思うんですけど、単純にアカウントを複数購入するとそれぞれで請求が発生して支払いが面倒だったりするじゃないですか。
クレジットカードの有効期限が切れたら全部のアカウント更新しに行かなきゃいけないとか面倒でしょ？

というわけで、支払いについては[一括請求 (コンソリデーティッドビリング)][9]を有効化しておくとよいでしょう。
これもAWS Organizationの機能です。

## 操作履歴とリソース変更履歴の記録

いつ誰がどのリソースをどのようにいじったか記録しましょうという話。
これはまぁもうそのまんまやればいい...とおもったでしょ？

SSOの時にAWS Organizationを有効化したほうがいいよとお伝えしておいたと思うんですけど、ここで使う[CloudTrailもAWS Organizationで組織下に一括で有効化できたりします。][7]
「組織の証跡の作成」に置き換えて対応しておくことで、マルチアカウント化した場合にも楽できます。


そしてこれは[AWS Configについても同様です。][10]
[全許可するセキュリティグループはどのアカウントでも作れないようにする][11]とか、最低限のセーフティネットを敷くのに便利です。

結局チームの規模が増えてくるとアカウントごとに管理者を立てることになるので、セキュリティは各アカウントごとに勝手にやってねって運用になるとは思うんですよね。
とはいえ誰もがちゃんと完ぺきに管理できるわけでもないので、最低限の保護はこちらから提供できるようにしておいて損はないはずです。
そのためにも、アカウント単体ではなくAWS Organizationで組織単位で有効化しておくようにしましょう。

ちょっと関係ないといえばない個人的に思うことなんですけど、ログだのレポートだのバンバンS3にアップロードすることになると思うんですけど、マジでバケット名の管理とどのアカウントに何のバケットがあって何に使われてるかちゃんと記録しておいた方が良いです。
バケット増えすぎてわけわからなくなるし、マルチアカウントになると余計にどのバケットがどこにあるかもわからなくなるし、後から来た人が消していいバケットとそうじゃないものを判断できなくなって無限にs3が膨れ上がっていくので。

## 脅威検知

まぁこれはもう[Amazon GuardDuty][12]の設定はめっちゃ簡単だし、とりあえず**全リージョンでやっときましょ。**
これだけで「うちは機械学習して攻撃を自動検知してるから」ってかっこいいこと言えるようになります。
ちなみに全リージョンやらないと、空いてるリージョンをメタ糞にされるので注意です。
ちなみにrootユーザーとか使うと速攻でメール飛んできてめちゃくちゃめんどくさくなるから覚悟してな。

ところでここまでの作業で**複数のアカウントやリージョンにいちいち設定していくの面倒だと思ったんじゃないかなと思うんですけど** 、そういう場合は[CloudFormation(Cfn)のStackSet][13]を使うことでまとめてリソースの自動生成と管理を行うことができます。（しかも汎用的なものはURL先にあるようにテンプレートを用意してくれている）
後々にはこういった機能を使い、これまでの設定をコードに置き換えて[Infrastructure as Code][14]を実現していきましょう。

## ベストプラクティスの確認

AWS Trusted Advisorでなんか色々見れるよって話だけど、まぁセキュリティ観点でそんな使ったことはないですね。

セキュリティの評価であれば、動画では触れていないですが[AWS Security Hub][15]という機能があります。
これはアカウント全体を見て、セキュリティ的にどれくらいの網羅がされているかというのを表示してくれる機能だったりします。
その中には今回使用しない予定のIAMユーザーのパスワードポリシー設定とかも含まれていて、何をどこまでやるかというのは管理者にゆだねられる部分ではあるんですが、大体60-80%くらいはスコアをたたき出すようにしてけばおおむねいい感じといえると思います

僕も100%までやったことはないんですよね～
でもいろんな観点をちゃんと教えてくれるので勉強になります。

## さぁ色々作ってみよう

おら、[ハンズオンやるんだよ][17]

Webアプリつくるなら[Amplifyマジおすすめ。][18]
CICDの自動化も同時にできるし、自然と環境全体をコード管理するようになってかっこいい。
何回か環境消し飛ばしたことあるけど、[Amplify][20]+[CodeCommit][19]でサクッと建て直せた。

よし、これで技術記事のメンツはとったな？
**後は好き放題書いていいな？**

## 怨嗟+α

**メリィィィィクリスマァァァァス！！！！！！！！！**

お前らクリスマスイブは楽しんだか？恋人と過ごした？それとも家族？ガタガタ命乞いをする準備はOK？
**ぼくはねぇー、パチンコ！！！！！！**
スマスロ体験してきたよ！５まんえんーーー！！！ぼくがひっしにはたらいてためたごまんえーん！！！！えーん！！！！！！！！

**あぁ、あぁしかし振り返ってみれば人生30周年、ついに誰かに愛されることはなかった！！！**
愛すこともなかった！！！！
そんなもんかよ世界！！！！そんなもんか！！！！！
もっとないのかよ、小説より奇なるドラマは！！！季節イベント展開は！！！

お前、お前さぁ！漫画読んでてクリスマス回なのにパチンコ売ってるだけの漫画があったらさぁ！！！
どうなるよ！？打ち切りだよ！！！！！当たり前だろうが！！！！！！！！
あの若林稔弥先生作の大人気漫画「[ぱちん娘][21]」ですらクリスマス回は3年くらい連載しても一度も掲載してないんだぞ！！！！！！
**そんなのが30年連続ってお前そりゃ見切りつけられるよ！！！！**
当たり前だろうが！！！！！！！

しかもなぁ、しかも今年のクリスマスはイヴともに休日なんだよ！！！！！！
僕たちのバイブル[社畜ちゃん][23]でもクリスマスは何度か語られてるが、全部平日なんだよ！！！！！
「クリスマスは仕事が忙しくってさぁ」とかそういう今仕事に打ち込んでるからアピールも許されないんだよ……同僚と飲みに行くイベントとかもないんだよ……
**今年のクリスマスは自分が孤独であることが浮き彫りになる悪魔の休日なんだよ！！！**
この時期にQiita記事書いてるやつも見てるやつも全員もれなくそう！！（偏見）

**イヤ僕だってヴぇっつに恋人がほしいとか、結婚したいとか、そういうことじゃないよ？**
だって僕は友情の先に恋愛があるべきだと思うし、いきなり恋愛から始めたい関係とかないし？
人に見られたときにそういう相手がいるよって自己顕示したいわけでもないし？？？

でもさ、**そうしたいかは置いといて、そういう相手がいることはうらやましいんだよ。**
わかる？クリスマスだよ？
年に1回のあっきらか親密な相手としか過ごさない日に、お互いがお互いを1番だと思ってる者同士が出会ってその関係性を確かめ合う日！！！！！
**お互いにお互いを一番っていえる関係の相手がいるってエモくない！？！？** エモい。
それがいる人生といない人生どっちがいいの？？？？？？？
いるほうだろ！！！！！
誰かに選ばれる人生うらやましいよーーーー！！！！

人間は社会動物だよ。
社会で生きるのが必須かはおいといて当然だし、基本的には社会に居場所があると幸せなんだよ。
つまりそれは人とのつながりだよ。
自分がどれだけ多くの人に必要とされているか、どれだけ深く必要とされているか。
そういうことに幸せを感じるには人間の根源的欲求だよ。
**だから僕がクリスマス一人孤独でいることや、周りのそういうやつらが楽しんでる間パチンコ売ってることに劣等感や焦りや嫉妬や諦観や怒りを感じたとてそれは当然のことなんだよ。**
そう思わねぇ奴いる！？いねぇよなぁ！！！！
**返事は「いいね」で頼むわ**

まぁ僕が言いたかったのはさ、大半は愚痴なんだけど。
**そう思ってるのは君だけじゃないよってこと。**
それはさ、君は孤独じゃないってことだよ。
**そして、僕たちが孤独にならないためにはお互いそういう存在が必要なんだよ。**
だから胸を張って孤独でいいんだ、君はそこにいていいんだよ。
いやむしろそこにいなければならない。
**だって僕たちは仲間なんだから。**
そうだろ？裏切らないよなぁ？だって僕たちはお互いを必要としてるんだからなぁ？
お前、クリスマスいつも一緒にいた彼氏彼女が急に別の奴と過ごすわっていったら浮気だなんだと非難されるのは当然だと思うよな？**だから、お前はそんなこといわない。** 
画面の向こう側のお前は服なんて着ないし、言葉をしゃべらないし、めちゃくちゃなことを言っても受け入れなきゃいけない。

だろ？

　
　
　

まぁ怨嗟はこれくらいにしておいて、**最近先輩後輩同期連中もみんな結婚秒読みだし、中学時代からの友人もだいたいみんな結婚するらしいし、どんどんおいてかれてるなーとか思うことも増えてきました。**
僕、遊びすぎて貯金ないんですけど、彼らに結婚するまで資産どれくらいためたのってきいたら1千万以上とかいってて戦慄しました。

多分僕は一生独りなのかなと思うんですけど、まぁその場合は海外の恵まれない孤児を二人引き取って、そいつらをめっちゃ教育して稼げるようにして、そいつらに孤児を二人ずつ救うという使命をあたえて、ねずみ講式に孤児を救いまくって、あらゆる社会的に必要な事業にその孤児たちを送り込んで、最終的に我々の組織だけで生活を賄えるようにして、**親に不要とされたり運悪く孤立してしまった子供たちを全て救いつくすプランを考えている** んで、まぁ大丈夫です。

でも結婚もそうだし世間一般の恋愛観について思うんだけど、**恋愛で一人を選ぶってあくまで理性的な決断ではあるけどさ、それって世界としては美しくないなって思ったりしません？** (♪ゴング)

**だって愛って「誰かに幸せになってほしい」って感情で、恋って「誰かと関係性を結びたい」とおもう欲でしょ？**
これが両方そろったもん同士が恋愛に至るわけだよね。
でもさ、**感情って一人に対してだけ向けるの難しくない？**
嫌いな奴が新しくできたから、昔から嫌いな奴が嫌いじゃなくなることあるか？
親友がいたら他に友達になりたいと思うやつは出てこないのか？
違うっしょ？
恋も愛も特別なものではなくてさ、感情なんて複数人に向けられてしかるべきものだと思うんだよ。
だから、お互い一人にだけその感情を向け続けることなんて本能的には無理じゃん。
**だから、お互いが複数人を愛し恋して許される世界ことが本来あるべき美しい世界だと思うんだよ。**
友達の人数に制限かけられてたらおかしいだろ？そういうこと。
とは思うんだけど、世の中の大半の方はそうではないと思ってると思うので、**ご意見お待ちしてます。** （コメ稼ぎ）
しゅっ！しゅっ！（♪シャドーボクシング）(戦闘準備OK)

でも、正直ハガレンの **「等価交換だ 俺の人生半分やるから お前の人生半分くれ！」** ってプロポーズは糞かっこいいからそういう価値観も好きなんだ。
多夫多妻やっちゃうと、等価交換にならないこともあるからね……
でもそこに「半分どころか全部あげる」って返すのマジエモい。
エモい。

**ちなみに僕的最強ヒロインは西森博之さんの「お茶にごす」の部長。**
一番好き。もちろん漫画も好き。
とりあえず全人類から未来の子供たちまで道徳の時間に全巻読破しといてほしい。

まぁ、複数人云々いいながら**一人愛したことも愛されたこともないんすけどね。へっ！**

そういえば賃貸と一軒家購入だと金銭面では賃貸のほうがお得というのは有名ですが、意外と僕の周辺の結婚する方はみんな一軒家を買われるらしいです。
何を重要視するか次第で割れる選択なのでこれを否定したいつもりはないんですが、僕は賃貸・一軒家どころか近所で別居したい派なんですよね。
お互い自分の家は自分で管理しつつ、子育てとかリソース集中が必要なタイミングは同居みたいな。
というのも、**相手に自分の汚いとこ見せてがっかりさせたくないんですよね。**

**人間、全部を公開して一生同じ奴と生きていくって妥協がたくさん必要だと思うんですよ。**
それが我慢できなきゃ分かれるし、タイミングによってはお互いどでかい傷を負うわけですじゃん？全部を肯定できることなんてほぼないわけですじゃん？
でも逆に全部を公開しない共有しない「友人関係」は欠点よりも長所を理由に長ーく続くことが多いきがしません？
**僕はできるだけその長ーく付き合える関係に近い形をとることがお互い長ーく幸せになることに必要なことだと思うんですよ。**
それがお互いのプライベートを確保し、役割分担とかどっちがどっちに何をしてあげてるとか妥協とかそういう概念から解放されることでできるんじゃないかなと。
世間一般の結婚して幸せな家庭像には合致しないかもしれないけどさ、本当に相手の幸せを願える美しい世界ってそういう選択も肯定される世界じゃないのかな。
なんて考えたりするんですよね。

**まぁいままで誰一人賛同してくれたこともないので、同意はもとめてねぇーけど！！！！**

なんかクリスマスとかバレンタインとか、恋愛がHOTなトピックになると自分の恋愛観とか結婚観とかそういうの無意味に深堀したくなりますよね。
わかります。
**よければコメント欄に皆さんのそういう系で思っていることぶちまけてってください。**

**次に書くノベルがロマンスものなので、ネタに困ってるんです。**
(これをいうのが今回の一番の目的)

[0]:https://pages.awscloud.com/event_JAPAN_Ondemand_Hands-on-for-Beginners-Security-1_CP_0806.html
[1]:https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/
[2]:https://qiita.com/saito_ry/items/191a6278e23873a2ff0a
[3]:https://aws.amazon.com/jp/iam/identity-center/
[4]:https://aws.amazon.com/jp/sns/getting-started/
[5]:https://aws.amazon.com/jp/partners/foundational-technical-review/
[6]:https://aws.amazon.com/jp/organizations/
[7]:https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/services-that-can-integrate-cloudtrail.html
[8]:https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/consolidated-billing.html
[9]:https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-procedure.html
[10]:https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/services-that-can-integrate-config.html
[11]:https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html
[12]:https://aws.amazon.com/jp/guardduty/
[13]:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html
[14]:https://www.rworks.jp/system/system-column/sys-entry/21725/
[15]:https://aws.amazon.com/jp/security-hub/
[16]:https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-1st-Step-2022-reg-event.html?trk=aws_introduction_page
[17]:https://aws.amazon.com/jp/events/aws-event-resource/hands-on/
[18]:https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-amplify-2022-reg-event.html?trk=aws_introduction_page
[19]:https://aws.amazon.com/jp/codecommit/
[20]:https://aws.amazon.com/jp/amplify/
[21]:https://p-town.dmm.com/writers/pachinko?page=5
[22]:https://qiita.com/advent-calendar/2022/advent-works-hi
[23]:https://twitter.com/vitaone_/status/1207800011586596867?s=20&t=fpUNjhyy_aMPsCytr3QMMQ