AWS 運用におけるベストプラクティスが学べる【Cloud Operations on AWS】を受講してみた

こんにちは、AWS事業本部オペレーション部の清水です。

AWS Certified SysOps Administrator - Associate 認定を取得するべく、「Cloud Operations on AWS」を受講してきました。

今回のトレーニングはドライランになり、試験的にまず社内向けに実施されました。今後は一般の皆様向けにご提供されるコースになります。

本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、まだドライランのためこちらの図には載っておりません。（多分、今後掲載されるはずです）

前提条件

• AWS Technical Essentials コースの修了
• ソフトウェア開発またはシステム管理の経験
• コマンドラインでオペレーティングシステムを管理する能力 (Linux 環境でのシェルスクリプト、Windows での cmd/PowerShell など)
• ネットワークプロトコル (TCP/IP、HTTP) に関する基礎知識

１日目

モジュール１：Cloud Operations on AWS の紹介

「運用」＝？

• リリース後 - クローズまでの期間を、「運用期間」と呼ぶ
• ユーザーにシステムを提供している期間

運用の目的

• システムを安定させ、かつ効率よく提供し続ける事
• "運用の目的"を達成するために、必要な作業全般が「運用」

このコースの歩み方

• 運用の目的と各種キーワードを照らし合わせながら、運用に対する意識付けや具体的な手段を学ぶ
• 運用の目的 x アクセス管理、デプロイ・・・

運用上の優秀性のベストプラクティス

• 準備
  • 何のために運用をやるのか
• 運用
  • モニタリング
  • 予期しない事象への対応
• 進化
  • 発生したイベントから、進化させていく

モジュール２：アクセス管理

認証

～ 誰がAWSにサインインしてるか（社員証みたいなもの）～

プリンシパル（AWSに操作を行う元）

1. IAMユーザー
2. IAMロール
   1. PassRole：プリンシパルが AWS サービスに IAM ロールを渡すための権限
   2. AssumeRole ：IAM ロールを引き受ける
3. アプリケーション
4. フェデレーテッドユーザー

認可

～ どんなリクエストを実行できるか（オフィスには入れるけど、この部屋にはこの人は入れない）～

1. 必要なアクションのみ許可
2. 必要なリソースへのアクセスのみ許可

ポリシーエレメント

• Effect
  • Allow、Denyの設定
• Action
  • 何を許可するのか（Start、Stopインスタンス等）
• Resource
  • 対象の設定（IDがXXXXのサーバー等）

IAM のベストプラクティス

• AWS管理ポリシーを利用する（一般的なユースケースに合わせた定義済みポリシー）
• MFAの使用
• 認証情報の定期的なローテーション
• 不要な認証情報を削除
  • 認証情報レポートを使って定期的に、棚卸をしよう

AWS Organizations と SCP

1. 複数のAWSアカウント間で一元化されたアカウント管理と監査
2. グループベースのアカウント管理
3. AWS のサービスへのポリシーベースのアクセス
   1. 管理アカウント・ルート
   2. 組織単位（OU)
4. アカウントの自動作成、管理

モジュール３：システム検出

AWS リソースを操作

1. マネジメントコンソール
2. AWS CLI
   1. アクセスキー
   2. シークレットアクセスキー
   3. IAMロールを使ってリスクを下げることが出来る
3. SDK

＞＞EC２自体の作成は、上記の３つのツールで可能！では作成したサーバーへの接続は？

AWS Systems Manager Session Manager

• ブラウザ上から、直接EC2に接続が出来る
• 使うためには？
  • Session Managerエンドポイントに通信が出来る事
    1. インターネットに対する経路
    2. プライベートリンクの経路

• セキュリティ上の利点
  • 一元化されたアクセスコントロール（IAMポリシー）
  • 踏み台ホストがいらない
  • アクティビティのログ記録と監査

AWS Config

設定

1. 変更管理
2. コンプライアンス

※アカウント作成されたばかりでは、設定されていない。自分で設定をする必要がある。

ルール

1. マネージドルール
2. カスタムルール

※推奨としては、なるべくすべてのリソースを記録すること。ただし記録するリソースが増えれば触れるほど、コストもかかってしまう。また変更が発生すればするほど、コストが嵩んでしまっていたが、この対策として昨年「定期的な記録のサポート」が出来るようにUPDATEがあった。

