AWS 試験チートシート

AWSサービス早見表

本エントリは AWS 各種サービスの特徴をサクッと理解していただくことが目的です。
中身は実際に私が AWS試験(CP・SAA) を合格するにあたり、過去問や参考書などからエッセンスを抽出したものとなります。これから受験を予定している方の参考になれれば幸いです。

※簡略化するにあたり一部厳密性に欠ける箇所がございます。予めご了承ください。

主なインフラの利用範囲

利用範囲	サービス名
グローバル	IAM, CloudFront, CloudWatch, Route53, WAF
リージョン	VPC, S3, DynamoDB, Lambda, API Gateway, IGW
AZ	EC2, EBS, RDS, Redshift, ElsatiCache

アクセス制御

IAM

名前	概要	補足
IAM	AWSへのアクセスを制御	–
ルートユーザー	全ての管理権限を持つユーザー	最初に登録したアカウント。基本使わない。アクセスキーは即削除。MFA有効化。
IAMユーザー	ユーザー, アプリの実体	名前, PW, アクセスキーで構成。 1アカウントあたり5000ユーザーまで。
IAMグループ	IAMユーザーの集合	1ユーザーあたり10グループ、 1アカウントあたり300グループまで。
IAMロール	ユーザー, アプリへ権限を一時的に付与 (PWやアクセスキーとは紐づかない)	IAMポリシーをアタッチして使う。アクセスキーID, シークレットキーを使うより安全。 (Ex) EC2内のアプリからS3への書き込み
IAMポリシー	IAMユーザー/グループにリソースへのアクセス権を付与 (JSONで記述)	優先度は、明示的な拒否 > 明示的な許可 > 暗示的な拒否。 AWS管理, カスタマー管理, インラインポリシーの3種類。
AWS管理ポリシー	AWSが管理するポリシーのテンプレ	一般的なユースケース向き。 AdministratorAccess, PowerUserAccessの2種類。
AdministratorAccess	全てのアクセス権を提供するポリシー	管理者となる IAMユーザーに付与。
PowerUserAccess	IAM以外のアクセス権を提供するポリシー	IAMを管理しないユーザーに付与。開発者など。
カスタマー管理ポリシー	ユーザーがカスタマイズするポリシー	自社のセキュリティ要件を満たすために利用。
インラインポリシー	IAMユーザー/ロール毎の詳細なポリシー	個別の埋め込みなので共有はできない。

セキュリティグループ / ネットワークACL

名前	概要	補足
セキュリティグループ	インスタンス単位のファイヤーウォール	インスタンス単位で全ルールが即座に適用。デフォルトではインバウンドのみ拒否。許可するルールのみを定義。(ホワイトリスト) 通信の戻りは自動で反映。(ステートフル)
ネットワークACL	サブネット単位のファイヤーウォール	サブネット単位で番号順にルールが適用。デフォルトではインバウンド, アウトバウンドの両方許可。拒否するルールのみを定義。(ブラックリスト) 行き, 戻りの通信を個別に制御。(ステートレス) 新規ネットワークACL 作成時には全トラフィックが拒否。
両方で許可	セキュリティグループ, ネットワークACL の両方で許可されて初めて「許可」となる	どちらか一方が拒否であれば「拒否」

Organization

名前	概要	補足
Organization	複数アカウントを一元化	–
サービスコントロールポリシー(SCP)	個人, 組織単位でリソースのアクセスを許可/拒否	–
Consolidated Billing	複数アカウントの請求を合算	請求先のマスタアカウントにメンバーを追加。割引オプションの恩恵を全員が受けられる。
RAM	組織内でAWSリソースを共有	複数アカウントでリソースを集約。運用負荷を下げ、コスト効率を向上させる。

暗号化

名前	概要	補足
Certificate Manager	SSL/TLS証明書を一元管理	–
カスタマーマスターキー (CMK)	AWSで暗号化/復号化を行う鍵	(Ex) キーID, 作成日などのメタデータ
クライアントサイド暗号化	AWSに転送する前のユーザー側暗号化	–
サーバーサイド暗号化	AWSサービス側での暗号化	(Ex) EBS, Redshift, S3 での暗号化
KMS	マネージドの鍵管理サービス (鍵はユーザー自身が作成しAWSが管理)	CMKの作成, 有効化, ローテーション, 削除。 (Ex) SDK, S3, EBS, RDSと連携
CloudHSM	AWSが管理するユーザー占有のハードウェア	セキュリティ要件がかなり厳しい場合に利用。 HSM自体はユーザーのVPC内に設置。
Secret Manager	DBなどの認証情報を暗号化して一元管理	DBの認証情報をAPI経由でセキュアに取得。認証情報の自動更新。KMSとの連携。

認証

名前	概要	補足
IDフェデレーション	既存の認証方式とAWSの認証を紐付け	SAML2.0, OpenID Connect を用いたSSO。
STS	一時的なアクセスキー, トークンを発行	IDフェデレーションで利用。
WEB IDフェデレーション	OpenID Connect 対応のSNSと連携	(Ex) Facebookアカウントを用いた新規サインイン
Cognito	WEB, モバイルアプリのSNSと連携	–
Directory Service	AWSが管理するADサービス	Microsoft AD, Simple AD, AD Connector の3種類。
Microsoft AD	Microsoft AD と連携	–
Simple AD	AD互換のSambaサービスと連携	–
AD Connector	オンプレAD と連携	–

