AWS認定ソリューションアーキテクト（SAA）合格に必要な知識

2022-02-21 AWS SAA に合格したので、
合格までに勉強してメモした AWS 情報を公開します。

以下が頭の中に入っていればバッチリです。

AWS SAA

S3

• S3 クロスリージョンレプリケーションは、バケットでバージョニングを有効にする
• バケット名は全世界でユニークであること
• バケット（箱を用意して）、オブジェクト（ファイル）を入れる
• Public 公開する
  • バケットでアクセス許可
  • オブジェクトでアクセス許可
  • デフォルトは非公開
  • バケットポリシーで ACL 制御する（Policy Generator で作成可能）
• ACL ポリシーは 20 KB の制限があることからアクセスポイントを追加することができる
• 「静的ウェブサイトホスティング」を有効にすると S3 バケットが Webサーバになる
• マルチパートアップロードをすることで分割アップロードできる
• 上書きは苦手
  • 変更箇所が少なかったとしてもオブジェクトをすべて再アップロードが必要なため
• ライフサイクルポリシーで S3 標準 → Glacier → Delete を自動でやってもらう
• 著名付き URL を発行すると一時的な公開ができる
• 永久的に公開するには ACL を正しく設定する
• Transfer Acceleration
  • CloudFront + S3 で構成し、地理的に離れている地域からの S3 アクセスを高速化する（CloudFront Edge Location へ接続する）
• Intelligent Tiering
  • 実際の利用頻度に応じて自動的に適切な S3 ストレージクラスを選択する
  • アクセス頻度やパタンが未知数のときに有効

Amazno S3 Glacier

• Type
  • 迅速： 1 ～ 5 分
  • 標準： 3 ～ 5 時間
• 大容量： 5 ～ 12 時間
• ストレージクラス
  • S3 標準： 頻繁にアクセスするデータ
  • S3 標準 IA： 低頻度アクセスで長期保管向け（かつアクセスには即応答）
  • S3 標準 1 Zone IA：冗長性が低い
  • Amazon Glacier/Deep Archive ： 長期保管

EC2

• 使い捨て可能な状態で作っていく（データを保持したりしない）のがベスト・プラクティス
• 使い捨てするためには AMI を作る（or 既存のを利用）必要がある
• AMI を作るためにはいくつかのやり方がある
  • オンプレ Migration
  • EC2 Image Builder（Ansible のような IaaC で自動ビルド）
    • OS パッチ適用とかに利用する
    • → パッチ適用済みの AMI を作る。その後、EC2 インスタンスを入れ替える。
  • AP Deploy のようなライフサイクルが短いものは「ユーザデータ」を利用する。
  • ライフサイクルが長いもの（パッチ適用とか）は AMI に入れる
• ファミリー
  • t：コスト抑えつつバーストする可能性があるとき
  • a：ARM
  • c：CPUたくさん
  • r：メモリたくさん
  • m：CPU/メモリバランスよく
• ファミリーの世代は新しいほうがよい
  • コストも下がるのに性能は上がっているので悪いことはない
• 料金／コスト
  • オンデマンドインスタンス
    • 長期契約は不要
    • 前払いなし
    • 割引なし
  • リザーブドインスタンス
    • 予約して利用する（1年 ～ 3年とか）
    • 前払い
    • まとめ買いすることが安くなる
    • スタンダード： ずっと固定（制約があるかわりに安い）
    • コンバーティブル： インスタンスタイプを上下変動できる
  • Savings Plans（RI の上位互換に近い）
    • 割引率は RI より落ちるが利用料金をコミットすることで割引する
  • スポットインスタンス
    • 余っているインスタンスがあれば利用する
    • だいぶ安い
    • 突然削除される可能性がある（2 分前に中断通知が届く）
  • Dedicated Instances
    • 特定の HW で必ず動くが選択はできない（再起動しても同じインスタンス）
    • セキュリティ要件とかが厳しいときに選択する
  • Dedicated Hosts
    • 動く HW を特定して制御できる
    • セキュリティ要件とかが厳しいときに選択する
• Compute Optimizer
  • 利用中のリソース分析ができるサービス
• クラスタープレイスメントグループ
  • 性能重視。大量のサーバをなるべく同じサーバで動かす。
• スプレッドプレイスメントグループ
  • 信頼性重視。なるべく違うサーバで動かす。
• T シリーズは、CPU クレジット方式でリソース制御をしていく
  • CPU を使っていないときはクレジットを保管していき、CPU 利用するときにクレジットを利用していく。そのため、バーストするようなときにも対応することが可能。