AWS Systems Manager

• OSの中の情報を、インベントリ機能を使って集約して確認することが出来る
  • わざわざサーバーに入って情報を確認しなくても、コンソール上で確認が出来る！便利！
• AWS Configとの違い：AWS ConfigはOSの中の情報は見れない。あくまでAWSサービスに関する情報だけ

ラボ１：AWS Systems Manager と AWS Config を使って AWS リソースを監査する

1. AWS インフラストラクチャ用に AWS Systems Manager をセットアップ
2. AWS Systems Manager Session Manager を使用して、Amazon EC2 インスタンスに安全にログイン
3. AWS インフラストラクチャ用に AWS Config をセットアップ
4. AWS Config を使用して、組織レベルのコンプライアンスについて AWS リソースを監査
5. AWS Systems Manager インベントリを使用して、マネージドインスタンスのメタデータを表示

モジュール４：リソースのデプロイと更新

タグとは

• メタデータをリソースに割り当て
• コスト配分タグ
• リソースグループ

タグ付け戦略

1. 何のためにタグを利用するのか、どんなタグが必要なのか目的を定義
2. タグの命名規則などルールを決める
   1. 大文字と小文字で区別されるのがポイント！
   2. 日本語は避ける、英数字推奨
3. 実際にタグをつけるための設計、実装
4. タグの運用と評価、改善

タグ付けを自動化するツール

1. AWS CloudFormation
2. AWS Service Catalog
3. IAM ポリシー
4. AWS Organizations タグポリシー

AMI

• EC2 Image Builderを使うと効率的に作成できる
  • テストまでカバーしているところがポイント

AWS Control Tower

• ランディングゾーン
  • ベストなマルチアカウント環境
• コントロール
  • ConfigやSCPを人の手で沢山作って配布しなくていい 、Control Towerにお任せ！
    • 予防：SCP
    • 検出：AWS Config

モジュール５：リソースデプロイの自動化

Infrastructure as Code (IaC)

• コードを使用して、インフラのデプロイや管理を行う
• インフラをコードで管理することによってメリットが生まれる
  • メリットは勿論あるが、デメリットもある

AWS CloudFormation

• テンプレート
  • JSON
  • YAML
• Application Composerを使って視覚的に、テンプレートを作成できるようになった！
• スタック

テンプレート構造

• Resources
  • 何を作るのか
• Parameters
  • 設定値をカスタム値を渡すために使用
• Outputs
  • スタックから値を返すために使用
• Mappings
  • キー毎に保存した名前と値のペアを含める
  • !FindInMapを使用して、保存した値を返す

AWS Service Catalog

• 管理者が設計したCloudFormationテンプレートを、現場ユーザーが改変しないようにする
  • 元のテンプレートは、ユーザーに触らせない
• 誰がこの製品を使って、製品を起動できるかアクセス権限も設定できる

ラボ２：コードとしてのインフラストラクチャ

1. Application Composer を使用して、デプロイ済みの CloudFormation テンプレートを更新
2. リソースグループを作成し、インフラストラクチャアセットの追跡タグを追加
3. AWS CloudFormation ドリフト検出機能を使用して、現在の設定と定義済みテンプレートの設定の違いを特定

２日目

モジュール９：システム正常性のモニタリングと維持

Amazon CloudWatch の概要

～自前だと監視サーバーを構築して、様々な管理業務が発生していた！～

メトリクス（AWS名前空間）

• デフォルト
  •  各サービスの情報を勝手にCloudWatchメトリクスに集約してくれる
  • 基本は５分間隔、無料利用枠
• カスタムメトリクス
  • デフォルトで集約されないものは、カスタムメトリクスを使って集約できる
  • 詳細モニタリングは１分単位、追加料金が発生
  • EC2の台数の調整をしたいときなど、AutoScallingのモニタリングの時に使ったりする場合がある
  • EC2そのものの情報ではなく、EC2内のOSの情報を収集したい場合、カスタムメトリクスを使う

AWS CloudWatch Agent

• 動的に変化するメモリ使用率、ディスク使用率など、動的な情報が収集できる
• OSにインストールされてる静的な情報などは、Systems Manager（インベントリ情報）のほうからとれる

