More than 1 year has passed since last update.

AWS Solutions Associate対策

Last updated at 2022-04-10Posted at 2022-01-10

はじめに

今回AWS Solutions Architect - Associateを受けたので自分の備忘録としてまとめました。
(ただメモとして書き殴っただけですので参考になるかわかりませんが、、、)
年末にノリで申し込んで約10日後に受験しました。(無事取得できました)
特にAWSをガッツリ触っているわけでなく、Azureを業務で軽く触っているぐらいです。
主にUdemyで勉強しました。Udemyオススメです。

IAM

IAMとは、安全にAWS操作をするための認証・認可の仕組みと思えば良い

ルートアカウント

AWSアカウントを作成した時に用意したEメールアドレスとパスワードを使用してサインインできるアカウント
権限が最強すぎるのでこのアカウントは基本的に使用しないようにする

ルートアカウントしかできないこと

AWSアカウントの停止
IAMユーザーの課金情報へのアクセス
S3バケットへのMFAによる削除の有効化
CloudFrontのキーペア作成 etc

IAMポリシー

どのリソースに対してどの操作をするかJSON形式で定義するもの
ユーザー、グループ、ロールにアタッチできる
(1)Effect (2)Action (3)Resource [ARNで記述](4)Condition

ポリシーのタイプ
(1)ユーザーベースのポリシー

IAMユーザーに対してアタッチする

(2)リソースベースのポリシー

AWSリソースに対してアタッチ
信頼ポリシー

(3)アクセス許可の境界

管理ポリシーを使用してユーザーベースのポリシーがIAMエンティティに付与できるアクセス許可の上限を設定できるが、アクセス許可は付与しない機能

IAMロール

AWSリソースに対してアクセス権限をロールとして付与できる

NAT

	インターネットGW	NAT GW
機能	NAT (VPC⇆インターネット)	NAT(インターネットとの接続にはインターネットGW必要)
NATの種類	static NAT	Dynamic NAPT
場所	VPC	(Public)Subnet
速度	なし	5-45Gbps

【Static NAT】

NATテーブルには通信前から「プライベートIPとパブリックIPの変換ルール」がt定義されているので、EC2から始まる通信であってもインターネットのクライアントから始まる通信であってもIPは変換され通信が可能
1対1変換でありインターネットからの通信も変換

【NAT Gateway】

プライベートIP(多)⇆パブリックIP(1)
複数EC2インスタンスから発する通信が各々のプライベートIPでNAT-GWを通過する際、NAT-GWで1つのパブリックIPに変換
複数のプライベートIPを1つのパブリックIPに変換してしまうと、戻りの通信においてどの通信がどのプライベートIPに変換すれば良いか一意に定まらない
→ TCP/UDPのポート番号も変換する
→この方式を「動的NAPTT = Dynamic NAPT」

EC2

【ストレージ選択】

(1)インスタンスストア

物理的に接続、内臓ハードディスク的な
一時的なストレージで、無料で使用可能

(2)EBS

ネットワーク接続
EC2と独立に管理
別途コストかかる

【AMIの利用】

Amazon Machine Image, OSの設定をしたやつ
EC2のBUとしてEBSを含んだ形でAMI作成できる
ゴールデンイメージ : 最適なEC２インスタンスを作成してそれをAMIにしたもの
AMI共有 : AWSアカウントIDを指定して権限を委譲するだけでAMIを特定のAWSアカウントを共有
リージョンの移動 : 別リージョンにコピー可能

【キャパシティ予約】 : リザーブドインスタンスとセットで利用

キャパシティ予約 : インスタンスタイプが起動可能であることの確保権。あらかじめキャパシティを確保しておくことで実行時のキャパシティ不足エラーを抑制

【スポットフリート】

スポットインスタンスの買い方の一種で条件を指定しておくとAWSがEC2のスポットインスタンスの価格を監視、条件があったEC2を見つけ出して起動、逆に使いたい価格より高くなったEC2は自動的に廃棄

【スポットブロック】

スポットインスタンスを1h-6hの間中断することなく継続利用可能
スポットフリートのオプション
安定化できる

【EC2フリート】

オンデマンドとスポットで構成されるインスタンスグループとして設定を定義する仕組み
利用上限も決められる

【Elastic Fabric Adapter】

HPCとMLを高速化するためのEC２用ネットワークデバイス

【Run Command】

マネージドコンソール上からPowerScript, windows updateの設定などのコマンド各種コマンドを実行できる機能

【ハイバーネーション】

シャットダウンする前にメインメモリの内容をハードディスク等に退避し、次回起動時にまたメインメモリに読み込んで、シャットダウンする前と同じ状態で起動する機能

【プレイスメントグループ】

インスタンス間における⭐️低レイテンシ⭐️な通信を実現するための機能
複数のインスタンスを論理的にグループ化して、パフォーマンスの向上・耐障害性を高める機能

(1)クラスタプレイスメントグループ

パフォーマンスを高めるもの
一般的に使用される、単一AZ内のインスタンスを論理的にグループ化
EC２間で高ネットワークスループットが発生する場合に適している
⭐️ 低レイテンシ、高スループット、の時採用
⭐️ ネットワークトラフィックの大部分がグループ内のインスタンス間で発生してる場合

(2)パーティションプレイスメントグループ

耐久性を高めるもの➡︎ ⭐️ アプリケーションに関連するハードウェア障害の頻度を軽減する
複数のAZに分散させることができる
HDFSなど大規模なワークロードに適している
⭐️ Hadoop, cassandra, kafkaなどの大規模な分散及び複製ワークロードで一般的に利用

(3)スプレッドプレイスメントグループ

耐久性を高めるもの
異なるハードウェアに配置されるグループで複数のAZにまたがることが可能
⭐️ インスタンスが同じラックを共有するときに発生する可能性のある同時障害のリスクを減らせる
⭐️ 少数の重要なインスタンスが互いに分離して保持される必要があるアプリケーションに推奨

【起動テンプレート】

インスタンスの作成ウィザードから設定していたパラメータをテンプレートにすることができる
一度テンプレートにしてインスタンスの情報を決めてしまえばそれ以降はテンプレートから作成することで手間を減らせる
起動設定の代わりに起動テンプレートを定義すると、複数のバージョンのテンプレートを使用できる

【起動設定】

ASGがEC2インスタンスを起動するために使用するインスタンス設定テンプレート

予約 (コスト削減)

名前	説明
オンデマンドインスタンス	・起動するインスタンスに対して秒単位で課金される
Savings Plans	・1-3年間、EC2の利用時間に関係なく、1時間につき一定の料金を支払うことを決めてEC2を利用するプラン・RIと同等の割引が適用されることに加え、スケールアップ等、構成の変更を行った場合でも割引が適用される
Reserved Instance	・1年、3年単位で購入できる格安インスタンス
Spot Instance	・AWS上サーバー上に存在し使われていないEC2インスタンスに値段をつけ、その入札価格が現在のスポット価格を上回っている限りそのインスタンスを利用→インスタンスが中断することがある。・継続的な処理が必要なく重要なタスクでない・バッチ処理ジョブなどの一時的な処理に利用される
Dedicated Hosts	・専有ホスト。ホストサーバーを保有したい場合利用。セキュリティー的にとか
Bare Metal	・仮想サーバのような仮想化ハイパーバイザを使わず、物理サーバをそのままユーザが利用できるサービス・AWSの各種サービスとの連携が可能でOSが直接下層のハードウェアにアクセス可能
ハードウェア占有インスタンス(Dedicated インスタンス)	ハードウェア占有インスタンスは、他のアカウントのEC2インスタンスと共有されることはない。言い換えると、同じアカウントのインスタンスとは共有されることになる

SP(Savings Plans)	説明
Compute	EC2, EMR, ECS, EKSクラスターの一部、Fargate, Lambda 最大、66%の割引が可能
EC2 Instance	EC2のみ最大,72%の割引が可能

RI(Reserved Instance)	説明
Standard	割引率が最も高く、設定変更などがあまり発生しない定常状態の使用に良い
Convertible	・割引きが適用、スタンダードと違ってリザーブドインスタンスの属性を変更できる・コンバーティブル(Convertible)のみ変更可能→ インスタンスファミリー, OS, テナンシー, 支払いオプション