スポットインスタンス

• スポットインスタンスは 2 分前に中断通知がくる。CloudWatch で取得して Lambda 経由でオンデマンドインスタンス起動可
• スポットインスタンスの利用を終えるとき
  • 「リクエストキャンセル」→「インスタンス停止」
  • 先にインスタンス停止すると新しいスポットインスタンスが起動する
• ワンタイムリクエストの場合は、インスタンス停止すると利用終了になる

EBS

• EC2 とは別のインスタンスで動いているディスク
• EC2 からは NW 経由で接続する
• Type
  • 汎用 SSD
  • プロビジョンド IOPS SSD
  • スループット最適化 HDD
  • コールド HDD
• EBS 最適化あり
  • NW 接続で接続する際に、EC2 の通常業務 NW と同じ帯域を利用するが、最適化ありにすると専用の NW で利用できる（帯域が太く早くなる）
• EBS はアタッチできるインスタンスは一つのみ
• データを共有したいとき、、、
  • EBS： 共有できないので不可
  • S3： 共有はできるが理想的ではない。ディスクアクセスをすべて API コールに変える必要があるので現実的ではない。
  • EFS/FSx：基本的に選ぶべき

AWS Global Accelerator

• http/https だけではなく、tcp/udp もルーティングできる ALB 等の前に置くスループット最適化のためのネットワークサービス
  • 動的なコンテンツを世界展開した際にスループットを上げる
  • 静的は CloudFront で OK
• Amazon が所有している NW を利用して通信できる（Internet より早くて安定している）

AWS Snowball

• ペタバイト規模のデータ転送（S3へ）
• 手元に物理デバイスが届き、格納して送り返す

Snowball Edge

• PC が届く
• S3 への格納はできるが、S3 Glecir のボールドへは直接格納できない
  • 一度 S3 に入れて、ライフサイクルポリシーで Glecir へ移動する

AWS Snowmobile

• エクサバイト規模のデータ転送（S3へ）
• 手元に物理デバイスが届き、格納して送り返す
• リージョン選択のやり方
  • データの所在と法令遵守（海外は NG とか）
  • ユーザから近い場所
  • サービスの機能と可用性（利用可能なサービスはリージョンごとに違う）
  • コスト効率（リージョンによってサービス料金が違う）

Amazon FSx

• ONTAP！！！
• SMB や ZFS を使うときはこっち

Amazon FSx for Lustre

• S3 連結の高性能ファイルシステム

Dynamo DB

• パーティションキーで格納するパーティションを特定する
• ソートキーでパーティションのなかで格納する場所を決める
• PK = パーティションキー、複合キー： パーティションキー & ソートキー
• 一つのパーティションに集中すると性能が劣化するので注意が必要！！
• グローバルテーブルに書き込むとマルチリージョンにレプリカを作る
• 結果整合性である（NoSQL の特性）
  • 書き込みが即時ではなく読み込むときまでに一貫性が保証されていればよい
  • 書き込み後、約 1 秒後に整合性が取られる（各 AZ へ連携する時間）

DynamoDB の拡張方法

• キャパシティーモード
  • オンデマンド
    • スパイク処理可能
  • プロビジョンド（デフォルト）
    • 読み込みと書き込みのキャパシティサイズを手動設定できる
    • 1 秒間に XXX 件の処理を消費できる（XXX = 設定値）
    • Auto Scaling も設定できる（基本的には Auto Scaling が望ましい）

DynamoDB Accelerator（DAX）

• DynamoDB に特化したインメモリキャッシュのマネージドサービス

DynamoDB Streams

• テーブルに対する変更を監視して最大 24 時間ログに保存する。
• テーブル変更に対するトリガーを設定することも可能。

AWS Database Migration Service

• オンプレからの移行（ちょっとずつ移行可能）
• スキーマ変換はできない
• スキーマ変換するときは AWS Schema Conversion Tool を使う

Amazon Kinesis

• ストリーミングデータのリアルタイム処理（Redhisft は Kinesis より重たいデータや重たい処理向け）
• Amazon Kinesis Video Streams
  • ストリーミング動画のキャプチャ、分析、保存
• Amazon Kinesis Data Analytics
  • SQL 発行できる
• Amazon Kinesis Data Streams
  • ストリーミングデータのキャプチャ
• Amazon Kinesis Data Firehose
  • AWS データストアにロードする

VPC

• VPC リージョンに対して適用する。複数 AZ に適用可能。
• マルチ VPC パタン
  • 小規模向け。NW で分離する。
