合併・買収 (M&A) 後のコストを最適化するための AWS Organizations でのベストプラクティス

合併と買収 (M&A) は、事業を拡大し、製品ラインを多様化し、新しい市場を開拓する機会を組織にもたらします。ただし、旧来の IT システムの統合、厳しい規制への準拠、事業継続性の維持など、そこにはさまざまな課題が伴います。リソースの重複を排除し、プロセスを最適化して運用の一貫性を実現するのと同時に、コストを管理および最適化することは、合併を完了したり M&A 活動を行ったりした後にビジネス価値を最大化する上で、極めて重要な役割を果たします。

このブログ記事では、AWS Organizations を利用したM&A 後の AWS リソースとコストの最適化と管理に関するベストプラクティスと考慮事項について説明します。また、Amazon S3 Storage Lens、AWS Compute Optimizer、AWS Cost Optimization Hub (コスト最適化ハブ) など、AWS Organizations が統合しているさまざまなコスト最適化サービスや分析サービスを紹介し、活用します。

前提条件

• AWS Organizations、AWS Control Tower、および AWS でのマルチアカウント設定を理解していること
• その M&A に関連する買収元企業と買収先企業の両方について、AWS Organizations で設定されている organization (※訳注：一般的な意味での “組織” と区別するために本記事では “organization” と表記します) の構造を理解していること
• 合併元 organization からメイン organization へのアカウントの移行が完了していること

ベストプラクティスと推奨事項

合併後の organization で適用可能なタグを評価し、リソースをグループ化してコストの一元管理を行う

合併後は、新たに合併されたビジネス内でタグを調整する戦略を立て、Resource Groups を利用してプロジェクトや環境、コストセンターなどの特定の基準に基づいてAWS リソースの論理的なコレクションを作成する必要があります。それにより、アップデートの適用、アプリケーションのアップグレード、ネットワーク設定の調整などの一括アクションを実行でき、それと同時にリソース全体のコストを容易に追跡・管理することができます。また、コスト要因の特定、予算の設定、リソース使用の最適化も行えるため、最終的に AWS における潜在的なコスト削減につながる可能性もあります。

包括的な可視性を得るには、AWS Organizations を使用して一元化された”請求とコスト管理” のフレームワークを確立してください。AWS 上で実行されているアプリケーションがあり、リソースが EC2 インスタンス、RDS データベース、S3 バケットなどの複数のサービスに分散している場合を想定してみましょう。このアプリケーション用のリソースグループを作成し、すべてのリソースをグループ化することができます。これにより、グループ内のすべてのリソースの合計コストを確認できるようになり、コストの集中箇所の特定や、使用パターンの分析、実際の需要に基づいたリソースのサイズ適正化などを行うことが容易になります。また、利用できていないリソースや過剰な支出を削減することもできます。

例えば、リザーブドインスタンスやスポットインスタンスなどのコスト最適化戦略をグループ全体に適用して、コスト削減を最大化することができます。AWS Resource Groups を使用して、リソースグループと呼ばれるキャパシティ予約の論理的なコレクションを作成できます。また、属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が異なるキャパシティ予約を 1 つのリソースグループに含めることもできます。キャパシティ予約のリソースグループを作成すると、個々のキャパシティ予約ではなく、キャパシティ予約のグループにインスタンスを割り当てることができます。キャパシティ予約のグループをターゲットとするインスタンスは、グループ内の任意のキャパシティ予約のうち属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が一致し、かつ他のインスタンスに割り当てられておらず利用可能なものとマッチングされます。

費用を正確に追跡するために、コストセンターを設けて、すべての AWS リソースに一貫したコスト配分タグを実装してください。例として、A 社と B 社が合併した後、「Project Alpha」と「Project Bravo」というワークロードが重複している各社のプロジェクトについて、コストの可視化を維持しながら AWS 環境を統合する必要がある場合を考えてみましょう。

コスト配分タグは以下のシナリオで役に立ちます:

• ”Project“, ”Environment“, ”CostCenter“, ”Application“, ”Department“ などの統一されたタグ構造を定義します。
• リソースを移行し、統一された構造に従ってタグ付けをし直します。例えば、“Project Alpha” リソースには “Project=Alpha”, “Environment=Production”, “CostCenter=IT” のようにタグ付けし、“Project Bravo” リソースには “Project=Bravo”, “Environment=Live”, “Department=Engineering” のようにタグ付けします。
• 重複しているワークロードを識別し、両方のプロジェクト名でタグ付けします。例えば、共有データベースリソースには “Project=Alpha”, “Project=Bravo”, “Environment=Production”, “CostCenter=IT”, “Department=Engineering” のようにタグ付けします。
• AWS Cost Explorer を使用して、さまざまなタグの組み合わせに基づいてコストレポートを生成します。これにより、共有コストを含め、各プロジェクト、環境、コストセンター、または部門に関連するコストを可視化できます。
• 共有リソースへの比例配分を含め、それぞれのプロジェクト、コストセンター、または部門に正確にコストを帰属させるコスト配分モデルまたはチャージバックモデルを実装します。

