問題の解き方

まず、問題と選択肢をよく理解する。知っている問題があっても飛び付かずによく読む。その上で以下の順で考える。

実装できない選択肢を除外
実装できるものの中から要件により吟味する
- 数値目標が達成できるか
  - S3・Glacierからの取り出し時間
  - 移行までの日数
- セキュリティ要件
  - 通信経路
  - 暗号化
- 運用コストが低い。具体的には以下のものを優先して選択する。
  - AWS管理範囲がより大きい
  - 開発が少なくて済む
- その他要件
  - OSをユーザが管理する必要がある → RDSではなく、EC2にRDBをインストール
  - 環境のコンパチビリティが必要 → Lambdaではなく、EC2やElasitc Beanstalk
複数選択の問題
- 2つ選びなさい。→ それぞれ単独で実現できる方法が複数ある。
- 組み合わせて2つ選びなさい。 → 複数組み合わせて初めて実現できる。
アカウント・VPC・リージョン
- 複数のステークホルダが登場する場合、アカウント・VPC・リージョンのいずれかを独立して保持しているのかに注意する。

数字関係

S3

ストレージクラス

耐久性はどれも99.999999999%
保存量あたりの料金は上の方が高い。下に行くほど安くなるが制約(太字)が増える。

ストレージクラス	レイテンシ	取り出し料金	可用性	AZ
S3	低	無料	99.99%	3以上
S3 IA	低	有料	99.99%	3以上
S3 1Zone IA	低	有料	99.5%	1
Glacier IR	低	有料	99.99%	3以上
Glacier Flexible Retrieval	分~時間	有料	99.99%	3以上
Glacier Deep Archive	12時間~数日	有料	99.99%	3以上

Glacier 取り出しオプション

出題例

アクセスされることは少ないが、24時間以内にデータをとりだすための最もコスト効率がよい選択肢は？
10時間以内に取り出すのにGlacier Flexible Retrievalに必要なオプションは？

取り出しオプション	Glacier Flexible Retrieval	Glacier Deep Archive
迅速	1~5分(250MB以内)	なし
標準	3~5時間	12時間
大容量	5~12時間	48時間

DynamoDB

アイテムの最大サイズ : 400KB
トランザクション ... 上限は以下
- 処理サイズ合計 ... 4MB
- アイテム ... 25
プロビジョンドスループット:
- 読み取り: 1 RCU = 4 KB(強い整合性) / 8KB (結果整合性)
- 書き込み: 1 WCU = 1 KB

Lambda

実行時間 : 最大15分

認証

外部環境から利用

IAM Identity Centerと外部アイデンティティプロバイダをSAML(AD or Web)で外部と連携。
STSを利用した別AWSアカウントからのシングルサインオン : SAMLに対応しているアイデンティティリソースが利用できない場合

RDS

Auroraとその他のRDSとの比較

Auroraとその他のRDSサービスはの違いの部分がよく出る。アーキテクチャの違いとしてAuroraは専用のシャードにデータが保存され、RDSはインスタンス内のストレージにデータが保存される。

項目	Aurora	その他RDS
可用性	リードレプリカがスタンバイ代わり	スタンバイインスタンスを設置
自動バックアップ	秒ごとにポイントインタイムリカバリ（PITR）	1回/日のテーブル + 5分ごとのトランザクション
スループット	そのほかRDSと比較して5倍	インスタンス次第
オンデマンド	可能(Aurora Serverless)	不能
リージョンまたぎ	別リージョンにリードレプリカを設置することで実現(Aurora Global Database)。 DRと読み取り遅延改善を兼ねる。	スタンバイインスタンスは設置できる。DR目的のみ。

RDS マルチAZ DBクラスター

比較的あたらしい機能。RDBでAuroraのような使い方ができる。

リードレプリカを異なるAZに2つ作成
リードレプリカがプライマリに昇格
- (当然だが)リードレプリカにコピーされたデータのみが復旧できる。

Elasticache

リードレプリカ vs Elasticache

両方がRDSの読み取り性能を底上げするものだが、用途が違う。Elasticacheは一度実行されたクエリとその結果を再利用するキャッシュであるため。

リードレプリカ ... 週1回のレポート機能など。
Elasticache ... 広域なウェブサービスなど。同様のクエリが大量に実行される場合。

Memcached vs Redis

Memcached : RDSのキャッシュシンプルな利用の場合
Redis
- RDSのキャッシュ : マルチAZによる冗長、データの暗号化が必要な場合
- 単独での使用 : オンライン対戦など

キャッシュ

Elasticache
DAX
Cloudfront
API Gateway

リアルタイム処理

Kinesisシリーズ

実装方法が多様なのでどうとでも言える。SAAの試験的には基本的には以下で判断の割り切りでも良い。

リアルタイム性(ミリ秒)が求められる時はKinesis Data Streams
リアルタイム性かつ分析はFlink。「SQL」や「異常検知」など。
リアルタイム性がない場合(バッチ)で分析する場合はFirehose

その他の要素としては以下。

要件	Kinesis Data Streams	Kinesis Data Firehose	Amazon Managed Service for Apache Flink
リアルタイム性	あり	なし	あり
データ保持期間	最大7日間	数秒～数分	処理中のみ（一時的）
ストリーム内処理	なし	Lambda,圧縮	Lambda,SQL(高度な分析)
出力先	Lambda,Firehose,カスタムされた処理	固定の保存先(S3, Redshift, OpenSearch, HTTPエンドポイント)	S3、Redshift、Firehose、OpenSearch