• マルチアカウントパタン
  • 大規模向け。アカウントで分割する。
  • 本番用 1、開発用 1（かつマルチ VPC ）がよくあるパタン
• 各リージョンには 5 つまで作成可能
  • 1 つはデフォルトで作成されるので基本的には 4 つ
  • もっと欲しい場合は AWS へ上限緩和申請をする
• VPC の中に subnet を作る
  • subnet は AZ に配置する
  • subnet は作るたびに 5 個の IP アドレスをリザーブする（ので使えない）
• VPC 内では自由に通信可能（ルーティング）
• ノウハウ
  • 小さいsubnetより大きいsubnetを検討する（/24 以上）
    • 小さすぎるとオートスケールなどで IP 枯渇しかねない
  • AZ ごとにパブリックとプライベートを割り当てるとよい
• CIDR 分割して VPC を作成するが、一つの VPC に対して追加の CIDR 範囲を割り当てることもできる

AWS Config

• AWS リソースの設定変更をモニタリングする
• 変更を検知すると SNS で通知できる

Amazon Aurora Serverless for Aurora MySQL

• Amazon Aurora のオンデマンドで Auto Scaling してくれる（性能無限）
• 容量を木にせず利用可能で、DB が Active のときだけお金がかかる
• Single AZ
• 従量課金なので、全く使われない可能性や突然多数のリクエストが発生する場合などに有利

AWS Storage Gateway

• ボリュームゲートウェイ
  • iSCSI でデバイスマウント
• ファイルゲートウェイ
  • S3 を NFS や SMB で利用できる
  • オンプレ側に GW 用の VM マシンか、物理的なマシン（HWアプライアンス）を用意する

Amazon EFS

• ライフサイクル管理
  • 一定期間アクセスがないファイルを、標準IA または 1ゾーン IA へ移行できる
  • ライフサイクルポリシーが使える

メカニカルシンパシー

• ワークロードごとに必要なサービスを選定できること
• 例えば、DB も RDB だけではなく、利用する機能（ワークロード）ごとに必要なデータ構造を検討して適切なサービス（RDB or NoSQL）を選定する

リージョン別エッジキャッシュ

• CloudFront でデフォルト使用
• エッジロケーションに保存する必要があるほど頻繁にアクセスされないコンテンツを置く

ENI

• セカンダリ ENI を追加すると、プライマリサーバがダウンした際にスタンバイサーバに ENI をアタッチすることができる
  • 要は VIP のように Active-Standby を構成できる（NW だけ）
• アダプタを増やすことは意味がない
  • 帯域も増えない
  • 冗長化の意味もない
• FW ルールがめんどうになる
• ec2 には可能な限りホスト名や ip は固定化しない

Elastic IP アドレス

• 固定 IP

セキュリティグループ（ファイアウォール）

• ENI 単位で設定する
• ルールはステートフル
• デフォルトは、
  • インバウンドはすべてブロック
  • アウトバウンドはすべて許可

ACL 制御

• subnet 間でのファイアウォール
• デフォルトはすべてのインバウンド、アウトバウンドを許可
• ルールはステートレス（戻りの通信も明示的に開ける必要がある）

ネットワーク設計の考え方

• 基本的にはセキュリティグループで制御する（必須なので）
• ACL はオプション制御で基本的には使わない

インターネット接続

• インターネットGWが必要
• プライベートsubnetから外に出ていくときは NAT GW
• 外から接続したい（DNAT）ときは NAT インスタンス

VGW（VPN Gateway）

• インターネット経由接続の VPN（IPsec）

AWS Direct Connect（DX）

• 閉域網を経由した VPN 接続
• DX ロケーション提供事業者がある
• 顧客拠点 <> DX ロケーションでルータを設置して契約する
• DX ロケーションまで距離が遠い（東京、大阪、豊洲）場合は、DX パートナーという中間業者を利用する（ISP の閉域網を利用して DX ロケーションまでつなぐ）

VPN 経路冗長化

• メイン回線は DX、バックアップは VGW（DX 2本は高い）

VPC ピア接続

• VPC 間接続
• リージョン内、リージョン間をサポート
• IP 空間は重複できない（CIDR を分ける）
• VPC 間で一つしか作成できない（が、内部的に冗長化されている）
• ピアをまたいだ通信はできない 1 on 1 の関係のみ
  • フルメッシュ型のネットワークはできない
• 帯域制限なし
• リージョンをまたいでもインターネットにはでていかない

AWS Transit Gateway

• VPC ピア接続より少し高いが高機能
• スター型のネットワークを構成できる
  • すべての NW を接続する Hub として機能する