ネットワーク

VPC

名前	概要	補足
VPC	仮想プライベートネットワーク	1つのリージョンを指定して作成。(Max5つ)
Internet Gateway (IGW)	VPCからインターネットへ接続	VPCにアタッチして利用。
VPCピアリング	異なるVPC間をプライベート接続	2つのVPCをインターネットを経由せずに直接通信。 DR対策用のマルチサイトで利用。異なるアカウント間でもOK。アドレスの重複はNG。 (ピアリングしないのであればVPCのCIDRは重複OK)
Transit Gateway	VPCのハブとして使われるGateway	複数VPC をまとめて管理。他のサービスが Transit Gateway を経由して各VPCに接続。
VPCフローログ	VPC内のトラフィック情報をキャプチャ	キャプチャは CloudWatch Logs へ転送。 ENI, サブネット, VPC単位で設定可能。
踏み台サーバー	一時的にアクセス可能なサーバー。主にメンテナンス用途。	パブリックサブネットで IPアドレスを用いて使う。(通常は停止) アクセス元は0.0.0.0/0ではなく特定IPアドレスを指定。 (Ex) SSHでの遠隔ログイン

サブネット

名前	概要	補足
サブネット	AZ内の小さなネットワーク単位	1つのAZ内に複数サブネットを作成可能。 (サブネットはユーザー自身で作成)
パブリックサブネット	インターネットと通信可能なサブネット	ルートテーブル内で IGW を指定したもの。
プライベートサブネット	インターネットと通信しないサブネット	–
ルートテーブル	サブネットの通信先を決めるもの	送信先IPアドレスとターゲットが書かれた表。

NAT

名前	概要	補足
NAT Gateway	NAT機能を持つマネージドなGateway	パブリックサブネットに配置。 AZ内で冗長化されているが、AZ間では冗長化されていない。 (Ex) プライベートサブネットからインターネットにアクセス
AZ間冗長化	それぞれのAZ毎に NAT Gateway を配置	NAT Gateway を複数AZにまたいで使用する際の構成。 1つのAZで障害が起きた場合でも処理を継続。
NATインスタンス	NAT機能を持つ EC2インスタンス	自身へのトラフィックを無効化するために、利用時には「送信元/送信先チェック」機能を無効化する。冗長化の設定はユーザー自身で行う。(やや面倒)

Direct Connect / サイト間VPN

名前	概要	補足
Direct Connect	オンプレとAWSを 1対1 で接続する専用線 (利用には数日かかる)	高速ネットワーク帯域。安定した通信。プライベート接続なので安全性も高い。 (東京 + 大阪など) 複数回線で冗長化することも。 VIFを構成すると追加の専用線を構築可能。
Direct Connect Gateway	オンプレと複数リージョンVPCを 1対多で接続	(Ex) VPCピアリング, Transit Gatewayとオンプレを接続
サイト間VPN	オンプレとAWSを接続する専用線 (低コストかつ迅速に導入可能)	インターネットを経由するため、速度, 安全性はDirect Connectより劣る。 Direct Connectと併用すればDR対策にもなる。
Virtual Private Gateway	オンプレとAWSを接続	Direct Connect, サイト間VPNで利用。
占有型	ユーザーが物理接続に対して契約した専用線	速度は 1Gbps, 10Gbps の2種類。
共有型	キャリアが契約した専用線を論理的に分割	占有型以外の速度を利用可能。

VPCエンドポイント

名前	概要	補足
VPCエンドポイント	プライベートネットワークからAWSへアクセス (インターネットは経由しない)	ターゲット先のエンドポイントを作成。 (Ex) CloudWatch Logs に VPCエンドポイントを指定しプライベートネットワークから書き込む。
Gateway型 (ネットワークレイヤ)	ルートテーブルにターゲットを追加	(Ex) S3, DynamoDBに接続
Interface型 (アプリケーションレイヤ)	APIコールに対してプライベート接続	(Ex) CloudWatch, SQSに接続

ELB

名前	概要	補足
ELB	EC2, IPアドレスのトラフィックを分散	ALB, NLB, CLBの3種類。自動スケーリング。ELB自体の内部冗長化。通信ログをS3へ保管。
ALB	HTTP(S)のトラフィックを分散 (レイヤー7で動作)	WEBからのリクエストを内容に応じて割り振る。
NLB	数百万のトラフィックを分散 (レイヤー4で動作)	大規模データを高速に処理。 HTTP(S)以外は基本これを使う。
CLB	旧式のロードバランサー (レイヤー4, 7で動作)	後方互換性のために用意されている。基本使わない。
エンドポイントで接続	ELBに割り振られたDNS名で接続	ELBのIPアドレスは変動するため、エンドポイントを指定して接続する必要がある。
ELB側でのSSL復号化	証明書の一元管理。インスタンス負荷軽減。	–
ヘルスチェック	正常なインスタンスで処理を継続	–
スティッキーセッション	特定インスタンスにリクエストを送信	(Ex) ユーザー毎のセッション管理
Connection Draining	サーバー処理が完了するまで解除を遅延	スケールイン時のエラーを防ぐ。
クロスゾーン負荷分散	複数AZの全てのEC2に均等に処理を分散	AZ毎にインスタンス数が異なる場合でも均等に分散。
外部ELB	パブリックサブネットに配置したELB	(Ex) EC2をプライベートに配置して安全性を高くする
内部ELB	プライベートサブネットに配置したELB	(Ex) 外部と通信しないELB

