kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

AWSサンドボックスアカウント運用のすすめ

AWS

AWSサンドボックスアカウントとは？

AWS基盤上でサービス開発をしている企業において、サービス開発に携わるすべてのエンジニア1が自由にAWSのサービスを試用・実験・検証できるAWSアカウント。

作り方

AWSの機能としてサンドボックスアカウントなどという物があるわけではないので以下の手順で作ります。

  1. それぞれの社内規定に従いサンドボックスアカウント用の予算を確保します
  2. それぞれの社内手順に従いAWSアカウントを作ります2
  3. すべてのエンジニアがAdministratorAccess権限3でログインとawscliコマンドを打てるようにします
  4. サンドボックスアカウント用に AWSのコスト予測アラートを設定します
  5. 下記のサンドボックス利用ルールとログイン方法を社内のエンジニアに周知します

利用ルール

MUST

  • 仕事上使う、使いたい、使えるか検討したいAWSサービスがあれば本番環境アカウント・開発環境アカウントなどではなくここでそのサービスを試行(テスト)してください

SHOULD

  • サンドボックスアカウント上に作られたリソースは一日ごとにすべて削除される、またはされる可能性があります4。それでも問題のない使い方をしてください

RECOMMENDED

  • リソースが日毎に消える可能性があるためCloudFormationやTerraformなどのInfrastructure as a Codeを利用することをおすすめします5

SHOULD NOT

  • 不必要なまでにコストがかかる実験・試用はしないでください
  • 大きなコストがかかるが必要性のある実験・試用をする場合はサンドボックスアカウントの運用責任のある部署へ先に一方ください。調整します

MUST NOT

AWSサービスの試行・検証・テストは自由ですがサービスへの攻撃を含むテストはAWSへの申請なしにしてはいけません。こちらで詳細を確認して可能なテスト種別であればAWSへ申請をして実行してください。

目的

tl;dr

  • 新サービス・新機能・使ったことのないサービスの試行を促進することで開発を高速化
  • 失敗してもいい空間(アカウント)を作ることで試行そのものを安全に高速化
  • 開発環境AWSアカウントなどで実験してはぐれインスタンスなどを残さないため

長い説明

AWSのサービスを実際に使用してみることなくサービス開発で利用することは非常に難しいです。AWSのリリースやドキュメントを読んだだけでサービスへ組み込もうとするとイメージと実体が乖離していたりパフォーマンスや機能などが期待と大きくずれていたりします。 そのためシステム設計の前にしろ後にしろどこかのフェイズでAWSのサービスを試行することになりますが、この際いくらかの問題を感じてきました。

  • インフラ構築中の開発環境アカウント/本番環境アカウントなどで試行する
  • → 試行中のリソースと実際のシステムの一部のリソースが混じり合う
  • → 間違ってシステムの一部のリソースを削除してしまったりする
  • → 試行自体が抑制される
  • → 知らないAWSサービスや新しいサービスが使いにくくなる
  • → システムがEC2インスタンスベースで構築される
  • → 運用コスト・保守コストが高くなる

こういったことが開発組織では起こりがちです。 こうなるとエンジニア含め会社全体が嬉しくないので、それを解決するために既存AWSアカウントと分離したサンドボックスアカウントという手段を考えました。

  1. クラウドエンジニアやインフラエンジニア、バックエンドエンジニアなどと呼ばれる普段からAWSを触ることが多い職種だけではなく、フロントエンドのエンジニアやアプリのエンジニアなどクラウド基盤を直接・間接問わず使用するすべてのエンジニア↩

  2. AWS Organizationを使うのがおすすめです↩

  3. 請求情報などを平エンジニアに見せたくないなどといった要望がある場合は制約を加えてもいいかもしれませんが基本的に悪手です。各々のエンジニア自身に自分たちの運用しているサービスのコスト感を意識させる意味でもコスト系も開放することをおすすめします↩

  4. コストへの配慮のため。お金じゃぶじゃぶの企業はこの項目いらないかも↩

  5. 実際のシステム構築でCloudFormationやTerraformなどを使ってもらいたいことも一因です↩