こんにちは！
家系ラーメン屋さんでライスが有料なのはなんか微妙じゃない？派の今井です🍜🍚

ここ半年間ほど社内のAWS周りを担当させてもらうことが多くなり、多少なりとも知見が増えました。
ということでせっかくならみんなで共有しよう！と社内で勉強会を開きました！

一人で抱えているといざ詰まったときにとても辛いので同じ仲間が欲しかったというのもありますが（笑）

いざ、勉強会の資料作りに際し、間違った内容を伝えるわけにもいかないので、AWS公式ドキュメントをはじめ様々な記事を読み漁りました💦

皆さんは「勉強会」と聞いてどのようなイメージを抱きますか？

学生時代の生徒vs先生のような、比較的一方通行に近い形の授業のようなものでしょうか？
大学のゼミ等、皆で意見を出し合ったりする大勢が主体的に参加しているようなものでしょうか？

別に正解はないと思うので、どちらでも、それ以外でも良いのですが、私は固くなることなく緩い感じで皆でワイワイし、それでいて内容としては、しっかりと得るものがある。

そんな勉強会にしようと思いました。
まあ、同じ社内のメンバー間なのでそりゃそうだろうって感じですね（笑）

・・・

【こんな内容やりました】AWS IAM について！

AWSの勉強会ということでどんな内容にしようかと色々と迷いましたが、アカウントの作成から始まり、ほぼ全てのAWSリソースに関わってくるAWS IAM(以下IAMとします。)を扱うことにしました。

概要と軽く内容に触れると以下のような感じでした。

◆AWSアカウント

・AWSアカウントの作成からIAMユーザーの作成
・IAMユーザー作成時におけるIAMグループの作成、ポリシー設定の検討ポイント紹介

◆認証と認可について

IAMといえばPolicyとRoleかと思います。そしてこの2つは特に最初は混同してたり、なんとな～くで使っている場合が多いかと思います。なのでその「なんとな～く」を、いわゆる「ちょっとワカル」的な状態にできるような理解の助けとして、認証と認可の違いに触れました。

・認証(Authentication)は本人性の確認 → 相手の身元を確認すること → 通信相手が誰かを確認すること

・認可(Authorization)はリソースに対する利用権限の付与 → 権限を与えること → リクエストが許可されるかどうかを決めること

認証と認可は本来は相互に独立した異なるものです。

この考え方がIAM PolicyとIAM Roleにつながります。
 

◆IAM Policy と IAM Role

・IAM PolicyとIAM Roleについて

上で触れた認証と認可の内容を元にし、RoleとPolicyを理解したいです。

IAM Policy : 認可の機能
IAM Role : 認証の機能

その上で以下リンク内にあるAWSリソースにアクセスする流れの図を用いて、PolicyとRoleの流れを見ていきました。
AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM)

・IAM Policy詳細

　 Policyドキュメントの書き方

　全6種類あるポリシータイプの内、使用頻度の高い（現時点の私のレベルで、、、）アイデンティティーベースポリシーとリソースベースポリシーの2つについて少し深堀して触れました。

・IAM Role詳細

　IAM Roleはあくまで、権限の定義であり、IAM Role自身はアクションを実行できない。

　sts.AssumeRoleによって一時的にアクションが可能になるということ。

◆スイッチロールの勧め

AWSを運用していると、否が応でもアカウントは増えていくと思います。

そこで、今まで上で紹介してきましたPolicy、Role、AssumeRoleのまとめとして、複数アカウントの王道的な管理方法である「スイッチロール」について実際に手を動かしながら紹介するとともに、便利なブラウザの拡張機能である「AWS Extend Switch Roles」についても触れました。

AWS Extend Switch Roles - GitHub - Chromeウェブストア

・・・

実際に勉強会を終えてーー

上の内容で実際に勉強会をしたわけですが、最初に僕は何て言ってましたっけ？

冒頭で以下のように言ってましたね。。。

固くなることなく緩い感じで皆でワイワイ楽しく気楽で、それでいて内容としてしっかりと得るものがある。そんな勉強会にしようと思いました。

・・・・・

はい。確かに緩い感じではできましたが、それは話している私だけで、
全体としては生徒vs先生の様な比較的一方通行に近い形の授業のようなもの感が否めない雰囲気でした。

参加頂いた方の2/3程はオンラインだったというのもありますが、もっと工夫できる点は多々あったと思います。

勉強会の反省点

以下、今回の反省点と今後の勉強会のために個人的に思ったポイントを3つ上げます。

１．内容に合わせて参加頂く対象層を絞る

今回事前に参加アンケートを取った際、ほとんどが普段からAWSを用いて開発しているエンジニアの方達だったので、あまりに基本的な内容過ぎてもダメだなと思い、少し深く難しい内容を用意しました。

自分としては初めての勉強会だったということもあり、エンジニア以外の多くの方に参加頂きました。結果、全体に内容がしっかりと伝わったかは微妙なところです💦

今後は内容を決めたら、それに合わせて参加募集のターゲットを絞って告知していこうと思います。

例えば、エンジニアを対象にした内容と、エンジニアではないけれど、どういうものか知りたい。興味があるといった方を対象にした場合で内容が異なるのは当然ですよね。

２．資料等は早めに仕上げて事前に共有しておく

当たり前のことなんですけどね（笑）結構ギリギリまで資料作成しちゃってました。。。

担当者のやり方、進め方次第な部分もあるので一概には言えませんが、

やはり事前に共有して資料に目を通しておいて貰った方が、実際に勉強会を進める上でもお互いにスムーズに進められますし、その場での質疑応答等もより活発になると思いました。

３．オンライン/オフライン問わず随時反応を確認し、話しかけつつ進める

ここが一番大事な気がします。

言われてみればここも当然の内容なんですけどね（笑）
いざやってみると一方的に話して一方通行に近い形の授業のようなもの になっていましたね💦

特に今回は多くがオンライン参加だったということもあり、画面の向こうにいる人の反応を気にすることがあまりありませんでした。。。

時折反応を伺ったり会話もあったのですが、それはオフラインで対面している人たちだけで内輪感が強い雰囲気になってしまってた気がします。。。

例えば、上に挙げた資料の事前共有を行っていれば、それを元に、オフラインでも随時話しかけたり質問を募集することもやり易かった気がします。
 

・・・

まとめ

大きく分けて以上3点が今回初めて勉強会を行って個人的に思ったことでした！
人に説明する、伝えるって難しいですよね。。。( TДT)

まあ、初回ということもあり、次の人がやり易いようにハードルを下げておいたってことで(￣∇￣)

勉強会をすると、みんなの知見が深まるだけでなく、資料作成や説明を考えたりする段階でより一層自分自身の理解も深まり、良いこと尽くめなので、やらない理由はないですね！☆彡

今後も社内でどんどん勉強会を開いて、みんなでどんどん知見を深め合っていきたいなーと思います。