【AWS SOA】AWSサービスまとめ
AWS SOA（AWS Certified SysOps Administrator – Associate）の受験対策としてAWS学習中に学んだことを書き残していきます！
AWS SOAで重要なサービスを中心にメモしていきます！※随時更新予定
【分野1】モニタリング、ロギング、および修復
AWS CloudWatch
CloudWatchとはAWSリソースとAWSで実行されているアプリケーションをリアルタイムでモニタリング監視できるマネージドのAWSサービス。
AWSリソースを利用したシステムの稼働状況やAWSリソースのステータス状況を監視する際に利用される。
Amazon CloudWatch の仕組みより画像引用
CloudWatch メトリクス
CloudWatchはメトリクス（リソースのデータセット、システムのパフォーマンスに関するデータ）を収集し、リソースの状況を監視できる。メトリクスは標準メトリクスとカスタムメトリクスの2種類がある。
標準メトリクスは各AWSリソースからCloudWatchにデフォルトで送信されるメトリクス（データ）を取得するために利用される。例えば、EC2の場合、インスタンスのCPU使用率やディスクIOなどが標準メトリクスで自動収集されている。
一方、カスタムメトリクスは標準メトリクスで取得されていないメトリクス（データ）を取得するために利用される。例えば、EC2の場合、インスタンスのメモリ使用率、ウェブページのロードに要する時間、リクエストエラー率などがカスタムメトリクスでのみ収集可能。
カスタムメトリクスを使用するには、PutMetricData API を使用する。カスタムメトリクスを使用すると、1分未満の高解像度のメトリクスを取得が可能になるが、料金が高額になり、解像度によりメトリクスの保持期間が異なる点が注意。15ヶ月が経過するとメトリクスは自動的に削除される。
| メトリクスの解像度 | 保持期間 |
|---|---|
| 1分未満 | 3時間 |
| 1分以上 | 15日間 |
| 5分以上 | 63日間 |
| 1時間以上 | 15ヶ月 |
CloudWatchはAuto Scalingグループ内のEC2インスタンス全体の統計を集計できる。「AutoScalingGroupName」と「メトリクス」（CPU使用率やディスクに書き込まれた総バイト数など）を指定すれば、Auto Scalingグループ内の全体監視が可能。CloudWatchはAWSリージョンをまたがってデータを集約できない。
【参考】Amazon CloudWatch のよくある質問
【参考】Amazon CloudWatch の概念
【参考】Auto Scaling グループ別に統計を集計する
CloudWatch モニタリング
CloudWatchのモニタリング（監視）間隔として、基本モニタリングと詳細モニタリングがある。特にEC2の場合が問われる感じ。
基本モニタリングは、デフォルトであり、メトリクスの取得間隔として5分で、無料。
一方、詳細モニタリングは、有効化すると、メトリクスの取得間隔が1分でより詳細なメトリクスデータを取得・表示できるようになるが、追加料金がかかる。
CloudWatchを使用してAmazon DynamoDBをモニタリングすることで、DynamoDB からrawデータを収集し、リアルタイムに近い読み込み可能なメトリクスに加工できる。デフォルトでは、DynamoDBメトリクスデータはCloudWatchに自動的に送信される。
【参考】基本モニタリングと詳細モニタリング
【参考】インスタンスの詳細モニタリングを有効または無効にする
【参考】Amazon CloudWatch でのモニタリング
CloudWatch アラーム
CloudWatchアラームで、CloudWatchのメトリクスやログをもとに、一定の期間に特定のしきい値を超える場合にメール送信（Amazon SNS）などでアラームの通知ができる。
メトリクスアラームと複合アラームにわけられる。
メトリクスアラームは、1つのCloudWatchメトリクスを監視、または複数の CloudWatchメトリクスに基づく数式の結果を監視する。メトリクスやメトリクスに基づく数式の結果に基づいて、1つ以上のアクションを実行できる。例えば、Amazon SNS トピックに通知を送信したり、Amazon EC2 アクションまたは Amazon EC2 Auto Scaling アクションを実行できる。
一方、複合アラームは別途作成した他のアラームのアラーム状態を考慮したルール式を含めて監視する。複合アラームは、ルールのすべての条件が満たされた場合に限り、ALARM 状態になる。複合アラームの場合、状態が変更されたときにAmazon SNS 通知を送信できるが、ALARM 状態になったときにEC2アクションまたはAuto Scalingアクションを実行できない。
| メトリクスアラーム状態 | 内容 |
|---|---|
| OK | メトリクスや式は、定義されているしきい値の範囲内 |
| ALARM | メトリクスまたは式が、定義されているしきい値を超えている |
| INSUFFICIENT_DATA | アラームが開始直後であるか、メトリクスが利用できないか、メトリクス用のデータが不足しているため、アラームの状態を判定できない状態 |
アラームの動作をテストするには、SetAlarmState API アクションまたは AWS CLI の set-alarm-state コマンドが便利。特定のEC2インスタンスのCPU使用率が80％になったらSNSで管理者に通知するなどのテストが事前にできる。
【参考】Amazon CloudWatch でのアラームの使用
統合 CloudWatch エージェント
オンプレミスサーバやEC2インスタンスに統合CloudWatchエージェントをインストールすることで、メトリクスを収集できる。
CloudWatchエージェントをインストールする一般的な手順は以下の通り
IAMロール「CloudWatchAgentServerPolicy」、または、プロファイル設定を適用することが重要。
- IAM ロールまたはユーザーを作成
- エージェントパッケージをダウンロード
- CloudWatch エージェント設定ファイルを変更して、収集するメトリクスを指定
- EC2 インスタンスにエージェントをインストールする場合、ステップ 1 で作成した IAM ロールをアタッチ
- サーバーにエージェントをインストールして起動
- オンプレミスサーバー上にエージェントをインストールした場合、ステップ 1 で作成した IAM ユーザーの認証情報を含む名前付きプロファイルを指定
CloudWatchエージェント（EC2）から収集するメトリクスを特定のリージョンに送信する場合は、CloudWatchエージェント設定ファイルのAgentセクションで「region」の設定をする必要がある。オンプレミスサーバーをモニタリングしている場合、このフィールドは使用されず、CloudWatchエージェントは「AmazonCloudWatchAgent」設定ファイルのAWSプロファイルからリージョンを読み取る。
【参考】CloudWatch エージェントのインストール
【参考】CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する
【参考】CloudWatch エージェント設定ファイルを手動で作成または編集する
CloudWatch Logs
CloudWatch LogsはAWSリソースとAWSで実行されているアプリケーションのログファイルを一元的にまとめて監視、保存、アクセスができるサービス。
メトリクスフィルタを作成することで、定義したフィルタパターンにあったログイベントを検索し、件数を数えて、その結果をメトリクスとして記録できます。ログデータを数値の CloudWatchメトリクスに変換し、グラフを作成したり、アラームを設定できる。
さらに、専用のクエリ言語を利用して、CloudWatch Logsに収集したログデータを検索し分析することができるCloudWatch Logs Insightsを利用すると便利。
問題が発生した場合、CloudWatch Logs Insightsを使用して、潜在的な原因を特定し、デプロイされた修正を検証できたりする。
【参考】Amazon CloudWatch Logs とは
【参考】フィルターを使用したログイベントからのメトリクスの作成
【参考】CloudWatch Logs Insights を使用したログデータの分析
Amazon EventBridge（旧 CloudWatch Events ）
Amazon EventBridgeとは、AWSリソースを変更するシステムイベントをトリガーとして、別のAWSサービスによるアクションの実行を自動化できるサーバレスサービス。
要はAWSサービスでなにかおこったら（イベント）、別のAWSサービス（ターゲット）で対処アクションを行うための橋渡しをするサービス。
イベントの具体例は以下
- インスタンスの状態が保留中から実行中に変更されると、Amazon EC2 がイベントを生成
- Amazon EC2 Auto Scaling が、インスタンスを起動または終了するときにイベントを生成
- AWS CloudTrail が、API コールを行ったときにイベントを発行
イベントとアクションの具体例は以下
- Auto Scalingグループが Amazon EC2 インスタンスを起動または終了するたびにイベントをログに記録し、そのイベントが成功したかどうかをログに記録する AWS Lambda 関数を実行
- EC2で新しいインスタンスが起動する度にログに記録するLambda関数を実行
- Amazon S3オブジェクトが作成されたときにAmazon SNSで通知を送信する
EventBridgeでターゲット先にイベントが配信できない場合、再試行ポリシーとデッドレターキュー（DLQ）を使用するのが推奨。
再試行ポリシー設定で、再試行する時間の長さと再試行回数を設定したり、ターゲットへの配信に失敗した後でイベントが失われるのを避けるために、デッドレターキュー (DLQ) を設定し、失敗したすべてのイベントをそこに送って後で処理できる。「qEventBridge DLQ」 が、ターゲットに正常に配信できなかったイベントを保存するためにEventBridgeが使用する標準的なAmazon SQSキュー。
※CloudWatch Eventsが進化・派生したのがEventBridge。EventBridgeにどんどん機能が追加されているのでEventBridgeで覚えるべき。例えば、EventBridgeはサードパーティのSaaSに連携できる点やイベントをアーカイブ保存、のちに再生できる機能がある点が特有です。
【参考】Amazon EventBridge とは
【参考】他の AWS のサービスとの統合に関するAmazon EventBridge のチュートリアル
【参考】イベントの再試行ポリシーとデッドレターキューの使用
【参考】Amazon EventBridge のアーカイブと再生
【参考】Amazon EventBridgeでできることをまとめてみた #devio2021
AWS CloudTrail
AWS CloudTrailは、ユーザー、ロール、または AWS のサービスによって実行されたAPIコールをイベントとして自動で記録するサービス。
アクションを実行したユーザーやアプリケーション、対象のリソース、イベントの発生日時、およびその他の詳細情報を識別して、AWSアカウントのアクティビティの分析と対応が可能。
CloudTrailは指定されたAmazon S3バケットにログファイルを送信する。CloudWatch LogsやEventBridgeを使用して、証跡のイベントを配信・分析もできる。
CloudTrailは「すべてのリージョンに適用される証跡」と「1つのリージョンに適用される証跡」を作成できる。すべてのリージョンに適用される証跡を作成した後でリージョンを追加した場合、その新しいリージョンは自動的に含まれ、そのリージョンのイベントがログに記録される。複数のリージョンを使用している場合、リージョンごとにログの配信先を変えることができる。
CloudWatch LogsでCloudTrailログファイルをモニタリングできる。
具体例として、セキュリティグループに関連する設定変更が発生したときにCloudWatchアラームを作成し、管理者のメールアドレスにSNS通知できたりする。
【参考】CloudTrail の仕組み
【参考】CloudTrail ログファイルの取得と表示
【参考】例 : セキュリティグループの設定の変更
AWS Config
AWS ConfigはAWSリソースの設定を継続的に記録管理するサービス。AWSリソースになされた設定変更の把握やその影響範囲を評価できるため、トラブルシューティングやセキュリティ分析で重宝される。
Config Rules
Config Rulesは、事前に準拠すべきルールを設定し、継続的にそのルールを準拠できているか準拠状況を評価できる機能。
AWSで事前定義されたマネージドルールと独自で定義できるカスタムルールがある。
ルールから逸出していたリソースを見つけた場合、Amzon SNSでリアルタイムに通知したり、AWS Systems Manager Automationを利用した修復アクションと連携できる。
【参考】AWS Config とは?
【参考】AWS Systems Manager Automation
Config アグリゲータ
アグリゲータは、マルチアカウントやマルチリージョンのAWS Config設定とコンプライアンスデータを単一アカウントで一元管理できるAWS Configの機能。
マルチアカウントマルチリージョンのデータ集約より画像引用
AWS Health
AWS HealthはリソースのパフォーマンスとAWS のサービスとアカウントの可用性を継続的に可視化するサービス。
AWS Health Events
AWS Health Eventsは、AWSサービスとリソースの変更に伴う、アプリケーションへの影響範囲や影響内容を把握できるサービス。
EventBridgeを使用して、作成したルールで指定した値とAWS Healthイベントで公表されたイベントが一致すると、ターゲットアクションを呼び出せる。例えば、更新が予定されているEC2インスタンスがAWSアカウント内にある場合に、AWS Healthを使用してEメール通知を受信できる。
【参考】Monitoring AWS Health events with Amazon EventBridge
【参考】AWS Health の概念
AWS Personal Health Dashboard
AWS Personal Health Dashboardとは、AWS利用者環境に影響を及ぼす重要なイベント通知やメンテナンスの対処法ガイダンスを通知するサービス。AWS障害情報も確認できる。
【参考】AWS Personal Health Dashboard
アウトプット問題
AWSリソース上で実行・記録されたAPI関連アクティビティを確認できるAWSサービス
AWS CloudTrail
AWS CloudTrailは、AWSアカウントの運用・リスク監査、ガバナンス、コンプライアンスを実現するためのAWSサービスです。 ユーザー、ロール、またはAWSサービスによって行われたアクションは、CloudTrailのイベントとして記録されます。イベントには、AWSマネジメントコンソール、AWSコマンドラインインターフェイス、AWS SDKとAPIで行われたアクションが含まれます。
AWS のモニタリングサービスで、EC2 インスタンス上で実行されているアプリケーションやシステムのメトリクスを収集し、ダッシュボードで可視化できるサービス
CloudWatch エージェント
EC2インスタンスのメタデータや設定情報など、あらゆる種類のデータをインベントリとして収集できるAWSのSystems Managerサービスの機能
AWS Systems Manager Inventory
AWS Systems Manager Inventoryは、AWSコンピューティング環境に対する可視性を提供します。Inventoryを使用して、管理対象ノードからメタデータを収集することができます。
Amazon S3でServer Access Logsを保存するときの推奨設定
ソースバケットとターゲットバケットの両方が同じAWSリージョンにあり、同じアカウントによって所有されている必要がある
サーバーアクセスログは、バケットへのリクエストの詳細な記録を提供します。 サーバーアクセスログは、多くのアプリケーションで有用です。例えば、アクセスログの情報は、セキュリティやアクセス監査に役立つことがあります。また、顧客ベースについて知り、Amazon S3の請求額を理解するのに役立つこともあります。
ログは、ソースバケットそのものを含め、ソースバケットと同じリージョンにある自分の所有するバケットに配信させることができます。しかし、ログ管理をよりシンプルにするために、アクセスログは別のバケットに保存することをお勧めします。
S3 バケットで SSE-KMS 暗号化を使用する場合、どのような条件が必要か？
1.AWS KMS keys は必ず別のリージョンに存在する必要がある。
2.AWS KMS keys はバケットと同じアベイラビリティーゾーンに存在する必要がある。
3.AWS KMS keys はバケットと同じリージョンに存在する必要がある。
4.AWS KMS keys の存在するリージョンは関係ない。
3. AWS KMS keys はバケットと同じリージョンに存在する必要がある。
S3 バケットで SSE-KMS 暗号化を使用する場合、AWS KMS keys はバケットと同じリージョンに存在する必要があります。
【分野2】信頼性とビジネス継続性
【分野3】デプロイ、プロビジョニング、およびオートメーション
アウトプット
Amazon EC2のT2インスタンスでCPUクレジットが枯渇しても、パフォーマンスを落とすこと無く、高いCPU使用率を保持できるオプション
T2 Unlimited
t2.micro もしくは t3.micro インスタンス（無料枠）でも利用が可能。t2.micro もしくは t3.micro インスタンスを AWS 無料利用枠の範囲で unlimited モードにより使用している場合、ローリング期間の 24 時間における平均使用率が、そのインスタンスのベースライン使用率を超過すると料金が発生することがあります。
AWS Cloudformationのセクションの1つで、regionに基づいて値を設定したい場合、地域名をキーとして使用し、特定の地域ごとに指定したい値を設定できるセクション
Mappingsセクション
オプションのMappingsセクションは、キーと対応する名前の値のセットをマッチングさせます。例えば、地域に基づいて値を設定したい場合、地域名をキーとして使用し、特定の地域ごとに指定したい値を含むマッピングを作成することができます。マップ内の値を取得するには、Fn::FindInMap組込み関数を使用します。
Amazon EBSでバックアップされたEC2インスタンスで別のインスタンスタイプに変更する前になすべきこと
インスタンスを停止する
AWS Systems Managerの機能で、オペレーティングシステムとアプリケーションの両方のパッチを適用するプロセスを自動化できる機能
AWS Systems Manager Patch Manager
AWS Systems Managerの機能であるPatch Managerは、管理ノードにセキュリティ関連のアップデートとその他のタイプのアップデートの両方を適用するプロセスを自動化します。
【分野4】セキュリティとコンプライアンス
AWS Secrets Manager
Secrets Managerは、アプリケーションにハードコードされた認証情報 (パスワードを含む) をAPIコールに置き換えることで、シークレット情報をセキュアに管理できるマネージドサービス。データベースのパスワードを自動的に更新するローテーション機能も備える。
Secrets Manager シークレットを監視するモニタリングツールが用意されている。ログは予期しない使用や変更を調査する場合に使用でき、不要な変更をロールバックできる。（Cloudwatch）
シークレットの不適切な使用やシークレットを削除しようとする試みに対する自動チェックも設定可能。（CloudTrailとS3の連携）
【参考】AWS Secrets Manager の概要
【参考】AWS Secrets Manager シークレットをモニタリングする
アウトプット問題
特定のVPCでLambda関数を許可するIAMポリシーのキーの名称
IAM 条件キー
VPC 設定で Lambda 固有の条件キーを使用して、Lambda 関数に追加のアクセス許可コントロールを提供できます。例えば、組織内のすべての関数を VPC に接続するように要求できます。また、関数のユーザーに対して使用を許可または拒否するサブネットとセキュリティグループを指定することもできます。
Lambda は IAM ポリシーで次の条件キーをサポートしています。
- lambda:VpcIds － 1 つ以上の VPC を許可または拒否します。
- lambda:SubnetIds － 1 つ以上のサブネットを許可または拒否します。
- lambda:SecurityGroupIds － 1 つ以上のセキュリティグループを許可または拒否します。
EC2インスタンスがCenter for Internet Security (CIS) Benchmarksに準拠していることを確認できるAWSサービス
Amazon Inspector
Amazon InspectorはEC2インスタンスの脆弱性と、CIS（Center for Internet Security）ベンチマーク、セキュリティのベストプラクティスに準拠できているか確認できるサービス。
AWS Storage Gatewayのサーバサイドの暗号化で利用される暗号化キーを2つ
SSE-S3（デフォルト）とSSE-KMS（オプション）
Storage Gatewayは、SSL/TLS（Secure Socket Layers/Transport Layer Security）を使用して、ゲートウェイアプライアンスとAWSストレージ間で転送されるデータを暗号化します。デフォルトでは、Storage Gateway は Amazon S3-Managed encryption keys (SSE-S3) を使用して、Amazon S3 に保存するすべてのデータをサーバーサイドで暗号化します。Storage Gateway API を使用して、AWS Key Management Service (SSE-KMS) キーによるサーバーサイド暗号化を使用してクラウドに保存されたデータを暗号化するようにゲートウェイを構成するオプションがあります。
AWS ISO認証、Payment Card Industry（PCI）、Service Organization Control（SOC）レポートなど、AWSのセキュリティおよびコンプライアンス文書をオンデマンドでダウンロードできるAWSサービス
AWS Artifact
AWS Shield AdvancedでDDoSイベントが発生した時にメトリクスを報告する連携先のAWSサービス
Amazon CloudWatch
Shield Advancedは、AWSリソース上のAmazon CloudWatchに、DDoSイベント中、イベントが発生していないときよりも頻繁にメトリクスを報告します。Shield Advancedは、イベント中は1分間に1回、イベント終了直後に1回、メトリクスをレポートします。イベントが発生していない間は、Shield Advancedは1日に1回、リソースに割り当てられた時刻にメトリクスをレポートします。この定期的なレポートにより、メトリクスはアクティブな状態に保たれ、CloudWatchのカスタムアラームで使用できるようになります。
指定されたKMSキーでEBSボリュームが暗号化されていることを確認するために利用されるAWSサービス
AWS Config
AWS Configの「encrypted-volumes」で接続状態にある EBS ボリュームが暗号化されているかどうかをチェックします。kmsIdパラメータを使用して暗号化のためのKMSキーのIDを指定すると、ルールは、添付された状態のEBSボリュームがそのKMSキーで暗号化されているかどうかをチェックします。
1つのAWSアカウントで作成したAWSリソースを、その同じアカウント内のすべてのロールやユーザー、または他のAWSアカウントと安全に共有するのに役立つAWSサービス
AWS Resource Access Manager（AWS RAM）
【分野5】ネットワークとコンテンツ配信
【分野6】コストとパフォーマンスの最適化
アウトプット問題
VPC内のネットワークインターフェイスに出入りするIPトラフィックの情報を取得することができる機能
VPC Flow Logs（フローログ）
VPC Flow Logsは、特定のトラフィックがインスタンスに到達しない理由のトラブルシューティングに役立ち、過度に制限されたセキュリティグループルールを診断するのに役立つ。また、インスタンスに到達するトラフィックを監視するためのセキュリティツールとしても役立つ。