キャパシティ予約
インスタンスタイプが起動可能であるという確保権。リザーブドインスタンスとはセットで使う
予めキャパシティを確保しておくことで実行時のキャパシティ不足エラーを抑制する
確実なEC2 Instanceの起動を確保する
主なリザーブド
- EC2リザーブドインスタンス
- RDSリザーブドインスタンス
- ElastiCacheリザーブドノード
- DynamoDBリザーブドキャパシティ
- Redshiftリザーブドノード

⭐️ 基本にSaving Planを優先して考える→柔軟性が高いため
⭐️ スタンダードRIとEC2 Instance SP, コンバーティブルRIとCompute SPの割引率は同一
⭐️ RIを選択するケースとしては、SP非対応のAWSを使用するとき

【インスタンスタイプ】

用途	インスタンスファミリー	説明
汎用	a, t, m	ウェブサーバーやコードリポジトリなど、インスタンスのリソースを同じ割合で使用するアプリケーションに最適
コンピューティング最適化	c	バッチ処理、機械学習推論、科学モデリング
メモリ最適化	r, x, z	メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスに最適なインスタンス
高速コンピューティング	p, g, f	浮動小数点計算、グラフィックス処理、データパターン照合など
ストレージ最適化	i, d, h	ローカルストレージの大規模データセットに対する高いシーケンシャル読み取りおよび書き込みアクセスを必要とするワークロード用

AutoScaling

3要素 :
(1) Auto Scalingグループ 
    - Auto Scalingを実行するサーバーグループを指定
(2) Launch Config 
    - AMIインスタンスタイプ、IAMなどを設定知って起動する
(3) スケーリングプラン
    - どのようにインスタンスを起動するか

Auto Scaling設定プロセス
(1) ELB作成
(2) ターゲットグループの作成
(3) 起動するインスタンスの設定
(4) Auto Scalingグループ作成
(5) AutoScalingポリシー or スケジュール設定
AutoScalingが閾値を超えたにも関わらずスケーリングがうまく実行されず24時間立ったとき自動的にAutoScalingは停止

【Auto Scaling Groups】

EC2インスタンスの開始から削除まで全ての動作に対する規則とポリシーを含んでいる
ex) 最小サイズ、最大サイズ、お望みの容量、拡大できる容量

【Auto Scaling Plan】

どのようにスケールするか

(1)手動スケーリング : バッチ処理など高負荷な処理への対応
(2)スケジュールドスケーリング : アクセス予測が可能なとき、日時指定などして指定
(3)動的スケーリング : ⭐️スケーリングポリシー⭐️に従い、自動的にスケーリング

【Auto Scaling Plan】
4.1 : シンプルスケーリングポリシー
4.2 : ステップスケーリングポリシー
4.3 : ターゲット追跡ポリシー : スケーリングメトリクスを選択してターゲット値を設定
ex) AutoScalingグループの平均集計CPU使用率を40パーセントに維持

【Auto Scalingの挙動】

インスタンスが最も少ないAZでインスタンスを起動
再分散の実施 : AZ間でインスタンス数を不均衡あると調整

【ターミネーションポリシー(終了ポリシー)】

Auto Scalingでスケールインが発生した時に、どのインスタンスを終了させるかを決めるルール

⭐️ 終了ポリシー (デフォルト)

最もインスタンスが多いAz選択 → OldestLaunchConfiguration(最も古い起動構成) → ClosestToNextInstanceHour (課金が近い) → ランダム

種類	説明
OldestInstance	最も古いインスタンスを終了する
NewestInstance	最も新しいインスタンスを終了
OldestLaunchConfiguration	最も古いLaunch Configuration
ClosestToNextInstanceHour	課金のタイミングが近い

クールダウンタイム : AutoScalingグループが追加のインスタンスを起動または削除することができない時間

【ヘルスチェック】

Auto-Scaling配下のEC２のヘルスチェックにはEC２のステータス情報またはELBのヘルスチェックのどちらかを利用

(1) EC2ステータス : インスタンスのステータスがrunning以外の状態を異常と判断
(2) ELB : ELBのヘルスチェック機能を活用する(正常なインスタンスのみをELBに追加)

【ライフサイクルフック】

インスタンス起動時 or 削除時にインスタンスを一時停止してカスタムアクションを実行

用語	説明
Desired Capacity	Auto Scalingが実行されない状態でのインスタンス数を設定この数値を変更することで、手動でスケーリングさせることも可能
Minimum capacity	スケールイン時にインスタンスを削除する際の下限のインスタンス数を設定
Maximum capacity	最大キャパシティはスケールアウト時に起動するインスタンスの最大数を設定する

Redshift

フルマネージド型のDWH
DBに対するアクセス競合が発生せず、ノードを増やせば増やすほどリニアに性能が向上
Redshiftクラスターは１つのリーダーノードと複数のコンピューティングノードから構成
リーダーノードは課金の対象外となり、コンピューティングノード数とノードタイプが課金対象

【Leader Node】

SQL処理コードの生成と展開
クライアントアプリケーションからクエリを受け取ってクエリを解析しクエリ実行プランを作成
コンピューティングノードに対するこれらのプランの並列実行を調整しコンピューティングノードから得た中間結果を集計してから、最終的にクライアントアプリケーションに結果を返す
クラスタの全てを管理

【Compute Node】

実際の処理
ローカル列志向ストレージ、クエリの並列実行
クエリ実行プランを実行し、これらのクエリを処理するためにデータをコンピューティングノード間で伝送する
集計の中間結果は、クライアントアプリケーションに送り返される前にリーダーノードに送り返される

コンピューティングノードタイプ

種類	説明
DS(高密度ストレージノードタイプ)	ストレージに最適化されたHDD DS1とDS２の２種類ある
DC(高密度コンピューティングノードタイプ)	コンピューティングに最適化されたSSD DC１の１種類しかない

【ノードスライス】

コンピューティングノードはスライスという処理の実行単位に分けたもの
各スライスは、ノードのメモリとディスク容量の一部を割り当てられて、ノードに割り当てられたワークロードを一部分を処理
リーダーノードは、スライスへのデータの分散を管理し、クエリまたは他のDB操作のワークロードをスライスに分配

【MPP(Massive Parallel Processing)】

リーダーノードが１タスクを複数のコンピューティングノードで分散割り当てして実行
コンピューティングノードを追加することで容易にスケールアウト可能

【シェアードナッシング】

複数のサーバやコンピュータを利用した分散処理のシステムにおいて、それぞれに占有のストレージ領域を与えることで、自律的な並列処理を可能とすること
同一データなどに対する競合を防ぐことができる雨、処理速度を向上させられる。DWHなどに利用される
各のノードスライスは、専用のCPUコア、メモリ、ディスクを持っており、各ノードスライス間で基本的にデータを共有するようなことはしない

【パラメータグループ】

パラメータグループ　： DBのコンフィグ
静的なパラメータの変更は、DBインスタンスを再起動する必要あり
パラメータグループを変更することも可能

ex)

auto_analyze
enable_user_activity_logging
require_ssl
search_path
statement_timeout

####⭐️ 【拡張 VPCルーティング】

Redshiftはクラスターとデータリポジトリ間の全てのCOPYとUNLOADトラフィックがVPCを通るように強制

##Route53

①シンプルルーティング

静的マッピングによるルーティング方式
複数の値を1つのレコードに設定すると、ランダムに応答する(DNSラウンドロビン)

②加重ルーティング

指定した比率で複数リソースにトラフィックをルーティングする
比率の合計100
ex)A/Bテスト, Blue/Greenデプロイ, サーバー性能に応じた負荷平準化

③フェイルオーバールーティング

ヘルスチェックの結果に応じて利用可能なリソースのみを応答する方式
プライマリやセカンダリを登録
事前にヘルスチェックを作成し、設定時にヘルスチェックとの関連づけが必要

④複数値回答ルーティング

IPアドレス単位での正常・非正常を判断してルーティングできる
複数レコードのうち、正常なレコードのみランダムで応答させる方式
MAX IP8つ登録

⑤レイテンシールーティング