Auto Scaling

名前	概要	補足
Auto Scaling	リソースの使用状況に合わせたスケーリング	予め設定した AMI から EC2 を起動。ユーザーデータを利用して AMI を最新化することが重要。
スケーリングプラン	いつ, どんな条件で Auto Scaling を実行するか	(Ex) 正常なインスタンス数を維持, 手動でスケール, スケジューリング, CloudWatchメトリクスに応じた実行
起動設定	Auto Scaling 実行時に起動する EC2の情報	(Ex) AMI, インスタンスタイプ, セキュリティグループ, キーペア
Auto Scalingグループ	起動するインスタンスの場所, 最小/最大数	–
クールダウン	Auto Scaling の待ち時間を設定	過剰にEC2インスタンスが増えるのを防ぐ。 (Auto Scaling は新しいEC2を立てるまで数分かかる)
ライフサイクルフック	Auto Scaling でEC2起動/終了を一時的に待機	待機中にアクションを実行。 (Ex) 起動時のデータ読み込み, 終了時のログ出力

Route 53

名前	概要	補足
Route 53	マネージドのDNS (ホスト名 -> IPアドレス)	(Ex) 独自ドメイン登録, ヘルスチェック, DNSフェールオーバー (Sorryページの表示)
パブリックホストゾーン	公開WEBサーバーなどの名前解決	–
プライベートホストゾーン	インターネットを介さない通信の名前解決	(Ex) 社内システム
ALIASレコード	Route 53 独自のDNS機能	ELB, CloudFront のエンドポイントを CNAMEレコードではなく Aレコードで指定。
レイテンシールーティング	レイテンシーが低いものへルーティング	–
加重ルーティング	設定した加重度に応じたルーティング	–
位置情報ルーティング	クライアントから近い場所へルーティング	リージョンをまたぐこともある。
フェイルオーバールーティング	ヘルスチェック後に正常なものへルーティング	–
シンプルルーティング	予め設定したレコードへルーティング	–
地理情報近接性ルーティング	クライアントとリソースの両方から近い場所へルーティング	–
複数値回答ルーティング	正常な複数レコードへルーティング	–

CloudFront

名前	概要	補足
CloudFront	エッジロケーションからコンテンツ配信 (S3, ELB, オンプレなどをオリジンに設定)	ユーザーに近いキャッシュサーバーから配信。高可用性。高パフォーマンス。低レイテンシー。キャッシュを返した場合、EC2, ELB にはログが残らない。
オリジン	キャッシュするコンテンツの提供元	CloudFront を利用すればオリジンが直接攻撃されない。
SSL暗号化	SSL証明書を用いた暗号化	CloudFront 配下の通信をSSL暗号化。ユーザー独自の証明書を導入することも可能。
フィールドレベル暗号化	HTTPSの前にユーザー固有の鍵で暗号化	(Ex) 個人情報など機密性が高いデータ
署名付きURL	一定時間だけアクセスできるURLを発行	(Ex) WEBサーバーを経由せず直接S3にファイルを格納
カスタムエラーページ	予め用意したエラーページを表示	オリジンからエラーコードが返されたときに利用。
地域制限	ユーザーの地域情報に応じてブロック	–
ストリーミング配信	WEB, 音声, 映像のストリーミング配信	–
Lambda@Edge	エッジロケーションで Lambda を実行	ユーザーから近いため通常の Lambda より待ち時間が短い。

WAF / Shield

名前	概要	補足
WAF	SQLインジェクション, クロスサイトディスクリプションなど一般的な攻撃に対するファイヤウォール	(Ex) CloudFront, ALB, API Gateway にアタッチし送信元IPアドレス, HTTP情報をもとに通信を許可/拒否
Shield	DoS, DDoS に対するファイヤーウォール	無料版：レイヤー3,4 (インフラ) を保護。有料版：レイヤー3,4,7 (インフラ + アプリ) を保護。有料版のみDDoS攻撃時のサポート有り。

その他

名前	概要	補足
Global Accelerator	AWSネットワーク網を利用した通信	インターネットを経由するより高速。最適化したトラフィックをエンドポイントに転送。
Elastic IP	固定のグローバルIPアドレス (1リージョンあたり5つまで)	EC2を停止してもアプリ, DNS設定を変更せずに済む。 EC2にアタッチされていない時, EC2停止時に課金される。
DataSync	オンプレからAWSへストレージデータを転送 (ネットワーク経由)	専用エージェントを用いたAWSへのデータ移行。 ML分析基盤をAWSに構築することも可能。 (Ex) オンプレから S3, EFS, FSx for Windows への転送

コンピューティング

EC2