• ルーティング
  • Transit Gateway ルートテーブル
  • VPC ごとのルートテーブル

VPC エンドポイント

• VPC の外にいるマネージド・サービス系にプライベートに接続する
• AWS バックボーン NW と接続する
• ゲートウェイエンドポイント（無料）
  • S3、DynamoDB
• インターフェイスエンドポイント（有料）
  • その他のサービス（SNS や CloudTrail など）
• エンドポイントは VPC 以外のアドレスからは受け付けられない
  • オンプレから VPN 経由で接続したい場合などは SNAT をする必要がある（プロキシファーム）

ELB

• Support: HTTP, HTTPS, TCP, SSL
• ALB（Application 層）
  • HTTP, HTTPS のバランシング（通常の LB）
• NLB（Network 層）
  • TCP, UDP, TLS のバランシング
• GLB
  • IPS や IDS へ転送可能
• Connection Draining（予閉塞機能）
  • 削除する EC2 インスタンスを予閉塞状態にし、セッションがなくなれば削除する

Route 53

• DNS
• 名前解決だけではなく、ヘルスチェック機能を保持していることからリージョン間の FO をさせることができる（ALB への IP アドレス）
• ルーティング
  • シンプルルーティング
    • 一つの IP ルーティング
  • 複数値ルーティング
    • DNS レコードに複数 IP を登録して生きている IP だけ返却する
  • 加重ルーティング
    • 重み付けをして振り分けバランスをコントロールする
  • レイテンシールーティング
    • レイテンシーがもっとも低い IP を返す（地理的に有効）

IAM

• IAM プリンシパル： 認証
  • IAM ユーザ
    • デフォルトはアクセス許可なし（すべての認可なし）
  • フェデレーティッドユーザ
  • IAM ロール
• アクセス許可（認可）
  • API コールに対する制御をする（ハイパーバイザより上は制御できない）
    • つまり、OS 認証や AP 認証では利用しない
  • リクエスト時に評価する
  • 順序： 拒否の評価 → 許可の評価 → Any 拒否
• ポリシー
  • リソースベースポリシー
    • S3 は ○○ なら OKのような感じ

STS

• IAM 情報を操作するためのインターフェイス
• STS ID ブローカを利用すると、社内の AD と連携して一時的な認証情報を発行することができる

Amazon Cognito

• ユーザプール（認証）
• ID プール（認可）

AWS Organizations

• 複数の AWS アカウントを組織（Organizations）でまとめられる
• 請求の一元化

Control Tower（無料）

• AWS Organizations を AWS 推奨の形でセットアップできる

Cost Explorer（コスト最適化）

• 利用状況の傾向を分析してくれる
• Savings Plans などの推薦もしてくれる

Amazon CloudWatch

• 監視
• CloudWatch Logs
  • ログ監視
• CloudWatch アラーム
  • 通知

EventBridge（昔は CloudWatch の一つだった）

• イベント監視

AWS CloudTrail

• 監査／監視
• ログ保管先は S3
• ログはデフォルトで暗号化済み（S3 サーバ暗号化）
• ログが改ざんされていないことを保証するための整合性チェック機能あり

Amazon Athena

• 分析基盤
• CloudTrail の JSON に対して SQL で取得して分析したりできる

VPC フローログ

• 有効にしておくとトラフィックを記録してくれる

GuardDuty

• 監視結果を機械学習を用いて不審なアクティビティを検出、通知する

Auto Scaling

• ELB と組み合わせて使う
• AZ は分散してくれる
• 台数制御方式
  • 必要なキャパシティ（自動制御で必要な台数を計算する）
  • 最小キャパシティ
    • AZ の数と Auto Scaling グループを同じにすると分散配置してくれる
  • 最大キャパシティ
    • 運用中に見極める
    • が、無限ループ等で無限にリソースを使っていかないように必ず設定する

AWS CloudFormation（IaaC）

• S3 に Upload する
• JSON or YAML
• DeletionPolicy（を有効にすると）
  • データを保持するようなものを変更する場合（S3, RDS 等）は、スナップショットを取得して変更（削除）してくれる
• スタックは適切に分割して作っていくとよい

AWS Elastic BeansTalk

• Web App と MQ Waker App のインフラ含めた一連を提供する
• 利用者はコードをアップロードするだけ

AWS OpsWorks

• Chef, puppet のレシピを利用可能（マネージドサービス）

AWS CloudFront

• CDN
• リージョン外にあるエッジロケーションにある
• TTL = Cache 保持時間（sec）
• ビヘイビアでパスに基づいて複数のオリジン指定ができる
  • /api* = API GW とか
  • .img =S3 とか
