AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【管理&ガバナンス篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。管理ガバナンス に関するサービスはこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

AWS Organizations(1)Organizationsの概要

AWS Organizations

AWS Organizationsは、 複数のAWSアカウントを統合 するためのアカウント管理サービス。 ビジネスの予算、セキュリティ、コンプライアンスのニーズを満たす 以下の機能が備わっている。

  • アカウントの一元管理
  • 一括請求
  • アカウントのグループ( OU )化
  • アカウント毎の アクセスコントロール
  • タグの標準化
  • AIと機械学習サービスがデータを収集/保存する方法を制御
  • 自動バックアップポリシーの使用
  • IAMの統合

これらの機能を実現するために、AWS Organizationsは以下のAWSサービスと連携している。

サービス名 有効化 実現できること
AWS IAM 不要 サービスアクティビティ による 最終アクセス時間の確認
AWS Artifact 必要 組織契約 による 契約の受諾
AWS CloudTrail 必要 組織の証跡 による 証跡の組織への適用
AWS CloudWatch Events 不要
AWS Config 必要 アグリゲータ による 集約ビュー の表示
AWS Control Tower 不要
AWS Directory Service 必要
AWS Firewall Manager 必要 AWS Firewall Manager による WAFルールの管理
AWS ライセンスマネージャー 必要
AWS RAM 必要
AWS Service catalog 必要
Service Quotas 不要
AWS シングルサインオン 必要
AWS System Manager 必要 Systems Manager Explorer によるデータの同期
タグポリシー 必要

AWS Organizationsを有効化すると、複数のAWSアカウントを一括管理することができる。それぞれのアカウントは、ルートを親として 組織単位 (OU)ごとに分類することができる。アカウントは、 管理アカウント (=ルート)と メンバーアカウント に分かれ、管理アカウントにはメンバーアカウントを管理するための様々な権限が付与される。AWS Organizationsの全ての機能を有効化することも、 一括請求機能のみを有効化 することもできる。各OUもしくはアカウント単位に、 サービスコントロールポリシー と呼ばれる各アカウントが持つ権限を明示したポリシーを適用することができる。 サービスコントロールポリシーとタグポリシーは、デフォルトでは無効化されている ので、利用する場合は有効化する。

ベストプラクティス

管理アカウントのベストプラクティス

管理アカウントにはSCPが適用されない ため CloudTrailだけを有効化 し、それ以外のAWSリソースは保有しない。また、管理アカウントのrootユーザのメールアドレスには、 マネージャーを宛先に含むグループメールを指定 する。このrootユーザの パスワードは長くて複雑なものを使用 し、 定期的に変更せずにその内容を金庫に保管、もしくはマネージャーが保管、パスワード管理ツールで保管 する。rootユーザは、MFAの使用を有効した上で、 そのアクセス方法とアクセスのログの記録方法を定める 。管理アカウントに登録する電話番号用に、 専用のSIMカードとデバイスを用意 し、こちらもそのアクセス方法とアクセスのログの記録方法を定める。アカウントへのアクセスや認証情報の 使用方法やリセット方法を定めた上で、定期的にレビュー を行う。

メンバーアカウントのベストプラクティス

メンバーアカウントのrootユーザにも、「グループメールアドレスの指定」「複雑なパスワードの使用」「MFAの有効化」を行う。また、 電話番号は管理アカウントと同一のものを指定 する。アカウントへのアクセスや認証情報の 使用方法やリセット方法を定めた上で、定期的にレビュー を行う。さらに SCPを使用して、メンバーアカウントのrootユーザが実行できることを制限 する。

組織とアカウント

組織

組織を作成する際に、全ての機能を有効化する(奨励)か、課金機能のみ有効化するかを選択することができる。全ての機能を有効化する場合には、各メンバーアカウントに、 AWSServiceRoleForOrganizations ロールが必要となる。また、全て機能を有効化した場合は、 課金機能のみの有効化に戻すことはできない

