この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
セッション名 : Best practices for organizing and operating on AWS
概要概要(機械翻訳) : 複数の事業部門からクラウド環境を管理・運用することは、困難なことです。このセッションでは、Warner Brothers Discoveryのシニアディレクター/クラウドエンジニアリング＆ガバナンスのグローバルヘッドであるBianca Lankfordから、チームが俊敏に開発しながら、安全、自動、信頼、コスト効率の高い方法でアプリケーションを管理・運用できるようにクラウド環境を整理した方法をお聞きします。AWS Organizations と AWS Systems Manager を使用して、アプリケーションを大規模に運用し、M&A を管理し、環境の製品としてのガバナンスを開発する方法をご覧ください。
スピーカー :
Andrew Blackham, PM, AWS
Steve Rice, Principal Product Manager, AWS
Bianca Lankford, Vice President Cloud Security, Warner Bros. Discovery
レポート
アマゾンではたくさんの顧客の声に耳を傾け、顧客の立場に立つことに膨大な時間を費やしています。
これはアマゾンの中で本当によく聞くシナリオです。
クラウドへの道を歩み始めたところです。
最初は1つのアカウントでスタートし、いくつかのワークロードをそこに投入します。
規模が大きくなると2つ目のアカウントを作成する必要性が出てきます。
やはり物事はどんどん大きくなっていくもので、気がつけばたくさんのアカウントが存在することになります。
財務チームは言います、「ちょっと待てよ、このアカウントは何なんだ？」
これだけのアカウントが必要なのだろうか？何のためのアカウントなのか？ちょっとした混乱があるようです。
このセッションでお話しするのは、まさに「先を読む」方法なのです。
Why AWS Cloud Operations?
ここには、いくつかの素晴らしい統計があります。 私が最も共感したのは、ビジネス・アジリティに関するものです。
37%ということは、市場投入までの時間が3分の1に短縮されたことになります。
Andy Jassy の引用によると、「顧客にとって、スケーリングにはスピードが不釣り合いなほど重要」だそうで、まさにその通りです。
Your journey to operating at cloud scale
クラウドへの移行という点では、魔法の杖を振ればすべてが完了するわけではありません。
これは旅であり、その道中には複数のステップがあります。このスライドを見ると、左側にセットアップがあります。
そして、右側にオペレートがあります。それについてお話します。
What we will talk about today
スケーリングについて話すとき、まず最初に、この3つのセクションに注目します。
スケーリングを成功させるための本当のアイデアは、前もって計画を立て、今すぐセットアップすることなのです。
後で大丈夫なように、今準備しておくことです。そして、それを実行するのは本当に大変なことです。
このセッションでは、このテーマを構造、セキュリティ、運用に分解して説明します。
Key elements of scaling - Structure
構造 (Structure) について話すときは、建物を建てることを考えたいのです。
クラウド環境を構築する際に何が起こっているのかを理解するには、これが一番簡単な方法なんです。
建物をたてる基本的な材料はレンガです。
骨組みや、建物の外観を定義するような構造について考えたいところです。
建物が完成したら、建物を効率的に管理するために必要なすべてのツールを備えたビルマネジャーが必要です。
発達したセキュリティシステムも欲しいところです。ドアをロックして、必要のない人を入れないようにする。
クラウド環境のレンガについて考えると、AWSアカウントをビルディングブロックとして考えたいところです。
私たちは常にAWSアカウントとは何かという概念に立ち戻る必要があります。
AWSではインスタンスを作成し、クラウド環境を素早く構築し、アップ・ダウンができます。
この柔軟性が素晴らしいんです。
アカウントを追加で作成する場合、どのようにスケーリングするかについて、もう少し明確に説明する必要があります。
アカウント間で拡張することを推奨する理由は、基本的に、あるアカウント内で限界に達したときです。アカウントにはクォータがあります。
セキュリティに関して言えば、アカウントをまたいで操作することで、自然に隔離された境界線ができます。
別のプロジェクトやサービスのために別のアカウントを作成すると、デフォルトでは他のアカウントに接続されません。
環境内に追加のアカウントを構築する際には、自然と分離された境界線となります。
特定のワークロードを特定の規制に基づいて遵守する必要がある場合、コンプライアンスに対応したアカウントを構築することができます。
このように、特定のニーズに合わせて環境を構築するという点で、多くの柔軟性を提供しています。
レンガを整列させ、分類するためのフレームワークや構造について説明します。
OU（組織単位）です。
OU は、アカウントを配置し、より大きなAWS環境の中で異なる環境をカスタマイズできるようにするための構造です。
組織や環境を設計する際には、まず小さく始めてから、徐々に拡大していくことが大切です。 小さなところから始めて、徐々に広げていく。 今日のプレゼンでは、このことを何度も聞くことになるでしょう。
セキュリティと運用のニーズを中心に設計し、ビジネス・ユーザーを中心に設計しないほうがいいかもしれません。 なぜかというと、OU にガードレールやポリシーを適用するからです。
そこで、今回は一般的なアンチパターンについてお話したいと思います。
ビジネス・チームを中心にOUを設計している場合です。
ビジネス・チームは大きく変動します。アカウントの所有者、チームの所有者は、明日も同じ所有者であるとは限りません。
経営陣が変われば、チームも変わるのです。
そのため、OU やカウントは、必ずしもビジネスチームを中心に考えるのではなく、アプリケーションやサービス、セキュリティなどを中心に考える必要があります。
もうひとつ、特にソフトウェア・プロバイダーでよく見られるのは、顧客ごとにアカウントを構築しようとするケースです。
新しい顧客ができると、その顧客のために別のアカウントを作成します。
この場合も、何百ものアカウントを管理するのは大変ですし、顧客も変動しやすいからです。
アカウントはリソースのコンテナとして考える必要があります。
繰り返しになりますが、小さく始めて、そこから積み上げていくのです。 もし、何の構造もなく、何の組織単位もないのであれば、まず1つから始めて、それから他の組織に広げていくのです。
AWS-recommended OU structure
すべてのお客様にお勧めする4つの OU と、あらゆる種類のビジネスに有効な OU をご紹介します。
- セキュリティ OU
- あなたの環境のセキュリティ面を管理する
- インフラストラクチャー OU
- 環境のインフラストラクチャー用
- ネットワークサービス、共有サービス
- サンドボックス OU
- 開発者のために構築されたすべてのアカウントをホスト
- 何が起こっているかを確実に理解する監査設定
- 予算制限を設ける
- ワークロード OU
- アプリケーションのライフサイクルステージごとにアカウントを作成することをお勧め (Dev,Test,Prod,etc...)
さらに6つの OU を紹介します。
- ポリシーステージング OU
- 組織に適用する前にポリシーをテストする場所
- サスペンド OU
- アカウントが削除される前に置かれる場所
- AWS のアクションを制限するポリシーを作成し、削除する前のアカウントを安全にホストする場所を提供
- 個人ユーザー OU
- 個々のユーザアカウント
- 例外 OU
- 新しいベータ版製品、新製品など高度にカスタマイズされたポリシーが必要な場合
- デプロイメント OU
- CI/CD パイプラインをホストするアカウント
- 移行 OU
- 合併や買収が盛んな現在では、アカウントが組織から出入りするケースが多いため、推奨しているもの
- これらのアカウントをホストし、機能をテストするための場所
Tools for the building manager
サービスを使って OU 構造を作ることが可能です。
Organizations には3つの要素があります。
Root はどのアカウントが Organizations に含まれるかを定義します。
OU は説明した通りです。
すべてのメンバーアカウントは、これらの組織単位に含まれます。
管理アカウントは、Organizations の管理に使用されます。
管理アカウントは安全に保ちます。(極力ログインしない)
管理のための操作は、可能な限り管理アカウント以外アカウントを委譲することを強くお勧めします。
Control Tower は AWS のベストプラクティスを、あなたの環境に自動的に適用するガバナンスサービスです。
何から始めればいいのかわからない、ガバナンスや構造について考えたことがない、といったケースで役に立ちます。
Account management API は、Organizations 内のメンバーアカウントの中央連絡先や代替連絡先を管理できるようにするものです。
最近、この1ヶ月で AWS のクラウドフォーメーションに対応し、アカウントの作成と管理ができるようになりました。
アカウント、OU、ポリシーの作成と管理を CloudFormation で行うことができます。
Your security system
あなたの環境に必要なセキュリティシステムについて少し話しましょう。
1つには、従業員による積極的なセキュリティメカニズム、そして、2つ目はセキュリティチームが必要とするすべてのものへの可視性と制御されたアクセスを確保し、装備することです。
SCP
ほとんどのお客様に実施していただいている予防的コントロールは、SCP(サービス コントロール ポリシー)です。
SCP を使用すると、カスタムガードレールを作成し、組織に適用できます。
SCP の面白いところは、アカウントに対するアクションを拒否するところです。
そのアカウントで実行されたくないアクションを実行する能力を拒否するポリシーを適用することができるのです。
SCP はメンバーアカウント、OU、または組織のルートに適用することができ、そのポリシーは組織の下位レベルでも継承されます。
SCP use cases
SCP の一般的な使用例について説明します。
セキュリティ OU を例にとって考えてみます。
この OU では、セキュリティサービスを使用する必要があります。
しかし、おそらく他のすべての AWS サービスを使用する必要はありません。セキュリティ担当のためだけのポリシーを作成し、不要な AWS サービスの利用を拒否することができます。
リージョンに基づく制限や要件がある場合、SCP を作成し、ユーザーが許可されていないリージョンの使用を拒否することができます。
リソースを作成する前にタグを付けることを要求したい場合、SCP を作成できます。
これは、適切なタグが適用されていない場合にリソースの作成を拒否するものです。
インスタンスサイズの許容値を指定できます。
これは、サンドボックス OU で、コストが高騰しないようにするためのものです。
ルートユーザーからのアクションを防止できます。
IAM ロールの削除や変更を防ぐことができます。
デフォルトの暗号化をオフにすることを防げます。
いろいろとできることがあるんですね。 これらは、セキュリティとユーザビリティのために、お客様からよく見られるユースケースであり、だからこそ、私たちはこれを推奨しています。
SCP design
SCP を設計する場合、組織の上位にある大まかなレベルのポリシーから始めるとよいでしょう。
そこから始め、組織の下位レベルでは、より具体的なポリシーを持つようにします。
たとえば、組織レベルではすべての EC2 インスタンスを許可するが、巨大な EC2 インスタンス・サイズを必要としない特定の OU では、より小さなサイズに制限する、といった具合です。
Central access and consolidated findings
中央集中管理についてです。
私たちが推奨する2つの特定のアカウントがあります。
ログアーカイブアカウントは、すべての CloudTrail のログをホストする場所であり、各アカウント内で実行されたすべてのアクションがログに記録されていることを確認できます。
そして、この特定のアカウントに CloudTrail の管理を委任できます。そのため、セキュリティチームはこのアカウントで Organizations 全体の状況を把握することができます。
2つ目は、セキュリティツーリングアカウントをお勧めします。
このアカウントでは、GuardDuty、Security Hub、IAM Access Analyzer、Detector、Inspector といった AWS のセキュリティサービスを利用します。
Organizations レベルでこれらのサービスを有効にし、そのサービスの管理をセキュリティツールアカウントに委任します。
セキュリティチームが、すべてのアカウントで何が起こっているかを確認し、すべての調査結果を確認し、それらの調査結果に対してアクションを取ることができるようにするためのものです。
この方法を推奨する理由は、管理アカウント内で実行されるアクションを制限したいからです。
Key elements of scaling
運用というのは、正しくセットアップしたことを証明することです。
テレメトリーの取得と分析を行い、自分たちのシステムに何が起こっているかを確実に把握する必要があります。
AWS では、運用を非常に重視しており、多くのベストプラクティスを蓄積してきました。
私たちが学んだことの1つは、1つのサイズがすべてに適合するわけではないということです。
AWS は多くの小さなチームで構成されています。同時にスケールをしています。
もしあなたがスケールを求めているのであれば、これから話すことはベストプラクティスとして役立つはずです。
Operations best practices
私は a single pane of glass でオペレーションを管理することを強くお勧めします。
なぜそれが重要かというと、ほとんどのお客様は複数の異なるツールセットを持ち、異なるブラウザタブやログインの間を行き来することさえあるからです。
それらを切り替えるだけでも、業務に多少の摩擦が生じます。
ですから、すべてを a single pane of glass にまとめてくれるようなツールを見つけることができれば、それは組織にとって大きな勝利となります。
2つ目は、ランブックと自動化に関するもので、これも当たり前のように聞こえるかもしれません。
しかし、MTTR や何かに素早く対応する能力を考えるとき、これは非常に重要なことなのです。
チームのスプリントや開発プロセスの中で、自動化とランブックを追加する時間を取る必要があります。
また、どのような規模の組織にも共通するベストプラクティスは、このフィードバックループを確保することです。
新しいソフトウェアをデプロイせずに本番環境でソフトウェアの動作を調整できるよう、フィードバックループを存在させることが本当に重要です。
私たちはこれを運用レバー、あるいはフィーチャーフラグと呼んでいます。
Tools should enable your priorities
もうひとつ、私たちが学んだことは、使用するツールが運用方法に大きな影響を与えるということです。
コンウェイの法則というのを聞いたことがあると思います。本質的に、あなたのソフトウェアはあなたの組織構造を反映するのです。
同じことがオペレーション側にも当てはまり、使用するツールがオペレーションの方法に影響を与えることになります。
AWSのお客様を見ると、スタートアップ企業、エンタープライズ企業、オンプレミスとのハイブリッド企業など様々ですが、これら全ての企業がスクリーンショットにある3つのコンポーネントを利用しています。この3つを一緒にするためのツールを探しているのです。
アプリケーションと顧客について考え、クラウド運用モデルの中で組み合わせ、十分な自動化を実現したいのです。
AWS Systmes Manager は本当に素晴らしいものです。
ほとんどが無料で、可視化することができ、迅速に修正することができます。
ここまで話したベストプラクティスを実際にどう使っているのか、Warner Brothers Discovery の Bianca さんにお話ししていただきます。
Warner Brothers Discovery
ワーナー・ブラザース・ディスカバリーをご存知の方がいるかもしれません。初めに大きな合併がありました。
ディスカバリーとワーナー・メディアは合併し、複数の国や言語で視聴可能なグローバル・エンターテイメント企業となり、象徴的なブランドを擁しています。
私はディスカバリー・ワールドの出身で、クラウドをいち早く導入していました。
クラウドを初めて導入するときに言われるアドバイスは、「とにかく導入して、ワークロードを動かし、ガバナンスのことは後で考えましょう」です。
そこで私たちは、まず少数のマルチテナント・アカウントからスタートしました。ビジネス・トランスフォーメーションからデジタル・ポスチュアまで、有機的に成長しています。
また、小規模な M&A やセキュリティチームの増加もありました。
こうしたことがすべて同時に起こっていたのです。私たちは一歩下がって、クラウドガバナンスの自動化とアカウントのライフサイクルの成熟度を高め、この驚異的な成長をサポートするにはどうしたらよいかを考えなければなりませんでした。
私たちは何をしなければならないのでしょうか？
人手を介すようでは駄目なのです。ハイエンドで高価値のシステムに取り組んでいる開発者が、IT チームがアカウントを提供してくれるのを待つようではいけません。
自動販売機が必要だったのです。統制され、安全で、誰もが安心して使えるものを提供する能力が必要だったのです。
私たちは、クラウドガバナンスに対して非常に製品化されたアプローチを確立し、自分たちをソフトウェアチームのように扱ったのです。
そして、どのような機能を、何を提供しなければならないかを開発しました。
私たちは、現場のエンジニアと Jira チケットで作業していました。私たちは説明責任とオーナーシップを確立しました。
そして最も重要なのは、基本的なポリシーのセットとともにアカウントを提供したことです。
Warner Brothers Discovery: Account lifecycle
専門チームがアカウントを提供するような形になっています。
Organizations を活用し、所有者とサービス制御ポリシーを持つアカウントを提供します。
では、専門チームについて、なぜ重要なのかについてお話しましょう。
個々のユーザーが自分のアカウントで必要なことを行うようにしますが、ポスチャーとライフサイクルの管理は専門チームが行います。
このチームは、高度なスキルを持つエンジニア、ソリューションアーキテクト、プログラムマネージャー、プロジェクトマネージャーで構成されています。
そして、全てのサービスをキュレーションしています。自分の組織で何が有効かを見極めています。
ですから、私たちはアカウントのライフサイクル、記録管理、オンボーディング、クロージングを担当しています。
この製品化されたアプローチにより、さまざまなビジネスユニット向けにすべてのコントロールをカスタマイズすることが可能です。
製品化されたガバナンスを使用することで、どのように規模にも応じたガバナンスを行っています。
Warner Brothers Discovery deep dive: AWS Organizations
これは私たちが始めたバージョン1から時間の経過とともにより進化したサンプルです。
ルート、基本的な OU、ワークロード、ワークロードには Prod、Non-Prod を持っています。
ポリシーステージングがあり、サスペンデッドがあります。
アカウントの自動化により、特定のポリシーが適用されます。
クラウドの専門知識とエンジニアリングの専門知識を持つチームを持つことで、適切なOU構造を構築することができるのです。
アカウントのライフサイクル機能セットを持つことは本当に重要です。
アカウントのプロビジョニングは簡単で、それほど多くの労力はかかりません。
デフォルトの機能で正しくプロビジョニングすること、これが重要です。
すべてのベストプラクティスをドラマチックな方法で組み込み、開発チームから見えないようにすることが本当に重要なポイントでした。
Warner Brothers Discovery deep dive: M&A
私たちはディスカバリーとして、このような大規模な合併が行われるとは思っていませんでした。
これらの方法で、巨大な企業の合併でも簡単に統合することが可能でしした。
1つの組織を2つにまとめると、どうなるでしょうか。
最小限のポリシーを適用する必要があります。 繰り返しになりますが、チームがキュレートし、理解し、得ているものを理解するために時間をかけているのはそのためです。
未知のものをテストするのは非常に難しいのです。
ポリシーを適用して、それがうまくいくことを願うのは、本当に難しいことです。
インフラは見えても、そのシステムの実際のビジネスクリティカルさはわかりません。
私たちにはフィードバックループがあります。
クラウドチームのなかに開発チームを作ることで、他の開発チームと同じツール、同じ環境で作業できるようになります。
そのため、信頼関係がすぐに確立されます。
ガバナンスが誰かの後に控えている場合、即座に「ノー」と答えるのは難しいものです。
しかし、そのような関係を構築することで、物事を前進させることができるのです。
また、セキュリティチームや財務チームとは、常に非常に強いパートナーシップを築いてきました。 そうすることで、まったく新しいセットアップを統率するために何が必要かを一緒に考えることができるのです。
Warner Brothers Discovery deep dive: best practices
最終的なビジネス成果は何でしょうか？
CloudTrail のようなトップレベルのものを組み合わせることで、大幅なコスト削減を実現しました。
これは、年間100万ドルの節約につながりました。
今年節約した分、今後の無駄な出費を防ぐことができれば、財務の全体像に貢献することができるのです。
そして、最も重要なことは、自社のクラウドの状況を一元的に把握することです。
私たちのベストプラクティスの中には、AWS Organizations を利用するものがあります。
アカウントのライフサイクルの自動化を管理する専門チームを持つには、コストカットに勝つための戦いも必要です。
そのチームには、アカウントライフサイクル、OU、サービスコントロールポリシーに責任を持たせてください。
サービスコントロールポリシーをセキュリティベースラインとビジネスベースライン全体に使用し、リスクとビジネスインパクトに基づいて、開始するポリシーの基本セットを決定します。
きれいなものだとは決して思わないですが、そこに到達することはできます。時間がかかり、忍耐が必要で、ここからもっともっと良いものにするためには、献身が必要なのです。
Where we started
AWS パートに戻ります。
もう一度最初の場所に戻ってみましょう。
私たちはこのような環境にいました。いくつかのアカウントが散在し、たくさんのユーザーも散在していました。財務チームは何が起こっているのか分かりませんでした。
可視性があまりなく、多くのリスクが存在していました。プロトコルもセキュリティ管理もできていなかったのです。
ベストプラクティスとキーポイントは何でしょうか。 もう一度おさらいすると、効果的な構造を計画したいものです。
アカウントをレンガのように考え、そのレンガの周りに OU を構築するのです。
アクセスを制限し、可能な限り予防的な管理を行います。
チームには一元化されたツールを装備し、セキュリティ関連の情報は可視化できるようにします。
運用担当者は、すべてが効率的に運用されていることを確認します。
ランブックと自動化を構築し、組織内やアカウント内で予防的なフィードバック・ループを構築することも必要です。
具体的な次のステップについて説明しましょう。
小さく始めて、そこから大きくします。
アカウントがいくつかある Organazations で、サービスコントロールポリシーを策定していない場合。アカウントが Organazations から離脱しないようにするポリシーを作成し、Organazations 内のテストアカウントでテストしてください。
あるいは、AWS のマネージドポリシーである予防的ガードレールの Control Tower を活用します。
アカウントをプロビジョニングし、所有権を提供するためのアカウントの仕組みを構築し、自動化を開始します。
ガバナンスは一朝一夕にできるものではありません。
決断を下し、その枠組みを今すぐ導入することが、長期的にあなたを支えることになるのです。
標準化されたセキュリティ管理と運用を可能にすること、将来の成長を見越して正しい構造を構築することを確実にするのです。
所感
すでにどのようなお客様でも複数の AWS アカウントを運用する時代です。
組織が管理する大量の AWS アカウントを管理するには、AWS Organizations と Control Tower の活用が欠かせません。
OU 構造例をスクリーンショットで貼り付けました。これは大変参考になるはずです。1つの OU だけで運用しようとしてはいけません。目的に応じた複数の OU を用意しましょう。
SCP やガードレールを使い、アカウント内で可能な操作、不可能な操作を定義します。それを構造化された OU に適用します。
これらはすべて自動化されていることが理想です。
管理アカウントではいかなる作業も行わないことが理想です。操作・閲覧用のアカウントを作り、それらに必要な権限を移譲する運用にします。
AWS Organazations をご利用の方々には当たり前に聞こえるかもしれません。しかし、基本を忠実に再現してはじめて高度な運用が実現できるものと考えます。
Warner Brothers Discovery 社の事例が参考になると思います。
以上、吉井 亮 がお届けしました。
3