保持期間

• 最大で15か月間

AWS CloudWatch Logs

1. 設定
2. 収集（S3にアップロード）
3. 分析

AWS CloudWatch アラーム

1. メトリクスを特定
2. 条件を定義
3. 通知を設定
4. アクションを定義

AWS CloudWatch イベント

AWS EventBridge

1. イベントパターンを指定
   1. 例）CloudWatch Alarm にてアラーム発生時のイベントから、イベントパターンに一致していれば EventBridge の処理対象にする
2. ターゲットを指定

AWS CloudWatch ダッシュボード

• メトリクス、ログ、アラームでダッシュボードを作成できる
• ダッシュボードは存在しているだけで、課金対象になるので注意
  • CloudWatch Resource Healthといった機能も出来た

AWS CloudWatch インターネットモニター

• 2022年に発表された機能
• AWSに到達する前に、インターネット上の問題が、アプリケーションに影響を与えているかどうか確認が出来る
  • 例）20時間前に、東京でXXXのネットワークに問題があった

AWS Health Dashboard

• AWS そのものが、現状障害がおきていないか確認が出来る

AWS X-Ray

• アプリケーション全体に対するモニタリング
• クライアント⇔フロントエンド→API→DynamoDB

モジュール６：リソースの管理

AWS Systems Manager

～サーバーの管理、タスクをサポートする～

• オペレーション管理
  • Explorer（運用に関するリソース状態を俯瞰するもの）
    • EC2インスタンスメタデータ
    • パッチコンプライアンス
  • OpsCenter（日々発生する運用項目の確認、対応を進めるための場所）
    • OpsItemsの詳細確認
  • IncidentManager（インシデントの軽減と回復を支援する）

• アプリケーション管理
  • AppConfig
    • 柔軟なパラメータデプロイ機能
    • APIコール等に応じた課金
  • パラメーターストア
    • 変更がないような静的なパラメータ向け
    • 基本は無料、一部オプション利用時に課金

• 変更管理
  • オートメーション
    • サーバーの隔離をするなど、インシデントが発生した時などに使ったりする
  • メンテナンスウィンドウ

• ノード管理
  • パッチマネージャー
  • パッチポリシー

ラボ３：コードとしての運用

1. AWS Systems Manager の出力ログを記録する CloudWatch ロググループを作成
2. AWS Systems Manager サービスを利用して、コマンドドキュメントを作成して実行
3. AWS Systems Manager サービスを利用して、オートメーションドキュメントを検索して実行
4. ログストリーム検査を通じて、環境内に加えられた変更を監査

モジュール７：高可用性システムの構成

AWS Route53

• 複数のリージョンにトラフィックを分散できる
• DNSレコードの登録
• Route53を利用した複数ELBへの負荷分散
  • ルーティングポリシーがある

モジュール８：スケーリングの自動化

EC2 Auto Scaling

• インスタンスの台数を自動的に増減！
• 設定した希望容量の維持

スケーリングポリシー

• スケジュールに基づくスケーリング
• 動的スケーリング
  • 簡易スケーリング（今はあまり、利用する機会がない）
  • ステップスケーリング（しきい値を、ユーザー側で指定する必要がある）
  • ターゲット追跡（AWSが推奨している、しきい値をユーザー側が指定しなくていい、需要の変化の波が想定できないため）
• 予測スケーリング
  • スケールアウトにしか対応していない！

スポットインスタンス

• スポットフリート（ターゲット容量を設定）

ライセンスマネージャー

• 指定したライセンスのルールにのっとって、スケーリングが可能

ラボ４：アプリケーションとインフラストラクチャをモニタリングする

1. Amazon CloudWatch エージェント、AWS Sessions Manager、コマンドドキュメント、Parameter Store を使用して、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでテレメトリを設定
2. CloudWatch ダッシュボードを作成して、CloudWatch エージェントのメトリクスを表示
3. 自動通知のために Amazon Simple Notification Service (Amazon SNS) トピックをサブスクライブ
4. 特定のメトリクスのしきい値を超えたときのモニタリングと通知のために CloudWatch アラームを設定
5. AWS Command Line Interface (AWS CLI) を使用して、AWS 環境内の任意の CloudWatch アラームを手動でテスト
6. ウェブサーバー用の AWS Lambda ベースの Canary アラームを作成

