※本ページは、筆者の他アカウントでの投稿を整理して本アカウントに移動したものです。
2016年頃から企業でのAWS利用に携わってきたので、おさらいを兼ねて検討タスクを整理してみます。
このあたりのコンセンサスをざっくりとれば、はじめてAWSそのもののスキルに本格的に取り組めると思います。
初期検討
セキュリティガバナンスのある企業における、AWS Tokyoリージョンの運営について整理します。
はじめにAWSを企業ユースで使うための準備タスクを列挙し、これらの整理が終わった後、AWS固有の設計に移ります。
| 区分 | 考慮する項目 | AWSの状況 |
|---|---|---|
| 取引先信頼性 | 信頼性・継続性 | AWSを利用する理由です。ガートナー等のアナリストレポートから市場地位や売上、製品優位性が確認できます。 |
| 企業ガバナンス | コンプライアンス情報からAWSとユーザーの役割分担が確認できます。特にサービス毎に適用される第三者認証が異なるので注意します。 | |
| 基準・ガイドライン | 最近だとFISC安全対策基準とのマッピング情報が公開され、金融機関での利用も一般的になってきました。 | |
| セキュリティ役割分担 | AWSは各種認定、強固なセキュリティ環境をもっていますが、ざっくりOSより上位はユーザーによる管理責任（責任共有モデル）となります。例えば、インターネットに公開されたOSがパスワード脆弱性により不正ログインされたとしてもユーザーの責任となります。 | |
| 法務 | 契約管理 | カスタマーアグリーメント（CA）が基本ですが、企業規模によっては、個別のエンタープライズ契約（EA）をAWSと締結することも可能です。 |
| 準拠法 | CAでもEAでも日本準拠法に変更します | |
| AWSアカウント管理 | AWSアカウント単位に契約が必要です。多くの場合、マルチアカウント運用（本番・開発用等）となるでしょう。 | |
| 請求支払 | 為替レート | 円払いは可能ですが、請求額はUSD為替レート（月中平均等で算出）の影響を受けます。 |
| 支払 | クレジットカードの登録が必要ですが、AWS利用料によってはAWS海外口座への直接送金も可能です。また、国内の「AWS請求代行会社」と契約することで代行会社経由の支払いが可能です（多くの場合、契約はCA同意が前提でしょう）。 | |
| 支払明細 | AWSアカウント単位にサービス毎の利用料が記載されます。システム毎等の内訳はAWSタグ機能で管理します。 | |
| 企業内ネットワーク | インターネット境界 | 多くの場合、インターネット境界設計（出入口の一元化等）があります。AWSアカウント内のリソースはAWS機能/設備で直接インターネットに出ることができます。このあたりの設定をOFFにする必要があるか等、ネットワーク設計、セキュリティポリシーの確認をしましょう。 |
| ネットワーク分離 | 本番・開発・DMZ等の分離の有無を確認しましょう。VPC（仮想プライベートネットワーク）の設計のインプットとなります。 | |
| セキュリティ設備 | 既存のセキュリティ設備の利用をするか、AWS独自の機能/設備を新設するか検討します。やはりVPCの設計に影響します。（プロキシサーバ、WAF、IDS/IPSの利用等） | |
| 社内調整 | 部門間役割分担 | 法務・総務（請求支払い）および社内ネットワーク担当部門とは最初にパスを作りましょう。特にイントラ網が設定されている企業の場合、ネットワークの足回りの設計がAWS利用の最初の協業です。 |
| ROI監視 | クラウド利用は統制をかけないとサーバ数が増加します。個別の運用管理も重要ですが、「何にいくら払っているか」を予算・実績の面から管理しましょう。予算、AWSアカウント毎の請求実績およびAWSタグ管理によるプロジェクト毎の内訳等が管理対象です。 | |
| サポート | 保守サポート | 基幹系の運用を想定している場合、AWSエンタープライズサポートが推奨されますが、請求代行会社にはサポートも含まれているケースが多いので、システム重要度に応じて検討しましょう。（AWSアカウント単位のサポート契約となります） |
| SI業務 | SI業務は別途パートナー会社が必要となります。AWS自身はプラットフォーム事業のみでSI事業は実施しません。 |
チームビルディング検討
中小規模企業でのAWS運営初期のチームビルディングについて整理してみます。
下記の通り、チーム目標に「迅速」を含めるので、内製・自前要素の強いチームビルディングを目的とします。
前提：
| 企業規模 | 組織構成 | 運営チーム目標 |
|---|---|---|
| 100～500名 | 情報システム部門がある組織 | パブリッククラウドの膨大なコンピュートリソースを安価かつ迅速に企業内に送り込み各種プロジェクト支援※を行うこと。 |
※AWSを活用するプロジェクト群を支援するためのチームであり、プロジェクト上のアプリ開発、ミドル/DB構築等はスコープ外。
上記規模だと、初年度は、リーダー1名のほか、4名分の人件費を確保できれば御の字で、構成は下記のとおりです。
リーダー以外の人件費で、ざっくり年間50Mの費用がかかる体制ですので、事前のAWS採用の費用対効果と相談します。
なお、ネットワークエンジニア、セキュリティエンジニアについては、初期は専任での確保は難しいため、既存担当に兼務・スポット対応を依頼することになるでしょう。
2年目以降は、サブリーダーやAWSインフラエンジニア、NW/セキュリティエンジニアを増員し、「ピザ2枚ルール」に対応したチームが完成します。
| ポジション | 人数 | スキルセット | 担当業務 |
|---|---|---|---|
| リーダー | 1名 | マネジメント | 予算取り、稟議作成、関係者承認取り付け。 |
| AWSインフラエンジニア | 1名 | AWSスキル保有者（Solution Architect資格保有者等） | AWSのサービス選定や方式設計、情報収集、PoC等。 |
| オペレーションエンジニア | 2名 | システムオペレーション | 利用者からの問い合わせ対応やマニュアル作り、初期のEC2の停止起動等のオペレーション等を担当します。高スキルは不要ですが、企業内の様々な時間の取られる対応や丁寧な作業を担当するため、ツーマンセルが望ましい形です。 |
| アプリケーションエンジニア | 1名 | スクリプト言語やツール開発経験 | ツール開発。（AWSがInfrastructure as code で運営可能なため、自動化は運営に貢献するため）また、AWSエコシステムのSaaS（Datadog等）検証や、サーバレス適用可否も担当。 |
AWSアカウント分割検討
企業内の1つのAWS運営チーム（AWSを利用するプロジェクトを支援する事務局ポジション）が複数のプロジェクトチームをゆるく統制していく観点で、AWSアカウント管理を考えてみます。
AWS利用時に作成するAWSアカウント（12桁）の管理単位は、下記考慮事項から複数のアカウントに分割することが多いです。
分割時の考慮事項
| 管理区分 | 管理要望 | 実装例 |
|---|---|---|
| 課金管理 | 請求書はAWSアカウント単位となるので請求書を用途により分離したい | プロジェクト単位、環境単位、管理部門単位等にアカウントを作成する |
| 環境管理 | アカウント内に本番・開発サーバ等の全リソースが混在、表示されるのは望ましくない | 各環境用アカウントを作成し、開発作業範囲から本番リソースを完全に分離する |
| サイバーセキュリティ対策 | インターネット公開リソースはサイバーアタックの対策管理を行う | DMZ用アカウントを作成し、セキュリティ投資集中やイントラリソース分離/ダメージコントロール等を可能にする |
| ソーシング管理 | 専門職作業や外注が頻繁に発生するリソースはAWSアカウント管理を委託したい | アウトソーシングが可能な単位にAWSアカウントを分離する（例：エンタープライズサポートを契約する基幹系や、24/365サポートを契約するアカウント等） |
| サービス開発/PoC | セキュリティは重要だが柔軟にAWSを活用、トレーニングする環境は必要 | 自由に作業できるが企業リソースとは分離されたサンドボックス用アカウントを作成する |
| 特権アカウント管理 | AWSアカウント情報の流出は大障害につながるので特権管理は必須 | rootアカウントは金庫に保管し、AWSアカウント内の操作はIAMユーザーを用いる |
| 運用省力化 | 運用コストは削減したい | 管理の複雑化を防ぐため、AWSアカウントの払い出しは慎重に行う。（例：社員/個人ユーザー単位でのアカウントの作成は行わない） |
上記を考慮したマルチアカウント管理例（省エネ型）
| アカウント名 | 用途 | 分割理由 |
|---|---|---|
| ログイン／監査アカウント | IAMユーザー集約先、アカウント間共有データ管理用 | アカウント分割において各アカウントにIAMユーザーを作成するのは管理上好ましくありません。ログイン用IAMユーザーを作成し、ログイン後、各アカウントにスイッチします。（rootアカウントは封印します）また、AWS監査機能ログ（CloudTrail、Config）等のアカウント共通管理データを監査目的で本アカウントに集約します。 |
| サンドボックス | AWSトレーニング用 | 他アカウントはセキュリティ要件で固めますが、本アカウントは自由なAWS操作を許します。 |
| 汎用開発環境 | インターネットからのInboud通信のない開発用途 | イントラ開発環境を分離します。開発環境コストも可視化します。 |
| 汎用本番環境 | インターネットからのInboud通信のない本番用途 | イントラ本番環境を分離します。コスト可視化に加え、開発作業から完全に分離します。 |
| DMZ | インターネット公開するサービス用途 | DMZを分離します。インターネット公開サービスは24/365インターネット経由のメンテや脆弱性対応等、イントラ内環境メンテとはスピードが異なります。セキュリティ強化とアウトソーシングの観点から分離します。 |
| 基幹本番環境 | 基幹システム用途 | 規模によっては、汎用本番環境と共用で問題ありません。ただ、他システム連携や運用設備、AWSエンタープライズサポート（契約はアカウント単位）等、安定最優先の性質があるため、フットワークの軽さが要求される汎用本番環境との分離も選択肢のひとつです。 |