AWS 試験チートシート

この記事は約38分で読めます。
sponsored link

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の全項目をチェック。

責任共有モデル