合併後の organization におけるリソースの重複を特定および削減する

organization が合併する際、クラウド環境間で重複が発生し、無駄な支出につながることがよくあります。包括的なレビューを行うことで、リソースの余剰を明らかにし、最適な統合を実現することができます。

まず AWS Organizations で有効にした AWS Cost Optimization Hub (コスト最適化ハブ) を活用して、合併後の事業体全体の AWS コスト最適化推奨事項の特定、フィルタリング、集計から始めることをお勧めします。それにより、リソースのサイズ適正化、アイドル状態のリソースの削除、Savings Plans、およびリザーブドインスタンスに関する推奨事項が得られます。図 1 に示すように、Cost Optimization Hub を使用することで、合併後の organization 全体で推奨されるコスト最適化と統合された調査結果を 1 つのダッシュボードで確認することができます。そこで推定される節約額は、AWS アカウント、AWS リージョン、リソースタイプなどでフィルタリングして集計することができます。

自動化された推奨事項がニーズに合わず、コスト最適化分析を自分で行いたい場合は、AWS Organizations と統合された AWS Cost Explorer を利用することで organization 全体の推奨事項を可視化することができます。

図 1: Cost Optimization Hub (コスト最適化ハブ) で毎月の節約額を見積もる

エンタープライズサポートのお客様の場合、AWS Trusted Advisor からの最適化に関する更なる推奨事項も確認いただけます。Trusted Advisor は、図 2 に示すように、十分に活用されていないリソース、アイドル状態のロードバランサー、その他のコスト削減の可能性がある領域を特定するのに役立ちます。organization 全体で AWS Trusted Advisor を有効にし、推奨事項を含むレポートを作成することをお勧めします。より規範的なガイダンスやベストプラクティスについては、ブログ記事「AWS Trusted Advisor による運用上の優秀性の継続的な最適化」をご覧ください。

図 2: AWS Trusted Advisor はコスト最適化のチェックの特定に有用

AWS Config は、AWS アカウント内のリソースの設定と関係性を評価、監査、確認することができます。このサービスはコスト最適化にも使用できます。特定の Amazon Relational Database Service (Amazon RDS) インスタンスがアカウントにデプロイされた場合にアラートを受け取ることができるシナリオを考えてみましょう。必要以上に大きなインスタンスタイプを使用されている場合、特定のアカウントに予期せぬコストが発生する可能性があります。これに対処するには、AWS Config にカスタムルールを実装し、データベースインスタンスを監視してアラートを提供することでコストを最適化できます。

合併後のビジネスニーズに合わせてコンピューティングコストを最適化する

AWS Compute Optimizer は、AWS Organizations を通じて管理されている複数のアカウントにわたって EC2 インスタンスを適切なサイズにするための推奨事項を提供することで、M&A 後のコストを最適化するのに役立ちます。ワークロードパターンを分析し、パフォーマンス要件を満たしながらコストを削減できるインスタンスタイプを提案します。Organizations でアカウントを統合し、Compute Optimizer の推奨事項を活用することで、十分に活用されていないインスタンスやサイズが大きすぎるインスタンスを特定して排除し、統合後の組織のコンピューティングリソース全体でコスト削減につなげることができます。

図 3: AWS Compute Optimizer – 動作の仕組み

Compute Optimizer コンソールから Compute Optimizer を AWS Organizations と統合します。これにより、Compute Optimizer はサービスに必要なリソースの作成などの必要な設定を実行できるようになります。

AWS Compute Optimizer の使用を開始するには、Compute Optimizer コンソールを使用してメンバーアカウントを Compute Optimizer の委任管理者として指定します。委任管理者アカウントを使用して、organization 内のすべてのアカウントのリソース最適化の機会を特定するように Compute Optimizer を設定します。詳細については、「AWS Compute Optimizer の開始方法」を参照してください。コンテナワークロードを扱う場合は、organization 内の複数アカウント間での分割コスト配分データ (SCAD) を活用することができます。

