Edited at

AWSソリューションアーキテクト – アソシエイトを合格するためにしたこと(1ヶ月)

先日(2019/08)、AWS SAA(ソリューションアーキテクト アソシエイト)に合格しました。

その経緯や勉強方法を纏めたので少しでも参考になればと思います


前提


  • 目的


    • 体系的な知識がなかったので一貫した知識を得たかった&自分が使用したことがないAWSの便利なサービスを知るため



  • 期間(大体1ヶ月)


    • 7/17(勉強開始) ~ 8/18(試験本番)



  • 結果


    • 788/1000(合格)



  • 勉強前のAWSの知識


    • EC2、VPC、S3などを軽く触ったことがあるぐらい



  • 勉強時間(だいたい)


    • 平日


      • 1 ~ 2時間



    • 土日


      • 2 ~ 4時間






やったこと

(大体、記載順の通りにやっていったと思います↓)


Udemy

これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(初心者向け21時間完全コース)

他の方も書いているが本当にオススメです。

(急ぎでない人は割引が行われているときに、購入するのが良いかもしれません)

動画を見ながらAWSを実際に動かしつつ、基本的なサービスについて学習できます。

全部で21時間ほどですが、私は時短のため1.25倍、1.5倍などで見てました。

最後に模試が2回分ついていますが、個人的には併せて以下もやっておくと良いと思います。

AWS 認定ソリューションアーキテクト アソシエイト試験模擬試験集(4回分260問)

模試は最初にやったときには4,5割しか取れませんでした。(9割ぐらい取れるまで何回もやる)

こおUdemyの模擬試験が(文章構成や難易度含め)一番本番と近いと感じました


書籍

合格対策 AWS認定ソリューションアーキテクト -アソシエイト

概要を抑えるための書籍です。

各章毎に問題があるので、こちらも9割ぐらい取れるまで繰り返します。

この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集

AWSはサービスの仕様が頻繁にアップデートされます。

書籍には古い情報が載っているものもあるので、最新の書籍を使用したかったというのもあり、使用しました(2019/7/20発売)。

最後に模擬試験が載っているのも良いポイントです。


模擬試験

https://www.aws.training/certification?src=cert-prep

AWS公式の模擬試験になります。

本番よりも難易度は易しいものになっているが、問題文の感覚を掴むのに良いかもしれません。

この時のスコアは8割ちょいでした。


Black Belt

AWS サービス別資料

AWSの公式資料です。

主要サービス(EC2、VPC、S3など)に絞って足りない知識を補う目的で使用しました。

(こちらの動画も時短のため1.25倍、1.5倍などで見てました。)


web問題集

AWS WEB問題集

Udemyや書籍で解いた問題については良かったのですが、漏れがないために念のためにこちらも解いてみました。