ネットワークレイテンシーが最も低いリージョンのリソースを応答する方式
設定時に指定したIPアドレスのリージョンが選択されるので、セットIDを入力して登録

⑥位置情報ルーティング⭐️

クライアントの位置情報に基づいて応答する方式
ex)適切な言語でローカライズされたコンテンツの提供

⑦地理的近接性ルーティング⭐️

ユーザーとリソースの地理的場所に基づいて応答

####【IPフローティング】➡︎ ENIの付け替え

障害発生時にダウンタイムをなくすため、Elastic IPを自動で付け替える機能

CloudFront

世界中にあるエッジロケーションを利用してCDNとして利用できるグローバルなコンテンツ配信サービス
GZIP圧縮によってコンテンツを軽くすることで高速な処理可能 : リクエストヘッダー Accept-Encoding:gzip
→ 圧縮ファイルを供給すると非圧縮ファイルを供給するよりもコスト安い
リージョナルエッジキャッシュというロケーションが追加されたが、ユーザー側で選択可能ではない
無料で新規ユーザーは50GBのデータ通信と2,000,000件のHTTPorHTTPSリクエストを毎月１年間利用できる
CloudFrontへのHTTP GET/POST/PUTリクエストの最大ファイルは20GB
⭐️ プロキシされるHTTPメソッド PUT/POST/PATCH/OPTIONS/DELETEは直接オリジンに送信される (エッジキャッシュがスキップ)
⭐️ リクエスト時に決定される動的コンテンツもエッジキャッシュをスキップしてオリジンサーバーへアクセス
webサイトのパフォーマンスを改善できる

CloudFront → S3

OAI
署名付きURL
署名付きcookie

【コスト】

ざっくり : 転送量 x 単価＋リクエスト数 x 単価　 = 料金

インターネットへのリージョンデータ転送アウト(GB単位)
HTTPメソッドのリクエスト料金(1万件あたり)
オリジンへのリージョン内データ転送アウト

【CDN(Content Delivery Network)】

webサーバーがコンテンツを配信する際にその前段としてCDNを配置
コンテンツをキャッシュすることでwebサーバーの負荷を軽減
キャッシュがないときはサーバーに取りに行く
キャッシュがあるときはCDNがコンテンツを返す

【CloudFrontディストリビューション (CloudFrontの設定のこと)】

オリジンサーバーでオブジェクトを保存した後、オブジェクトがどこにあるかをCloudFrontに伝える役割を持つ
ディストリビューションを作成すると、CloudFrontはあなたがオブジェクトを管理するために使用する一意のドメイン名を提供
作成可能なディストリビューションは2つ

(1)ダウンロードディストリビューション : HTTP or HTTPSを使用してコンテンツを配信
(2)ストリーミングディストリビューション

コンテンツオリジン : どのサービスのコンテンツ配信を高速化するか
地域制限 : 特定の国のユーザーがコンテンツにアクセスできないようにする
セキュリティ : HTTPSを必須にするかどうか
アクセスログ : cloudFrontでviewerのアクティビティを示すアクセスログを作成するかどうか

【オリジンアクセスアイデンティティ(OAI)】

S3にあるwebコンテンツを配信する時に、CloudFrontからのみアクセスさせる仕組み
閲覧者のS3への直接アクセスはブロック

【署名付きURL】

URLを知っている人だけが、CloudFrontからコンテンツを取得することができる
個々のファイルへのアクセスを制御する場合に使用
署名付きCookieはRTMPディストリビューションではサポートされていないため署名付きURLを利用する
ユーザーがCookeiをサポートしてない場合は使う

【署名付きcookie】

特定のcookieをセットされている人だけが、cloudfrontからコンテンツを取得することができる
複数の制限されたファイルへのアクセスを提供する場合など
URLを変更したくないときに利用 ⭐️

【コスト】

トラフィックの分散
リクエスト数
データ転送アウト

用語	説明
OAI	・OAIはS3バケットへのアクセスをCLoudFrontからのリクエストを絞るための仕組み・OAIと呼ばれる特別なユーザーを作成し、そのユーザーに限定してアクセスを許可
カスタムヘッダー	カスタムヘッダーをオプションで設定して、カスタムオリジンへのアクセスを制限する仕組み
Viewer Protocol Policy	・HTTPとHTTPS両方nにアクセスできる・HTTPをHTTPSにリダイレクトにする・HTTPSのみアクセスさせる
Origin Protocol Policy	CloudFrontからオリジンへのアクセスプロトコルをここで指定できる

【キャッシュ有効期限】

用語	説明
TTL	CloudFront配信時に設定されるキャッシュ保持時間
Expires	キャッシュの期限切れを設定
Cache-Control max-age	CloudFrontがオリジンサーバーからオブジェクトを再度取得するまでオブジェクトをキャッシュに保持する期間を指定

【フィールドレベル暗号化】

個人を特定できる情報などの機密データのセキュリティをより強化
ユーザーが決めたフィールド固有の暗号化キーを使用して、リクエストがオリジンに転送される前にhttps内で機密データをさらに暗号化

Global Accelerator

TCP or UDPを介して様々なアプリケーションのパフォーマンス向上
1つ以上のAWSリージョンで実行されているアプリケーションにエッジでパケットをプロキシすることにより、TCPまたはUDPを介した幅広いアプリケーションのパフォーマンスを向上
CloudFrontに似ている
HTTPだけでなく、TCP/UDPのトラフィック・ルーティングに対応
クライアント証明書は利用する、クライアントIPは保存する
アプリケーションをエッジロケーションで実行、CDNのアプリケーション版
キャッシュを使わず幅広く柔軟に対応できるので Global Accelerator、キャッシュを使ってお手軽にCDNを構築するのでCloudFront
HTTPの特に静的IPアドレスを必要とするユースケースや、高速なリージョン間フェイルオーバーに適しているだけでなく、HTTP以外のユースケース、例えばゲーム(UDP), IoT(MQTT), VoIPにも適している

S3 (Simple Storage Service)

オブジェクトストレージ
デフォルトで複数AZに冗長化
⭐️ アプリケーションでバケット内のprefixごとに1sあたり3,500回以上のPUT/COPY/POST/DELETEリクエスト or 5,500回以上のGET/HEADリクエスト達成できる
prefixを増やせば並列化できる

名称	取り出し時間	説明
S3 standard （標準）	即時	・複数箇所にデータ複製、最もコストが高い・頻繁にアクセスされるデータに高い耐久性、可用性、パフォーマンスオブジェクトストレージ
S3 Standard-IA (標準-低頻度アクセス)	即時	・標準に比べて安価・データの読み出しに対してコスト発生・低頻度アクセス用だが読み込みはすぐできる
S3 Intelligent-Tiering	即時	・アクセスパターンに基づいてコスト効率の高いストレージ階層に自動で移動、または不明な存続期間が長いデータ向け
S3 One Zone IA (1ゾーン低頻度アクセス)	即時	・標準-IAより安価。・1つのAZのみにデータを保存。・ログファイルとかがベスト・データへのアクセス頻度が低く、高い耐久性を必要とせずかつ必要に応じてすぐに取り出したい場合に適している。・AZで障害時にデータが消滅する場合がある
Glacier	数分-数時間	・アーカイブ目的。標準と比べても格納コスト1/5 ・データの読み出しに料金がかかる・最低保持期間が90日
S3 Glacier Deep Archive	数時間	・長期アーカイブデータ向け・Glacierより安価。

-	S3 Glacier	S3 Glacier Deep Archive
迅速	1-5分	利用なし
標準	3-5h	12時間以内
大容量	5-12h	４８時間以内

【コスト】

ストレージ容量
データ転送 : 課金されるのはS3からの送信だけ、受信(upload)は無料

*インターネットへの送信、別のAWSリージョン、CloudFrontへの送信は別料金
*同一リージョン内のAWSサービスとの通信は無料

リクエスト数

*S3では、GET/PUT/POST/LIST/COPYなどのリクエストに対しても課金ある
*GETは安い、PUT/POST/LIST/COPYは高め
*DELETEは無料

【署名付きURL(Presigned-URL)】

特定のURLからのみS３にアクセスできるようにする機能

【ライフサイクル機能】

S3上で一定期間経過したオブジェクトを自動的に削除したり標準IAやGlacierに移行する機能

