はじめに
DX 技術本部の yu-yama です。
AWS 認定 SysOps アドミニストレーター – アソシエイトを取得したので取得までの流れを記します。
受験前の AWS 経験
AWS 経験は 4, 5 年で、コアサービスは一通り触っており、SAA を 2020 年 6 月に取得、DVA を 2021 年 1 月に取得しています。
学習期間
- 2週間と少し(2021/01/21 ~ 2021/02/07)
学習の流れ
2021/01/21 ~ 2021/01/31
-
試験ガイドで、試験範囲を確認する
-
分野ごとの比重を見て、特に問われるところを確認します
- 分野 1 モニタリングとレポート(22%)
- 分野 2 高可用性(8%)
- 分野 3 デプロイメントとプロビジョニング(14%)
- 分野 4 ストレージとデータ管理(12%)
- 分野 5 セキュリティとコンプライアンス(18%)
- 分野 6 ネットワーク(14%)
- 分野 7 自動化と最適化(12%)
-
モニタリングとレポートは重点的に、高可用性は軽めで良さげと判断
-
-
合格体験記確認
-
先人のやったことを読んで合格までになにをどこまでやればよいかをイメージ
などなど...
-
-
AWS トレーニングと認定 | Exam Readiness: AWS Certified SysOps Administrator - Associate (Japanese)を受講し、分野ごとに問われる AWS サービスを確認
- 問われる AWS サービスと各分野ごとの原則(解答時の指針となるもの)が表示されるのでしっかりメモ。
2021/02/01 ~ 2021/02/04
-
ブラックベルト読み込み
-
AWS トレーニングと認定 | Exam Readiness: AWS Certified SysOps Administrator - Associate (Japanese)で問われる AWS サービスのブラックベルトを読み込みます。知っているものは流しめに。知らないサービスはじっくりと。
-
以下のブラックベルトを読みました。
-
Management & Governance
-
Security, Identity & Compliance
-
Support
-
AWS Cost Management
-
-
2021/02/05 ~ 2021/02/07
- AWS トレーニングと認定 | Exam Readiness: AWS Certified SysOps Administrator - Associate (Japanese)とブラックベルトを整理したメモに目を通し、ユースケースがいまいちイメージできないもの、用語の理解が浅い部分をなくすようにメモに肉付けします。
模擬試験
- 受けませんでした。AWS トレーニングと認定 | Exam Readiness: AWS Certified SysOps Administrator - Associate (Japanese)を受けると分野ごとの説明の最後に確認問題が出るので、雰囲気はつかめます。
本番
- まず全問解いて後で見直すものと確信を持てるものを分ける。65 問解いたところで大体 1 時間弱残るはず。
- 後で見直すものを一通り見直して試験終了
- (SAA と DVA と同じです)
感想
ギリです。1問落としていたら落ちていたでしょう。手ごたえはDVAと同じだったのですが、結果として100点以上DVAと差が付いたのでなにかしら問題集(Udemyかkoiwaclub)を解いてもっと各分野全体的に掘り下げる必要があったと感じました。
とはいえAWS トレーニングと認定 | Exam Readiness: AWS Certified SysOps Administrator - Associate (Japanese)とブラックベルトを読めばそれなりに勝負にはなります。
次はプロフェッショナルレベルか専門知識ですが、いよいよちゃんと勉強しないと受からなさそう...
最後に作成したメモを貼っておきます
試験に向けて作成していたメモ
## 分野 1 モニタリングとレポート
`メトリクスとアラームの作成と維持`
`メトリクスを認識し、パフォーマンスと可用性を区別`
`メトリクスのパフォーマンスと可用性に基づいて是正`
### Amazon CloudWatch
- Amazon CloudWatch の概念
- 名前空間
- 関連するメトリクスのグループ
- 標準では AWS サービスごと
- 例) AWS/EC2, AWS/RDS, AWS/ELB etc
- メトリクス
- モニタリング対象の変数
- 例) CPUUtilization, NetworkIn, NetworkOut etc
- ディメンション
- メトリクスを一意に識別できる名前と値のペア
- 例) CPUUtilization のインスタンス ID
- 例) NetworkIn のインスタンス ID
- 統計(Statistic)
- 指定された期間のメトリクスデータの集計
- Alarms
- メトリクスが特定の条件を満たした際に自動的に行われるアクション
- メトリクス
- 標準メトリクス
- CPU 使用率(CPUUtilization)
- ディスクオペレーション数
- ロードバランサーと登録済みの EC2 インスタンス間で正常に確立されなかった接続の数(BackendConnectionErrors)
- S3 バケットに対して行われた HTTP リクエストの総数(AllRequests)
- カスタムメトリクス
- 標準メトリクスでは収集できないメトリクス
- EC2 インスタンスの **メモリ使用率**や**ディスク使用率**
- CloudWatch エージェントを導入して取得する
- EC2 のモニタリングタイプ
- 基本モニタリング
- 料金:無料
- データは 5 分間隔
- 詳細モニタリング
- 料金:追加料金が必要
- データは 1 分間隔
### Amazon CloudWatch アラーム
- アラームの評価期間の数に各評価期間の長さを掛けた値が 1 日を超えてはいけない
- アラームは 3 つの状態のいずれかになる
- OK:しきい値を超えていない
- ALARM:しきい値を超えている
- INSUFFICIENT_DATA: アラームが開始された、または十分なデータがないメトリクスは使用できません
- 既存のアラームの名前は変更できない
### CloudTrail
- アカウントアクティビティを監視・記録・保持する
- Amazon S3 にログを自動的に送信する
- Amazon CloudWatch Logs, Events との統合
- 証跡ログでわかること
- いつ API コールが実行されたか
- どこから API コールが実行されたか
- **誰が API コールを実行したか**
- どのリソースが影響を受けたか
- 証跡ログ Amazon S3 バケットを基本に、Amazon CloudWatch Logs への出力もサポート
### AWS Config
- 現在のシステムステータスやリソース構成を報告
- 構成履歴を制御
- 設定変更のモニタリング機能
- **設定変更を行った IAM ユーザーは記録しない**(誰がやったかは分からない)
- AWS リソースの構成変更をロギングする
- どのユーザーによる操作かは分からない
- CloudTrail を参照する
- ルールの準拠状況を確認出来る
### AWS Service Catalog
- AWS のプロビジョニングに関するリスクを低減する(コスト、セキュリティ、ガバナンス)
- セルフサービスチームポータル
- 標準的な AWS 環境のデプロイをテンプレート化する
- テンプレートのバージョン管理を行う
- 製品
- CloudFormation テンプレートをパッケージ化したもの
- バージョンが管理可能
- ポートフォリオ
- 製品の集合
- ポートフォリオ単位でユーザーに製品の使用を許可
- 制約
- 製品のデプロイ方法を制御。ポートフォリオごとに各製品に制約を追加
### 原則
- CloudWatch を理解するポイント。
- 標準メトリクスがどのようなユースケースで利用されるのか
- カスタムメトリクスが利用されるケース
を理解すること
- API 呼び出しに関する調査・記録の問題は、AWS CloudTrail に関連する可能性が高い
---
## 分野 2 高可用性
`シナリオに基づいてスケーラビリティと伸縮性を導入する`
`高可用性と耐障害性の違いを認識して、AWS 環境上での扱いを区別する`
- 高可用性と耐障害性は同じではない
- 高可用性とは、アーキテクチャ内のいずれかのコンポーネントが完全に故障しても、システムが**機能し続けること**
- 耐障害性とは、アーキテクチャ内のいずれかのコンポーネントが完全に故障しても、システムは**パフォーマンスを低下させることなく機能し続けること**
- スケーラビリティと弾力性(伸縮性)は同じではない
- スケーラビリティは、ハードウェアを強化する(スケールアップ)か、ノードを追加する(スケールアウト)かのいずれかでリソースを追加するだけで、**システムがより大きな負荷に対応できる能力**
- 弾力性とは、通常、スケールアウトに関連して、動的に負荷に対処するために**必要なリソースに合わせる能力**
### Route 53
- スケーラブルな DNS のウェブサービス
- リージョン間でトラフィックを分散するために使用
### Amazon CloudFront
- グローバルな CDN(コンテンツ配信ネットワーク)
- パフォーマンスと拡張性に最適化された設計
### ロードバランサーのタイプ
- ALB
- HTTP or HTTPS
- HTTP ヘッダー情報を参照する
- NLB
- 全ての TCP トラフィックを受け取り、ラウンドロビン方式でステートレスウェブサーバーにルーティングを行う
### Amazon EC2 Auto Scaling
- スケールアウトとスケールイン
### 原則
- AWS Auto Scaling, Elastic Load Balancing, および Amazon CloudWatch は、
メトリクスに基づいてリソースを自動で追加、および削除できるように連携して動作するように設計されている
- 一部のサービスはデフォルトで高可用性および耐障害性があり、他のサービスは SPOF を回避するために高可用性および耐障害性を設計する必要がある。
- デフォルトで高可用性のサービス:ELB と Amazon Route 53
- 高可用性設定を必要とするサービス:Amazon EC2 と Amazon RDS
- 負荷分散
- AWS リージョン内では Amazon ELB
- Amazon リージョン間での Amazon Route 53
---
## 分野 3 デプロイメントとプロビジョニング
`クラウドリソースをプロビジョニングするために必要な手順を特定し、実行する`
`デプロイの問題を特定し、修復する`
### AWS Elastic Beanstalk
- デプロイの詳細を自動的に処理
### OpsWorks
- Chef, Puppet を使用して実行できる
- インスタンスを自動的にプロビジョニングできる
- Chef サーバなどをマネージドサービスとして地峡する
### AWS CloudFormation
- テンプレート、スタック
- テンプレートについて
- Parameters セクション
- スタックを作成または更新するたびにテンプレートにカスタム値を入力できる
- Mappings セクション
- キーと名前付きの一連の値が対応付けられる
- マップ内の値を取得するには、Fn::FindInMap 組み込み関数を使用する
- Resources セクション
- スタックに含める AWS リソースを宣言する
- Outputs セクション
- 他のスタックにインポートする、応答として貸す、コンソールで表示する出力値を宣言する
- スタックのリソース更新のロールバックに失敗(UPDATE_ROLLBACK_FAILED)する原因は、スタックのリソースが CloudFormation の外部で変更された場合である
### 原則
- AWS Elastic Beanstalk は、アプリケーションを AWS にデプロイするための最も便利な方法の 1 つ
- AWS CloudFormation は AWS サービスのデプロイに使用され、OpsWorks はアプリケーションスタックのデプロイに使用される
- スタックやレイヤーなどの AWS OpsWorks コンポーネントと、さまざまなアプリケーションレイヤーをデプロイする方法を理解する
- 例) 既存のアプリケーションスタックに RDS レイヤをデプロイする方法
---
## 分野 4 ストレージとデータ管理
`データ保持を作成及び管理する`
`データ保護、暗号化、およびキャパシティ計画のニーズを識別して実装する`
### インスタンスストア
- EC2 インスタンスの物理サーバの内臓ディスク
- EC2 とは分けられない
- EC2 を停止するとデータが揮発する
### EBS
- EC2 とはネットワークで接続
- EC2 とは別で独立して管理されるので、インスタンスがなくなっても EBS は保持
- インスタンスストアと EBS のユースケース
- インスタンスストアは一時ファイル置き場
- EBS はデータ格納用
- EBS スナップショットの機能
- EBS のデータを Amazon S3 にバックアップする機能
- Amazon S3 に格納されたスナップショットから、データが存在する EBS を復元できる
- 復元された EBS を EC2 インスタンスにアタッチされていたものと置き換えることで、EBS のリストアをすることが可能。
- EBS スナップショットと AMI イメージの違い
- EBS スナップショット
- EBS ボリュームのバックアップであり、S3 に格納される
- AMI イメージ
- EC2 インスタンスの起動に必要な情報+ EBS スナップショット
### Amazon EBS のボリュームタイプ
- SSD
- 汎用 SSD(gp2)
- さまざまなトランザクション負荷に利用できる
- プロビジョンド IOPS SSD(io1)
- 低遅延、もしくは高スループットが必要なミッションクリティカルなアプリが利用
- HDD
- スループット最適化 HDD(st1)
- アクセス頻度が高く、スループットが高いワークロードが利用する
- Cold HDD(sc1)
- アクセス頻度の低いワークロードが利用する
- IOPS とスループットの違い
- IOPS
- 1 秒間のストレージ書き込み読み込み性能
- スループット
- 1 秒間の最大データ転送量
- 暗号化されたボリュームから作成されたすべてのスナップショットは暗号化されている
- 全ての Amazon EBS ボリュームタイプを暗号化できる
### Amazon Elastic File System
- 共有ファイルストレージ
- マウントされたファイルボリュームが必要な場合、EFS がソリューションとなる
- S3 よりもコストが高い
### Amazon S3
- 高速、高耐久性、高可用性
- キーベースのオブジェクトにアクセス
- データ量に上限なし
### Amazon S3 Glacier
- きわめて低コストなデータのアーカイブと長期バックアップ
- 料金が S3 に比べて安いが取り出し時間が遅い
- 迅速 1-5 分
- S3 の方がコスト安いかも
- 標準 3-5 時間
- 大容量 5-12 時間
### 原則
- アーカイブデータ、ミッションクリティカル、Public にアクセス可能などのキーワードは、正しいストレージタイプを決定するのに役立つ
- 例) Amazon S3, Amazon S3 Glacier
- 各 Amazon EBS タイプのおおよそのストレージパフォーマンス制限を知る
- Amazon EBS は永続的ブロックストレージボリュームを提供します。
- Amazon EC2 インスタンスストアボリュームは、インスタンスに一時的なブロックレベルのストレージを提供します。
- プロビジョンド IOPS はコストが高くなりますが、最高性能の IOPS とスループットを提供します。
- Amazon EBS では、1GB あたりのプロビジョニング料金を支払い、ボリュームはアベイラビリティゾーンに保存されます
- Amazon S3 と Amazon EFS を使用すると使用した分の料金を支払います。これらはリージョンベースのサービスなので、複数のアベイラビリティゾーンに冗長的に保存されます。
- RPO と RTO には異なる要件があります
- RPO(Recovery Point Objective) 目標復旧時点
- 復旧するバックアップファイルの古さを表す
- RTO(Recovery Time Objective) 目標復旧時間
- インシデントの発生から通常の業務に戻るまでに許容できるダウンタイムの最大時間
---
## 分野 5: セキュリティとコンプライアンス
`AWS におけるセキュリティポリシーを導入し管理する`
`AWS を使用するときにアクセスコントロールを導入する `
`責任共有モデルにおける役割と責任を区別する`
### AWS IAM
- アクセスと認証を一元管理できる
- AWS アカウントの機能として無料で提供される
### AWS GuardDuty
- セキュリティの観点から**脅威を検知**する AWS マネージドサービス
- AWS のアカウントとワークロードを保護
- 不審なアクティビティがないかどうか AWS 環境をモニタリングし、検出結果を生成
- 脅威リストと信頼できる IP リストを独自に追加できる
### 原則
- ほとんどの場合、IAM ユーザーではなく、IAM ロールを選択するほうが望ましい
- IAM で多数のユーザーを作成することは推奨されない。ID フェデレーション、ユーザープールその他の ID ストアのソリューションを検討する
- より優れたソリューションは ID フェデレーションで ActiveDirectory を利用すること
- セキュリティグループはステートフルで、ネットワーク ACL はステートレス。受信と送信の許可ルールと拒否ルール、各サービスの対象範囲を理解する
---
## 分野 6 ネットワーク
### セキュリティグループ
### ネットワーク ACL
- サブネットレベルでセキュリティを強化
### AWS ネットワークのトラブルシューティング
- サブネット同士が通信できない場合
- ネットワークの問題であるかどうかを確認し、インスタンスではないことを確認する
- ネットワーク ACL を確認する
- セキュリティグループを確認する
- VPC フローログが有効な場合はログをチェックする
### AWS マネージド VPN 接続を設定する
- 必要なコンポーネント
- Customer Gateway(カスタマーゲートウェイ)
- お客様側
- Virtual Private Gateway(仮想プライベートゲートウェイ)
- AWS 側
## 原則
- 一般に、大きな Amazon EC2 インスタンスサイズ(ファミリー内)は、より大きなローカルネットワーク帯域幅容量を持つ
- AWS Direct Connect は、AWS への専用ネットワーク接続を指す(プライベートファイバーと考える)
- プライベート仮想インタフェース -> VPC
- パブリック仮想インタフェース -> パブリックサービス(S3 など)
- AWS マネージド VPN は、リモートネットワークと AWS 間に IPsec VPN を提供する
- カスタマーゲートウェイとは、お客様の VPN 終端(ルータなど)を指す
- 仮想プライベートゲートウェイは、AWS 側の VPN 接続の終端を指す
---
## 分野 7 自動化と最適化
`AWS を使用してリソースの使用率を管理及び保護する`
`効率的なリソース活用のための、運用コスト最適化戦略`
`管理 オーバーヘッドを最小限に抑えるために、手動または繰り返し可能なプロセスを自動化する`
### AWS Systems Manager
- ソフトウェアインベントリ(IT 資産管理)
- OS パッチ
- OS 管理及び構成
- リソース状況の可視化
- マネージドインスタンスにするための手順
- (Amazon Linux や Windows, Ubuntu Server のオフィシャルイメージには導入済み)
1. SSM Agent の導入
1. SSM Agent から SSM API への経路(アウトバウンド)確保
1. IAM ロール付与
### Amazon Inspector
- 自動セキュリティ診断サービス
- EC2 にエージェントを導入し、プラットフォームの脆弱性を診断するホスト型診断サービス
- ルールパッケージ
- CVE(Common Vulnerabilities&Exposures 共通脆弱性識別子)
- CIS(Center for Internet Security) 米国のインターネットセキュリティ標準化団体
- OS のセキュリティベンチマーク
- セキュリティのベストプラクティス
- 実行時の振る舞い分析
### AWS Trusted Advisor
- AWS 環境を分析して、環境を最適化するための推奨ベストプラクティスを提供
- ベストプラクティスの 5 つのカテゴリ
1. コスト最適化
1. パフォーマンス
1. セキュリティ
1. フォールトトレランス(システムや機器の一部が故障・停止しても、予備の系統に切り替えるなどして機能を保ち、正常に稼働させ続ける仕組み)
1. サービス制限
- サービスの上限に対して 80%を超えている使用料を確認出来る
### AWS Cost Explorer
- AWS のコストをグラフで可視化する
- フィルターやグルーピングによるカスタマイズ
- メンバーアカウントごとのコスト分析
- タグによるプロジェクトごとのコスト分析
- コスト最適化提案の確認
- リソース最適化の推奨
- 予約購入の推奨事項
- 例) プロジェクト(部門)ごとのコストの確認
- タグでグルーピングを行う
- 前段階として、リソースへのタグの付与およびタグの有効化が必要
- グルーピングで表示する料金は、指定したキー(key)の値(Value)ごとの料金
## 原則
- Amazon CloudWatch, Auto Scaling, および AWS Lambda を使用して自動的にリソース使用率を管理します
- AWS CloudFormation は Infrastructure as code を可能にします。
- AWS Trusted Advisor はコストの最適化、パフォーマンスの向上、セキュリティ、フォールトトレランス、およびサービス制限の推奨事項にとって重要なツールです。
- CloudFormation, OpsWorks, Elastic Beanstalk
- 質問でクォータ(サービス制限)を確認するように求められた場合、Trusted Advisor がツールとして念頭に置かれている可能性が高い