# OPS05-BP08 複数の環境を使用する
<a name="ops_dev_integ_multi_env"></a>

 ワークロードの実験、開発、テストを行うには、複数の環境を使用します。本番環境に近い環境ほど使用するコントロールレベルを増大し、デプロイ時にはワークロードを意図したとおりに運用できるという確信を得ます。

 **期待される成果:** コンプライアンスとガバナンスのニーズを反映した環境が複数あります。本番環境への移行過程で、次の環境に移行する前にコードのテストを実施しています。

1.  組織は、ガバナンス、コントロール、アカウントの自動化、ネットワーク、セキュリティ、運用上のオブザーバビリティを提供するランディングゾーンの確立を通じてこれを行います。複数の環境を使用して、これらのランディングゾーン機能を管理します。一般的な例は、[AWS Control Tower](https://aws.amazon.com/controltower/) ベースのランディングゾーンへの変更を開発およびテストするためのサンドボックス組織です。これには、[AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/) および[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) などのポリシーが含まれます。これらの要素はすべて、ランディングゾーン内の AWS アカウント へのアクセスとオペレーションに大きな影響を与える可能性があります。

1.  これらのサービスに加えて、チームは、AWS および AWS パートナーによって公開されたソリューション、または組織内で開発されたカスタムソリューションを使用してランディングゾーンの機能を拡張します。AWS によって公開されるソリューションの例には、[Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) と [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) があります。

1.  組織は、本番稼働へのパス上の環境を通じて、ランディングゾーンのテスト、昇格コード、ポリシーの変更と同じ原則を適用します。この戦略によって、アプリケーションチームとワークロードチームに安定した安全なランディングゾーン環境が実現します。

 **一般的なアンチパターン:** 
+  あなたは、共有開発環境で開発を実行しており、別のデベロッパーがあなたのコードの変更を上書きします。
+  共有開発環境の制限的なセキュリティ制御により、あなたは新しいサービスや機能を試すことができません。
+  あなたは本稼働用システムで負荷テストを実行し、ユーザーの機能停止を引き起こします。
+  データ損失につながる重大なエラーが本稼働環境で発生しました。あなたは、データ損失がどのように発生したかを特定し、これを再び発生させないようにするため、本稼働環境において、データ損失につながる条件を再現しようとします。テスト中のさらなるデータ損失を防ぐため、あなたは、ユーザーがアプリケーションを使用できないようにすることを強制されます。
+  あなたは、マルチテナントサービスを運用していますが、専用環境を求める顧客のリクエストをサポートできません。
+  テストは常に実行するとは限らず、テストを行う場合は本番環境でテストします。
+  あなたは、単一環境というシンプルさが、環境内での変更の影響範囲に勝ると考えています。
+  キーランディングゾーン機能をアップグレードしましたが、変更によって新しいプロジェクトまたは既存のワークロードのアカウントを公開するチームの能力が損なわれます。
+  AWS アカウント に新しいコントロールを適用しましたが、その変更はワークロードチームが AWS アカウント 内に変更をデプロイできるかどうかに影響します。

 **このベストプラクティスを活用するメリット:** 複数の環境を展開すると、デベロッパーやユーザーコミュニティ間で競合を生じさせることなく、複数の同時開発、テスト、本番環境をサポートできます。ランディングゾーンなどの複雑な機能では、変更のリスクが大幅に軽減され、改善プロセスが簡素化され、環境への重要な更新のリスクが低減されます。ランディングゾーンを使用する組織は、アカウント構造、ガバナンス、ネットワーク、セキュリティ設定など、AWS 環境内のマルチアカウントからメリットを得られます。時間の経過と共に、組織が成長するにつれて、ランディングゾーンは進化し​​、ワークロードとリソースを保護および整理できるようになります。

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 複数の環境を使用して、実験を行える最小限のコントロールを備えたサンドボックス環境をデベロッパーに提供します。並行して作業が進められるように個別の開発環境を提供して、開発の俊敏性を高めます。デベロッパーがイノベーションを試せるように、本番環境に近い環境でより厳格なコントロールを実装します。コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。テスト結果の有効性を向上させるためにロードテストを行う場合は、本番環境と同等の環境をデプロイします。

 プラットフォームエンジニアリング、ネットワーキング、セキュリティオペレーションなどのチームは、組織レベルでさまざまな要件を持つ機能を管理していることがよくあります。アカウントの分離だけでは、実験、開発、テストのための個別の環境を提供および維持するには不十分です。このような場合は、AWS Organizations の個別のインスタンスを作成します。

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+ [AWS での Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+  [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+ [複数のアカウントを使用して AWS 環境を整理する - 複数の組織 - AWS 環境全体に対する変更をテストする](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/multiple-organizations.html#test-changes-to-your-overall-aws-environment)
+ [AWS Control Tower ガイド](https://catalog.workshops.aws/control-tower)