３日目

モジュール１０：データセキュリティとシステム監査

IAM Access Analyzer

• 複数のAWSサービスに対して、アクセス権限をチェック、評価してくれるサービス
• 無料で利用できるので、有効化しておくのがオススメ
  • 外部や他のAWSアカウントから、自分たちのAWSアカウントへアクセスされていないかどうか

ポリシーの評価

• AWSでは、強いポリシーの作成と特定リソースへのアタッチで権限昇格ができてしまう
  • Permission Boundary（権限昇格を防ぐ）

AWS CloudTrail

• AWS上のAPIコールを記録する
• 誰が・いつ・どこから・どんな方法で・何をしたか、イベントを確認できる
  • 特定のインスタンスをシャットダウンしたユーザー
  • セキュリティグループの設定を変更したユーザー
  • アクセス権がないため拒否されたアクティビティ

Amazon Athena

• ログ分析
• S3に貯めたログデータを、SQLで分析できる

Amazon GuardDuty

• AWS上のサービスへの設定に関する攻撃の検出
• ネットワーク、DNSログなど人の目で気づきにくい脅威が発見されたら検出してくれる
  • デフォルトでは有効化されていない
  • リージョン毎の設定になっている

Amazon Inspector

• AWSサービス上に使われているガジェットへの、脆弱性が潜んでいないか検出
• 例）EC2インスタンスの中で動いてるAPPなどで、脆弱性が潜んでないか等
  • SSM Agentが入っていれば、自動でInspector v2も動くようになった
  • 脆弱性の検出と対策の提案をしてくれる

モジュール１１：安全性と耐障害性に優れたネットワーク運用

【VPC内部】

Amazon VPC

• インターネットと通信させたい：パブリックサブネット
• インターネットと通信させたくない：プライベートサブネット
  • サーバー → 外部のインターネットだけ通信させたい：ルートテーブル・NATゲートウェイを使う
• セキュリティグループ
• VPCピアリング
  • VPC同士を結んで、接続できる
  • 同じVPC上に、複数のシステムを同居させるとセキュリティや設定管理上のリスクが生じるため、システムごとに、VPCを分割
• AWS Transit Gateway
  • 複数のVPCとオンプレミスのネットワークを接続可能にする
  • 大規模ネットワーク管理の場合、ピアリング接続は非効率になるのを解消する
  • ネットワークのハブのような感じ

【VPC外部】

AWS CloudFront

• エッジロケーション：AWSネットワークの境目に配置
  • コンテンツ取得のレイテンシーの向上
  • コンテンツを、わざわざAWS上にあるS3まで取りに行ったりしなくてもいい
• オリジン（コンテンツの置き場所）を決めたら、ビヘイビア設定（キャッシュの動作）を行う

AWS WAF

• 怪しい通信を検出して、ブロックする
• カウントモードの活用
  • 実際には動かない状態でWAFルールを適用して、本番環境へ適用前に意図せぬシステム影響を把握する

AWS Certificate Manager

• SSL/TLS証明書を取得・管理・サービスに適用

モジュール１２：マウント可能なストレージ

Amazon EBS

• ソリッドステートドライブ（SSD)
  • 複数の回数に分けて、データを読みに行くのが得意
  • 汎用SSD
    • gp2
    • gp3：gp2より新しい世代
  • プロビジョンドIPOS SSD
    • gp2やgp3よりもっとパフォーマンスが必要な時
• ハードディスクドライブ（HDD)
  • 一回で大量のデータを読みに行くのが得意
  • スループット最適化 HDD
  • コールド HDD

スナップショット

• １つのAZに障害が起きた場合、EBSのデータ損失を防ぐ
• 見えないS3バケットに、スナップショットが保存される
• AWS Backupを使用して、スナップショットを自動化できる

EC2インスタンスストア

• EBS同様、EC2から起動できるストレージ
• EBSより高パフォーマンス
• 一時データ（キャッシュなど）

Amazon EFS

• 複数のサーバー、コンピューティングリソースから参照できるファイルシステム

Amazon FSx

• 広く使用されている4つのファイルシステムをサポート

1. FSx for Windows ファイルサーバー
2. NetApp ONTAP
3. FSx for OpenZFS
4. FSc for Lustre