• 特定の国からのリクエストを除外したいときは CloudFront が必須（ALB だけではできない）

AWS Shield

• DDoS 保護
• AWS CloudFront を利用すると Shield Standard が無料でついてくる
• Shield Advanced だと DDoS で跳ね上がったコストを AWS が補填してくれる

Amazon ElastiCache

• インメモリのデータストア
• RDS のキャッシュにも使える
• フルマネージドサービス
• Redis or Memcached

Redis

• シングルスレッド
• マルチノードで動く（こともできる）

Memcached

• マルチスレッド
• 1 ノードで動く（可用性はない）

Amazon SQS

• キューのマネージドサービス
• 標準キュー（分散処理）
  • 最低 1 回の配信をする（複数回送る可能性がある）
  • 冪等性が必要
• FIFO キュー
  • 1 回のみの処理
  • パフォーマンスは標準キューより落ちる
  • 整合性を保って非同期処理にしたいとき
• 可視性タイムアウト
  • メッセージ取り出したらロックを掛ける
  • 同じメッセージを複数インスタンスで処理しないようにするときに使う
• キューの受信待機時間
  • 空のメッセージを取得する可能性を下げたいときに待機時間を増やす

Amazon SNS

• 通知
• トピックに紐づくサブスクライバを管理できる
• トピックにメッセージを渡すと登録済のサブスクライバへ連携する
• E Mail、HTTP/HTTPS、SMS、SQS、Lambda

SQS と SNS

• SNS で SQS へキューイングする仕組みが多い
• SQS はパブサブができないので、SNS でサブスクライバとして SQS を登録することでキックできる
• 画像アップロード後の圧縮とかは S3 Upload を SNS でイベントをひろい、SQS をキックする

Amazon MQ

• MQ のマネージドサービス
• Active MQ
• すでに MQ を使っている人向け
  • 1 から作るのであれば SNS + SQS が良い

Amazon ECS

• コンテナのオーケストレーション（コンテナ実行管理）
• Amazon オリジナル

Amazon EKS

• コンテナのオーケストレーション（コンテナ実行管理）
• Kubernetes

Amazon ECR

• コンテナのリポジトリサービス

AWS Fargate

• フルマネージド型のコンテナサービス
• コンテナのホスティングサービス
• EC2 でコンテナを動かすのではなくおまかせしたいのであれば Fargate

コンテナのパタン

• ECS + EC2
• ECS + Fargate
• EKS + EC2
• ESK + Fargate

AWS Lambda

• ステートレス
• FaaS（Function as a Service）
• 最大 15 分間の実行
• 利用時間課金

AWS Step Functions

• 複数の Lambda を連携できる（直列、並列）
• ステートマシン
• Lambda 等をひとつの Function を大きくするのではなく、細かく作ってそれを連携する（ステートを保持することができる）

RPO/RTO

• Amazon S3
  • 複数 AZ、単一 リージョン
  • クロスリージョン レプリケーション を利用することもできる
• Amazon S3 Glacier
  • 複数 AZ、単一 リージョン
  • クロスリージョンは利用できない
• Amazon EBS
  • 単一 AZ
  • ポイントインタイムボリュームスナップを S3 に保管
• AWS Snowball
  • 物理的に複製する
• AWS DataSync
  • EFS, FS, S3, オンプレでデータをレプリケートできる
• Amazon RDS
  • 基本的には単一 AZ
  • リードレプリカをマルチ AZ と組み合わせる
  • クロスリージョンはバックアップを移動させておく
• Amazon Aurora
  • リードレプリカをクロスリージョンで構成可能
• Amazon DynamoDB
  • グローバルテーブルを使う
    • 非同期でクロスリージョンへコピーされる

AWS Backup

• バックアップ管理を一元化できる（だいたいの AWS サービスで利用可能）

バックアップリストアのレベル（安い順）

• S3 バックアップ／S3 リストア

  • バックアップを S3 に入れておく

• パイロットライト

  • DR 側で Web/AP 系の EC2 は停止させておくが、DB だけレプリケートさせておく。
  • つまり、DR 側も同じ構成で作成しておき、起動しないで置いておく

• 低キャパシティのホットスタンバイ

  • 通常時から DR を低キャパシティ環境として利用する
  • 切替時は Auto Scaling で自動拡張、切り替えができる
  • 切り替えたあとに動かない！ってことはない

• マルチサイト（Active Active）

  • 両リージョンを Act Act として利用する

• DAX は VCP の中にある

• DynamoDB 単体は VPN の外