今日の積み上げ
現在、AWSの社内ハンズオンイベントの企画を進めています。
本日、企画書を作成したので、明日事業部長にプレゼンする予定です。
特に問題なければ、専用のAWSアカウントを作成し、会社経費でハンズオンができる環境が手に入ります。
環境が手に入る、と言っても、私の所属する事業部にはAWSに精通しているメンバーがいないため、どうやって環境を整備すればいいのかは自分でいろいろ調べるしかない状況です。（ここが一番勉強になる部分だと思うので、頑張りどころ！）
そこで、
「どうせアカウントを作るなら、サンドボックス環境みたいなものが作れないか」
ググってみると、サンドボックス環境に関する記事が多数見つかりました。
ただ、運用事例として、シングルアカウント運用とマルチアカウント運用の両方が存在しているようで、自分たちの場合どちらが適しているのかが知りたくなりました。
＜シングルアカウントの課題＞
- 誤操作によるリソース停止、削除
- 操作する人を分けるのが難しい
- コストの管理が難しい
- アカウントごとに上限（クォータ）がある
このうち、アカウント毎の上限については、Service Quotasサービスで上限緩和申請を出すことで対応可能（VPCの数は最大100まで増やせる）で、特に大きな問題ではなくなりました。
誤操作や人の見分けについては、リソースの名前付けなどを工夫することで、対応していけば、ある程度はなんとかなるかな、と甘い見込みもあります。
コストの管理には「タグ付け」が有効になると思いますので、イベント実施前までに試してみることでなんとかなるのでは、とこちらも甘い見込み。
事業部的に予算がしっかり確保できるのであれば、マルチアカウント（１人１アカウント）での解決が理想なのだろうと思われます。
ただ、事業部的にはマルチアカウントにすることのリスク（請求管理、統制、情報漏洩など）をどうヘッジできるのか、誰が管理するのかなども気になるところでしょう。
私自身も現段階でノウハウが十分あるわけでもなく、正直手探りで対応するしかないことを考えると、
- マルチアカウントでの運用管理は、私自身含めメンバーのスキルが十分整っていない状況では時期尚早なのではないか
- まずはローリスクで始めてみる方向（つまりは、シングルアカウントでまずはやってみる）のであれば、問題なし
といったストーリーになるのではないかと想定しています。
付け焼刃ではありますが、プレゼンに向けて、NRIの佐々木さんの「薄い本Ⅱ」の第４章「サンドボックスアカウント作成のチュートリアル」を読んで、多少理論武装して臨むつもりです。
はてさて、どうなることか？
結果は、明日のブログで報告させてもらいます。
それでは、また。