名前	概要	補足
EC2	AWSのコンピューティングクラウド。	＜構築の流れ＞ ①AMI の選択 ②インスタンスタイプの選択 ③インスタンスの詳細設定 ④ストレージの設定 ⑤タグの追加 ⑥セキュリティグループの設定 ⑦キーペアの設定
AMI	EC2を作成する際に利用するVMのイメージ (EC2の構成情報 + EBSスナップショット)	＜EC2を別リージョンへ複製する流れ＞ ①EC2の AMI をコピーし複製先に別リージョンを指定 ②新しいリージョンで AMI からEC2を起動
インスタンスタイプ	EC2で利用するサーバースペック	vCPU, メモリ容量の組み合わせを選択。タイプ変更時はインスタンスを停止。
インスタンスの詳細設定	ネットワーク情報, IAMロールなどを設定	–
ストレージ設定	EBS or インスタンスストアを選択	–
タグ	AWSリソースにつけるラベル	(Ex) 運用の効率化, 課金の振り分け
キーペア	公開鍵, 秘密鍵を発行 (紛失時は新しいキーペアを発行し別のEC2を起動)	公開鍵はAWSで管理され、EC2起動時にコピー。秘密鍵はユーザーが保管し、EC2アクセス時に利用。
ユーザーデータ	EC2起動時に最新データを反映させるためのスクリプト	–
インスタンスメタデータ	インスタンス自身のデータ	(Ex) インスタンスID, IPアドレス, ホスト名, 公開鍵, 実行中インスタンスの設定/管理
EBS最適化インスタンス	EBS専用の通信帯域を用意したEC2 (ネットワーク帯域とは別)	EBSが他のトラフィックの影響を受けなくなる。
EC2の休止	EC2のメモリ状態を保管し IPアドレスを保持	EC2インスタンス作成時に設定する必要がある。
VM Import	オンプレの VMイメージをAWSに取り込み	–
VM Export	AWSの VMイメージをオンプレへ出力	–

プレイスメントグループ

名前	概要	補足
プレイスメントグループ	同一AZ内のEC2を論理的にグループ化したもの	EC2インスタンス間の通信を高速化。クラスタコンピューティング用途。
クラスタープレイスメントグループ	同一AZ内でEC2をグループ化 (全てのEC2を同一ラックに格納)	同一ラック内のEC2間の通信を高速化。低レイテンシー。高スループット。
パーティションプレイスメントグループ	パーティション単位でEC2をグループ化 (パーティション毎のラック分け)	分散環境 (Hadoopなど) 向き。パーティション単位でのDR対策にも。
スプレッドプレイスメントグループ	EC2が個別に電源とネットワークを持つ (全てのEC2を異なるラックに配置)	障害時の影響を抑えられる。

Lambda

名前	概要	補足
Lambda	サーバーレスでコードを実行	メモリ容量, 実行時間(ミリ秒) に対して課金。実行は Max15分なので時間がかかる処理には不向き。 (時間がかかる処理は AWS Batch を使う)
ExecutionRole	Lambda にアタッチされた IAMロール	IAMロールに従ってリソースへアクセス。
Lambdaのログ	処理結果は CloudWatch Logs に保存できる	–

コンテナ

名前	概要	補足
ECS	AWSのマネージドコンテナオーケストレーション (CPUやメモリなどを論理的に分割)	Dockerコンテナの実行, 停止, 管理を行う。＜構築の流れ＞ ①クラスター作成 ②タスク定義 ③ELB設定 ④サービス設定
クラスター作成	EC2の論理グループを作成	(Ex) インスタンスタイプ, インスタンス数, EBSストレージの設定
タスク定義	ECSの実行環境を定義	(Ex) Dockerイメージの格納先, メモリ制限, ネットワークの設定
サービス設定	起動するコンテナの数, 最大数を定義	–
EKS	(Googleが開発した) Kubernetes用のマネージドコンテナオーケストレーション	–
Fargate	ECS / EKSの両方で動作するサーバーレスコンピューティングエンジン	動的な処理が得意。サーバー, クラスタ管理が不要。(EC2の場合は管理が必要)

その他

名前	概要	補足
API Gateway	APIの作成, 監視, 保護などを容易に行う	サーバーレスなためLambdaと相性が良い。 (Ex) API実行→API Gatewayを経由→Lambda→S3へ画像を保存
EMR	大量データを処理するWEBサービス	(Ex) 分散アプリの実行, Hadoopクラスターの構築/管理
Lightsail	アプリやWEBサイトを手軽に構築	(Ex) WordPressが使えるサーバーの構築

ストレージ

S3