ただ本番まで時間がなかったので、最新の20個(#100 ~ #120)ぐらいに絞って解きました。


弱い部分をメモする

何回やっても間違える問題や忘れそうな箇所は下記ののようにEvernoteに纏めて隙間時間で見直すようにしました。

この記事の最後に当時のメモした内容を記載しておきました(メモ書き&間違っている箇所もあるかもしれませんが)


取得して良かったこと

Trusted Adviserなど今まで自分が知らなかったサービスを知ることができ選択の幅が広がったり、

各サービスの料金の発生条件などを詳細に理解することでコスト削減に繋がったことです。


余談


  • (技術のバックグラウンドが違うとはいえ)1、2週間で資格を取っている方もいれば、年単位で時間をかけている方もいるので難易度が予測しにくいのも不安要素の一つでした。

  • したがって途中で「これだけやれば十分かな、でも他の問題集もやろうかな」と迷うことがありましたが、私の場合はとりあえずやることにしました。

  • Udemyや書籍などについている模試の結果が悪くても気にしない方がいいと思います


    • そこから繰り返して満点近く取れれば問題ないです



  • 本番の試験は長丁場なこともあり、最初から最後まで集中力を維持して問題を読むのが大変でした。

    したがって、当たり前ですが疲れていても必ず見直しはした方が良いかと思います。

    (私の場合は見直しで回答を変えたものが割とありました)

  • とりあえず、時間が許す限り出来ることを(ほぼ全て)やるのが良いと思いました


参考

最後に他の方の合格体験記で参考になりそうなものを挙げておこうと思います

- AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる

- AWS 認定 Associate level を大体一ヶ月で取った話

- インフラ知識ゼロの2年目プログラマーがAWS SAAに1ヶ月で合格した方法

- AWS認定ソリューションアーキテクト アソシエイト(2018年2月リリース版)の試験メモ


メモ

自分が勉強した時のメモ

   * VPC

* VPC ⇄ 仮想プライベートゲートウェイ(VGW) ⇄ VPN ⇄ カスタマーゲートウェイ(CGW) ⇄ データセンター
* ゲートウェイ型(VPC エンドポイント)
* Amazon S3
* DynamoDB
* に接続するときに使用する
* それ以外はプライベートリンク型
* プライベートネットワーク空間のCIDRは16 ~ 28まで
* /21
* 2048IPアドレス
* /22
* 1024IPアドレス
* /23
* 512IPアドレス
* 社内向け(イントラネット)の場合はプライベートホストゾーンを構成する
* ネットワークACL
* アウトバンドのTCPポートは1024 ~ 65535で設定する(クライアントのOSに依存するため)
* あくまでアクセス制御(暗号化ではない)
* ルールナンバーの低い値から高い値で評価される(低い方が優先度高い)
* NAT
* NATインスタンスは複雑
* NATゲートウェイ
* 帯域幅を自動的に拡張して、オーバーヘッドの削減などが可能
* ルートテーブルにプライベートサブネットを設定する
* EC2
* ex)
* c(ファミリ)5(世代)d(追加オプション).xlarge(インスタンスサイズ)
* I3ファミリーはレイテンシー、超高ランダムI/Oに適している
* ユーザーデータ
* 起動時にシェルスクリプトなどを実行する
* メタデータ
* 自分自身のデータを取得(hostnameなど)
* 制限
* リージョン毎に20
* 上限緩和が可能
* 責任分担
* OSのパッチ適用は利用者の責任
* 終了しているインスタンスは料金が発生しない
* 「http://169.254.169.254/latest/meta-data/」などからメタデータを取得できる
* ハードウェア専有インスタンス
* 同じAWSアカウントとはHWを共有する可能性がある
* Dedicated Host
* 同じAWSアカウントでも物理サーバーを共有しない
* ベアメタル
* 直接サーバーのメモリやCPU(ハードウェア)を操作できる
* スポットインスタンス
* CloudWatch Eventsで中断通知を受け取れる
* 中断時の1時間未満の利用分は料金発生なし
* スケジュールドリザーブドインスタンス
* 月一回だけバッチ処理をしたい場合などに適している(日次、週次、月次)
* EC2インスタンスの暗号化はEBSボリュームの暗号化を有効にする
* Elastic IP(EIP)
* 使用されてない or EC2がrunning以外で課金される
* EBS
* 同一のAZのみ利用可能
* EBSの複製はスナップショット(S3)、EC2インスタンスはAMI(AMIはEBSも含まれている)
* スループットHDDの方が汎用SSDよりコストが低い
* スループットHDDはビックデータ、分析、Hadoopなどに向いている(シーケンシャルアクセスに最適)
* EBS Backed インスタンス(OSがEBSにインストールされる)
* 起動、停止、再起動、削除が可能
* instant store-backed インスタンス(OSがインスタンスストアにインストールされる)
* 再起動、削除のみ
* スナップショットのコピーを作成するときに暗号化オプションを有効化できる(AES-256)
* スナップショットはEBSの利用状況に関係なく、非同期に作成可能
* スナップショットの取得開始後は完了を待たずに再びマウント可能
* 最も回復性が高いのはミラーリング
* 最適化インスタンスは独立した帯域を確保して安定したI/O性能に繋がる(Networkとの帯域を分離する)
* EBSはアタッチされてない場合でも料金が発生する(容量を確保しているため)
* RAID0
* 並行して同時に記録することで読み書きを高速化できる
* RAID1
* 冗長性、耐障害性を提供する
* DeleteOnTerminationをfalseにすることで、インスタンスが停止してもEBSは保持できる
* Amazon DLM
* EBSのバックアップ、削除、保存などを自動化できる
* Redis
* Redis Auth
* パスワードの入力を求めることが可能
* Memcached
* データ型
* シンプル
* マルチスレッド
* あり
* S3
* 耐久性
* 99.999999999%(イレブンナイン)
* 可用性
* S3 標準 / Gracier
* 99.99%
* S3 Intelligent-Tiering / S3 Starndard
* 99.9%
* S3 1zone-A
* 99.5%
* Gracier
* 最大容量は250MB未満
* 同じリージョン内の複数の施設に複製が作られる
* 新規登録は即時反映、更新と削除は以前のデータが参照される可能性がある
* 暗号化
* 暗号化を許可した場合はバケットポリシーの(暗号化情報ありの)PUTリクエストも許可する必要がある
* 複合化は自動でされる
* 保存する前に暗号化、ダウンロードする前に複合化される
* サーバーサイド暗号化
* SSE-S3はAmazon S3がデータとマスターの暗号化キーを管理する方式であるため、暗号化と複合化はS3によって自動で管理される
* デフォルト
* 自分で管理の必要がない
* SSE-KMS
* KMS使った暗号化
* SSE-C
* カスタマー
* 暗号化キーはユーザーが管理
* クライアント暗号化
* CSE
* クラウド上での鍵の保存が許されない場合に使用する
* S3 Select
* 必要なデータセットのみ取り出せる
* 静的ホスティング
* 登録済みのドメインネームがあること
* 「バケットネーム」と「ドメインネーム」が同じである必要がある
* S3 Transfer Acceleration
* クライアントとの通信を高速、安全に実施できる
* ユーザーポリシー
* このユーザーは何ができるか?
* IAMユーザに対して任意のバケットへのアクセス権限を付与
* バケットポリシー
* このS3リソースには誰がアクセスできるのか?
* CouldFrontとの連携、IPアドレス制限などで使用
* ACL
* ユーザーポリシーやバケットポリシーが優先される
* 通常はバケットポリシーを使う
* GlacierのVault Lockは機密情報を登録できる(編集できないようにする)
* マルチパートアップデートを利用することで大容量オブジェクトを高速でアップロード出来る。
* RRSは耐久性が落ちるが、読み取り速度は変わらない
* S3のイベント通知先は3つ
* SNS
* SQS
* Lambda
* URLは「バケット名.s3-website-リージョン」ex) pintor.s3-website-ap-northeast-1
* クロスリージョンレプリケーションは異なるAWSリージョンにあるバケット間でコピーする
* SQS
* SQSはPull型、非同期型
* メッセージ保持期間 = 4(デフォルト) ~ 14日
* データサイズは最大256KB
* 暗号化はKMS
* ストリームデータはKinesis Data Streamsを使用する
* Kinesis Firehose
* Redshift、S3、Dynamoなどへ、データを変換しつつ配信できる(プログラミングをしなくても設定できる)
* Elastic IPアドレスの割り当ては、頻繁にサーバーを停止させるアプリ上では必要な設定ですが、通常は割り当てがなくてもインターネットへのアクセスは可能
* SNS
* SNS、SESはどちらもメール送信可能だが、SNSはSMS(電話番号)メッセージが可能
* システムのアラート(停止など)を通知されるトピックが作成可能
* pub-subに対応
* ELB
* Certificate Manager
* SSL証明書を作成することができる(ELBなどに設定可能)
* ALBだけがwebsocketに対応している
* EC2と違ってCloudWatch Agentは使用できない
* ECSのトラフィックも制御できる
* クロスゾーン負荷分散が有効な場合、トラフィックを分散する
* Connection Drainingを使用して異常なインスタンスへのリクエストを停止することができる
* 各サービス毎にスケールさせたい場合は、一台ずつALBも用意する
* CloudTrail
* 全リージョン(各リージョン)で使用できる
* デフォルトで暗号化(SSE)されることになっている
* Cloud Trailはアカウントの(API Callの)履歴を監視できる(「ユーザーの」ではない)
* Access Adviser(Service Last Accessed Data)
* IAMユーザー、グループなどが最後にサービスにアクセスした日付と時刻を表示する
* AWS Config
* (AWSアカウント、IAM)自体のリソースの管理を行ったり、履歴を監査することができる(スナップショットなど)
* ユーザーのログは追えない
* コンプライアンス目的などセキュリティ監査に使える
* 現在の構成のスナップショットを取ることもできる
* Cloud Trailはアカウントの(API Callの)履歴を追跡するだけ、AWS Configはリソースまで追跡
* アクティビティログを追うのはCloud Trail(通知など)
* ConfigアグリゲータはConfigルールの評価結果を複数のアカウントやリージョンについて集約する
* Credential Report
* 認証情報レポート(パスワード使用日、Access Keyなど)を作成することができる
* https://www.youtube.com/watch?v=qrZKKF6V6Dc&feature=youtu.be
* Trusted Adviser
* スナップショットやElastic IPの状況、制限のチェック(アドバイス)
* インターネットゲートウェイには帯域幅はない
* ECSはAWS FargateとEC2(FargateとEC2はデータプレーン=実行環境)
* EKSはEC2のみ
* Fargateを利用する場合はEC2のクラスターをプロビジョニング、設定、スケールする必要がない
* タスクに対するIAMロールを設定できる
* Lambda
* APIコールとデータ量に応じて費用がかかる
* スケールイン、アウト可能で低コスト
* 一時ボリュームの最大512MB
* タイムアウトは最大15分まで
* Canary
* 新しいLambdaバージョンに移行するための設定
* Layer
* 関数の共通処理を書いておける(処理の重複をなくすことができる)
* API Gateway
* キャッシュを有効化することで、パフォーマンスを向上する
* IAM
* ユーザー上限=5000、IAMグループ上限=100
* IAM ユーザーがメンバーになれるグループ=10
* IAMポリシーの選択は管理ポリシーから選択することを優先させる
* 複雑&特殊なIAMポリシーが必要なときにのみインラインポリシーを利用する
* ルートアクセス権
* ルートアクセス権限を持つのはEC2とEMR
* Auto Scaling
* 「起動設定」はどのようなインスタンスを起動するかを決める
* AMI、インスタンスタイプ、セキュリティグループ、IAMロール
* 「グループ」
* 起動最小数、最大数、VPC、スケーリングポリシー
* ヘルスチェックはEC2もしくはELBに設定可能
* ELBのヘルスチェックの異常を検知するためには「ELB」に設定する
* クールダウンタイマーで指定した時間内は、次のスケールインを実行しないことが可能(スケールインを無視する)
* デフォルトは300秒
* 前のスケーリングアクティビティが有効にある前に起動や削除はしない
* ターミネーションポリシー
* どのインスタンスを終了させるかを決めるもの(OldestInstanceなど)
* CloudFormation
* ログを一元化(中央ロギング)することができる
* CloudFormationスタック
* 複数のリージョンやアカウントで一斉にプロビジョニング可能
* Opsworks
* サーバーのパッチ適用、アップデート、バックアップなどが自動的に実行される
* CloudFront
* S3バケット(オリジンサーバー)への直接アクセスを保護するためにはOAI(オリジンアクセスアイデンティティ)を使用する
* 現在のURLを変更したくないときは署名付きCookieを使用する
* オブジェクを更新して、古いものを読み込ませたくない場合はTTLを短くする
* VM Import/Export
* オンプレのVMwareなどをEC2にインポートできる
* Snowball
* ペタバイト級のデータを転送(数十日時間かかる想定)
* Direct Connect
* 専有 1 or 10Gbps
* 共有 ~ 10Gbps
* 追加で独立したネットワーク環境が必要な場合はVIFが最も低コスト
* バックアップ経路としてVPNが使える
* 他のリージョンのVPCにアクセスしたい場合はDirect Connect Gatewayを使用する
* DynamoDB
* DAX
* キャッシュからのレスポンスを高速化できる(アクセス集中のときに使用する)
* 高コストではあるため、先にAuto Scalingで対応できるかを検討する
* Streams
* 追加、削除などの履歴を取ることが可能
* キャプションをトリガーとして、クロスリージョンレプリケーションなどをすることができる
* AppSync
* データをリアルタイムで更新する
* Lambdaと連携するときはIAMロール
* Data Pipeline
* 定期的なデータ取得が可能
* 容量を増強するのはシャードテーブル
* 大量のデータの保存には向いていない
* RedShift
* 障害が発生した場合は自動または手動スナップショットから復元することになる
* クロスリージョンスナップショット
* プライマリリージョンに問題が起こった時に、即座にクラスターを復元できる
* パイロットライト
* 停止した状態の構成を別リージョンで用意
* コストがかかる
* CloudWatch
* 課金アラームも設定できる
* EC2の「メモリ使用量」はカスタムメトリックスを使用する必要がある
* RDS
* CPU利用率、メモリ空き容量、ストレージ空き容量はデフォルト
* 拡張モニタリングを使用すると、子プロセスやOSプロセスをモニタリングできる
* CloudWatchアラームを使用して、EC2インスタンスを事相的に停止、終了再起動などするアラームを設定可能
* CloudWatch AgentはLogs用でありアラームは出来ない
* CloudWatch Events
* EC2インスタンスの状態変化(ex. インスタンスの起動、停止など)(リソース変化)を監視
* EBSプロビジョンどIOPSボリュームは1分間、それ以外は5分間隔でメトリクスを送信する
* RDS
* RDSのAuto Scaleはストレージ容量の増加(負荷分散、スループットはリードレプリカ追加)
* ランダムI/O遅延を防ぐことが可能
* MyIsamは非推奨
* CloudWatchではCPUとメモリの割合は提供されない。
* みたい場合は拡張モニタリングを有効化する
* 読み取りはスケールアップではなく、リードレプリカの追加の方が適切
* 短期間でデータを破棄する用途には向いていない
* Enable IAM DB Authentication=IAMデータベース認証(IAMのDB認証を有効にする)ことでIAM DB認証を有効化できる(パスワードを使用する必要がない)
* Aurora
* カスタムエンドポイントを使用するとワークロードによってDBインスタンスを使い分けることが可能
* リードレプリカを採用することで別リージョンでも利用できるようになる
* MysqlとPostgreSQLの代わりに使える
* OracleなどはRDS
* SWF
* 一部の処理が滞ってる場合は手動アクションが必要とされている
* 分離アーキテクチャ(分散アプリケーションコンポーネント間で使える)
* Kinesis
* S3との連携には向いていない
* Route53
* 加重ルーティング
* Blue Greenデプロイはこれを使用
* Aliasレコード
* 以下のAWSサービスエンドポイントのIPアドレスを返す(通常はCNAMEを使用)
* 静的ウェブサイト(S3)
* CloudFront
* ELB
* フェールオーバールーティング
* Active/Activeの場合、異常が発生していない場合両方のインスタンスに処理を振り分ける
* ヘルスチェックの結果に応じて応答する
* AレコードはIPv4、AAAAレコードはIPv6
* MXレコード
* メールサーバー
* トラフィックフロー
* トラフィックルーティングをビジュアライズ(可視化)できる
* GuardDuty
* 「AWSアカウント」に対する検出サービス
* CloudWatch Eventと連携して、通知を設定できる
* Inspector
* 「アプリケーション」のセキュリティチェックサービス
* Cognito ID
* モバイルアプリのための認証サービス
* AD Connector
* クラウドの情報を使用せずに、オンプレのADとIAMとを連携することが可能
* すでにActive Directoryを使用している場合に使える(IAMロールも使用すること推奨)
* AWS X-Ray
* ユーザーリクエストを追跡、分析可能
* Perfect Forward Secrecy
* カスタマイズはELBとCloudfrontのみで使える
* AWS Shield
* DDos攻撃に有効
* CloudHSM
* 不正使用防止策が施されたHSMのアクセスを利用できる
* フェデレーション
* OpenID Connect
* ウェブIDフェデレーション(ソーシャルID=Facebook, Googleなど)を利用できる
* SAML2.0
* SAML2.0に対応している場合Active Directory
* LDAP
* SAML2.0に対応していない場合はカスタムIDブローカーを使用(STS)
* Amazon MQ
* メッセージブローカーサービス
* 既存のアプリケーションからメッセージングサービスを容易に移行できる
* AWS Step Functions
* 複数のAWSサービスをサーバーレスワークフローに整理できる