ワークロードとインフラストラクチャが増えるにつれて、リザーブドインスタンスを利用してコストを削減したり、使用量に応じた階層型料金によるメリットを活用したりできる機会が増えます。適切なリザーブドインスタンス (RI) の構成を決定するには、使用パターンを分析することが重要です。両方の organization の既存の RI コミットメントを評価し、M&A 後の環境への適用可能性を評価します。使用パターンやインフラストラクチャの要件の変更に合わせて RI を必要に応じて変更または移管することで、RI の使用率を高め、コストを削減できます。

統合的なデータアーカイブとストレージの戦略を策定する

M&A のトランザクションが終わったら、両 organization のストレージ使用状況を見直し、コスト削減の機会を見極めましょう。統合プロセス中または統合プロセス後のデータ保持とコンプライアンス要件を管理するためのデータアーカイブおよびストレージ戦略を策定します。

Amazon S3 Storage Lens は、オブジェクトストレージの使用状況やアクティビティの傾向を organization 全体で可視化し、コストを最適化してデータ保護のベストプラクティスを適用するための実行可能な推奨事項を提示します。S3 Storage Lens は、組織内の数百、数千ものアカウントにわたるオブジェクトストレージの使用状況とアクティビティを単一のビューで提供し、ドリルダウンして複数の集計レベルでインサイトを得ることができる初めてのクラウドストレージ分析ソリューションです。S3 Storage Lens を使用すると、そのバケット内のオブジェクトへのアクセスが頻繁ではない “コールド S3 バケット” を識別できます。図 4 に示すように、アカウント、リージョン、バケット、またはプレフィックスに基づいてフィルターを追加することで、詳細なインサイトを可視化できます。Amazon S3 Glacier や Amazon S3 オブジェクトライフサイクルポリシーなどの AWS ストレージサービスを活用することで、データアーカイブとライフサイクル管理を自動化し、時間の経過とともにストレージコストを削減することができます。

図 4: Amazon S3 Storage Lens では、organization 内のすべての S3 バケットにわたるオブジェクトストレージの使用状況とアクティビティを一元的に確認可能

バックアップポリシーとデータ保持の効率的かつ一元的なデータ管理を行うには、AWS Backup の AWS Organizations との統合を有効化してください 。これは、合併後の organization の複数の AWS アカウントとサービスにわたるバックアップとデータ保護を一元管理するための、費用対効果の高いソリューションを提供するものです。詳細については、「AWS Backup のコストを最適化する」を参照してください。

ネットワークインフラストラクチャの重複箇所を特定し解消する

M&A では、しばしば異なる IT インフラストラクチャを統合する必要がある場合があり、それによって重複や非効率性が生じる可能性があります。これらのトランザクションには通常、ハイブリッドネットワークが含まれます。M&A の後に AWS でのデータ転送やネットワークのコストの最適化を怠ると、多額の不要な支出が発生する可能性があります。データ転送とネットワークの最適化の手法を活用することで、最終的には M&A による財務上のメリットと相乗効果を最大限に引き出すことができます。

M&A において、新規アカウントを既存の AWS Organizations 構造に統合する際には、IT インフラストラクチャの統合と、データ転送やネットワークなどの関連コストの最適化が重要となります。主なステップには、リージョン別のデータ転送パターンの特定および統合、データ転送料金を削減するための AWS PrivateLink や Resource Access Manager の活用、一元的な VPC 接続管理のための AWS Transit Gateway の利用などがあります。

AWS Data Exports と Amazon QuickSight による一元的なコストモニタリングにより、統合された請求データの可視化が可能になります。AWS Organizations 内でサービスコントロールポリシー (SCP) を実装することで、統合されたアカウント全体にコスト最適化プラクティスを強制的に適用できる一方、AWS コスト配分タグを使用することで、特定のビジネスユニットやプロジェクトにコストを分類し配分することが可能です。

統合フェーズでのネットワーク最適化の推奨事項の詳細については、AWS ネットワーク最適化のブログ投稿を参照してください。

サポートおよびライセンスにかかるコストを管理する

適切なサポート計画を立てることで、コストの削減、リスクの軽減、事業継続性の確保、合併後の事業体のより円滑な管理の促進が可能になります。そのためにエンタープライズサポートプランへアップグレードをお勧めします。このプランでは、AWS コスト最適化の専門家によるサポートを受けることができるようになります。そこでは AWS のアーキテクチャや使用パターンのレビューを通して、リソースの最適化やインスタンスのサイズ適正化、リザーブドインスタンスの活用、費用対効果の高いサービスやアーキテクチャの採用などについて、カスタマイズされた推奨事項が提供されます。