組織にアカウントを追加するには、

  • メンバーアカウントを新規で作成
  • 既存のAWSアカウントを招待

のいずれかを選ぶことができる。 組織を作成した際、管理アカウントに登録されているメールアドレス宛に確認のメールが送信される 。AWS Organizationsが持つことのできる管理アカウントは1つのみである。 管理アカウントはサービスコントロールポリシーの影響を受けない 。Organizationsを削除すると復元できず、またポリシーも削除される。削除する際には、 全てのメンバーアカウントを消去する必要 がある。

Organizationsに参加したメンバーアカウントでは、サービスコントロールポリシーやタグポリシーが即座に適用され、またサービスの信頼を有効化している場合は、そのサービスからメンバーアカウントに対してアクションを実行することが許可される。また、Organizations内で新規のメンバーアカウントを作成することもできる。

アカウント

メンバーアカウントを新規で作成した場合は、 ルートアカウントと AWSServiceRoleForOrganizations ロール、 OrganizationAccountAccessRole が作成 される。一方で、既存のAWSアカウントを招待した場合には、 AWSServiceRoleForOrganizations ロールのみが作成される。既存のAWSアカウントを招待した場合でも、運用の統一性を考慮して、 OrganizationAccountAccessRole ロールを作成することが望ましい。

新規でメンバーアカウントを作成すると、 アカウント名や電話番号などの情報が管理アカウントからコピー される。また、 rootアカウントのパスワードが自動作成されるが、これを取得することはできない 。このパスワードを取得するためには、パスワードの回復プロセスを実行する必要がある。

組織に属する アカウントの一覧はCSVファイルでエクスポートすることができる

メンバーアカウントを新規で作成した場合は、作成から7日以降に組織から削除することができる 。また、メンバーアカウントが組織を離れると全てのタグが削除される。アカウント自体を閉鎖する場合には、 rootユーザのパスワードを取得した上でアカウントの閉鎖処理を行う。

OU

OUは最大5レベルの深さまでネスト できる。OUは名前の変更、タグ付け、アカウントとの紐付け、削除が可能。

組織ポリシー

組織にはサービスポリシーと管理ポリシーが存在する。 ポリシーはルート, OU, アカウントに関連づけることができルートもしくはOUに紐づけられたポリシーは、そのOUもしくはその下にあるOUが継承 する。

ポリシーの継承

サービスポリシーの場合、フィルタのように振る舞うため、 上位のSCPにDeny構文があった場合、下位のSCPでそのサービスを許可することはできない 。拒否リストの場合は、まず全てのサービスが許可されていて、不要なサービスを明示的に拒否する。 拒否リスト戦略は、AWSのサービスが追加された場合でもメンテナンスが不要 である。 許可リストの場合は、デフォルトのFullAWSAccessを削除して暗黙的なDenyを適用 し、必要なサービスのみを許可したSCPをアタッチする。

How SCP Permissions Work

管理ポリシーの場合、構文内に 継承演算子 が含まれており、これに従った動作を行う。継承演算子には、 @@assign, @@append, @@remove が存在する。