名前	概要	補足
S3	高耐久/容量無制限のオブジェクトストレージ (ただし1ファイルあたりのサイズ制限有り)	ID, メタデータでデータを管理。非常に安価。同一リージョン内の 3つのAZ へ自動で複製。 (耐久性は99.999999999%, 可用性は99.99%)
バージョニング	オブジェクトのバージョン管理	誤操作時に前のバージョンに戻すことが可能。復元性は向上するがその分コストがかかる。
クロスリージョンレプリケーション	別リージョンのS3バケットに複製	別のアカウントを複製先にすることも可能。 (複製なので誤操作の対策にはならない)
結果整合性モデル	データの新規追加では整合性が保証されるが、更新/削除は反映されるまで時間がかかる。	–
IAMポリシー制御	IAMユーザー/ロールへのアクセス制御	(Ex) Read / Get / Put操作の制御
バケットポリシー制御	IPアドレス, IAMユーザーへのアクセス制御	S3バケットにJSONを記述。
ACL制御	AWSアカウント単位でのアクセス制御	(Ex) 不特定多数へファイルを公開/非公開の設定
ブロックパブリックアクセス制御	バケットポリシー, ACL の設定を一括制御	意図せず外部へ公開されることを防ぐ。
AES-256暗号化	S3バケットに使われるAESの256bit暗号化	S3の鍵, KMSの鍵, ユーザー独自の鍵の3種類。
スタンダード	デフォルトのストレージクラス	99.999999999%の耐久性。
標準低頻度アクセス	データの読み取りに対して課金。	(Ex) アクセス頻度が少ないデータ
1ゾーン低頻度アクセス	標準低頻度アクセスより耐久性は劣るが安価。 3つのAZではなく 1つのAZ にデータを保存。	(Ex) アクセス頻度が低く耐久性が不要なデータ
低冗長化ストレージ	3つのAZではなく 2つのAZ にデータを保存	スタンダードに比べコストを抑えられる。
S3 Glacier	アーカイブ用途の大容量, 安価なストレージ	データ復元のため取り出しに時間がかかる。
Glacier Deep Archive	Glacier より安価だが取り出しに時間がかかる	＜取り出し時間＞ Glacier – 迅速：1〜5分 Glacier – 標準：3〜5時間 Glacier – 大容量：5〜12時間 Deep Archive – 標準：12時間以内 Deep Archive – 大容量：48時間以内
Intelligent-Tiering	アクセス頻度に応じてストレージを自動的に分類	低頻度/高頻度の2階層に分類。
ライフサイクルポリシー	ある期間でオブジェクトを削除/アーカイブ化	(Ex) 過去データの断捨離, Glacierへの移行
マルチパートアップロード	オブジェクトを分割してS3への転送を効率化	オブジェクトをパート単位で分割して転送。 (その後S3でオブジェクトが再構築される)
S3 Transfer Acceleration	クライアントとS3間の通信を高速化	エッジロケーション, AWSネットワークを利用。
Webサイトホスティング	静的コンテンツをサーバーを構築せずに公開 (HTMLや動画は◎, PHPファイルは×)	(Ex) Route53 と連携させSorryページを表示
署名付きURL	S3へ一定期間許可するURLを発行	非AWSユーザーのS3アクセス用途。 (一般公開用のアクセス権も併せて削除)
OAI	S3への直接アクセスを制限	(Ex) CloudFront のみにアクセスを許可し S3でプライベートコンテンツを配信。

EBS

名前	概要	補足
EBS	EC2にアタッチする永続可能なストレージ。 EC2とネットワーク接続。GBあたりの従量課金。旧式〜最新式まであらゆるファイルシステムに対応。	ボリューム作成後 (1台の)EC2 へアタッチ。 EBS単体ではデータへアクセスできない。データは1つのAZ内で自動的に冗長化。
プロビジョンドIOPS SSD	最も高パフォーマンスなSSD。最も高価。 (Nitro Systemを選択すると IOPS が最も高くなる)	ストレージ容量 + 指定したIOPS に対して課金。 (Ex) 汎用SSDで対応できないシステム
汎用SSD	デフォルトのボリュームタイプ。SSDを安価で利用。 (容量毎に IOPS が用意されている)	(Ex) 仮想デスクトップ, 開発環境, 低遅延アプリ
スループット最適化HDD	大量ストレージを安価に利用	(Ex) ビッグデータ, DWH, ログ処理
コールドHDD	アクセス頻度が低い大量データの保存に適したHDD	IOPS重視なら SSD。スループット, コスト重視なら HDD。
マグネティック	旧世代のボリュームタイプ	アクセス頻度が低いデータ向き。旧型。
スナップショット取得	スナップショットは取得開始時点のもの (取得開始から終了までの変更は反映されない)	自動的にS3へ保管。(高耐久性) 初回はフルバックアップ。2回目以降は増分で取得。
EBSの暗号化	ボリューム新規作成時に暗号化設定を行う	＜既存のEBSを暗号化する流れ＞ ①既存ボリュームのスナップショットを作成 ②①を複製する際に暗号化オプションを指定 ③暗号化済みスナップショットからEBSを作成 ④EC2から既存のEBSをデタッチ ⑤EC2へ暗号化済みEBSボリュームをアタッチ

EFS / FSx

名前	概要	補足
EFS	複数EC2で使うマネージドな共有ストレージ (NFSプロトコルのためWindows用では使えない)	EBSより高価。高可用性。高拡張性。複数AZに冗長化してデータを保管。 (AZをまたいだファイルへもアクセス可能)
FSx	複数EC2にアタッチできる共有ファイルシステム	マルチAZに対応。(高可用性) S3へのバックアップ。(高耐久性) 通信は自動で暗号化。 IAMロール, セキュリティグループで制御。
FSx for Windows	WindowsサーバーのSMBプロトコルを利用	AD連携, WindowsのACL でアクセス制御。
FSx for Lustre	処理能力が高い Linuxベースのファイルシステム	データ処理に最適化。機械学習向き。 Linuxベースのアプリとの連携が楽。

Snowファミリー

名前	概要	補足
Snowcone	ペタバイト規模のデータをオフラインでAWSへ転送	小型のケース。申請して届くまで1週間ほどかかる。他のSnowfamily同様、高速で安全な転送が可能。
Snowball	数ペタバイト規模のデータをオフラインでAWSへ転送	中型のケース。
Snowball Edge	Snowballの拡張版	エッジ処理のための仮想サーバー&ストレージ。
Snowmobile	エクサバイト規模のデータをオフラインでAWSへ転送	大型のトラック。

