エンジニアの成長のためのAWS Sandbox環境構築事例紹介

この記事の目次
はじめに
皆さんこんにちは!クラウドエンジニアリング部のS.Mです。
AIの急速な発展とともにクラウド技術の重要性がますます高まっている昨今、当社でも多くのエンジニアの皆さんが次のような悩みを抱えていらっしゃいました。
「AWSを実務レベルでしっかり学びたいが、実サービスを触るわけにはいかず悩んでいる」
「個人アカウントではリソ-ス削除漏れによる費用請求が不安」
このような悩みを抱えている方々のために、私たちが社内に正式リリースしたAWS Sandbox完全自動化システムの実際の実装事例をご紹介したいと思います。
Sandboxとは ?
AWS Sandbox環境は、個人またはチームがAWSサービスを学習し、実験できる空間を提供します。
各ユーザーは個人の金銭的費用負担なく、一定の期間・金額の範囲で多様なAWSサービスを自由に触ることができます。
つまり、砂の城のように簡単に作って簡単に消すことができるAWS学習および開発環境です!
使用例
- 個人の学習・ハンズオンに使う
- AWSの新しいサービス・機能を試す
- 検証のためのサーバーやコンテナ環境を作る
特徴
- 月額$50まで自己負担なし
- リージョン制限
- 基本的なサービスが一通り使える(一部の高額なサービスは制限している)
- xlarge以上インスタンスタイプ禁止
なぜ独自システムを構築したのか?
読者の皆さんの中には「AWSが2025年5月にInnovation Sandbox on AWSという公式ソリューションを提供しているのに、なぜ独自開発したのか?」と疑問に思われる方もいらっしゃるかもしれません。
実は、私たちは2024年3月にこのシステムを社内に正式リリースしており、AWSの公式ソリューションが登場する約1年前から独自のSandbox環境を運用していました。当時はこのような包括的なソリューションが存在しなかったため、社内のニーズ(Microsoft Forms連携、既存の承認ワークフロー統合)に合わせて一から設計・構築する必要があったのです。
AWS Sandbox自動化システムを構築した話
上記の通り2024年3月から運用を行っておりますが、リリースの時点から段階的に運用の自動化を行い、現在はほぼすべての運用を自動化できています。
以下、この自動化を中心とした構築内容について紹介します。
既存環境の限界
AWS学習と実習環境構築には、次のような根本的な問題がありました。
- 複雑な手動プロセス: アカウント作成から権限設定まで数日を要し、運用負担となっていた
- 分散したセキュリティポリシー:個別アカウントごとの異なるセキュリティ設定によるリスク
- 予測不可能なコスト:個別ユーザーのリソース放置による予想外の課金
これらの課題を解決するため、私たちは「最初から最後まで人の介入なし」をモットーに完全自動化システムを設計しました。
【ポイント1】 完全自動化されたアカウント作成ワークフロー