エンタープライズサポートの大きな利点は、organization 全体を対象としていることです。organization 全体でエンタープライズサポートプランを契約すると、追加または招待したすべてのアカウントに自動的に同じレベルのサポートが継承されます。これによりプロセスが合理化され、合併時に各アカウントに個別のサポートプランを付与する必要がなくなります。ただし、この機能は現在一部のリージョンのお客様のみが利用可能であり、お客様のエンタープライズ契約にはそのための必要な条項が含まれている必要があります。この機能を有効にする資格や、サポートプランに関する追加情報についてはテクニカルアカウントマネージャーにお問い合わせください。

AWS License Manager を使用することで、ソフトウェアライセンスの管理やライセンスコストの調整が可能になります。AWS Organizations と AWS License Manager を統合することで、organization 全体のライセンスを可視化できます。合併後の事業体全体のソフトウェアライセンスを一元的に可視化できるため、M&A の際のライセンスコストの最適化に役立ちます。図 5 は AWS License Manager がどのようにライセンスの追跡、プール化、再配布を可能にするかを示しており、これによりコンプライアンスを確保しながら重複購入を回避して、大幅なコスト削減につなげることができます。

図 5: AWS License Manager ダッシュボードは AWS およびオンプレミス環境全体にわたる Microsoft、SAP、Oracle、IBM などのベンダーからのソフトウェアライセンスの概要を提供

ソフトウェア調達を効率化し、重複するライセンスを排除し、合併後の事業体全体で統合された可視性を確保するために、organization 全体で AWS Private Marketplace を有効にすることをお勧めします。これにより、中央集権的なガバナンス、コスト管理、および効率的なソフトウェア配布が可能になり、M&A の際にスムーズな移行を可能としつつ、コスト削減を実現することができます。

M&A 成功後に継続的にコストを監視し最適化する

M&A 後は、自組織の環境内のコストを継続的に監視することが極めて重要です。これは通常、当組織が最大限の最適化のためのスコープと機会を持ち、環境内での効率性を向上させる立場にあるためです。プロアクティブなコスト監視と最適化のプラクティスを確立し、進化するビジネスニーズとコスト要因に基づいてリソースの使用量を継続的にレビューして調整します。定期的にコスト最適化レビューを実施して、不要または十分に活用されていないリソースを特定して排除するように計画してください。これには、インスタンスのサイズ適正化、未使用リソースの削除、費用対効果の高い価格モデル (リザーブドインスタンス、スポットインスタンスなど) の活用などが含まれます。

合併後の organization の複数のアカウントで Amazon CloudWatch メトリクスをモニタリングすることで、CPU/メモリの使用量が低く、ダウンサイジングや終了が可能な、十分に活用されていないリソースを確認できます。使用パターンに基づいてリソースを起動および停止することで、アイドル状態のリソースのコストを削減できます。AWS Budgets と AWS Cost Anomaly Detection をセットアップして、データ転送やネットワーキングに関連する潜在的なコスト急増や異常が発生したときにアラートや通知を受け取るようにしてください。AWS Lambda 関数を使用してアイドル状態のリソースを自動的に停止または終了する自動最適化を実装してください。また、需要に基づいてリソース容量を動的に調整する AWS Auto Scaling の使用も検討してください。

コスト管理プロセスと手順を文書化する

M&A を通じて得たコスト管理のプロセス、手順、および得られた教訓を文書化して、組織の知識を把握し、統合後の組織への知識移転を促進してください。統合後のコストを効果的に管理できるように、コスト管理のベストプラクティス、ツール、プロセスについてステークホルダーにトレーニングとサポートを提供してください。これにより、コスト意識の文化が育まれ、M&A 移行期間中の効果的なコラボレーションが可能になります。

社内に知識共有プラットフォームがある場合は、そこにプロセスを文書化してください。また、エンタープライズサポートプランに加入している場合は、フルマネージド型の安全なプライベート空間である AWS re:Post Private を活用して、組織固有のクラウドコミュニティを構築し、独自の知識リソースへのアクセスを提供することもできます。AWS re:Post Private は、信頼できる AWS 技術コンテンツを一元化し、プライベートな議論の場を提供します。これにより、チームが社内チーム間および AWS と連携する方法を改善して、技術的な障壁を取り除いたり、イノベーションを加速させたり、クラウドでのより効率的なスケーリングを実現したりできるようになります。

