AWS SAA まとめ
AWS SAA受けるにあたり、一旦知識をまとめてみました。
個人の勉強用のため、読みづらかったり、情報が誤っている可能性もあるのであまり信用せず。。
※ちなみに自分は受験登録時に名前登録間違えて受験すらできませんでした。。。（０次試験敗退）お金も帰ってこないのでみなさん気をつけてね。。。来週リベンジしよう。。
ネットワーク
VPCについて
IGW
- インターネット側への出口
- 各VPCに一つだけアタッチ可能
- 単一障害点とはならない
- ルーティングでIGW（０.0.０.０）と繋がっているものがパブリックサブネット
NATゲートウェイ
- プライベートIPをグローバルに変換
- NATインスタンスとの違いは冗長化されている点
VGW
- オンプレミスとの接続点
- 各VPCに一つだけアタッチ可能
- 一つで複数のDirectConectやVPNと接続可能
サブネット,ルートテーブル
- サブネット作成後にAZを指定する。作成後は変更できない
- サブネット一つに対し、一つのルートテーブルを作成する
- ルートテーブルの作成はいつでもできる
- サブネット一つに対してネットワークACLを一つ作成する
- いつでも変更可能
- 一つのVPCにつき２００個のサブネット作成可能。申請で増やせる
- サブネット内のIPアドレスのうち５つは予約されているため使用不可
- １つのルートテーブルを複数のサブネットで共有可能だが、一つのサブネットに複数のサブネットを設置はできない
セキュリティグループ
- インスタンス単位の通信の制御
- ステートフル（戻りを設定不要）
- 全て評価
- ホワイトリスト形式
ネットワークACL
- ステートレス（戻りも設定しなければならない）
- 番号順に評価
- ブラックリスト形式
VPCエンドポイント
- S3やDynamoDBと直接接続できる
VPCピアリング
- 別AWSアカウントのEC2などとプライベートな接続が可能
VPCフローログ
- 送信元先IPやプロトコル番号、データ量などを解析できる
CloudFront
- 静的コンテンツをキャッシュし、オリジンサーバの代わりに配信できる
- サーバの負荷を下げながら安定したサービス提供ができる
- URLのパスによってオリジンサーバを指定することができるため期間限定などに対応可能
- 拡張子やURLごとにキャッシュ期間を指定できる
- 変更の多い静的コンテンツはキャッシュを短くし、画像など変更あまりないものはキャッシュを長くする
Route53
- リージョンサービス
- ドメインの取得や更新もでき、AWSアカウントと共に請求できる
- Aliasレコードを指定することによって各サービスのFQDNを指定できる
ルーティング方式
シンプルルーティング
- 特殊性のない１対１のルーティング
フェイルオーバルーティング
- アクティブ／スタンバイ方式で、アクティブ側のヘルスチェックが失敗した時にスタンバイ側へルーティング
- Sorryコンテンツの表示に便利
位置情報ルーティング
- ユーザの位置情報に基づいたルーティング。日本からのアクセスは日本語のサイトにルーティング
地理的近接性ルーティング
- リソースの場所に基づいてルーティング
レイテンシールーティング
- 一番遅延の少ないところにルーティング
複数地値回答ルーティング
- 生きている中からランダムにルーティング
加重ルーティング
- 比率でルーティング。ABテストなどに有効
コンピューティング
EC2
- EC2とEBS間の通信を高速化したい場合はEBS最適化オプション
- Ec2の課金の仕組みは時間、リージョン、インスタンスタイプ、AMIによってきまる
- 停止中のインスタンすは課金されないが、EBSの費用はかかる
- デフォルト購入タイプは従量課金性のオンデマンドインスタンス
インスタンスタイプ
スポットインスタンス
- AWS上で余っているものを使う、一番安い
- ただし余剰な領域が少なくなると自動的に停止される
- そのため、いつ停止しても良いような開発環境や機械学習の学習処理などに使うとよい
リザーブドインスタンス
- 期間が決まっている場合有効
- 年単位で使用することが決まっている場合はオンデマンドインスタンスより安い。
DedicatedHost
- EC2を完全にユーザ専用にできる物理サーバ
ELB
- ELB自体が冗長化されている
- 利用は無料
- 事前にスパイクがわかっている場合はプレウォーミングを申請
- ヘルスチェック機能あり
- スティッキーセッション機能
ロードバランサーのタイプ
CLB
- L4／L7レイヤーでの分散
- 機能もALBと比べると少なく、値段もちょっと高い
ALB
- L7レイヤーでの分散
- 多機能(URLパターンでの分散,WebSocket対応)
- ECSと相性良い
NLB
- L4レイヤーでの分散
- HTTP（S)以外の通信で使う
スケーリングプラン
手動スケーリングプラン
- バッチ処理など一時的に処理負荷が上がる場合に有効
ターゲットトラッキングスケーリング
- CPU使用率など特定のターゲットを一定に保つようにする
ステップスケーリング
- アラームの段階を定義して、段階的にスケーリングする
シンプルスケーリング
- 一つの閾値を元にスケーリング
スケジュールスケーリング
- 営業時間中などの特定の時間にアクセス頻度が上がる時にスケール
Lambda
- 実行数と実行時間で課金される
- リクエスト量に応じて自動スケール
トリガーとなるもの
- S3バケット削除追加
- DynamoDB更新
- SNS通知
- SESメール通知
- APIGateWayにHTTPSリクエストがあった時
- CloudWatchEvents
その他設定が必要な項目
- 割り当てるメモリ量
- タイムアウトまでの時間
- アクセス対象のリソースに対するIAMロール
運用ツール
CloudWatch
- リソースの状態を監視する
- リソースに独自のエージェントを入れることでCloudWatchLogsにログを集約することができる
- その場合、IAMロールの設定が必要
- イベントやスケジュールで何かしらの後続アクションを定義するClouWatchEventsがある
- 収集したログに対して監視する文字列を設定してアラーム出せる
CloudTrail
- AWSリソースの作成やマネジメントコンソールの作成など操作を記録
- S3にログを保存することができる
- 過去９０日まで見れるが設定次第でそれ以前をS３に保存できる
- デフォルトで暗号化されている
AWSConfig
- AWS上のリソースの変更履歴を見れる
- 監査に有効
ストレージ
EBS
- ブロックストレージといえばEBS
- 容量拡張は可能（縮小は不可）
- ボリュームタイプの変更（増減どちらも）
- AZ内の複数物理ディスクに保管（AZ死んだらアウト）
- スナップショット機能あり
- 複数のEC2からアクセスとかはできない
- EC２とEBSは同AZである必要がある
- 異なるAZのEC2につけるにはスナップショット作成してアタッチ
- 暗号化可能（スナップショット、EBS間の通信も暗号化される）
- 既存EBSを暗号化する場合はスナップショットを作成し、スナップショットを暗号化、そこからEBS入れ替え
ボリュームタイプ
汎用SSD
- EC2のデフォルトボリュームとして使われる
プロビジョンドIOPS
- 性能高い
- IOPSときたらこれ
- データベースにも使われる
スループット最適化
- ログやバッッチに使われる
- スループットといったらこれ
Cold HDD
- コストがもっとも低い
- アクセス頻度の低いアーカイブに使われる
バースト機能
- プロビジョンド以外はバースト機能あり
- バースト前提で設計はアウト
EFS
- 複数のEC2からアクセス可能なファイルストレージ
- 複数のEC2から参照したい要件の場合だいたいこれ
- ３つのAZに自動的に保存される
パフォーマンスモード
- 基本的には汎用パフォーマンスモード
- ビックデータ分析などは最大IOパフォーマンスモード
スループットモード
バーストスループットモード
- ベースラインを設定し、それを超える場合はバーストモードになる
プロビジョニングスループットモード
- 任意のスループットモードを指定できるもの
- 大量のインスタンスから同期アクセスなど頻繁にデータにアクセスされる場合に有効
- スループットモードの変更は運用中も可能（前回の作業から２４間は開けなければならない）
- どちらを使うかの判断基準はCROUDWATCHのBurstCreditCatchで判断できる
S3
- リージョンサービスのため、クロスリージョンレプリケーション可能
- 優れた耐久性をもつ容量無制限のオブジェクトストレージ
- ディレクトリ構成を持たず、メタデータをユーザ独自で付与できる
- 結果整合性。保存前の状態が参照されることもある
ユースケース
- データのバックアップ
- ビックデータ分析のデータレイク
- ETLのデータ中間保存領域
- EC2やコンテナからのログ転送
- 静的コンテンツのホスティング
- 簡易なKeyValueデータベース(S3 Select)
バケット名
AWS内で一意である必要がある
オブジェクト
データそのもの「バケット名＋キー名＋バージョンID」
メタデータ
作成日時やアプリで使用できるユーザ独自のものも可能
ストレージクラス
STANDARD
- デフォルト 低レイテンシー高スループット
- 耐久性イレブンナイン
- 可用性９９.９９
STANDARDー１A
- STANDARDに比べて安価
- データ読み出しに際して課金
- 高速なアクセスが必要だがそれほど頻繁にアクセスしない
- 耐久性イレブンナイン
- 可用性９９.９９
ONEZONE-１A
- 単一のAZのみで保管(その分安い）
- 一つのAZが死んだら終わり
- 耐久性イレブンナイン
- 可用性９９.５
INTELIGENTーTIERING
- 参照頻度が明確に決められない場合に有効
- ３０日以上参照されなかったものは自動的にSTANDARDー１Aに
- 頻繁にいどうが発生する際にはコストがかかる可能性あり
- 耐久性イレブンナイン
- 可用性９９.９９
GLACIER
- ほとんど参照されないアーカイブ目的
- オブジェクト新規作成時にこのタイプは指定できない
- ライフサイクル管理機能によって自動的に行く場所として指定
- 直接アクセスはできない、数時間取り出しにかかる
- 標準取り出し（３〜５時間、コスト中）
- 大容量取り出し（５〜１２時間、コスト低）
- 迅速取り出し（１〜５分、コスト高）
- 耐久性イレブンナイン
- 可用性９９.９９
GLACIER DeepArchive
- GLACIERよりさらに安い。
- 標準取り出し（１２時間以内）
- 大容量取り出し（４８時間以内）
ライフサイクル管理
移行アクション
- データの利用頻度に応じて移行して行く(S3からGLACIERへなど)
有効期限アクション
- 一定期間を超えたものを削除
- S3は保存容量に応じて課金されるため、コスト削減に繋がる
バージョニング機能
- バケット単位で有効無効できる
- 新旧両方を保存するため、両方の容量が必要
- MFAを併用することで誤削除防止
Webサイトホスティング
- S3バケットに静的コンテンツをリリース可能。動的コンテンツは不可
- 独自ドメインで使用する場合は、ドメイン名とバケット名を同じにする必要がある
アクセス管理
- IAM、NACL、バケットポリシーを使える
- バケットポリシーはバケット単位
- NACLはオブジェクト単位
- IAMはユーザ単位
- IAM > バケットポリシー > NACL
署名つきURL
- アクセスを許可したいオブジェクトに対して有効期限つきのURLを発行することができる
データ暗号化
サーバ側暗号化
- ストレージに書き込まれる時に暗号化され、読み出し時に複合
クライアント暗号化
- AWSSDKを使ってクライアント側で暗号化
GLACIER
- S3と同様の耐久性イレブンナインを持ちながら容量あたりの費用を抑えたもの
- S3のように名前をつけることはできず自動裁判のIDで管理される
- ボールト：S3でいうバケット。リージョンおよびアカウントで一意であればよい
- 取り出しオプションには高速、標準、バルクがある
GLACIER SELECT
- GLACIERをS3にSQLで抽出
暗号化
- SSLで転送され、デフォルトで暗号化される
STRAGE GATEWAY
- オンプレミスにあるデータの受け口
- 保存先にはS3やGLACIER
タイプ
ファイルゲートウェイ
-オンプレのクライアントサーバのNFSからマウントし、非同期だがほぼリアルタイムでS3に格納する
- 速度は遅いので、速度を求める場合はEFSなどを検討
ボルームゲートウェイ
- 各ファイルをオブジェクトとしてではなく、S3全体をボリュームとして扱える
- 必要に応じてS3のスナップショットからEBSを作成して、EC2にアタッチ可能。キャッシュ型ボリュームとしても利用可能
テープゲートウェイ
- テープデバイスの代替としてS3やGLACIERにバックアップすることができる
セキュリティ
- S3に転送する際はHTTPSを使用
- KMSを使ってのデータ暗号化も可能
- CHAP認証も可能
データベース
- RDB : RDS,RedShift
- NoSQL : DynamoDB,ElasticCache,Nepture
RDS
- 運用の効率化に有効
- データ保存用ストレージはEBSを使用
- 容量の拡張はオンライン中も可能だが、パフォーマンスが劣化する
マルチAZ構成
- １つのリージョンないの２つのAZにDBインスタンスを配置
- マスター・スタンバイ構成で可用性が上がる
- 注意点としては書き込み速度が遅くなる
- フェイルオーバには６０ー１２０秒かかる
- FQDNのDNSレコードがスタンバイに書き換わるまでタイムラグ
リードレプリカ
- 通常のRDSとは別に参照専用のインスタンスを作成可能
- マスターDBの負荷を抑えたり、読み込みが多い場合のスケールアウトが可能
- マスターDBのメンテナンスをしている間、接続先をリードレプリカにすることで停止無しにメンテナンス可能
- レプリカは非同期レプリケーションのため、タイミングによっては古いデータが参照されることも
バックアップ／リストア
- 自動バックアップ1日に一回自動的にバックアップを作成することができる
- バックアップの保持期間は３５日
- バックアップから復元する場合は既存のDBに入れることはできず、バックアップから新規のインスタンスを作成する必要がある
- そのため、削除するDBインスタンスを再利用する可能性がある場合は削除時にバックアップを取得するオプションをつける
手動スナップショット
- 任意のタイミングでスナップショットを作成できる
- １リージョンあたり１００個まで作成可能
- バックアップ取得中は短時間のIO停止がある。ただ、マルチAZ構成の場合はスタンバイ側から作成するため、中断期間はなくなる
ポイントインタイムリカバリ
- 直近５分前から最大３５日前までの任意のRDSを作成できる。自動バックアップをONにする必要あり
セキュリティ
- EC2や他サービスからの通信をSSLで暗号化が可能
- 暗号オプションをおんにすることで、データ、スナップショット、ログの暗号化が可能
- 既存のデータを暗号化したい場合は、スナップショットの暗号化コピーし、新規のRDSを作成する
AURORA
- MySQL、PostGresの上位互換
- 単一リージョンの３つのAZに計６つコピーされ自動的に同期される
- マルチAZ構成オプションはない。プライマリインスタンスに障害が発生した場合、レプリカインスタンスが昇格する
エンドポイント
クラスタエンドポイント
- プライマリインスタンスに接続するためのエンドポイント。全ての操作が可能
読み取りエンドポイント
- レプリカインスタンスに接続するためのエンドポイント
- 読み取りのみ可能で、読み取りエンドポイントに接続することで負荷分散が行える
インスタンスエンドポイント
- 各インスタンスを指定して接続する。接続先のインスタンスによって、可能な操作ができる
カスタムエンドポイント
- インスタンスをグルーピングしてアクセスできる
RedShift
- データウェアハウス向けのBIツール複数ノードにおける分散並列処理ができる
- 列思考データベース
- 大容量のデータに効率的にアクセスできる
- 取得するデータを圧縮して素早い
- リージョンサービスなのでクロスリージョンレプリケーション可能
- 手動スナップショットを無効にすることでコスト削減可
- 複数のノードのまとまりをRedShiftクラスタという。
- クラスタは一つのリーダノードと複数のコンピュートノードから構成される
リーダノード
- 実行クエリを受けて実行プランの作成をおこなう
コンピュートノード
- 実際に探索を実行するところ
RedShift Spectrum
- S3に置かれたデータを外部テーブルとしてクエリできる
DynamoDB
- NoSQL、KeyValueときたらこれ
- 拡張性、高速処理、あまり頻繁にデータ更新しないといったらこれ
ユースケース
- 高い信頼性と拡張性
- スループットが増減するようなピーク帯のあるもの
- 大量のデータを格納して高速で処理
- 広告やゲームなど行動履歴を管理するもの
- Webアプリケーションのセッションデータベース
- 単一障害点を持たず、３つのAZに自動的に保存されるため可用性が高い
- スループットキャパシティを指定して自動的にそれを担保するため自動スケール（RとW）
- ダウンタイムなく変更可能、増加は制限なし、減少は1日９回まで変更可能
- プライマリキーだけで速度が上がらない場合はセカンダリキーを作成する
- ローカルセカンダリインデックス：元テーブルと同じパーティションで検索が完結
- グローバルセカンダリインデックス：プライマリキーとは異なる属性を使う
- インデックスの使用はコストがかかるのでその場合はRDBでいいのではという声もある
- 基本結果整合性だが、オプションを使うことで反映された状態のデータを返すこともできる
自動メンテナンス
- 各項目に有効期限を設定できて、期限が切れたら自動削除できる
- ただ即座に削除されるのではなく、４８時間後に削除される
DynamoDBStreams
- 直近２４時間の追加、更新削除の変更履歴を保持できる
- 変更内容に応じたリアルタイム処理が可能
DynamoDBAccerator（DAX）
- DynamoDBの前段にキャッシュをおいて性能工場、読み取り回数の減少が見込める
ElasticCache
- インメモリ型データベース、パフォーマンス向上が見込める
- セッション管理に使える
Memcache
- シンプルなキャッシュシステムを使用したい
- データが消えてもいい
- 必要なリソースの増減が頻繁でスケールインアウトが必要な場合はこれ
Redis
- Memcacheよりも多くのデータ型が扱える
- キャッシュ用とだけでなくキューを使え、データの保護も有効
- 多様なデータ型を使用したい
- 障害時のフェールオーババックアップリストアが必要
セキュリティ
AWS Organaizations
- ユーザの請求の一括請求ができる
- ルートユーザはMFAなどにしていくことがおすすめ
IAMポリシー
- 操作権限の設定
- これをIAMユーザやIAMグループにアタッチする
- Action（どのサービスの）、Resource（どういう機能や範囲）、Efects（許可、拒否）するを設定
- 対象ごとに作成するインラインポリシー
- 管理ポリシーは複数ユーザの管理に向いている
- そのなかでAWS管理ポリシーはAWS側で用意しているテンプレ、カスタム管理ポリシーはユーザが作る
- カスタム管理ポリシーは過去５世代まで遡れるため、間違っていたら戻せる
IAMユーザー
- 各サービスの各操作を制限することができる
- 認証方法は二つ
- ユーザIDとパスワード、MFAを組み合わせることもできる
- アクセスキーとシークレットアクセスキー：CLIやAPIからAWSのリソースにアクセスする場合に使用
- IAMユーザとIAMグループは多対多
IAMロール
- 一時的にAWSリソースへのアクセス権限を付与する場合に使用する
- 他にはIDフェデレーョン（ADを使用して認証）WebIDフェデレーション（Facebookなどで認証）
KMS
- AWS場で共通鍵の管理ができるマネージどサービス
- マルチテナント
- 鍵の作成、暗号化、復号化ができる
- マスターキーでデータキーを暗号化し、データキーで対象を暗号化
CloudHSM
- VPC内のハードウェア占有
- 鍵はユーザ側で管理する
- 大規模システムに向いている
アプリケーションサービス
SQS
- アプリケーションを疎結合にするもの
- キューの作成や削除
- メッセージ管理（送信、受信）
- 最大サイズは２５６Kb
- なので画像などは扱えない。実データはS3やDynamoDBに格納してそのパスをキューに入れるなどの設計がある
キューの設定
Standardキュー
- メッセージの配信順序は保証されない
- 二重取得の可能性あり
- シーケンスをつければ順序ある程度保証
- １秒あたりのトランザクション数はほぼ無制限
FIFOキュー
- 配信順序は保証される
- １秒あたりバッチ処理ありで３００件、バッチ処理なしで３０００件の制限がある
取得方法
ロングポーリング
- メッセージがない場合は設定されたタイムアウトまでレスポンスを返さない
ショートポーリング（デフォルト）
- メッセージの有無にかかわらず即座にレスポンスそのため、複数のキューがある場合は高コストになる
可視性タイムアウト
- 受信後削除されるのは受信側がOK出してから。
- そのため、複数で受信してしまう可能性がある
- 可視性タイムアウトの時間まで受信できない設定をすることでそれを防ぐ
遅延キュー
- キューに送られたメッセージを一定時間見えなくする
デッドレターキュー
- 処理できないキューを別のキューに移動する機能
- 受信し続けることを防ぐ
SWF、StepFunction
- どちらもワークフローサービス
- StepFunctionの方が可視化で編集できるためはるかに簡単に作成できる
- 処理の実行順序などが保証されている
SNS
- プッシュ型のサービス
- SMS、Email、SQS、HTTP、HTTPS、モバイル、LAmdaなどに通知可能
SES
- Email送信サービス
後半雑。。。