問題の解き方
まず、問題と選択肢をよく理解する。知っている問題があっても飛び付かずによく読む。その上で以下の順で考える。
- 実装できない選択肢を除外
- 実装できるものの中から要件により吟味する
- 数値目標が達成できるか
- 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キューの構成にする。
- SNS (必要に応じてフィルタリング) → 個別のSQSキュー → 処理
セキュリティ
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
- 高速化
- Route 53 地理的ルーテイング
- Cloudfront
- Global Accelarator
- S3 Transfer Acceleration
- その他
- KMS : クロスリージョンキーでバックアップした暗号済みエンティティをレストア
マネージドサービスとEC2
シンプルに「OSをユーザが管理する要件があります。」と問題文にある場合は、EC2に所望のソフトをインストールして選択する。
落とし穴
- ALBはPrivateLinkに指定できない。NLBはできる。
- 例えば、「転送コストを下げさせる意図」の問題で誤った選択肢で「ALBをエンドポイントとしたPrivateLink」が出てくる。VPC間をプライベートでの繋ぐソリューションとしては、VPCピアリング・RAMでのVPC共有がある。