【バージョニング】

有効にすると、S3内のオブジェクトのあらゆるバージョンを取得できる
意図しないオブジェクトの削除を行ったときも復元できる
⭐️ 一度バケットのバージョニングを有効にすると、バージョニング無効の状態に戻すことはできない (停止は可能)

【静的webサイトホスティング】

htmlファイルや画像ファイルなどをS3において、クライアントからのリクエストに応じてそのまま表示
サーバーなしにwebサイトをホスティング可能
サーバーが必要ないために値段が安い
動的サイトは不可、SSL設定はCloudFront必須

【S3の暗号化】

名前	説明	鍵の管理場所	手間	料金
SSE-S3	・AES-256 暗号化タイプ・"x-amz-server-side-encryption":"AES256" ・利用状況の監査証拠がとれない	S3	少	無料
SSE-KMS	・"x-amz-server-side-encryption":"aws:kms"ヘッダーを設定して利用する・cloudtrailにより証跡ログが取得可能	KMS	中	KMSの料金が適用
SSE-C	・AES-256 暗号化タイプ	ユーザー	多	?
CSE(Client Side Encryption)	クライアント側	ユーザー	多	?

KMSでカスタマーマスターキー(CMK)を削除することは破壊的行為であ利、危険性を伴う
だから、KMSには削除待機期間が設定されている
KMSでCMKを削除するには、キーの削除スケジュールを設定しておく必要がある
待機期間は、最短7日から最長３０日(デフォルトでは30日)

【アクセス制御】

種類	対象	説明
ACL	バケット・オブジェクト	簡単に設定できるがその分柔軟なアクセス制御はできない
バケットポリシー	バケット	設定は複雑、柔軟なアクセス可能
IAMポリシー	IAMユーザー/グループ	S３への操作権限をIAMユーザー・グループに対して付与

Public Access
バケットポリシーが不正に書き換えられ、バケット内のオブジェクトが公開されることを防ぐ機能
外部に公開しないバケットは有効化

####【CORS (Cross-Origin Resource Sharing)】

すでにドメインが設定されているS3バケットを他のドメインに共有することができる

【S3 クロスリージョンレプリケーション(CRR)】

S3オブジェクトを別リージョンのバケットに自動で複数することが可能
オブジェクトの登録と同時に実行
バケットにおけるオブジェクトの作成・更新・削除をトリガーにレプリケーションを実行

【S3 select vs Athena vs Redshift Spectrum】

用語	説明
s3 select	・単一ファイルが対象・GZIP圧縮データやCSV・jsonに対して実行可能・クエリの機能が少ない
Athena	・複数のファイルを対象にできる・クラスタ(サーバ)を必要とせず、S3にデータがあればすぐに利用可能リトライ機能がなく、データを絞って高速にスキャンする S3上のログ等にデータを保管しておりそれを分析用途に簡単に利用したい場合 S3をデータレイクとして位置付け、S3上のデータに直接アクセスできるインターフェースを用意 Athena SQLクエリでSageMaker機械学習モデルを呼び出し、機械学習による推論も実行可能
Redshift Spectrum	Redshiftクラスタが起動されている前提であるため、RedShiftを利用している場合におすすめ大規模データに対して、複数クラスタで動作するため高速なレスポンスが期待できる・S3にデータをおいたままそのデータにアクセスできる方法
Macie	機械学習によりS3の機密データを検出、分類、保護する、フルマネージド型のサービス

S3をデータレイクとして位置付け、S3上のデータに直接アクセスできるインターフェースを用意
S3に格納された複数のファイルに対してクエリを行う→Athena, Redshift Spectrum

【S3 Transfer Acceleration】

地理的に一番近いエッジロケーションを利用して高速にデータアップロードを実施
送信元から遠く離れたs3へのデータ転送をAWSのエッジロケーションとしてネットワークプロトコルの最適で高速化するサービス
ユースケース : 世界中からアップロード, 大陸間で定期的にGBからTBのデータを転送するケース
費用 : 1GB uploadあたり、$0.04が上乗せ

【S3 マルチパートアップロード】

大容量のファイルを分割して転送する機能→S3へのアップロード時間の短縮
オブジェクトサイズが100MB以上の場合は、単一のオペレーションでオブジェクトをアップロードする代わりにマルチアップロードを使用する必要がある
S3 Transfer Accelerationと併用すると転送速度が一段と向上
S3バケットに保存できるオブジェクトの最大ファイルサイズ→5TB
prefixを利用して日付ベースでuploadを分散することで少なくとも3,500 request/s, データ取得で5,500/sサポート
S3のPath : s3://<bucket>/<prefix>/<object> (prefix : ディレクトリみたいなもの)

【S3イベント】

S3オブジェクト操作と連動したシステム連動処理
SNS / SQS / Lambdaに通知設定

RDS (Relational Database Service)

RDBSサービス
データ操作にSQL使用
障害時や誤作動が起きた際に５分前の状態に戻せる
RDSインスタンスにSSHはできない
DBインスタンスはMAX７日間停止できる
最大で５個のリードレプリカを作成して、読取処理の負荷分散可能
ファイルシステムとの連携はサポートされていないため、連携を実現するためにはEC2インスタンスにデータベースをインストールしてサーバを構築する必要がある
ライフサイクルポリシーによるBUはできない
EC2インスタンス＋EBSの構成が例えばMYSQLをインストールして動かしている
マルチAZ構成のRDSでは、プライマリデータベースのインスタンスがダウンした場合に管理者の介入なしにDB操作できるようにフェールオーバーが自動的に処理される。フェイルオーバーするとRDSはDBインスタンスのCNAMEレコードをスタンバイから切り替えて、新しいプライマリに昇格

【RDS暗号化】

RDSの暗号化されたDBインスタンスDBでは、基盤となるストレージに保存されているデータが暗号化され、自動化されたバックアップ、リードレプリカ、スナップショットも同様に暗号化される

【RDSのスケールアップ】

インスタンスサイズの変更
インスタンスタイプの変更
ストレージタイプの変更

【リードレプリカ】

RDSにおいてDB読み取り処理をオフロードすることできる機能
読み込み専用
マスターの複製DB
マスターの読み取りにかかる負荷を軽減でき、これによりマスターのパフォーマンスが向上

【レプリケーションラグ】

リードレプリカは非同期にレプリケート
レプリケーションデータが遅れることが多く、最新のトランザクションのいくつかを表示できないことあり

【IAMデータベース認証】

通常のパスワードを使ったデータベースの認証の代わりが権限を付与したIAMロールを用いることで認証を行う

【RDSプロキシ】

アプリケーションとRDSの間に配置され、ProxyとしてDBへの接続を効率的に管理
高速フェイルオーバーによる可用性の向上
Lambdaを利用してRDSのデータベースnに接続する際は、RDSプロキシをエンドポイントの代わりに利用して、接続することでコネクションを効率的に実行することができる
「接続が多すぎる」エラーが頻繁に発生するDBインスタンスやクラスターは、プロキシ経由が良い
Lambda -> RDS Proxy -> RDS Good!

【ストレージオートスケーリング】

実際にストレージが少なくなって来ると自動でストレージがサイズアップしてくれるようになり、実際に使う分＋αだけ支払えば良い

⭐️【読み取りリクエストが急増した時の対応】

リードレプリカ増設(コスト低い)
インスタンスタイプの性能変更
キャッシュレイヤーでElastiCache(コスト高)

Aurora

大規模なクエリ処理が発生するRDB
クラウド専用の分散型のRDS
MySQLと比べて最大５倍、標準的なPostgreSQLと比べて最大で３倍高速
商用DBと同等のセキュリティ、可用性とかを1/10で実現
最大15のリードレプリカを利用した高速読み込みが可能
Auroraはクラスターが3つのAZに分散されて構成され、さらにRDSと同様にマルチAZのフェールオーバー構成を有効化することが可能
フェールオーバーの実行時間はAuroraレプリカを作成している場合は30s以内に完了

【Aurora Multi-Master】

全てのDBインスタンスで書き込みオペレーションを実行
⭐️ DBの書き込み操作のためダウンタイムを許容できない時使用

【Aurora Serverless】