私たちのシステムの最大の特徴は完全自動化されたアカウントプロビジョニングです。
Microsoft Forms 利用申請
↓
Step Functions起動
↓
社内承認システム連携(ワークフローベース承認)
↓
Step Functions 後続処理
↓
AWSアカウント作成 + 権限設定
↓
利用者に作成完了メールを送信
※ 運用担当は承認の1クリックをするだけでアカウント作成が完了します!
StepFunctionsベースワークフロー
// 承認/拒否による自動分岐処理
const definition = applicationHandlerTask.next(
choice
.when(
sfn.Condition.stringEquals('$.application_lambda_result.result', 'approve'),
accountManagementHandlerTask.next(sendgridExecuteHandlerTaskApprove)
)
.when(
sfn.Condition.stringEquals('$.application_lambda_result.result', 'reject'),
sendmailExecuteHandlerTaskReject
)
);
Lambdaマイクロサービス構造
- 申請リクエスト用Lambda:Microsoft Formsデータ処理および社内承認システム連携
- Account作成用Lambda:AWS Organizationsアカウント作成およびIAM権限設定
- 申請者にメール送信用Lambda:自動メール通知システム
- 承認リクエスト用Lambda:API Gatewayを通じた承認フロー処理
【ポイント2】AWS Organizations基盤アカウントライフサイクル管理
体系的なOU構造となるように設計しています。
Root Organization
├── Master OU(組織管理アカウント)
├── All OU
│ ├── Management OU(運用アカウント群)
│ │ ├── Audit Account(監査・ログ集約)
│ │ ├── StackSets Account(デプロイ管理)
│ │ └── SSO Account(IAM Identity Center)
│ └── Main OU(アクティブSandboxアカウント群)
└── Separation OU(アカウント閉鎖管理)
├── Closed OU(閉鎖完了)
└── Nuke OU(リソース削除実行)
【ポイント3】自動化されたコスト管理システム
コスト管理は以下のように閾値を設けて自動化しています。
1段階 - 予防的警告(80%到達)
- AWS Budgetsベース実際コストモニタリング
- 予算対比80%到達時自動メールアラート
- 予測コスト100%超過時早期警告送信
2段階 - 自動リソース制御(90%到達)
- SNS Topicベース自動アラートシステム
- EC2インスタンス自動停止(データ保存)
- RDSインスタンスおよびクラスター自動停止
- 管理アカウントからCross-Account Roleを通じたリモート制御
3段階 - アカウント隔離(100%超過)
- SNS Topicを通じた自動アカウント閉鎖プロセス開始
- Separation OUに自動移動
- 新しいリソース作成完全遮断
- 既存リソースは読み取り専用で保存
【ポイント4】予想外の課金防止
個別ユーザーのリソース放置や過剰な利用にによる予想外の課金は防止されています。
Service Control Policy(SCP)ベースポリシー制限
# リージョン制限ポリシー例
- Effect: Deny
NotAction: ["chatbot:", "iam:PassRole"]
Resource: ""
Condition:
StringNotEquals:
aws:RequestedRegion: ["ap-northeast-1", "us-east-1"]]
※ 全アカウント共通制限
Sandboxアカウント専用制限
- xlarge以上インスタンスタイプ禁止(予算$50保護)
- 高コストサービス制限(予算超過防止)
AIサービス安全制御
- AWS Bedrock等AIサービスオプトアウトポリシー適用
- 学習データ流出防止のための自動オプトアウト設定
実際の運用成果について
システムリリース後定量的成果として運用効率性とセキュリティ面で以下のように向上されました。
運用効率性
- アカウント作成時間: 短縮(完全自動化)
- 運用業務自動化率: 自動化適用
- 設定エラー: 標準化による減少
- コストオーバーラン: 予算管理システムで防止
セキュリティ
- ポリシー一貫性: 標準化適用
- コンプライアンススコア: 向上
- セキュリティ事故: 安定運用維持
そして技術文化については以下のように変化しました。
IaC(Infrastructure as Code)基盤文化導入
- すべてのインフラ変更のコードレビュー義務化
- CDK TypeScriptベースタイプセーフなインフラ管理
- Gitベースインフラ変更履歴完全追跡
自動化優先思考方式
- Manual Last: 手動作業を最後の手段として考慮
- Fail Fast: 迅速な失敗を通じた素早い学習
- Observability: すべてのシステムの完全な可視性
おわりに
フロントエンド、バックエンド、モバイル開発など、どの分野のエンジニアでも、現代のアプリケーション開発にはクラウドの知識が不可欠です。
私たちのSandbox環境では、個人専用のAWSアカウントで安全にクラウドサービスを学習でき、実際のプロジェクトで活用できるスキルを身につけることができます。
インフラの専門知識がなくても大丈夫です!
S3でのファイル保存、Lambda関数の作成、RDSでのデータベース構築など、アプリケーション開発に直結するAWSサービスから始めて、段階的にクラウドスキルを向上させていく事ができます。
マイナビには資格取得支援制度があるため、Sandboxを活用することで、自己負担なしでAWSを触って勉強し、さらに資格取得まで行うことができます!
私たちと一緒に成長したいエンジニアの皆さんをいつでも歓迎します。
※本記事は2025年10月時点の情報です。