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の全項目をチェック。 |
責任共有モデル