自動でスケールして、アクセスがなければ勝手に停止するAWSのMySQL/PostgreSQLインフラ

【Aurora Global Database】

Auroraクラスターを複数のリージョンにまたがって構築
AWSリージョン障害時の災害復旧実現
世界中からデータベースを高速に読み書き実現
プライマリ・リージョンから別リージョンへ低レイテンシーにデータがレプリケート
書き込み転送機能 : 有効にするとセカンダリリージョンでは読み込みだけでなく書き込みも可能

DynamoDB

マネージドのNoSQLデータベースサービス
データが3つのAZに分散して格納されるため耐久性が高く、格納容量に上限がない
また、key-value形式で簡易に操作できるかつレイテンシーが低いため、キャッシュやwebセッションの格納先としても利用
小規模データを保存、処理するためにはNoSQLDBを利用することが最適
API経由操作キーに対するvalueのCRUD操作は可能、ただしJOIN/Transaction/Commit/rollbackは不可
Read/Writeが多いシステムにgood
WEBセッション管理, S3オブジェクトのメタデータの保存に使用
データサイズは無制限、1つのデータは４００KBに制限

####【DAX (DynamoDB Accelerator)】

DynanoDBに特化したインメモリキャッシュ→DynamoDBテーブルへの数ミリ秒のレイテンシーを数マイクロ秒に短縮
DAXは、開発者がキャッシュの無効化、データ入力、クラスターの管理を実施する必要なし

【DynamoDBストリーム】

テーブル上の作成、更新、削除の時に別のAWSサービス(ほぼlambda)をトリガーとする機能
トリガーを利用してLambdaを実行するなど
DynamoDBテーブルに保存された項目の追加・変更・削除の発生時の履歴をキャプチャできる機能

データの保存

過去２４時間以内のデータ変更の履歴を保存し、２４時間を経過すると削除される
データ容量はマネージド型で自動的に管理

データ保存の順番 : 操作が実施された順番に応じてデータはシリアライズされる

【DynamoDBグローバルテーブル】

ほかのリージョンにテーブルのレプリカ作成
グローバルテーブルを作成するためにはまず１つのDynamoDBテーブルを作成してストリームを有効にする

【DynamoDB AutoScaling】

テーブルとインデックスを監視してアプリケーショントラフィックの変化に応じて、自動的にスループットを調整
DynamoDBテーブルを作成するとAutoScalingがデフォルトで有効
CloudWatchのモニタリングに基づいてトラフィックパターンに応じてプロビジョンスループット性能をユーザーにかわって動的に調整

【整合性モデル】

結果整合性
強い整合性

【料金】

(1) キャパシティユニット(read/write)
(2) ストレージ容量
(3) データ転送量

ElastiCache

大量かつミリ秒未満の応答時間のデータを扱うアプリケーションのインメモリデータストアとして活用
キャッシュエンジンは、RedisとMemcached が選択可能
ユーザー行動データの高速な処理には最適なDB
ノード、シャード、クラスタの単位が存在する
ユースケース : セッション管理, メタデータの蓄積、ソーシャルメディアのデータ分析、DBキャッシュ処理、Pub/Sub処理、ランキング、レコメンデーション

ノード(Node)

キャッシュサーバで、ElastiCacheの最小単位
選択したノードタイプによって性能(メモリやCPUなど)が異なる

シャード(Shard)

ノードをまとめるグループ
1つのシャードにプライマリノード1個と、リードレプリカ(読み込み専用)0-5個持つ

クラスタ

シャードをまとめるグループ
クラスタ毎にキャッシュエンジンを選択可能
クラスタモードは有効と無効を選択可能

インメモリキャッシュパターン

CDNのデータベース版
頻繁にアクセスするデータをDBではなくインメモリキャッシュに格納することで、DBの負荷を軽減する設計パターン

Redis	Memcached
・高速に値をRead/Writeできるインメモリキャッシュ型DB ・シングルスレッド・スナップショット機能がある・データを永続化できる	・高速に値をRead/Writeできるインメモリキャッシュ型DB ・マルチスレッド・スナップショット機能がない・データを永続化できない・フェイルオーバーや復元できない
・複雑なデータ型が必要な時・永続化が必要な時・フェールオーバーが必要な時・pub/subが必要な時	・シンプルなデータ型だけで充分な時・マルチスレッドが必要な時・バックアップと復元の機能がない・キーストアに永続性がない

Redis : インターネットスケールのリアルタイムアプリケーションにミリ秒未満のレイテンシーで動作する超高速インメモリデータストア
Redis : ゲームリーダボード、機械学習、メディアストリーミング、リアルタイム分析、セッションストア
*RedisをDynamoDBと統合することもできるが、DynamoDBにフィットしているDAXを使うことに比べるとはるかに複雑
ElastiCache for Memcached はS3の静的コンテンツを配信するためのキャッシュとしては使用できない

移行関連

①AWS Application Discovery Service(ADS)

移行計画を支援するサービス

②AWS Database Migration Service(DMS)

データベースを短期間で安全にAWSに移行することが可能
DB移行ツール

③AWS Server Migration Service(SMS)

仮想マシンの移行サービス
VMware, Hyper-V, Azure上の仮想サーバーをAMIとしてAWSに移行
手間がかからない
無料

④AWS Schema Conversion Tool

あるDBエンジンにおける既存のDBスキーマを、別のDBエンジンのスキーマに変換するツール

LB

####(1) 【Connection Draining】

バックエンドのサーバーがELBから切り離されてもセッションを持ち続ける機能
バックエンドのEC2を登録解除しても処理中のリクエストが終わるまで一定期間待つ
ソフトウェアのメンテナンスなどで使える機能
既存の接続を開いたまま、登録解除または異常なインスタンスへのELBのリクエスト送信を停止することができる
これにより、LBは登録解除または異常なインスタンスに対して行われた実行中のリクエストを完了するトラフィック処理を実施
LBが接続を維持する最大時間を指定 : 1~3,600s (デフォルトは300s)

(2) 【スティッキーセッション】

セッションの維持を行う機能→クライアントからのリクエストを毎回同じインスタンスに転送する機能のこと
HTTPレスポンスにELBでCookieを埋め込んでそのCookieを基にバインド先のインスタンスを固定する
送信先のEC2が障害によってダウンした場合は、セッションが途切れる問題が発生するのでELBによるスティッキーセッションは一時的に利用が良い

(3) 【Cross-Zone Load Balancing】

配下のEC2の負荷分散に応じて、複数のAzにまたがるEC2インスタンスに均等に負荷分散を行う
各LBはすべてのAZの有効なインスタンスにリクエストを分散する
これによりクライアントのDNSキャッシュが効いていてもバックエンドのインスタンスには適切に負荷分散がかけられる
ALBでは常にクロスゾーンバランシングが有効になっている

【Proxy Protocol (プロキシプロトコル)】

HTTPでいうところのX-Forwaded-forをHTTP以外で使いたい時のプロトコル

EBS (Elastic Block Store)

EC2インスタンスに接続して利用できるブロックレベルのストレージ
OSから見えるストレージボリュームで、アプリケーションやユーザーデータなどを格納
スナップショットでバックアップされS3に保存、増分バックアップ
スナップショットはEBSの利用状況に関係なく、非同期に作成
EC2とは独立
SGによる通信制御対象外であり、全ポートを閉じてもEBSは利用可能
他のAZのインスタンスにはアタッチできない
プロビジョンドIOPSのみ複数インスタンスで共有できる
スナップショットの管理→DLMによる管理

ストレージタイプ

名称	説明
①汎用SSD (GP2,GP3)	・デフォルトのボリュームタイプ・安定したI/O性能が利用できる・ストレージの読み書きに関しては課金されない
②プロビジョンドIOPS SSD (io1, io2, io2 block express)	・汎用SSDよりも高いI/O性能が求められるケース・複数のEC２への接続が可能・ストレージ容量だけでなく指定したIOPS数に対しても課金されるため注意。
③スループット最適化HDD(st1)	・主にファイルのシーケンシャルアクセスが多い場合に高いスループットを提供するタイプ。・大規模なデータを扱う時good ・用途としてはMapReduce,ETL処理、ログ処理、DWH、ビックデータ分析など・小さなファイルサイズを大量に読み書きするには向いていない
④コールドHDD	・高いスループトが不要な場合には、より低価格なコールドHDDのタイプ。・ログファイルの保管など高いスループットを求められないバックアップ領域などが主な用途
⑤マグネティック	旧世代のボリュームタイプ