ラボ５：アーカイブとデータ復旧のためのデータスナップショットの自動化

1. 既存の Amazon Simple Notification Service (Amazon SNS) トピックをサブスクライブ
2. AWS Backup でバックアッププランを作成する方法を説明
3. バックアップボールトの概要、AWS Backup でバックアップボールトを作成する方法を説明
4. Amazon Elastic Block Store (Amazon EBS) ボリュームのオンデマンドバックアップジョブを作成
5. バックアップの作成後に Lambda 関数を使用して復元ジョブを開始し、ボールトにあるバックアップをテスト
6. AWS CloudWatch のログを調べる

モジュール１3：オブジェクトストレージ

Amazon S3

• 耐久性（99.999999999％）、可用性が高い
  • 置いておいたデータが壊れる心配はしなくていい
• レプリケーション
  • 同じリージョン内でも、複数アカウントのデータ集約が必要な要件の場合
  • リージョン毎全部潰れてしまう最悪ケースを考えた場合、他リージョンにレプリケーションが必要な要件の場合
• バージョニング
• オブジェクトロック
  • コンプライアンスモード：保持期間は誰も触れないようにロック
  • ガバナンスモード：特定の権限を持っているユーザーのみ、保持期間内にデータ更新や削除が可能
• ブロックパブリックアクセス
  • 基本的に有効化にしておくのが良い
    • S3バケットの直接のアクセスは防ぎつつ、CloudFrontを利用してコンテンツを配信する
  • S3バケットに設定
  • アクセスポイントに設定
  • アカウントに対して設定
• ストレージクラス
  • Intelligent-Tiering
    • アクセスパターンが読めない時に使う
    • 利用にはコストがかかる
    • 各オブジェクトのアクセスパターンに応じて、各オブジェクトのストレージクラスを変更
  • Express One Zone
    • １つのAZのみでデータが保管
    • S3に対するデータアクセスのパフォーマンスの向上（データ分析、機械学習など）
    • データの損失のリスク、耐久性は考える必要がある

モジュール１４：コストのレポート、アラート、最適化

状況把握

• 請求ダッシュボード
  • 支出の概要を、ウィジェットから把握
• 請求書
  • 見積り：メールで毎月送られてくる
  • コンソール上でも、同じ内容を確認することが出来る
• Cost Explorer
  • コストの情報をより細かく分析できる
• Cost and Usage Report（CUR)
  • この4つの中で最も細かいデータを確認することが出来る
  • 自分たちで設定が必要
  • レポートが定期的にS3に出力される → AthenaやQuickSightで分析

コスト管理メカニズム

• AWS Budgets
  • 予算を設定しておいて、超えたもしくは超えることが予想されると、アラートを発動
    • 予算を超えると、事前に設定しておいたIAMポリシー（これ以上新しい操作をできないように権限を調整する）を適用
    • 予算を超えると、EC2、RDSをストップする
• CloudWatch 請求アラーム
• コスト異常検出
  • 過去1週間で、10ドルしか使っていなかったサービスが、50ドルに跳ね上がっている等

AWS Compute Optimizer

• 無料で利用が可能
• コスト最適化のために、レコメンドをもらえる
  • Lambda関数でも、メモリ割り当て過ぎじゃない？
  • リソース無駄になっているよ等

ラボ６：CloudOps の最終ラボ

1. Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を使用してモニタリングと通知のソリューションを作成
2. AWS Config ルールを使用して、コンプライアンスに違反している設定を検出
3. AWS Config と AWS Systems Manager のドキュメント (SSM ドキュメント) を使用して、コンプライアンスの問題を修正
4. AWS CloudFormation のドリフト検出を使用して、ネットワーク設定の変更を特定

おわりに

このトレーニングでは、ラボの時間よりも座学が多めの内容になっており、感覚的に7割くらいが座学です。

前提条件を把握している前提で進むため、AWS初学者の場合、先にSAAの資格取得やそれに付随するトレーニングを受けておくのがオススメです。

普段から、AWSサービスを満遍なく触っている運用担当者には、運用の目的について改めて考え、「システムを効率よく提供する」ためのAWSサービス各種を学べますので、業務でも活かせる知識を学べるかと思います。

この記事がどなたかのお役に立てば幸いです。