本記事は
【Advent Calendar 2024】
19日目の記事です。
🌟🎄
18日目
▶▶ 本記事 ▶▶
20日目①
🎅🎁
こんにちは、西内です。
先日のJAWS-UG朝会 #64にて本記事と同じタイトルで登壇を行い、CCoEについて発表しました。
本ブログでは、JAWS-UG朝会 #64で発表した内容を説明していきます。
発表資料
はじめに
今回の記事では「CCoEとは何か」について説明しますが、その前に「そもそもなぜクラウドが重要とされているのか」から解説し、最後にAWS上で行うCCoE活動の例を示します。
そもそもなぜクラウドが重要なのか
クラウドはシステム開発におけるアジリティ（俊敏性）が高い
世間ではクラウドによるシステムの開発・運用が浸透していますが、何故ここまで重用されているのでしょうか。
以下にクラウド利用のメリットを書き出してみます。
- システムの導入・運用コストがオンプレミスシステムと比較して低い
- ハードウェアの調達が不要
- 従量課金により簡易な技術検証が実施しやすい など
これらを総合して考えられることは、アジリティ（俊敏性）が高いということです。
ここで、従来のオンプレミスシステムによる開発の流れを考えてみます。
下図のように、インフラストラクチャーの準備を終えてアプリケーションの開発に着手するまでに、様々な前準備が発生するかと思います。
一方で、クラウドによる開発の流れは下図のようになります。
サーバに入れるOSの検討こそすると思いますが、それ以外は前準備をすることなくサーバの立ち上げが可能です。
スペック（CPU性能、ストレージ容量）も一旦仮の値で立ち上げて、後から変更も可能です。
また、起動までの作業もAWSであればWebブラウザ上で数クリックするだけで完了します。
このように、従来型のシステムと比較してクラウドは開発のスピードがより速くなります。
アジリティの高さはDX（デジタルトランスフォーメーション）推進において非常に重要
先述のアジリティの高さは、昨今様々な企業で求められているDXにおいても重要な要素となってきます。
DXの定義を見てみましょう。
企業が、ビッグデータなどのデータとAIやIoTを始めとするデジタル技術を活用して、業務プロセスを改善していくだけでなく、製品やサービス、ビジネスモデルそのものを変革するとともに、組織、企業文化、風土をも改革し、競争上の優位性を確立すること。
引用元：DX（デジタルトランスフォーメーション）| 用語解説 | 野村総合研究所(NRI)
ここでポイントとなるのは「デジタル技術を活用して」「製品やサービス、ビジネスモデルそのものを変革する」ことです。
製品やサービス、ビジネスモデルに変革をもたらすには様々な施策を早いスパンで試行錯誤していく必要があります。
その際に、クラウドによる開発のアジリティは親和性が高く、DXを進めるうえで重要な要素となります。
一方でアジリティの高さだけを見てはならない
ここまでの話でクラウドによるシステム開発はアジリティが高く、DXにおいても重要であるということをご理解いただけたかと思います。
しかし、アジリティの高さは時に様々な問題を招いてしまいます。
- 必要なセキュリティ対策が講じられない可能性がある
- 不要なリソースへの請求が発生する可能性がある
- 重要なリソースを誤って削除してしまう可能性がある など
このような問題の発生を防ぐためにも組織内のクラウド利用を適切に管理しつつ、活用推進をしていく組織が必要となります。
CCoEとは
CCoEは何をする組織か
先ほどの章で、クラウド利用をするにあたり適切な管理を行う組織が必要な話をしました。
CCoEはこのようなクラウドの管理や活用推進を行う組織になります。
なお、CCoEの正式名称はCloud Center of Excellenceです。
CCoEが推進することの例としては「ハンズオン環境の提供・管理」「課金状況の把握・コスト管理」「アカウントへの適切なセキュリティ設定」「ユーザアカウントごとの権限設定」「人材の育成」などがあげられます。
CCoE活動は部署をまたぐ
先ほど述べたCCoEが推進する事項は一つの部署内で完結せず、複数の部署とのやり取りが発生するものになります。
例えば「アカウントへのセキュリティ設定」は情報セキュリティ部とコミュニケーションを取りながら社内のセキュリティガイドラインに適合する対策を検討しつつ、アカウントを所有する部署へ内容を伝達する必要があります。
他にも「人材の育成」であれば、人事部とコミュニケーションを取りながら研修の制度や資格取得補助の仕組みを考える必要があります。
このようにCCoEの取り組みは全社的なものであり、案件を持つ部署以外にも本社機構の部署とのコミュニケーションが多く発生します。
CCoE組成の一例
では、CCoEはどのように編成していくのが良いでしょうか。
様々な組成の仕方があるかと思いますが、一番明快なのは情報システム部等の元々存在した社内の部署をそのままCCoEとして昇格するという方針が考えられると思います。トップダウン・ボトムアップで考えると、トップダウンの色合いが強いでしょう。
一方で、「複数の部署とやり取りが発生する」という側面に着目して、各部署から人材を引き抜く・兼務してもらうという形で組成する考え方もあります。こちらはボトムアップの色合いが強いでしょう。
「どちらが正解か」と問われると「どちらか一方が正解とは限らない」というのが回答になります。
会社の内部事情や各部署の人員の都合があるため、会社ごとに正しいあり方は異なると考えられます。
ただ、CCoEの役割として複数の部署とコミュニケーションを取るという点を考慮すると、後述のボトムアップ型の方が業務の遂行がより円滑に進められるのではないかと考えられます。
AWSを使ってCCoE活動を進めるには
AWSでの具体的な取り組みの例
概念的な話が続きましたが、ここからはAWSを社内で利用している場合CCoEとしてするべきことは何か、について考えてみます。
こちらも何を取り組むべきかは正解が一つではありませんが、例としては下記のようなことが考えられるでしょう。
- アカウント分離
- AWS Organizationsを使った複数アカウントの管理
- IdP導入およびAWS IAM Identity Centerとの連携
- AWS ConfigやAmazon GuardDutyなどのセキュリティ設定の導入
上記の事項について具体的にこれからご説明します。
アカウント分離
まず一つ目はアカウントの分離です。
シングルアカウントでAWSを利用している場合、不都合が発生することがあります。
「開発環境用のサーバを誤って削除してしまった」「請求金額を部署単位で分けて把握したいが全体の金額しか見られない」などです。
これらの課題に対するアプローチがマルチアカウント管理という考え方です。
アカウントを環境・部署・プロジェクト等に応じて分けることで、予期せぬ誤操作を防ぐことが出来、且つ請求の金額を分離して把握することが可能になります。
AWS Organizationsを使った複数アカウントの管理
先述のマルチアカウント管理を更に効果的に行うには、AWS Organizationsを使うことが推奨されます。
Organizationsでは複数のアカウントをOrganizational Unitという単位でまとめ管理することが出来ます。
例えば、Sandboxとしての検証環境の単位、開発アカウント群、本番アカウント群、部署といった単位で分けて管理することができます。
また、それらのまとまりに対して権限統制を敷くことも可能です。
また、Organizations内に取り込んだアカウントはコンソール上やCLIから一覧を取得することも可能になります。
IdP導入およびAWS IAM Identity Centerとの連携
アカウントが増えることで新たな課題も発生します。それは、アカウントへのログインをIAMユーザで行っている場合、アカウントの数だけID・パスワードが増えるということです。
マルチアカウント管理の弊害ともいえる課題でしょう。しかし、この課題を解決するサービスがあります。
それがAWS IAM Identity Centerです。このサービスにより、複数アカウントへログインする際のユーザやアクセス権限を一元管理することが可能になります。
AWS ConfigやAmazon GuardDutyなどのセキュリティ設定の導入
セキュリティサービスの導入も重要な事項です。
Organizationsで管理しているアカウントに対して必要なセキュリティ設定を検討し、全てのアカウントに対して導入を行う必要があります。
これは各アカウントの所有者に任せるのではなくCCoE側から設定を導入し、各アカウント側からは解除できないようにするのが良いでしょう。
最後に
今回はCCoEという概念とAWSでは具体的にどのようなことを実施するべきかを書きました。
クラウドは便利ですが適切な管理を行わなければ、多額の請求やセキュリティインシデントが発生してしまうことがあります。
社内のクラウド利用状況を俯瞰して適切な管理を行うような組織を作ることが大変重要になります。