サービスを AWS Organizations と統合してボリュームディスカウントを利用する

このブログ記事で説明されているサービスは、サービスのコンソールまたは API 操作 / CLI コマンドなどを使用して AWS Organizations 上で有効化することができます。これにより、必要なリソースの作成など、organization に必要なすべての初期化ステップを AWS サービスが実行できるようになります。

合併する organization のアカウントを合併後の organization に統合したら、organization 内のすべてのアカウントの使用量を合算することで、ボリュームディスカウント、リザーブドインスタンス割引、および Savings Plans を共有できます。請求の観点からは、AWS は organization 内のすべてのアカウントをあたかも 1 つのアカウントのように扱います。Amazon Simple Storage Service (Amazon S3) などの一部のサービスには、特定の使用量に応じたボリューム料金階層があり、サービスの使用量が増えるほど料金が低くなります。一括請求により、AWS はすべてのアカウントの使用量を合算して適用するボリューム料金階層を判定し、可能な限り全体的な料金を低く抑えます。その後、AWS は各アカウントの使用量に基づいて全体のボリュームディスカウントの一部を各メンバーアカウントに割り当てます。

たとえば、Bob の一括請求には、Bob 自身のアカウントと Susan のアカウントの両方が含まれているとします。Bob のアカウントは管理アカウントなので、Bob は自分自身と Susan の両方の料金を支払います。Bob はその月に 8 TB のデータを転送し、Susan は 4 TB のデータを転送します。

この例では、AWS は最初の 10 TB のデータ転送に対して GB あたり $0.17、次の 40 TB に対して GB あたり $0.13 を請求します。これは、TB あたりに換算すると最初の 10 TB については $174.08 (= 0.17 × 1,024)、次の 40 TB については $133.12 (= 0.13 × 1,024) に相当します。なお、1 TB = 1,024 GB である点に注意してください。

Bob と Susan が使用した 12 TB については、Bob の管理アカウントに ($174.08 × 10 TB) + ($133.12 × 2 TB) = $1,740.80 + $266.24 = $2,007.04 が請求されます。

一括請求を階層化することのメリットがなければ、AWS は Bob と Susan の使用量に対してそれぞれ TB あたり $174.08 を請求することになり 、合計で $2,088.96 となっていたはずです。

3 つの AWS アカウントがあり、S3 ストレージとしてアカウント A は 10 TB、アカウント B は 15 TB、アカウント C は 20 TB を使用しているものとします。個別のアカウントの場合、それぞれのストレージ階層に基づいて個別に請求されます。これらのアカウントを AWS Organizations を使用している organization に統合すると、45 TB (10 TB + 15 TB + 20 TB) のストレージ使用量の合計が organization レベルで集計されます。この 45 TB の使用量は上位のストレージ階層に該当する可能性が高く、その場合個別アカウントの料金階層と比較して GB あたりの料金が低くなります。

AWS Organizations を通じてこのボリュームディスカウントを利用することで、特に organization 内の複数の AWS アカウントに大量のストレージ要件が分散している場合に、S3 ストレージ全体のコストを大幅に削減することができます。

まとめ

このブログ記事で紹介したベストプラクティスを導入することで、組織はリソース利用を最適化し、コストを効果的に管理し、財務リスクを最小限に抑え、合併・買収 (M&A) の活動に関わるすべての関係者にとって統合を成功させることができます。ワーナーブラザーズ・ディスカバリーが AWS Organizations サービスやその他の統合サービスをどのように活用して買収を成功させたかを理解するには「Improving Mergers and Acquisitions Using AWS Organizations with Warner Bros. Discovery」をご覧ください。

AWS コストのレビュー、可視化、最適化に対して AWS の推奨事項と支援を最大限に活用するには、このブログ記事で取り上げているコスト最適化ハブ、S3 Storage Lens、Compute Optimizer などのサービスを AWS Organizations と統合してください。分散化された柔軟な管理を実現するために、AWS Organizations と統合されたサービスの委任管理者としてメンバーアカウントを指定することを検討してください。AWS Organizations と統合可能なサービスのリストを確認するには、AWS Organizations で使用できる AWS サービスをご覧ください。

M&A を進めている中で organization の統合に関するベストプラクティスのガイダンスをお探しの場合は「AWS Organizations のアカウント評価」と、アカウントの効果的な移行に関する 3 部構成のブログ投稿シリーズを参照してください。さらに詳細な情報については「Choosing an AWS cost management strategy」と「Starting your Cloud Financial Management journey: Cost savings」をご覧ください。

著者について

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。