IOPS : ストレージが1sあたりに処理できる(I/O)アクセスの数(ストレージに書き込むのが早いかどうか)
スループット : 単位時間あたりでどれくらいデータを転送できたか(処理能力が高いかどうか)
⭐️ ブートボリュームとしてスループット最適化HDD, Cold HDDは使用できない

【DeleteOnTermination】

インスタンスが終了すると、EC2は接続されていた各EBSボリュームのDeleteOnTermination属性を使用して、ボリュームを存続させるかどうか判断
「非有効化」にすることでEBSボリュームのみ保持可能

【DLM(Data Lifecycle Management)】

EBSのスナップショット作成や削除をスケジューリングできる
EBSの定期的なバックアップスケジュールを実施して貴重なデータを保護
古いBUを削除してストレージコストを削減する

【EBSボリュームの削除】

インスタンスを終了すると、EC２は接続されていた各EBSボリュームのDeleteOnTermination属性を使用してボリュームを存続させるか削除すべきか判断する

1	2
ルートボリュームのEBS	デフォルト設定ではEC2インスタンスの削除と共にEBSボリュームも削除される
DeleteOnTermination属性	・有効にしているとEC2インスタンスの削除に応じてEBSも削除される・非有効化することでEBSボリュームのみ保持可能

1	2
EBS	ネットワークで接続されたブロックレベルのストレージでEC２とは独立管理 EC2を終了してもEBSデータは保持可能 SnapshotはS3で保存
インスタンスストア	EC2の一時的なデータが保持され、EC2の停止・終了と共にデータがクリアされる

EBSミラーリング : 同じデータを複数のディスクに書き込むこと可能

【Multi-Attach機能】

1つのプロビジョンドIOPS SSD(io1, io2)ボリュームを同じAZにある複数のインスタンスにアタッチ可能

【RAID】

RAID0 : 複数のディスクを１台のディスクのように扱う、ストライピング
RAID1 : 2つのボリュームを同時に、ミラーリング

【インスタンスストア】

EBSよりもパフォーマンスが優れる
データは揮発性
インスタンスが停止・終了だとデータは失われる
スナップショットを取得することもできない
ただし、再起動ではデータは維持される
EBSは「ボリューム、IOPS、スナップショット」で費用が発生するのに対し、インスタンスストアの費用はEC2に含まれる

EFS (Elastic File System)

複数のEC2インスタンスからアクセス可能な共有ストレージ(インターネットからは直接アクセスできない)
複数AZに分散して保存
NFSv4プロトコル (Amazon FSx ときたら SMB Protocol)

【マウントターゲット】

EC2インスタンスから接続先のマウントターゲットを設定
EC2→マウントターゲット→EFSの流れ

【EFS Standard】

最高レベルの耐久性と可用性を必要とするワークロードに最適

【EFS Standard-IA】

EFSの低頻度アクセス用のストレージ
低頻度アクセスと判断されたものが自動的に安価なEFS IAストレージに移行してくれる
ライフサイクル管理を有効に

パフォーマンスモード	使用例
汎用	・ウェブ配信環境・コンテンツ管理システム・一般的なファイルサービス
最大I/O	・ビッグデータ解析・メディア処理

AWS DataSync

オンプレミスストレージとEFSの間でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービス

【Amazon FSx for Lustre】

多くのスーパーコンピュータで利用される高性能な分散ファイルシステム
データリポジトリとのシームレスな統合
S3のデータセットとAmazon FSx for Lustreファイルシステムを関連づけ実際に処理を行う時にのみLustreを使用する
処理が終了したら、ファイルシステムを削除したらFXs for Lustreについては課金されない

Kinesis

【Kinesis Data Stream】

バッチ間隔を60sに設定など、バッチサイズまたはバッチ間隔を指定可能
kinesis data streamのデータ保持期間はデフォルトで24時間で、最大値は168時間
配信ストリームは自動的にスケーリングされ1つのシャードは１sあたり１MBのデータを取り込むことができ、書き込みは１sあたり1,000レコードを取り込み可能
送信先にアップロードされたデータをKMS暗号化キーを指定して、自動的に暗号化を実施
コンソールやCloud Watchからメトリクスを参照可能
送信データ量とデータ形式の変換に対してのみ料金が発生
ビッグデータのストリーミングをリアルタイムで処理

CloudWatch

【VPCフローログ】

VPCフローログはネットワークトラフィックを取得しCloudWatchでモニタリングできるようにする機能
NICを送信先/送信元とするトラフィックが対象
キャプチャウィンドウと言われる時間枠10minで収集・プロセッシング・保存する

SQS

フルマネージド型のメッセージキューサービス
SQSを利用したポーリング処理 : イベントのトリガーをタイミングに依存しない連携が可能- 水平スケーリング : webシステムおアプリケーションの間にSQSキューを追加することによりスケーリングを実現
SQSのキューによってEC２インスタンス側のワーカー処理を複数で並行処理をすることが可能
メッセージ数は無制限 (ただし、拡張クライアントライブラリーを利用すると２GBまでのメッセージのやりとりが可能)
SQSに送信できる最大サイズは256KB
デフォルト４日間 (SQS側での最長保持期間は14日間)
オンプレ上でメッセージングサービスを利用しているシステムをそのまま移行する場合MQで、クラウドネイティブなサービスを構成する場合はSQSを利用する
SQSは、リクエスト毎に課金が発生。MQは、利用した時間およびMQを通過したデータ量に応じて課金が行われる

キューの種類

種類説明

スタンダード・一回以上の配信 : １回は確実に送信されるが、複数回送信されることもある
・⭐️ベストエフォート型 : メッセージが送信された時と異なる順序で配信されることがある
・メリットはほぼ無制限のスループット
・基本的に、順序性に依存せず、処理の重複を許容できるのであればスタンダードキュー

FIFO ・ ⭐️ 一回だけの送信 : メッセージの重複は発生しない
・順序保証 : 先入れ先出しのため
・

種類	説明
スタンダード	・一回以上の配信 : １回は確実に送信されるが、複数回送信されることもある・⭐️`ベストエフォート型` : メッセージが送信された時と異なる順序で配信されることがある・メリットはほぼ無制限のスループット・基本的に、順序性に依存せず、処理の重複を許容できるのであればスタンダードキュー
FIFO	・ ⭐️ 一回だけの送信 : メッセージの重複は発生しない・順序保証 : 先入れ先出しのため・

バッチ処理を使用する時は、FIFOキューはAPIメソッド(SendMessageBatch, ReceiveMessage, DelettetMessageBatch)ごとに1sあたり最大3,000のトランザクションをサポート
3000のトランザクションは300のAPIコールを表し、それぞれに10このメッセージのバッチがある
デフォルトではFIFOキューは1sあたり300メッセージしか処理できない

【ライフサイクル】

Producerがメッセージ送信
Consumerがメッセージを取得
Consumerが処理を終了し、メッセージを削除

*最長メッセージ保持期間を超えてキューに残っているメッセージは自動的に削除される
*デフォルトのメッセージ保持期間は４日間

【可用性タイムアウト】

この時間内は他のコンシューマによる同じメッセージの受信と処理が防止される
メッセージのデフォルトの可視化タイムアウトは30s (min0s, max 12h)

【遅延キュー】

キューへの新しいメッセージの配信を数秒延期させることができる
遅延期間の間コンシューマーに表示されなくなる

【SQSパラメータ】

パラメータ	-
receiveMessageWaitTimeSeconds	・Lambdaがメッセージをポーリングして応答を返す前に待機する時間(1-20s) ・ 0を指定すればショートポーリング0を指定すればショートポーリング
visibilityTimeout	メッセージがキューから読み取られた後、メッセージがconsumerに表示されない時間の長さ
maxReceiveCount	メッセージをDLQに移動する前に、送信元キューに表示されるように配信できる回数
maximumBatchingWindow	Lambda関数を起動する前に。SQSのレコードを集めるための最大時間。最大300sまで設定可能

