こんにちは、sumiです。
Tech系スタートアップにおいてエンジニアの確保は必須ではあるものの、無名なスタートアップがつよつよエンジニアを獲得するのは難しく、まだまだ未熟なエンジニアも多いのが現状ではないでしょうか。
未熟なエンジニアは伸び代がありますが、スタートアップには育成にかけるリソースはありません。みんな自発的に学習をしています。
自ら動き、楽しく学ぶことで大きな成長につながりますし、そこで得られた知識や経験を日々の業務にコミットすることで仕事もうまくいく。わたしは自身の経験からそのことをよく理解しているつもりです。
AWSのスキルは実際に開発を行う中で学び習得することもありますが、開発は最小権限での実行に限定されることになるため、限られたサービスの利用しか実行できないため、より良いビジネスへのアイデアを出すには限界があります。
そのため、AWSサービスを自由に触ることができるSandbox環境を用意することにしましたので、その運用について紹介します。
Sandbox環境とは
自由にAWSのサービスを触りまくって遊ぶことが許されている実験・学習用のAWSアカウントです。開発等で使用しているAWSアカウントとは分離させて、実際に運用しているシステムに影響を出すことなくAWSサービスを触ることができる環境です。
AWSを学習するためにはドキュメントをはじめハンズオンやユーザーグループの開催する勉強会などがありますが、AWSを本当に理解するためには実際に触ってみることが大事です。
実際にAWSサービスを触らないまま「なんとなく理解した」つもりで、実際の開発で取り入れようとすると、意外なところに壁があったり、実はもっと最適な方法があって後で気づくことになることもあります。
こうなるとエンジニア含め、その先にあるお客様にとっても嬉しくないので、それを解決するために既存AWSアカウントと分離したSandboxアカウントという手段を採用しました。
目的
わたしは、以下3つの目的をもってSandboxの運用をはじめることにしました。
- AWSサービスをより広く深く理解し、ビジネスアイデアを増やす
- 費用やセキュリティに関して不安を感じることなく思いっきり遊んで学び、エンジニアとしてスキルアップを目指す
- アウトプットを増やしてエンジニア組織としての知名度の向上を目指す
運用方法
Sandbox環境の運用はシンプルです。
組織の従業員全員がOktaを経由して、シングル・サインオンでAWSのSandbox環境にAdministrator権限でアクセスできるようにしています。そして、月に一度アカウント内のすべてのリソースを削除しています。
しかしながら、巨大なインスタンスを立てて膨大な費用を請求されることや、脆弱な穴を作って放置することは組織として望んではいません。そのため、一定のルールとガードレールを設ける必要があります。
運用ルール
私は以下のルールで運用を始めることにしました。
- 毎月1日に aws-nuke でアカウント内のリソースを削除
- 予算は組織全体で$500/月。 (ここは組織拡大を見越して一人当たりの予算とかにすればよかったかも)
- コスト予測アラートをセットする
- サーバー情報をインターネット上に公開しない
- アクセス資格情報をソースコードに含めない
- 業務のための検証はSandboxではなくプロジェクトのアカウントで行うこと
- 使って欲しくないサービスはSCPで制限する
- Route53 ドメイン登録
- Snowball
- Ground Station
- Marketplaceの購入
- リザーブドインスタンスの購入
Sandboxの重要な要素の1つは、Sandbox環境で遊ぶ人々が環境を制御できるようにする必要があることです。つまり、管理者権限です。しかし、大いなる力には大いなる責任が伴います。初心者は大いなる力を手にしたことを理解しないまま使うこともあるでしょう。
そのため、これらのルールを守り、システム的な制御を設定する必要があります。
ただ不便で面倒なルールはお断りです。可能な限り自由でエンジニア・フレンドリーなルールづくりを心がけています。
セキュリティガードレール
エンジニアが思いっきりアクセルを踏み込んで実験を楽しむには、セキュリティの脅威を排除する必要があります。そのためにセキュリティ・ガードレールを作成し、利用者が安全に実験に没頭できる環境を用意します。
これらのサービスを使用して、組織に合ったガードレールを作成することもできます。
AWSConfig
AWS Configを使用して、AWSアカウント全体のリソース構成を管理するためのマネージドルールとカスタムルールを実装することができます。
たとえば、マネージドルールを実装して、すべてのS3バケットでサーバー側の暗号化が有効になっていることを監視して、サーバー側の暗号化が有効になっていない場合、AWSConfigは非準拠のリソースを検出してフラグを立てます。SSMで自動修復してもよきですね!
AWSCloudTrail と AmazonEventBridge
EventBridgeはAWSのあらゆるサービスのアクションをトリガーにすることができる超便利なサービスですよね。これと、AWS CloudTrailを監査ツールとして使用して、AWS環境でAPI呼び出しを継続的に監視することができます。
やってほしくない不正な動作を検知させるにはもってこいです。
AWSOrganizations (SCP)
不要なアクションを防ぐために、セキュリティガードレールとしてSCPを実装する必要があります。サンドボックスアカウントは、SCPをすべてのサンドボックスアカウントに簡単に適用できるように、組織内の「サンドボックス」組織単位(OU)の中にいれています。
うちでは使用できるリージョンを制限しています。GuardDutyを全リージョン有効にするのはさすがにコストがかかりすぎなので、4つくらいに絞ってます。
あとは上記のルールで指定した「使って欲しくないサービス」の制限です。
やって欲しくないアクションを拒否するようにしています。
他にもやってみてもいいかなと思うアイデアとしては、
- EC2インスタンスは特定のタイプしか使えないようにする
- Configルールの変更ができないようにする
などはあるのですが、まだ実装できてないので今後取り組んでいきたいところ。
コストの追跡と管理
Sandboxアカウントには予算を必ず設定しておきましょう。
また、その支出が正常なものか(不正に利用されたものではないか)を判断できるようにしておくことも重要です。
そのために、BudgetsとCostExplorerの存在はかかせません。
AWSBudgets
AWS Budgetsを使用すると、コストまたは使用予算に割り当てられた金額を超えた場合、または超えようとしている場合にアラートをあげることができます。
AWS CostExplorer
過去の使用量とコストを表示し、予想される支出を予測し、コストを最適化する方法の推奨事項を提供してくれる有能なサービスです。コスト異常検出の機能もあるので、SNSと組み合わせれば、「気づいたら請求金額がえらいことに…」なんて事態は防ぐことができそうですね。
やってみて
運用をはじめてみると、AWSに興味はあるけどAWSの料金がよくわからなくて、個人では怖くて使えなかったというエンジニアたちが使い始めるようになりました。
最近のコスト・レポートから見ると、AmplifyやDynamoDBといった実業務で触ったことのあるサービスを、より深く理解するためにSandbox環境で学習している傾向が見られました。
また、公式で提供されているハンズオンを試してみたり、新しく登場したサービスを触ってみるなど、実験・学習用途としての利用もされているようで、組織のAWSスキルの向上に貢献できているような気がしました。
ですが、まだまだ毎月の予算を使い切るほど利用はされていないので、もっと社内のエンジニアたちを焚き付けてどんどんAWSにのめり込んでもらって、たくさんアウトプットをしていけるような組織づくりをしていきたいなと思います。
まとめ
開発チームにとって、Sandboxアカウントは、安全な設定でAWSサービスをテストおよび検証する自由を提供し、エンジニア自身の成長を促す役割があります。人材の育成は企業にとって重要なことですが、育成のためのリソースが不足しているスタートアップにとっては必要なものではないでしょうか。
意図しない結果を防ぐための制限(ガードレール)を設定した上で、広い特権を付与することで、AWSのあらゆるサービスを安全で自由に学ぶことができます。
AWSにはたくさんのサービスがあり、日々進化を続けています。マネージドで便利なサービスも増えました。それらをビジネスに活かすために私たちは日々学ばなくてはなりません。
ビジネス・チャンスを広げるためにも、AWSで何ができるのかを学びましょう。
Top comments (0)