Source: https://www.slideshare.net/AmazonWebServices/storage-and-data-migration-aws-innovate-toronto

その他

名前	概要	補足
インスタンスストア	EC2用の一時ストレージ (ホストコンピュータに物理的にアタッチ)	インスタンス起動後EC2へアタッチ。無料。ホスト領域を使うため非常に高速。 EC2 を停止するとデータが消える。(揮発性) 再起動ではデータは消えない。 ( EC2停止, 起動時はホストが変わってしまう)
Storage Gateway	S3へアクセスするサービス (プロトコルは NFS, SMB, iSCSI )	EC2やオンプレ環境で利用。種類は以下の4つ。
キャッシュ型ボリューム Gateway	データをS3に保存し、アクセス頻度の高いものはローカルにキャッシュ	プロトコルはiSCSI。 (データ転送に TCP/IP を利用)
保管型ボリューム Gateway	データをスナップショットとしてS3に格納 (スナップショットなのでデータ自体は無い)	プロトコルはiSCSI。
テープ Gateway	物理テープの代替としてデータをS3に格納	プロトコルはiSCSI。
ファイル Gateway	データをオブジェクトとして直接S3に格納	プロトコルはNFS。
AWS Import AWS Export	物理ディスクから AWS内のストレージへ転送。 AWS から物理ディスクへ書き出し。	短時間で大容量のデータを転送。移行には高価なディスクが必要。送信時の耐久性やセキュリティが懸念される。

データベース

RDS

名前	概要	補足
RDS	マネージドのリレーショナルDB	＜種類＞ AWS独自のDB：「Aurora」他の環境でも使われるDB：「PostgreSQL, MySQL, MariaDB, Oracle DB, Microsoft SQL Server」＜障害時の挙動＞シングルAZの場合：自動で再起動。マルチAZの場合：スタンバイDBへフェールオーバー。
Aurora	他DBより安価で高性能なマネージドDB。 SQL処理用の DBインスタンス、データ格納用のクラスターボリュームで構成。	1AZあたり2つのディスク計6ヶ所へ書き込み。クラスターボリュームは3ヶ所のAZに存在。 → 読み書きを行うプライマリーDBインスタンス 1つ。 → 読み取り専用の Auroraレプリカ 2つ。
パッチ適用	バグ修正や機能変更など。(数ヶ月に1回)	指定した時間帯にAWSが自動でパッチを適用。
バックアップ方法	DBスナップショット + トランザクションログ	DBスナップショットはAWSが毎日自動で取得。 (最大35日間保存) トランザクションログは5分毎に自動でS3に保存される。
リストア	DBスナップショットからDBを復元	RDS削除時に「Retain」を有効化しないと、 DBスナップショットも一緒に削除されてしまう。
ポイントインタイムリカバリ	特定の日時時点にデータを復元	DBスナップショット + トランザクションログを用いて特定時点でのデータを復元。
マルチAZ	RDSを複数AZに構築	データの欠損をほぼ0にできる。障害時はスタンバイDB へ自動でフェイルオーバー。通常はデータを直近5分以内にしか戻せない。
リードレプリカ	読み取り専用のDB (マスタDBとの同期処理は非同期で実行)	マルチAZ, 異なるリージョン間でも構築可能。 DB負荷を下げるためのレポート層にも利用。読み/書きを分離させパフォーマンスと耐久性を向上。アクセスが増え続ける場合は DynamoDB を検討。
SSL接続	アプリから RDS へSSL接続	–
Aurora Serverless	必要なときだけDBを起動 (通常はクラスタボリュームのみ)	SQLリクエスト時のみDBを起動。低頻度アプリ, 負荷が一定でないアプリ向き。

DynamoDB

名前	概要	補足
DynamoDB	マネージドの NoSQL DB。キーバリュー型。大量データ向き。 ( 構造化/非構造化データの両方に対応)	データは同一リージョン内の3つのAZに保存。 (Ex) WEBセッション, メタデータの管理, スマホゲーム用DB, IoTデータ用のDB
API経由での通信	DynamoDB の通信は SDK, CLI で API を使う	–
結果整合性モデル	データが正しく反映されるまで時間がかかる	3つのAZへの書き込みには時間差がある。 (情報が最新のものでない可能性も)
Consistent Read	書き込みが反映された最新データを読み取る	(3箇所のうち) 2箇所で反映された値を返す。
DynamoDBグローバルテーブル	複数リージョンのDBでデータ整合性をとる	全てがマスタテーブルであり 1つの変更が全テーブルに影響する。
DynamoDBストリーム	データ変更の履歴を24時間保持	DynamoDB に負荷をかけずに集計/分析を行う。データ変更時に通知を受け取ることも可能。
DynamoDB Accelerator (DAX)	DynamoDB用インメモリキャッシュ	100万回以上のアクセスを数ミリ秒で処理。 DynamoDB へのアクセス負荷軽減。
オンデマンド課金	データの読み/書きに対して課金	(Ex) トラフィックが事前に予測できない場合, 利用分だけ課金する方が安い場合
プロビジョニング済課金	事前に 1秒あたりの読み/書きの回数を予測	(Ex) トラフィックが予測できる場合, トラフィック変化が小さい場合

Redshift