サービスポリシー( SCP

サービスポリシーは、 最大で使用できるアクセスの権限を各アカウントに対して指定できる機能 。Organizationsの全ての機能を有効化した場合に使用できる。 メンバーアカウントのルートユーザにも適用されアカウントに与える影響が非常に大きいため、適用する際には詳細なテストが必要である。IAMのサービスアクティビティに表示される、各アカウントの最終アクセス時刻を参考にポリシーの内容を決定することが望ましい。

サービスポリシーは以下のタスクには影響しない。

  • 管理アカウント
  • Service-linked Role
  • ルートユーザの認証
  • サポートプランの変更
  • CloudFrontの一部機能

サービスポリシーは、IAMポリシーとほぼ同じ構文を使用する。 Principal, NotPrincipal, NotResource は使用できない。複数のポリシーが適用されている場合は、明示的なDenyがAllowよりも優先される。ポリシーの例は、 サービスコントロールポリシーの例 を参照のこと。

管理ポリシー

AIサービスのオプトアウトポリシー は、Amazon CodeGuru Profiler、Amazon Comprehend、Amazon Lex、Amazon Polly、Amazon Rekognition、Amazon Textract、Amazon Transcribe、Amazon TranslateなどのAIサービスで行われるサービス改善のためのコンテンツ保存のオプトアウトを設定できる。

バックアップポリシー は、AWS Backupを使用したバックアップのルール(バックアップの頻度、バックアップが発生する時間枠、バックアップするリソースを含むAWSリージョン、バックアップを保存するボールト)を指定できる。

タグポリシーは、タグキーおよびタグ値の大文字と小文字の処理方法の設定などを規定することができる。デフォルトでは、タグポリシーへのコンプライアンスの強制はされない。強制をサポートするAWSサービスは 強制をサポートするサービスとリソースタイプ を参照のこと。

参考リンク

AWS System Manager(1)System Managerの概要

AWS System Manager

AWS System Manager は、統合インタフェースでインフラを可視化し、EC2のみならず オンプレミス上のサーバ を含めたさまざまなリソース( マネージドインスタンス )を管理し表示することができる。これによりモニタリングやトラブルシューティング、リソースとアプリケーションの管理などを迅速に行うことができる。

これらのリソースは、リソースグループ と呼ばれるグループごとに分類でき、状態をダッシュボード上から俯瞰することができるため、アプリケーションに影響を当てる可能性のあるリソースをすばやく特定することができる。また、OSのパッチレベルやソフトウェアのインストール状況なども簡単に確認することができる。

また、インスタンスの停止や再起動などの 運用タスクの自動化 や、リモートからのパッチの適用や設定の変更などができるため、ヒューマンエラーや運用負荷の軽減を図ることが可能である。

なお、System Managerは、過去に Simple Systems Manager と呼ばれていたため、現在も略して SSMと呼称される。

AWS System Managerの機能

System Managerを用いることで、以下を行うことができる。

カテゴリ サービス名 内容
運用管理 Explorer 運用データ(OpsData)を集約して表示するダッシュボード
運用管理 OpsCenter 運用作業項目(OpsItems)の表示と調査
運用管理 CloudWatch Dashboards メトリクス の表示
運用管理 Trusted Advisor & Personal Health Dashboard (PHD) プロビジョニングとヘルスイベントの表示
アプリケーション管理 Resource Groups AWSリソースの グループ化
アプリケーション管理 AWS AppConfig アプリケーション設定 を作成、管理、迅速にデプロイ
アプリケーション管理 Parameter Store 設定データ 管理と 機密管理 のための安全な階層型ストレージ
アクションと変更 Automation メンテナンスとデプロイの自動化
アクションと変更 Maintenance Window タスクのスケジュール を設定
インスタンスとノード 設定コンプライアンス パッチと設定の不一致を確認
インスタンスとノード インベントリ ソフトウェア インベントリの収集
インスタンスとノード マネージドインスタンス インスタンスの セットアップ
インスタンスとノード アクティベーション オンプレミス上のノードの承認
インスタンスとノード Session Manager ブラウザベースの シェルでアクセス
インスタンスとノード Run Command リモートから コマンドを実行
インスタンスとノード State Manager インスタンスを 定義された状態 に保つ
インスタンスとノード Patch Manager パッチ の適用
インスタンスとノード Distributor パッケージの作成
共有リソース ドキュメント Systems Manager が実行する アクションを定義

SSM Agent

SSM Agentは、EC2オンプレミスサーバ にインストールすることのできるソフトウェアで、System Managerはこのソフトウェアを介して、これらのリソースの更新や管理、設定を行うことができる。 EC2上で提供されているWindows ServerやAmazon Linux、 Ubuntu ServerのAMIには、あらかじめSSM AgentがインストールされているSystems Manager エンドポイントとの間でHTTPS通信を確立する必要があり、HTTP Proxy経由で通信する設定にすることもできる。なお、このエージェントの動作ログは以下の場所に格納されている。

  • /var/log/amazon/ssm/amazon-ssm-agent.log
  • /var/log/amazon/ssm/errors.log

SSM Agentの実行にはroot権限が付与 されていることから、このSSM Agentを用いて SendCommand や StartSession コマンドを行うことが可能なAWS上のIAM ユーザ等の管理や権限付与には注意する必要がある。SSM Agentをリリースのたびに更新し最新のバージョンを保持するためには、マネージメントコンソール上のマネージメントインスタンスのページから、Agent auto update (エージェントの自動更新)を選択する。

運用管理

Explorer

Explorerは、AWSリソースの情報を表示するダッシュボード。AWSアカウント全体もしくは当該リージョンの Amazon EC2Systems Manager OpsCenterSystems Manager Patch Manager などから運用データを取得し、これを一覧で確認することができる。

Explorerでは、 タグで情報をフィルタリング したり、 リソースデータの同期 機能を用いて、 複数のアカウントの情報を横断的に閲覧する こともできる。

OpsCenter

OpsCenterは、運用データを表示・調査・解決するための場所である。これを用いることで、各事象に対して迅速な対応が可能。

アプリケーション管理

Parameter Store

パラメータストアは、設定データ 管理と 機密管理 のための安全な階層型ストレージを提供し、パスワードや認証情報などを安全に保存できる。これらの情報には、作成時に定義した一意の名前を用いてアクセスできる。また、以下のAWSサービスと接続し、パラメータストアの情報を提供する。

  • Amazon Elastic Compute Cloud (Amazon EC2)
  • Amazon Elastic Container Service (Amazon ECS)
  • AWS Lambda
  • AWS CloudFormation
  • AWS CodeBuild
  • AWS CodeDeploy

パラメータストアは、 StringString List ,、Secure String をサポートしている。Secure Stringは、KMS-CMK (カスタマーマスターキー)を用いて暗号化される。また、パラメータには、デフォルトパラメータと アドバンストパラメータ が用意されている。前者から後者への移行は可能であるが、 その逆はできない 。アドバンスパラメータは、許可される パラメータ数やデータサイズが緩和 され、かつ パラメータポリシーが規定できる課金 される。

パラメータは 階層状 に管理できる。階層構造にすることで管理がしやすく、また 同一階層のデータを一括して取得することもできる 。パラメータポリシーを付加することで、 有効期限や失効期限 などを定めることができる。

パラメータにはタグを付与できる。また、更新されるたびに バージョン がインクリメントされる。パラメータラベル と呼ばれるエイリアスを指定することもできる。

AWSが提供しているパブリックパラメータを使うことで、AMIやリージョンの最新の情報を取得できる。

インスタンスとノード

コンプライアンス

コンプライアンスは、マネージドインスタンスをスキャンして、パッチコンプライアンスと設定の不一致を確認することができる 。具体的には、Patch Manager によるパッチ適用State Manager による Association に関するコンプライアンスデータ が表示される。また、 設定変更履歴をConfigから取得 したり、コンプライアンスをカスタマイズして 独自のルールを作成 したり、Run Command や State Manager を使って問題を修復 できる。

Resource Data Sync を用いることで、全てのマネージドインスタンスからのコンプライアンスをS3に蓄積/集約することができる。これらのデータは、Amazon Athena および Amazon QuickSight で可視化することもできる。データを蓄積するS3には、System Managerからのデータ書き込みを許可する Bucket Policy の作成が必要

インベントリ

インベントリを使用することで、 マネージドインスタンスからメタデータを収集 することができる。収集できるメタデータは、以下の通り。

カテゴリ 内容
アプリケーション アプリケーション名、発行元、バージョンなど
AWS コンポーネント EC2 ドライバ、エージェント、バージョンなど
ファイル 名前、サイズ、バージョン、インストール日、変更および最新アクセス時間など
ネットワーク設定の詳細 IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスクなど
Windows 更新 Hotfix ID、インストール者、インストール日など
インスタンスの詳細 システム名、オペレーティングシステム (OS) 名、OS バージョン、最終起動、DNS、ドメイン、ワークグループ、OS アーキテクチャなど
サービス 名前、表示名、ステータス、依存サービス、サービスのタイプ、起動タイプなど
タグ インスタンスに割り当てられるタグ
Windows レジストリ レジストリキーのパス、値の名前、値タイプおよび値
Windows ロール 名前、表示名、パス、機能タイプ、インストール日など
カスタムインベントリ カスタムインベントリの操作 に説明されるようにマネージドインスタンスに割り当てられたメタデータ

これらのデータも、上述の Resource Data Sync でS3に保存することができる。インベントリのセットアップは、SSMドキュメントの AWS-GatherSoftwareInventory を Association で実行することによって実現できる。

Run Command

Run Commandを使用することで、マネージドインスタンスにログインすることなく安全に、管理タスクを実行することができる。Run Commandを実行するためには、コマンドを発行するIAM ユーザに実行権限を付与する必要がある。また、対象のインスタンスに対しても、 IAMインスタンスプロファイルを作成して適用する 必要がある。

State Manager

State Managerは、EC2等を定義された状態に保つプロセスの自動化を行う。例えば、起動時に特定のソフトウェアをインストールする、ネットワークを構成する、ソフトウェアの更新を行うなどのタスクを行う。

Patch Manager

Patch Managerは、セキュリティ関連などのパッチをマネージドインスタンスに対して適用するプロセスの自動化を行う。 ベースライン と呼ばれるパッチの適用ルールには、 リリースから数日以内に自動承認されるルール と、 承認済みおよび拒否済みパッチのリスト が含まれている。サポートされるOSは、 パッチマネージャーの前提条件 を参照のこと。各OSには、パッチ適用用のリポジトリが用意されており、これを指定するか、 代替パッチソースリポジトリ を指定することもできる。

AWSによってあらかじめ用意されている定義済みパッチベースラインの場合、

  • 「セキュリティ」タイプで重要度レベルが「非常事態」または「重要」のすべてのOSパッチを7日後に自動承認する
  • 「Bugfix」タイプのパッチをリリースから7日後に自動承認する

などのルールが事前に定められている。これらのパッチを適用する対象のインスタンスをグループ化するために、 パッチグループ を作成することができる。パッチグループは、 1 つのパッチベースラインにのみ登録できる。また、SSMドキュメントの AWS-RunPatchBaseline を適用する際に、対象のインスタンス等を指定することもできる。 パッチが適用されるとインスタンスは再起動される

SSMドキュメント

SSMドキュメントは、マネージドインスタンスで実行するアクションを定義するスクリプト。SSMドキュメントには、以下のタイプが用意されている。使用可能なスキーマバージョンやフォーマット等が定められているため、利用する際には ドキュメントを参照のこと。AWSが提供する Automation ドキュメントの名称や挙動は、Systems Manager Automation ドキュメントの詳細リファレンスを参照する。また、公式ドキュメントは存在しないが、AWSが提供する Command ドキュメントも多数存在する。

タイプ 内容 Schema Run Command State Manager Automation Maintenance Window Distributor Session Manager Change Calendaer
Command 設定の適用 1.2, 2.0, 2.2
Automation タスクの実行 0.3
Package ソフトウェア
Session セッションの定義
Policy AWS-GatherSoftwareInventory を使用したインベントリデータの取得 2.0-
Change Calendaer カレンダーエントリ