この記事は株式会社qnoteのQiita Advent Calendar 2022の13日目の記事です。
はじめに
AWS Certified Solutions Architect – Associate(SAA-C03)に一発合格したので、自分の学習内容についてまとめました。
ちなみに受験時点での私のステータスは以下の通り。
- WEBエンジニア(PHP,JSの使用経験1年半)
- AWS(EC2,RDS,S3)の使用経験1年半
この記事はあくまで自分の学習記録として残したメモです。
SAA受験のための全ての内容を網羅しているわけでは無いことをご了承ください。
対象者
この記事は下記のような人を対象にしています。
- 駆け出しエンジニア
- プログラミング初学者
- AWSの資格取りたいけど、何から手をつけたら良いかわからない人
結論
Ping-tやっときゃ間違いない。
AWS SAAを取得する勉強に使用した教材
合計約23時間、期間にして2ヶ月程度。
AWS Technical Essentials (Japanese) 日本語実写版 (5時間)
AWSの最も基本的な内容を学習できるコース。
日本人スタッフの小芝居がやや鼻につくが、内容はとてもわかりやすい。
Exam Prep: AWS Certified Solutions Architect - Associate (Japanese) 日本語字幕版 (3時間)
AWS SAAを受験するにあたり、どの程度準備ができてるか、を確認するコース。
かなり不明な内容が多かったため、次のBlack Beltで各サービスの概要を調べてまとめることに。
AWS Black Belt Online Seminar (4時間)
各サービス10~20分程度、調べてまとめる学習を繰り返した。
プレゼンを試聴したり、スライドを見ることができるので、お好みの学習スタイルを選べる。
Exam Readiness: AWS Certified Solutions Architect – Associate (Digital) (Japanese) (日本語実写版 (2時間)
AWS SAAを受験するにあたり、どの程度準備ができてるか、を確認するコース。
この時点で、「聞いたことのない単語はほぼ無いな〜」という状態に。
AWS Certified Solutions Architect – Associate Official Practice Question Set (SAA-C03 - Japanese) (45分)
模擬試験。
Ping-t(問題演習サイト)(8時間)
こちらから無料で登録できる。
SAA-C03に対応した問題が500問ほどあり、全て無料で何度もチャレンジできる。
問題は本番よりやや難しい問題が多かった印象。
この問題集の正答率を9割以上にしてけば安心ですね。
ぶっちゃけ、Black BeltとかExam Readinessを飛ばして、これに時間を割けば良かった、と反省。
問題に付随する解説が丁寧なので、自分で調べてまとめるより、間違った問題の解説を読んでいく方が効率的。
AWS受験トリビア
- オンライン受験で「試験官は英語、試験は日本語」という選択肢もある
- 合格した資格は3年間で失効する
- オンライン受験(Pearson Vue)のアプリのボタンの反応が鈍く、試験に集中できないレベルなので要注意
- オンライン受験でも、早く終われば、いつでも終了できる
モジュール0: 基礎知識
- データセンター<アベイラビリティゾーン(AZ)<リージョン
- AWSリージョンの考慮事項
- コンプライアンス
- レイテンシー
- 価格設定
- サービス可用性
- AWS APIにアクセスする3つの方法
- マネジメントコンソール
- コマンドラインインターフェイス(CLI)
- ソフトウェア開発キット(SDK)
- RootユーザーにはMFAはほぼ必須
- IAM
0-1.コンピューティング基礎
- コンピューティングオプション
- 仮想マシン(VM) = EC2
- AMI(Amazon Machine Image)
- EC2 インスタンスタイプ(インスタンスファミリー+世代番号)
- インスタンスファミリー
- 汎用(T,M)
- コンピューティング最適化(C)
- メモリ最適化(R)
- 高速コンピューティング(P,Gなど)
- ストレージ最適化(I,D,H)
- インスタンスファミリー
- EC2 インスタンスサイズ
- 起動→保留中→実行中→停止中→停止済み
- シャットダウン中→終了(終了保護オプションあり)
- 休止準備中or実行中のみ、課金される
- コンテナサービス(コンテナオーケストレーションツール)
- スケーリングを自動化・高速化できる
- ECS(Amazon Elastic Container Service)
- EKS(Amazon Elastic Kubernetes Service)
- サーバーレス
- アプリケーションの開発だけに集中できる手法(責任分解点が他と異なる)
- AWS Fargate(ECSやEKSを利用できるサーバーレス)
- AWS Lambda
- Lambda関数+トリガー
- CloudWatch Logsからアクセス可能。
- 長時間実行するサービスには不向き
- 使用中のみ課金される
- Lambda関数+トリガー
- 仮想マシン(VM) = EC2
0-2.ネットワーク基礎
VPC(Virtual Private Cloud)
- リージョン
- IP範囲(CIDR)
サブネット(パブリック(EC2)/プライベート(DBなど))
VPC
AZ
IP範囲(VPCの範囲内)
IGW(Internet Gateway)をVPCにアタッチすると、インターネットでEC2にアクセスすることが可能になる
VGW(Virtual Gateway)をVPCにアタッチすると、暗号化されたVPN接続できるようになる。
- メインルートテーブルはVPCと関連づけられている
- カスタムルートテーブルとパブリックサブネットを関連づけ
- 送信先:0.0.0.0/0、ターゲット:IGWで登録(=インターネット経由のアクセスを許可)
- ネットワークアクセスコントロールリスト(ネットワークACL)
- デフォルトで全て許可なので、許可or拒否ルールを設定する
- インバウンド/アウトバウンドでhttpとhttpsを許可する
- サブネットごとに設定する
- ステートレス
- セキュリティグループ
- デフォルトが「インバウンド:すべて拒否、アウトバウンド:全て許可」なので、許可リストを作成する
- インバウンドでhttp(ポート80)とhttps(ポート443)を許可する(ステートフルリソースだから)
- EC2インスタンスごとに設定する
- 監視
- メトリクス
- CPU使用率など
- メトリクス
- Amazon CloudWatch
- ELB(Elastic Load Balancing)
- 可用性が高く、自動的スケールが可能
- リージョナルサービス(S3やRDSと同じ)
- アプリケーションロードバランサー(ALB):http,https
- リスナー(ポート、プロトコル)
- ターゲットグループ
- ルール
- レイヤー7(アプリケーション層)
- ネットワークロードバランサー(NLB):tcp,udp,tls
- 低遅延で大量アクセス分散
- レイヤー4(トランスポート層)
- ゲートウェイロードバランサー(GLB)
- レイヤー3(ネットワーク層)
- サードパーティーの仮想ネットワークを拡張
- クラシックロードバランサー(CLB)
- 最も古い
- レイヤー7 or 4
0-3.ストレージ基礎
- ファイルストレージ
- 共有が必要なファイル(開発環境など)
- NASと類似
- ブロックストレージ
- 頻繁にアクセスするファイル(DBなど)
- DASやSANと類似
- オブジェクトストレージ
- アクセスが少ないファイル(画像など)
- EC2インスタンスストア
- EC2内部のストレージ
- エフェメラルボリューム
- 高速
- インスタンス停止・終了するとデータが保持できない
- EBS(Elastic Block Store)
- EC2外部のストレージ
- インスタンス停止・終了してもデータが保持できる
- EC2インスタンスと1対1でアタッチする
- デタッチしない限り、他のインスタンスでは利用できない
- ボリュームタイプ
- SSD
- HDD
- S3(Simple Storage Service)
- インターネット用ストレージ
- オブジェクトストレージ
- 分散ストレージ
- 5TB/個のファイルを無制限に保存可能
- バケット名
- dns準拠(特殊文字やスペースはNG)
- EFS(Elastic File System)
- ファイルストレージ
0-4.データベース基礎
- RDS
- Managed DB
- DBソフトウェア管理の責任なし
- EC2でDBをホストする
- Unmanaged DB
- DBソフトウェアの管理が必要。
- RDSは単一のAZ内のサブネットでホストされる
- マルチAZ配置をすることで、2つのAZに同期したRDSを配置できる
- DNS経由でフェイルオーバーが実現できる
- Purpose build Database
- Amazon DynamoDB
- 非リレーショナルDBなので、とにかく早い
- 読み書きしてる間だけ課金
- Amazon DocumentDB
- コンテンツ管理に最適(MongoDB互換)
- Amazone Neptune
- グラフデータベース
- SNS分析
- Amazon QLDB
- 不変な台帳データベース
- 銀行、不動産など
- Amazon DynamoDB
- Amazon DynamoDB
- サーバレスDB
- テーブル>項目>属性
- 非リレーショナルDB
- フルマネージドnoSQL DB
- 大量アクセスに適する
- オンラインゲームなどに適している
ここまでが基礎内容となります。
以下のモジュール1~4は実際の試験項目に沿ってまとめました。
モジュール 1: 弾力性に優れたアーキテクチャ
1-1.多層アーキテクチャソリューションの設計
1-2.可用性と耐障害性に優れたアーキテクチャの設計
災害対策(DR)の計画
DR目標は2つ
- 目標復旧時間(RTO):サービスの中断からサービスの復元までの最大許容遅延(=ダウンタイム)
- 目標復旧時点(RPO):最後のデータ復旧ポイントからの最大許容時間(=データ損失)
戦略は4種類
戦略名 | 手法 | RPO/RTO | データ | サービス | コスト |
---|---|---|---|---|---|
バックアップと復元 | アクティブ/パッシブ | 数時間 | バックアップ済 | なし | $ |
パイロットライト | アクティブ/パッシブ | 数十分 | ライブ | アイドル | $$ |
ウォームスタンバイ | アクティブ/パッシブ | 数分 | ライブ | キャパシティを下げて実行 | $$$ |
マルチサイトアクティブ/アクティブ | アクティブ/アクティブ | ほぼリアルタイム | ライブ | ライブ | $$$$ |
CloudFormation
- インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができるサービス。
- テンプレートを作成すると、同じ構成を何度も構築できる
- テンプレートはリージョンを跨いで使用可能。
- マッピングを使用すれば、別リージョンに対しても同じAMIを指定することが可能。
1-3.デカップリングメカニズムの設計
非同期デカップリング
API Gateway + Lambda + SQS + Aurora
Amazon Simple Notification Service (SNS)
- Message や Topicの設定、操作、および送信ができる
- 「publish-subscribe (pub-sub)」は、定期的なポーリングを行う必要のない「push」通知メカニズムを使ってfan out (一括送信) できる
- HTTP/SやEメールなど複数の「プロトコル」に対応
Amazon Simple Queue Service (SQS)
- キューにメッセージを最大14日保存。
- 大量リクエストが一時的に発生する場合にキューで受ける。
- アプリケーション間の依存関係を弱めたい場合に利用。
- 重い処理が含まれていても素早く応答をしたい場合に利用。
- 複数の処理を並列処理したい場合に利用。(SNS+SQS)
キューは2種類。
スループット | 配信方式 | 配信順序 | 利用料金 | |
---|---|---|---|---|
スタンダードキュー | ほぼ無制限 | 二回以上の配信もあり得る | 順序が変わることもある | 100万件を超えた場合100万件ごとに0.4USD |
FIFOキュー | 1 秒あたり最大 300 件のメッセージ | 1回のみ | 順序性を保つ | 100万件を超えた場合100万件ごとに0.5USD |
キューのアクセス制御は2種。
- IAMポリシー:ユーザー/ロールに対して制御
- SQSポリシー:キューに対して制御
(参考)連携サポートマネージドサービス
- ストリーミングデータ
- Kinesis:テキストから動画まで
- Kafka
- API Gateway
- メッセージデータ
- SNS:push方式、pub/sub
- SQS:pull形式、P2P
- MQ:pull式、P2P or pub/sub
Amazon EventBridge
サーバレスのイベントバスサービス
SNSでは実現困難な、組織を跨いだ複雑な連携に対応。
3種のイベントバス
- デフォルト:AWSサービスと連携
- カスタム:独自のアプリと連携
- パートナー:SaaSと連携
料金は「AWSサービスの受信は無料、それ以外は有料」
1-4.耐障害性ストレージの選択
各ストレージサービスまとめ
- ブロックストレージ
- EBS
- インスタンスストア
- オブジェクトストレージ
- S3
- Glacier
- ファイルストレージ
- EFS
EFS
- NFS(Network File System)によるストレージ
- アクセスはファイル単位
- フルマネージド
- 同一VPC内の場合、複数AZのEC2からアクセス可能
- ユースケース
- パッケージアプリの共有ディレクトリ
- ビックデータ
- コンテンツの共有リポジトリ
- コンテナインスタンスフリート全体が使用するデータ
- S3、EBSとの違い
S3 | EFS | EBS PIOPS | |
---|---|---|---|
スループットスケール | スケーラブル | 数GB/s | 0.5GB/s |
耐久性 | 3カ所以上で複製 | 複数AZ | 単一AZ |
レイテンシ | 比較的あり | 少しあり | ほぼ無し |
ユースケース | ビックデータ メディア処理ワークフロー コンテンツ管理 Web配信 ホームディレクトリ |
ブートボリューム トランザクション NoSQL DB データウェアハウス ETL |
|
スループット重視 | レイテンシー重視 |
EBS
- アクセスはブロック単位
- 最大容量は16TiB
- 同一AZのインスタンスのみアクセス可能
- EC2に複数のEBSを接続可能
- EBSは複数の同一AZ内EC2にアタッチすることができる
- ボリュームタイプは4種
汎用SSD | プロビジョン度IOPS | スループット最適化HDD | コールドHDD | |
---|---|---|---|---|
ボリューム | 1~16Tib | 4~16TiB | 0.5~16TiB | 0.5~16TiB |
IOPS | 100~16,000 | 100~64,000 | ~500 | ~250 |
スループット | 160MiB/s | ~500MiB/s | ~500MiB/s | ~250MiB/s |
ユースケース | システムブートボリューム 仮想デスクトップ 小~中規模のデータベース 開発環境や検証環境用 |
高い IO 性能を要求するアプリケーション 高い性能を要するワークロード 大規模なデータベース |
EMR データウェアハウス 大規模なETL処理 大規模なログ分析 |
ログデータ保管 バックアップ アーカイブ |
コスト | 低い | 高い | 高い | 低い |
モジュール 2: 高性能なアーキテクチャ
2-1.コンピューティングソリューションの特定
2-2.ストレージソリューションの選択
S3
- 容量無制限
- 高い耐久性
- 安価
- スケーラブル
- VPC Endpoint
- 同一リージョンでNAT Gatewayを経由せずにprivate subnet内のサービスからS3へアクセス可能にする。
- ストレージクラス
Standard | Intelligent-Tiering | Standard-IA | One Zone-IA | Glacier | Glacier Deep Archive |
---|---|---|---|---|---|
最低保持期限 | 30日以上 | 30日以上,128KB以上 | 30日以上,128KB以上 | 90日以上 | 90日以上 |
アクティブ | 変化するアクセスパターンのデータ | 低頻度アクセスデータ | 再作成可能な低頻度アクセスデータ | アーカイブデータ | アーカイブデータ |
マルチパートアップロード(100MB以上)
2-3.ネットワークソリューションの選択
Managed VPN
- AWS Site-to-Site VPN
- VPC とリモートネットワーク間で、IPsec および VPN 接続を作成できます。
- Site-to-Site VPN 接続の AWS 側では、仮想プライベートゲートウェイによって、自動フェイルオーバーのための 2 つの VPN エンドポイント (トンネル) が提供されます。
- Site-to-Site VPN 接続のリモート側でカスタマーゲートウェイを設定
Direct Connect
- お客様がキャリヤから調達する専用線の片端とAWS Cloudを、Direct Connectロケーションで接続するサービス
Transit Gateway
- 他拠点から接続する場合に利用
VPN CloudHub
- リモートネットワークが複数ある (たとえば、複数の支社がある) 場合は、仮想プライベートゲートウェイを通じて複数の AWS Site-to-Site VPN 接続を作成すると、それらのネットワーク間で通信できるようになります。
- 支社間でVPNできるようになるということ
参考ドキュメント
VPC ピアリング(最大125)
参考ドキュメント
PrivateLink
- 自分のVPCのNLB配下のWEB等のサービスを、同一リージョン内の他のVPCに公開できるサービス。
- VPCピアリング等と異なり、IPアドレスレンジの重複等の考慮が不要で、AWS内に閉じた安全なNW接続を実現できる。
- サービスを公開する側(エンドポイントサービス)と、サービスにアクセスする側(インターフェースエンドポイント)のセットで構成される。
VPCエンドポイント
- エンドポイントサービス
- VPC 内の独自のアプリケーション。
- 他のAWSプリンシパルは、そのVPCからエンドポイントサービスへの接続を作成できる。
- ゲートウェイエンドポイント
- サポートされるAWSサービスを宛先とするトラフィックのルートテーブルで、ルートのターゲットとして指定するゲートウェイです。
- S3
- インターフェイスエンドポイント
- インターフェイスエンドポイントは、サポートされているサービスを宛先とするトラフィックのエントリポイントとして機能するサブネットの IP アドレス範囲のプライベート IP アドレスを持つElastic Network Interface
Route 53
- ネームサーバーをマネージドで提供するサービス
Global Accelerator
- ALB、NLB、EC2の前段に置いてアプリケーションの可用性とパフォーマンスを改善するサービス。
- ALB、NLB、EC2はエンドポイントとして扱われ、エンドポイントはエンドポイントグループに属します。
- 基本的には特定リージョンにエンドポイントグループを作成しますが、リージョンを跨いでバランシングすることも可能なので、リージョン間でのアプリケーションのバランシングも可能。
- EC2に置いてALBなどがLBの役目をしますが、ALBに置いてはGlobal AcceleratorがLBのような役目を行います。
- CloudFrontとの違い
プロトコル | キャッシュ | クライアント証明書 | |
---|---|---|---|
Global Accelerator | TCP/UDPのトラフィック・ルーティングに対応 | 使わない | 利用する |
CloudFront | http/httpsのみ対応 | 使う | 利用しない |
CloudFront
- エッジロケーションで利用する負荷分散のためのマネージドサービス
- エッジロケーションにオブジェクトとしてキャッシュを保存
- Route53 > CloudFront > ELB > EC2
- 高速配信
- データ保護
- レポート・ロギング
DataSync
- データ転送のためのフルマネージドサービス
- ユースケース
- オンプレミスからのデータ移行
- ストレージレプリケーションによるDR
- SMBデータのHotバックアップ
- データのアーカイブ
Snow Family
- データセンターの設置が困難な厳しい環境や、ネットワーク接続が不安定な場所でも、お客様のオペレーションを実行可能にする製品
- 下記3サービスから構成される
- AWS Snowcone
- Snowファミリーで最も小さく、8TBの使用可能なストレージを搭載。
- 大体ティッシュ箱より少し大きいくらいのサイズで持ち運びするのに優れています
- 耐久性も高い。
- AWS Snowball
- Snowball Edge Storage Optimized(100TB)
- Snowball Edge Compute Optimized(42TB)
- AWS Snowmobile
- セミトレーラートラックが牽引する長さ14mの輸送コンテナ
- マルチペタバイトまたはEB(エクサバイト)規模のデジタルメディアの移行やデータセンターの停止に最適
- AWS Snowcone
Transfer Family
- AWS ストレージサービスとの間でファイルを送受信できるフルマネージドの転送サービス
- SSH
- SFTP
- FTPS
- FTP
- AS2
DMS(Database Migration Service)
- フルマネージドDBに移行するためのサービス
- 物理では無く、論理レプリケーション
- フルロード(既存データ)
- CDC(更新差分)
2-4.データベースソリューションの選択
RDS
- フルマネージドDB
- マルチAZデプロイメント
- リードレプリカは5台まで
- 汎用SSD
- プロビジョンドIOPS SSD(低レイテンシー)
- マグネティック(HDD,下位互換)
- 複雑なトランザクションやクエリが必要な場合、採用。
Aurora
- マネージドDB
- 6つのコピーが作動
S3データレイク
- 規模にかかわらず、すべての構造化データと非構造化データを保存できる一元化されたリポジトリ
DocumentDB
- ユースケース
- コンテンツ管理
- モバイルアプリ
- カタログ
- マーケティング
- ゲームユーザープロファイル
- MongoDB互換性あり
- フルマネージド
- JSON-likeなデータ群を管理
- 6つのコピーが3AZで稼働
- S3に定期的にバックアップ
サービス名 | 向いている用途 |
---|---|
RDS | トランザクションと使って信頼性の高いクエリを投げたい 金融・認証などのスキーマに従いたい Oracle, MySQL, PostgreSQL, RDBMSの既存システムから移行したい |
DynamoDB | スケーラブルに使いたい JSONをネストさせて柔軟にアクセスさせたい |
DynamoDB
- フルマネージドのNoSQLDB
- ハイスケーラブル、低レイテンシー
- ストレージの容量制限無し
- ユースケース
- 広告・ゲームのユーザーログ
- モバイルアプリのバックエンド
- 各言語対応のSDKあり
- DynamoBD Streams
- 24h以内の履歴を保持し、取り出し可能にする
RedShift
- データレイク分析のためのマネージドサービス
- ユースケース
- 経営ダッシュボード
- 定型レポート
- アドホック分析
- 機械学習の前処理
- ETL / バッチ
モジュール 3: セキュアなアプリケーション
3-1.アクセスの設計
3-2.アプリケーション層の設計
3-3.データセキュリティオプションの選択
Key Management Service (KMS)
- Key Management Infrastructure (KMI)
- 暗号鍵保管のための仕組み
- リージョン間での鍵の共有はできない
CloudHSM
- ハードウェアベースのキー管理
Certificate Manager(ACM)
- TLS / SSLキーの管理
Marketplace
参考ドキュメント
OpenSSL
参考ドキュメント
モジュール 4: コストを最適化したアーキテクチャ
4-1.ストレージソリューションの特定
AWS Trusted Advisor
- ベストプラクティスのチェック
- コスト最適化
- パフォーマンス
- セキュリティ
- 耐障害性
- サービスの制限
Data Lifecycle Manager(DLM)
参考ドキュメント
Backup
S3 Intelligent-Tiering
4-2.コンピューティングサービスとデータベースサービスの特定
オンデマンドインスタンス
リザーブドインスタンス
ハードウェア専有インスタンス
スポットインスタンス
Saving Plans
リードレプリカ
4-3.ネットワークアーキテクチャの設計
CloudFront
踏み台ホストを使用したSecure Shell(SSH)
Remote Desktop Protocol(RDP)
Systems Manager (SSM)
- 安全かつスケーラブルにAWSを運用するためのサービス
- マネージドインスタンス化
- SSMエージェント
- SSM APIへのアクセス経路
- EC2ロール
- SSM セッションマネージャー
- 通信ポートを解放せずにサーバーにシェルアクセスする手段
EC2 Instance Connect
おわりに
AWS Certified Solutions Architect – Associate(SAA-C03)を受験するための学習内容についてまとめました。