名前	概要	補足
Redshift	ペタバイト規模を扱えるマネージドな DWH	BIツール用途。大量データの集計/分析。 (分析に RDS を用いると負荷が集中する)
ノード	コンピューティングリソースの集まり (ノードの集まりはクラスター)	リーダーノードがリクエストを受け取り、それを複数のコンピュータノードに分散。
スナップショットの取得	クラスタのポイントインタイムバックアップ	自動スナップショットは一定期間後に削除。手動では永続的にバックアップを保存可能。
クロスリージョンスナップショット	スナップショットを別リージョンにも格納	–
Redshift concurrency scaling	突発的に負荷に対して自動でスケーリング	スケール範囲は事前に設定。
Redshift Spectrum	Redshift の拡張版。S3のデータも分析可能。	Athena と比較される。

ElastiCache

名前	概要	補足
ElastiCache	マネージドのインメモリDB。キーバリュー型。 ( Memcshed, Radis の2種類)	メモリ上で処理。高パフォーマンス。 RDBの負荷軽減・高速レスポンスが目的。 (Ex) WEBのセッション, SQLクエリ
Memcached	シンプルな構造のデータを一時的にキャッシュ (あくまで一時的なものなのでDBは別で用意する)	ノード間の複製は行われない。マルチスレッドを持つ大きなノード向き。
Radis	複雑な構造のデータを永続的にキャッシュ (データストアとしても利用可能)	プライマリノードのデータを非同期でレプリカノードに複製。マルチAZ構成では障害時に自動でフェイルオーバー。暗号化, 復元, コンプラ認証などにも対応。

その他

名前	概要	補足
Neptune	マネージドのグラフDB。 (モノ同士の繋がりを示す)	ノード (データの要素), エッジ (ノード間の関係), プロパティ (ノードとエッジの属性)で構成。 (Ex) 人同士の繋がり, 鉄道の最短経路
Athena	S3内のデータをSQLで分析	–
QuickSight	マネージドなBIツール	RDB, S3, Athena, 外部DB のデータを可視化。コスト最適化にも使われる。

データ通知 / 連携処理

SES / SNS

名前	概要	補足
SES	AWSのEメールサービス	SES の API を使ったメール配信。
SNS	メッセージ通知サービス	配信先は HTTP(S) / SQS / Lambdaなど。

SQS

名前	概要	補足
SQS	マネージドなメッセンジャーキュー (デフォルトで4日間保存)	疎結合なアーキテクチャーを実現。 (Ex) 複数EC2へ非同期に分散処理, バックエンドに負荷が集中する処理, キューを介したトラフィック毎のフロー制御
標準キュー	メッセージ処理の順序は保証されない	(Ex) 動画のエンコーディング, 順序が関係ない並列バッチ処理
FIFOキュー	メッセージをキューイングした順序が保証	(Ex) 順序性が必要な処理
ショートボーリング	キューが空の場合に”Empty”が返送	SQSはリクエスト課金なので、空振りの場合でも無駄にコストがかかる。
ロングボーリング	キューでメッセージが取得できるまで待つ (1〜20秒)	SQS のレスポンスを減らす。
可視性タイムアウト	他の受信者にメッセージを一定時間見せない (30秒)	処理の重複を防ぎリクエストを減らす。スポットインスタンスと相性が良い。 (強制終了しても他の受信者が処理を引き継ぐ)

Kinesis

名前	概要	補足
Kinesis	ストリーミングデータの収集, 処理, 分析	サーバーレス。ボリュームに応じた拡張。 EC2 + AutoScaling よりも簡単かつ低コスト。 SQS と異なり複数人が同時にメッセージを受信できる。
Kinesis Data Streams	ストリーミングデータの収集	大容量データをシャドー単位で分割して処理。 (Ex) IoTデータを Lambda 上のアプリと連携
Kinesis Data Firehouse	ストリーミングデータの保存, 配信	(Ex) データを分析用としてS3, Redshiftに保存
Kinesis Data Analytics	ストリーミングデータの分析	(Ex) SQLで1分毎のストリーミングデータを集計

Data Pipeline / EventBridge

名前	概要	補足
Data Pipeline	データのETL処理, パイプライン処理	ETL処理のスケジューリング, 順次処理の定義, 処理の成功/失敗通知など。 (Ex) 定期的にDBからデータ抽出→バックアップ取得→テーブル削除
EventBridge	AWSや外部イベントを連携させるハブ	設定したルールで他サービスとリアルタイム連携。 (Ex) EC2停止→EventBridge→Lamda→EC2再起動

構成

CloudFormation

名前	概要	補足
CloudFormation	AWSリソースをコード化したテンプレで展開	–
テンプレート	CloudFormationの設定ファイル	キーバリュー型。JSONやYAMLでリソースを記述。
スタック	テンプレートで記述されたリソースの集合	–

その他

名前	概要	補足
Elastic Beanstalk	Webアプリ/サービスのデプロイ, 管理を容易に行う	サーバーへのデプロイ, 環境管理を自動化。リリース後も監視。
OpsWorks	サーバー構築作業を自動化	Chef を用いて Elastic Beanstalk より詳細な設定を行う。リリース後も監視。
CodeDeploy	アプリのデプロイを自動化	(Ex) Fargate, Lambda へのデプロイ
CodePipeline	アプリのビルド, テスト, デプロイの手順を実行	–

運用

CloudWatch