その他

MSK(Kafka) : Firehose,Flinkに対しての入力元になる
DynamoDB Streams : Lambdaで処理
Cloud Watch Logs : Kinesisシリーズで利用可能

データ移行

Transfer Family
- SFTP,FTP,FTPS
- 保存先 : S3,EFS
DataSync
- エージェントをインストール、Snowcore(エージェントがインストール済み)
- 保存先 : S3,EFS,FSx
Storage Gateway
Snowball
DMS

以下の要件をよく読み解いて回答する。

移行後もオンプレからの利用はあるか？
移行までの時間に関する解答

移行までの時間に関する解答

以下を勘案する。ちょっとした計算も必要。
ざっくり、1Gbpsの回線で10TB/日が転送可能と覚えておくと便利。

データ量
移行完了までの期限
ネットワーク帯域

データ移行後も

設計

疎結合

基本的にSQSを使うことになるが、一段深いところで使い分けや例外があるのでまとめる。

SQSのパラメータによりAuto Scaling
- キューの長さ : 負荷に応じて
- 一番古いキュー : 処理性能SLAを守る
重複処理の回避
- 自動処理のみ : SQS 可視性タイムアウト
- 人間のオペレーションがある場合 : Step Functions
ファンアウト構成
- SNS (必要に応じてフィルタリング) → 個別のSQSキュー → 処理
  - 「順序通り」や「重複してはいけない」要件がある場合はSNS,SQSともにFIFOキューの構成にする。

セキュリティ

WAF vs Shield

Shield : EC2、ELB、CloudFront、Route 53, Global Accelarator ※API Gatewayは対象外

WAF : CloudFront, ALB, API Gatewayなど

地理的制限

WAF
Cloudfront
Route53

運用

異常検知

CloudWatchアラート単体とEventBridgeの組み合わせにより実現。CloudWatchアラートの方が実現は簡単だがシンプルの判断でOK。

CloudWatchアラート : シンプル。基本的に通知のみ。通知先はSNS。
EventBridge : 色々できる。復旧などの自動化。通知もできる。

CloudWatchアラート単体での復旧

EC2 : StatusCheckFailed_Instance が対象。
Auto Scaling : EC2のメトリクスが対象

分析

SQLを使えるサービス

S3 Select
Athena
Redshift
Flink

Redshift

WLM(Work Load Management) : 特定のクエリやユーザーごとにリソースの優先順位や割り当てを制御する。(経路指定)
拡張 VPC ルーティング : Redshiftクラスターのデータの送受信がすべてVPC内のルートテーブルとセキュリティ設定に従うようになる。これにより、インターネットを経由せずにプライベートネットワーク内で通信を制御できる。

ETL・分析実行

Glue
- ETL
- PySpark(Spark+Python)で処理
- サーバレス
- Glue Studio、DataBrewなどのユーザ向けツールあり
- データ : 構造化・半構造化・非構造化(簡単なテキストデータ処理)
- データストア : なし ※データカタログはデータソースのメタデータを管理
EMR
- Spark/Hadoop
- クラスター管理
- データ : 非構造化
- データストア : 大規模
Redshift
　- 高度のSQL処理
　- クラスター管理
　- データ : 構造化する必要がある
　- データ量 : 大規模
~~Pipeline~~ ... 2024/7/25から非推奨

クロスアカウント・リージョン

クロスアカウント

Security Token Service (STS)
Resource Access Manager (RAM)
サービスごとのリソースベースポリシー
- S3 : バケットポリシー
- SQS,SNS : アクセスポリシー
- EC2 : AMI,スナップショット
- RDS : スナップショット
- KMS : 暗号化したEBS(スナップショット)を複合化するのに許可する
- ECR : レポジトリ共有

クロスリージョン

DR
- バックアップ・リストア
  - RedShift
  - AWS Backup
  - S3 CRR (クロスリージョンレプリケーション)
- パイロットライト
  - 単独での専用サービスは無い。通常時は最小リソースを実行。フェイルオーバー後、AutoScalingにより需要に合わせて性能を拡張する。
  - RDS リードレプリカ
- ウォームスタンバイ
  - Aurora グローバルDB
- マルチサイト
  - Dynamo DB グローバルテーブル
フェイルオーバー
- Route 53
  - フェイルオーバールーティング
  - ヘルスチェック
高速化
- Route 53 地理的ルーテイング
- Cloudfront
- Global Accelarator
- S3 Transfer Acceleration
その他
- KMS : クロスリージョンキーでバックアップした暗号済みエンティティをレストア

マネージドサービスとEC2

シンプルに「OSをユーザが管理する要件があります。」と問題文にある場合は、EC2に所望のソフトをインストールして選択する。

落とし穴

ALBはPrivateLinkに指定できない。NLBはできる。
- 例えば、「転送コストを下げさせる意図」の問題で誤った選択肢で「ALBをエンドポイントとしたPrivateLink」が出てくる。VPC間をプライベートでの繋ぐソリューションとしては、VPCピアリング・RAMでのVPC共有がある。

やった勉強