1	2
Step Function	・細分化した機能を連結させて、視覚的に設計ができるサービス・ユースケース : 注文処理、在庫追跡、複雑なユーザー登録プロセス、管理者が承認した場合に限り処理を行う
Simple WorkFlow	・ワークフローを構築・実行するためのサービス・EC2インスタンスを利用したサーバーベースのワークフロー機能であるためサーバーレスオーケストレーションは提供していない

##SNS

フルマネージド型のPub/Subメッセージングサービス
Push機能
更新を定期的に確認したり、「ポーリング」したりする必要性がない
送信側がトピックを作成して受信側をポリシー指定することで制御された非同期通信を実現

Amazon MQ

メッセージブローカー
業界標準のAPIおよびプロトコルをサポート (従来のメッセージコードを書き換える必要なく現状維持できる)

VPN

VPN設定に必要 : 仮想プライベートゲートウェイ, カスタマーゲートウェイ

CloudFormation

用語	説明
変更セット	・スタックの更新前にリソースの更新や削除を把握することができる
ドリフト	・CFテンプレートの内容と、実際のリソースの異なる点を発見してくれる便利な機能
StackSets	・複数のアカウントおよびリージョンのスタックを一度のオペレーションで、作成、更新、削除できる機能

AWS Secrets Manager

DBの認証情報やパスワードなどの任意のシークレット情報をAPIコールで取得できるもの
アプリケーションにシークレット情報を保存する必要がなくなる
DB認証情報を格納して自動ローテートするたのセキュアな方法

AWS KMS(Key Management Service)

データを暗号化するための鍵の管理を行ってくれるサービス
暗号鍵をAWSの責任範囲において保管したり、更新したりしてくれる
データの暗号化の鍵(データキー)と暗号化のための鍵(マスターキー)を管理
CloudHMSより安価
サポートされる暗号鍵は、KMS:共通鍵, CloudHMS : 共通鍵と公開鍵

AWS CloudHSM

専用のハードウェアで暗号化キーを保管
CloudHSMの方がより安心してキーを管理することができる
KMSに比べると高価

AWS Directory Service

セキュリティ保護サービス

(1) AWS WAF

(2) AWS Shield : DDoS攻撃からリソースを守るサービス

(3) GuardDuty : 脅威を検出するサービス

CloudTrailイベントログ、VPC フローログ、DNSログなどの複数のAWSデータソース全体で何百億件ものイベントを分析
AWSのアカウント、ワークロード、S３に保存されたデータを保護するために、悪意あるアクティビティや不正な動作を継続的にモニタリングする脅威検出サービス
設定画面でGuardDutyを無効にする : GuardDutyがAWS環境を監視して新しい結果を生成するのを停止するだけでなく、既存の結果とGuardDutyの設定も失う

(4) Inspector : セキュリティの脆弱性評価

自動化されたセキュリティ評価サービスで、EC2インスタンスへの意図されていないネットワーク経路や、脆弱性をチェックできる

AWS Storage Gateway

オンプレミス環境にあるデータをクラウド上のストレージにおく。そのためのゲートウェイ
EC2インスタンスだけでなくオンプレミスサーバーにs3をマウントして利用も可能
データを暗号化できる
データの格納先　: S3, EBS, Glacier(ストレージゲートウェイの種類によって格納先が異なる)