名前	概要	補足
CloudWatch	AWSリソースの情報を収集, 監視, 可視化	利用開始時からモニタリング。 (Ex) CPU使用率が閾値を越えたらアラート
標準メトリクス	デフォルトのEC2メトリクス	(Ex) CPU利用率, 読み取り回数, 読み取り/受信バイト数
カスタムメトリクス	CloudWatchエージェントを通じたメトリクス	(Ex) メモリ使用率, ディスク使用率など独自の指標
詳細モニタリング	1分間隔で監視できる有料プラン	無料版は5分間隔で監視。(どちらも15ヶ月データを保存) EBS, ELB, RDSは無料版でも1分間隔で監視。
CloudWatchアラーム	メトリクスが閾値をこえた場合にアラーム	アラームと連動してアクションを実行。 (Ex) CPU利用率が70%の場合 AutoScaling でEC2を追加
CloudWatch Events	AWSリソースの状態を監視しアクションを実行	状態に応じて Lambda, SNS などを実行。 (Ex) インスタンス終了→Lambda→新インスタンス起動
CloudWatch Logs	AWSログを統合的に収集。利用には CloudWachエージェントが必要。	EC2のカスタムログ配信などに利用。 (Ex) Warning文字列があればメールで通知

その他

名前	概要	補足
CloudTrail	過去90日分の操作ログを記録 (APIコールの履歴)	S3へ保存されたログから不正なアクセスを見抜く。 (Ex) ログイン履歴, EC2削除履歴
GuardDuty	AWS内のログからセキュリティ上の脅威を検出	悪意のある攻撃や不正な操作を検知。結果は CloudWatch Events へ連携。
Config	AWSリソースの構成変更をログとして記録 (ユーザーの操作履歴)	(Ex) EC2の作成/削除, S3の設定変更, Configルールに違反したIAMユーザーを抽出
VPCフローログ	VPC内のネットワーク間通信をキャプチャ	意図しない通信がないかを監視。 CloudWatch Logs でログを保存, 可視化。
System Manager	AWSリソースの運用状況を可視化, 制御	(Ex) パラメータの一元管理, 運用タスクの制御/自動化
Trusted Advisor	AWSベストプラクティスと比較するプログラム	コスト最適化, セキュリティ, 耐障害性, パフォーマンス, サービスの制限の5項目
Backup	AWSデータのバックアップを一元化/自動化	ポリシーを設定してスケジューリング。 (Ex) EFSのバックアップを取得
Inspector	EC2上のアプリの脆弱性を診断	セキュリティレポートも作成可能。
侵入テスト (Penetration Test)	AWSに事前申請して利用する脆弱性テスト	EC2, NAT Gateway, RDSなどのリソースを診断。

購入オプション

名前	概要	補足
オンデマンドインスタンス	初期費用なし。従量課金。	(Ex) 開発環境, キャンペーンサイト
リザーブドインスタンス	1〜3年の長期契約。安く使える。(Max75%オフ)	購入は Standard, Convertible タイプの2種類。 (Ex) 予め必要数が決まっているサーバー, 常に起動する必要があるサーバー
Standardタイプ	リージョンやAZを指定したインスタンス	–
Convertibleタイプ	インスタンス構成のアップグレードが可能。割高。	–
スケジュールされたリザーブドインスタンス	日/週/月を指定したリザーブドインスタンス	–
スポットインスタンス	AWSの余剰リソースを格安で利用。(Max90%オフ) スポット価格が入札価格を上回ると強制終了。	スポットブロックとスポットフリートの2種類。処理が中断されても再実行できるシステム向き。 (Ex) 動画のエンコード処理
スポットブロック	継続した動作を保証するスポットインスタンス	割高だが強制終了を防げる。(Max 6h)
スポットフリート	性能を指定したスポットインスタンス	強制終了時に同じ性能のインスタンスに代替。
インスタンスファミリー	EC2などのリソースに合わせたサイジング	＜種類＞汎用：一般的。バランス型。コンピューティング最適化：CPU処理に特化。メモリ最適化：大容量のメモリに特化高速コンピューティング：GPUなど高速処理に特化。ストレージ最適化：ストレージ容量やI/O性能に特化。
インスタンス世代	アーキテクチャーの新しさ	最新のものを使えば処理時間が短縮され安くなる。
インスタンスサイズ	vCPUの数	(Ex) 4xlarge = vCPUが16個搭載

コスト管理

名前	概要	補足
Cost and Usage Report	リソース使用状況のレポート	CSV形式で S3, Redshift などに保存。
Cost Explorer	Cost and Usage Reportのデータを可視化/検索	(Ex) EC2使用量やコストを時系列で可視化
Budgets	予算やリソース使用量を設定し超過時にアラート	–

サポートプラン

名前	概要	補足
ベーシック	標準プラン	技術問い合わせ不可。 Trusted Advisorの4項目のみチェック。
デベロッパー (営業時間内のみ対応)	学習用途	1人だけ技術問い合わせ可能。 Trusted Advisorの7項目のみチェック。
ビジネス (年中無休)	本番環境の運用者向け	組織の全員が技術問い合わせ可能。 Trusted Advisorの全項目をチェック。
エンタープライズ (年中無休)	ミッションクリティカルなシステムの運用者向け	専用のTAMが1人つく。組織の全員が技術問い合わせ可能。 Trusted Advisorの全項目をチェック。