1	2	3
(1)ファイルゲートウェイ		・オンプレミスに保存しているファイルをS3のオブジェクトとして保存・S3の1オブジェクト = オンプレミスの１ファイル・NFS / SMBプロトコルで接続NFS / SMBプロトコルで接続
(2)ボリュームゲートウェイ	キャッシュ型	・`プライマリはS3ストレージ` ・プライマリーデータをS3に保存して、頻繁にアクセスされるデータはキャッシュしてローカルに保存
	保管型	・`プライマリーオンプレミスストレージ` ・メインデータはローカルに保存する一方で、そのデータを`非同期にS3にバックアップする
(3)テープゲートウェイ		・物理テープライブラリへの代替として、ストレージゲートウェイを仮想テープライブラリとして使用

API Gateway

APIの作成・管理を行う
REST(ステートレス)とWebSocket(ステートフル)のAPI対応

【設定項目】

用語	説明
メソッドリクエスト	リクエストに認証が必要か、どのようなクエリパラメータを受け付けるかといったAPI Gatewayの受付設定を行う
統合リクエスト	アップストリームの指定、リクエストボディの変換といったAPI Gatewayとアップストリーム間の統合を行う
統合レスポンス	ステータスレコードのマッピング、レスポンス内容の変換といったアップストリームとAPI Gateway間の統合を行う
メソッドレスポンス	ステータスレコードごとのレスポンスヘッダーやレスポンスボディの設定といったAPI Gatewayからクライアントへのレスポンス設定を行う

【APIの公開】

作成したAPIを外部に公開するためにはデプロイを行う
各APIはデプロイ先としていくつかのステージを持ち、それぞれ異なるバージョンのAPIを公開することができる

【スロットリングの利用】

リクエスト数が多すぎる場合、制限をかけることで、トラフィックの急増に対してバックエンドサービスを守る

1	2
サーバ側	全てのクライアントに対するリクエストを制御する。全体のリクエストが多すぎるためにバックエンドサービスが処理できなく事を防ぐ
クライアントあたり	クライアントごとに「使用プラン」に応じて制限を行う。特定のユーザーからのリクエストが多い場合に有効

【アクセス制御】

◇ リソースポリシー(RESTのみ)

JSON形式のリソースポリシーを定義することで、API Gatewayのどのリソースに、どのアクセスからの、どのようなアクションを許可/拒否するかを指定できる
API Gatewayのリソースポリシー作成・更新のために必要な権限 : apigateway:UpdateRestApiPolicyとapigateway:PATCH権限必要
リソースポリシーを設定・変更したら、APIのデプロイを実行

◇ IAM認証

APIの各要素へのアクセス権限を設定したIAMポリシーを作成し、アタッチすることによりAPIへのアクセスの制御が可能になる
これには、対象の各APIメソッドでIAM認証を有効化する必要がある

⭐️ ◇ Lambdaオーソライザー

Lambda関数を作成することで、認証プロバイダーでの認証結果を元にAPIへのアクセス制御をメソッド単位で行えるようにする

◇ Cognitoオーソライザー

認証プロバイダーとしてCognitoユーザープールを用いて、APIへのアクセス制御をメソッド単位で行うことも可能
Lambda関数を作成する必要がない

◇ APIキー

API Gatewayの使用量を制限するために発行するアクセスキー
APIキーの使用量制限はそれぞれのAPIキーに対して設定するのではなく、使用量プランという設定項目でスロットリング設定を行い、APIキーで使用量プランに紐付けることで設定

Lambda

DynamoDBから取得したデータに任意の集計をかける関数
Lambda関数は実行数に応じて支払いが発生するため、Lambda関数が無期限に実行されないようにタイムアウト設定がされている
同一アカウントの同一リージョン内で1,000までの同時実行をサポート
Lambdaの言語サポート : C#/.NET, Go, Java, Node.js, Python, Ruby

【Lambdaの制限】

タイムアウト(デフォ3s, max15分) ⭐️
実行数はデフォルト100, max1000
/tmp ディレクトリのストレージの保存可能容量512MB
Lambdaレイヤー MAX5つまで
Lambda関数は最大512MBまでのデータ容量

【Lambdaレイヤー】

Lambdaファンクション間で共通するコンポーネントをLambda Layerとして定義し参照できる(5つまで)

Fargate

コンテナを実行する時にホストマシンとなるEC2のスペックを意識することなく設計できる
⭐️ コンテナ化されたアプリケーションが使用するvCPUとメモリリソースの量に応じて課金される
vCPUとメモリリソースは、コンテナイメージがPullされてからECSタスクが終了するまでの時間が計算され、最も近い秒数に切り上げれる
⭐️ EC2起動タイプのECSは、使用されたEC2インスタンスとEBSボリュームに基づいて課金

AWS Systems Manager

AWSで利用のインフラストラクチャーを可視化し制御するためのサービス
RGごとに運用データを確認できる
EC2のパッチ、更新、設定変更、削除、停止、およびデプロイなどを自動化

AWS Step Functions

JSON形式でステートマシンを定義して、ワーカーフローやワーク処理系のアプリケーションを構築することが可能
Lambda関数およびAWSの複数のサービスをビジネスプロセスとして配列することができるサーバーレスのワークフロー作成・管理サービス
ワークフローに手動アクションを必要とするいくつかのタスクが存在する可能性があると、その手動アクションが処理されなければワークフローがアクション待ちの状態となるため、タスクが停滞

AWS Organizations

複数のAWSアカウントに対してポリシーを設定してアクセス権限を管理
AWSアカウントの作成と管理の自動化
複数アカウントをまとめたグループを作成し、アカウントを自動化し、それらのグループにサービスコントロールポリシーを適用することが可能
単一の組織内の複数AWSアカウントの支払いを統合できる
→ストレージの利用量を統合して請求することによって、コストを削減できる可能性

AWS X-Ray

ユーザーがAmazon APIからのAPIリクエストを通じてサービスを呼び出した場合に、ユーザーリクエストを追跡および分析できる
アプリケーションが処理するリクエストに関するデータを収集するサービスで、レスポンスタイムやレスポンスステータス、アプリケーションに対するリクエストに関するデータを収集し、コンソール上で表示したり分析することで問題を特定
サービスマップと呼ばれるグラフから全体のパフォーマンスを確認することができ、リソースのレイテンシーや障害の発生率の特定などを確認できる

サービスマップ

アプリケーションから生成されたトレースしたデータを可視化したもの
クライアントが始点で、各サービスのノードが終点になる

##コストまわり

AWS Billing and Cost Management

AWS Budgets

コストまたは使用量が予算額を超えた時にアラートを出すカスタム予算を設定可能
予約アラートできる

Cost Explorer

これまでに発生したコストをグラフィカルに視覚化(過去のコスト確認)
課金状況を確認
RIの使用率レポート / カバレッジレポート
課金状況を確認
RIの使用状況までわからない

コストと使用状況レポート (Cost & Usage Reports)

利用可能な最も包括的なコストと使用状況のデータが含まれている
RIの使用状況わかる
AWSのコストと使用状況に関する最も包括的なデータを提供でき、またAthenaのデータ統合機能を使うことで、自分のコストと使用状況に関する情報に対してSQLできる
Redshift or QuickSightにデータをupload可能
コストを時間または日、製品または製品リソース、または自分で定義したタグごとに分類したレポートを受け取ることができる

AWS 料金計算ツール

費用見積もりツール
1ヶ月は７３０時間を前提

AWS Snowball

物理ストレージデバイスを使用してS3に大量のデータを送るデバイス

####(1)Snowball (古い)
50TB, 80TB

####(2)Snowball Edge (推奨)

100TB転送 (利用可能は80TB)
複数ディスクでクラスタリングを組むことできる
snowballよりエンドポイントの選択肢が多い

1	2
Snowball Edge Compute Optimized	機械学習とか
Snowball Edge Storage Optimized	大規模なデータ移行と定期的な転送ワークフロー、およびさらに高容量を必要とするローカルコンピューティングに適している

*Snowball Edge Storage Optimized : 数十テラバイトからペタバイトのデータをAWSに安全かつ迅速に転送する必要がある時に採用

#IAMロール
アプリケーションやAWSサービスに権限を与える仕組み。以下の2つの機能

①Switchロール

IAMユーザーが異なるAWSアカウントを管理するために使用できる機能

②IDフェデレーション

AWSのIDとは異なるIDを連携させる
(IAMユーザーを作成しなくても、FacebookのアカウントにAssumeRoleで権限を引き渡す)

(1) Open ID Connector

(2) AD Connector

(3) SAML2.0 : オンプレでID管理サーバがSAML2.0に対応している場合

【IAMの記録管理】

用語	説明
IAM アクセスアナライザー	外部エンティティと共有されているS3バケットやIAMロールなど分析してt、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスをt特定
Access AdvisorのService Last Accessed Data	IAMエンティティが、最後にAWSサービスにアクセスした日付と時刻を表示する
Credential Report	利用日時などが記憶されたIAM認証情報のレポートファイル
AWS Config	AWS ConfigはIAMユーザー、グループ、ロール、ポリシーの変更履歴、構成変更を管理するサービス
AWS CloudTrail	各種アカウントアクティビティやAPIコールをログに記録し、モニタリングするサービス

用語

AWS Lake Formation : S3を利用したデータレイク構成を容易に実施
cloud9 : クラウドベースのIDE,エディタのインターフェースと実行環境を一緒にしたIDE
AWS Service Health Dashboard : すべてのAWSリージョンで全てのAWSサービスの現在のステータスを確認できる
AWS Artifact : 重要なコンプライアンス関連情報の頼りになる一元管理のリソース
Amazon Lightsail : コンピューティング、ストレージ、データ転送などwebサイトやwebサービスなどに使うサーバーとして必要な機能を組み合わせてパッケージしたもの
Amazon Elastic Transcoder : クラウドメディア変換サービス
Amazon Polly : 文章をリアルな音声に変換するサービス
Amazon Rekognition : 画像分析と動画分析をアプリケーションに簡単に追加
Amazon Lex : 音声やテキストを使用して任意のアプリケーションに対話型インターフェースを構築するサービス
AWS IoT Core : 外部のデバイスとクラウド側を安全に接続するためのサービス。IoTに特化したサービスなので、IoTを扱う場合はAPI Gatewayなどではなくこちらのサービスを使用することでデバイスからAWSにアクセスする際のエンドポイントや認証処理、イベント実行などを統合的に管理することができる
QuickShight : RedShift, S3, Athena, Aurora, RDS, IAM, CloudTrainl, CloudDirectoryなどのAWSサービスと連携してBIツールとして
EMR : オープンソースとしてのフレームワークであるsparkとHadoopを使用して、膨大な量のデータを迅速かつコスト効率よく処理。高速データ処理
AppSync : GraphQLというwebAPIを用いてデータにアクセスでき、処理を行うことができるもの。APIで自動でデータを取りにいってくれる
Neptune : グラフDB

試験Tips

エッジロケーションで提供しているサービス : CloudFront, Route53, WAF
VPC Peering : 中国リージョンでは利用できない

顧客からの読み取りリクエスト増加対応

(1)リードレプリカの増設
(2)インスタンスタイプの変更
(3)キャッシュレイヤーでのElastiCacheの利用 (これは高価)

特定の国からアクセスを拒否

Route53の位置情報ルーティングする
CloudFrontの地域制限を利用する

CPU70%でアプリが応答しない

RDS DBインスタンスにリードレプリカを追加して、アプリケーションの読み込み負荷を分散する
複数のRDS DBインスタンスを構築し、データをシェーディングする

webページの平均読み込み時間を短縮

セッションとSQLクエリを保存するためにElastiCacheを使用し、DBの負荷を軽減する
RDSのリードレプリカを使用する

特定のユーザーに配信可能な方式

cloudFrontへのアクセスをOAIに限定
cloudFrontの署名付きURLを利用
VPC間の管理を効率化 = AWS Transit Gateway

S3へのファイルをアップロード速度を向上させるための最も費用効果の高い方法

マルチパートアップロード
S3 Transfer Acceleration

用語	説明
simple AD	AWS側にフルマネージド型のディレクトリを新規作成
AD Connector	オンプレミス環境のActive DirectoryとIAM管理を統合 SSOと連携したtシングルサインオンが可能
AWS Managed Microsoft AD	AWS側にMicrosoft Active Directoryとの互換性があるフルマネージド型のADを作成

参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Redis	Memcached
・高速に値をRead/Writeできるインメモリキャッシュ型DB ・シングルスレッド・スナップショット機能がある・データを永続化できる	・高速に値をRead/Writeできるインメモリキャッシュ型DB ・マルチスレッド・スナップショット機能がない・データを永続化できない・フェイルオーバーや復元できない
・複雑なデータ型が必要な時・永続化が必要な時・フェールオーバーが必要な時・pub/subが必要な時	・シンプルなデータ型だけで充分な時・マルチスレッドが必要な時・バックアップと復元の機能がない・キーストアに永続性がない