AWSサービス早見表
本エントリは AWS 各種サービスの特徴をサクッと理解していただくことが目的です。
中身は実際に私が AWS試験(CP・SAA) を受験するにあたり、過去問や参考書などからエッセンスを抽出したものとなります。これから受験を予定している方の参考になれれば幸いです。
※簡略化するにあたり一部厳密性に欠ける箇所がございます。予めご了承ください。
主なインフラの利用範囲
| 利用範囲 | サービス名 |
| グローバル | IAM, CloudFront, Route53など |
| リージョン | VPC, DynamoDB, Lambda |
| AZ | EC2, RDSなど |
アクセス制御
IAM
| 名前 | 概要 | 補足 |
| IAM (Identity and Access Management) |
AWSへのアクセスを制御 | – |
| ルートユーザー | 全ての管理権限を持つユーザー | 最初に登録したアカウント。基本使わない。 アクセスキーは即削除しMFAを有効化する。 |
| IAMユーザー | ユーザーやアプリの実体 | 名前, PW, アクセスキーで構成。 1つのアカウントあたり5000ユーザーまで作成可。 |
| IAMグループ | IAMユーザーの集合 | 1ユーザーは10グループまで所属できる。 1つのアカウントあたり300グループまで作成可。 |
| IAMロール | ユーザーやアプリへ権限を一時的に付与 (PWやアクセスキーとは紐づかない) |
IAMポリシーをアタッチして使う。 アクセスキーIDやシークレットキーを使うより安全。 (Ex.) EC2で実行中のアプリからS3への書き込み |
| IAMポリシー | IAMユーザーやIAMグループに、 AWSリソースへのアクセス権を付与 |
JSONで記述。 優先度は、明示的な拒否 > 明示的な許可 > 暗示的な拒否。 AWS管理 / カスタマー管理 / インラインポリシーの3種類。 |
| AWS管理ポリシー | AWSが管理するポリシーのテンプレ | 一般的なユースケース向き。 AdministratorAccess / PowerUserAccessの2種類。 |
| AdministratorAccess | 全てのアクセス権を提供するポリシー | 管理者となるIAMユーザーに付与。 |
| PowerUserAccess | IAM以外のアクセス権を提供するポリシー | 開発者などに付与。(IAMを管理しないユーザー向け) |
| カスタマー管理ポリシー | ユーザーがカスタマイズするポリシー | 自社のセキュリティ要件を満たすために使用。 |
| インラインポリシー | IAMユーザーやロール毎の詳細なポリシー | 個別の埋め込みなので共有はできない。 |
セキュリティグループ / ネットワークACL
| 名前 | 概要 | 補足 |
| セキュリティグループ | EC2用のファイヤーウォール | インスタンス単位で全ルールが即座に適用。 デフォルトではインバウンドのみ拒否。 許可するルールのみを定義。(ホワイトリスト) 通信の戻りは自動で反映。(ステートフル) |
| ネットワークACL | サブネット単位のファイヤーウォール | サブネット単位で番号順にルールが適用。 デフォルトではインバウンド / アウトバウンドの両方許可。 拒否するルールのみを定義。(ブラックリスト) 行き / 戻りの通信を個別に制御。(ステートレス) 新規ネットワークACL作成時には全トラフィックが拒否。 |
| 許可の仕組み | セキュリティグループとネットワークACLの 両方で許可されて初めて「許可」となる |
どちらか一方が拒否であれば「拒否」 |
Organization
| 名前 | 概要 | 補足 |
| Organization | 複数のAWSアカウントを一元化 | – |
| SCP (Service Control Policy) |
Organization内の複数アカウントに対して IAMポリシーなどを結合的に管理 |
– |
| Consolidated Billing | 複数アカウントの請求を結合して支払う | 請求先のマスターアカウントにメンバーを追加。 割引オプションの恩恵を全員が受けられる。 |
暗号化
| 名前 | 概要 | 補足 |
| Certificate Manager | SSL/TLS証明書を一元管理 | – |
| CMK (Customer Master Key) |
AWSで暗号化 / 復号化を行う鍵 | キーID / 作成日などのメタデータ |
| CSE (Client Side Encryption) |
AWSに転送する前にユーザー側で暗号化 | – |
| SSE (Server Side Encryption) |
AWSサービス側での暗号化 | (Ex.) EBS / Redshift / S3 での暗号化 |
| KMS (Key Management Service) |
マネージドの鍵管理サービス (鍵はユーザー自身が作成しAWSが保管) |
CMKの作成 / 有効化 / ローテーション / 削除。 (Ex.) SDK / S3 / EBS / RDSとの連携。 |
| CloudHSM (Hardware Security Module) |
AWSが管理するユーザー占有のハードウェア | セキュリティ要件がかなり厳しい際に用いられる。 HSM自体はVPC内に配置される。 |
| Secret Manager | DBの認証情報を暗号化して一元管理 (Redshift / RDSなど) |
DBの認証情報をAPI経由でセキュアに取得。 認証情報を自動更新することもできる。 KMSとの連携にも対応。 |
認証
| 名前 | 概要 | 補足 |
| IDフェデレーション | 既存の認証方式とAWSの認証を紐付け |
SSO。 プロトコルは、SAML2.0 / OpenID Connect。 |
| STS (Security Token Service) |
AWSへの一時的なアクセスキーを発行 | IDフェデレーションなどで利用される。 |
| WEB IDフェデレーション | OpenID ConnectをサポートするSNSと連携 | (Ex.) Facebookアカウントを経由したログイン |
| Cognito | WEB / モバイルアプリのSNSと連携 | – |
| Directory Service | AWSで管理されるマネージドのADサービス | Microsoft AD / Simple AD / AD Connector の3種類。 |
| Microsoft AD | AWS上でMicrosoft ADを利用 | – |
| Simple Connector | AWS上でAD互換のSambaサービスを利用 | – |
| AD Connector | オンプレのADと連携 | – |
ネットワーク
VPC
| 名前 | 概要 | 補足 |
| VPC (Virtual Private Cloud) |
AWS上の仮想プライベートネットワーク (リージョンあたり Max5 まで作成可) |
安全性の高い独自ネットワーク。 1つのリージョンを指定して作成する。 |
| IGW (Internet Gateway) |
VPCとインターネットを繋ぐ役割 | VPCにアタッチして使う。 |
| VPCピアリング | 異なるVPC間をプライベート接続 |
2つのVPCをインターネットを経由せずに直接通信。 DR対策用のマルチサイトで使われる。 異なるアカウント間でも可能だが、アドレスの重複はNG。 (ピアリングしないのであればVPCのCIDRは重複OK) |
| Transit GW | VPCのハブとして使われるGW | 複数VPCをまとめて管理。 他のサービスがこれを経由して各VPCに接続する。 |
| VPCフローログ | VPCで通信するトラフィック情報をキャプチャ | キャプチャはCloudWatch Logsへ転送される。 ENI / サブネット / VPC単位で設定。 |
| 踏み台サーバー | 一時的にアクセス可能なサーバー | (Ex.) メンテナンスなどSSHやRDPでの遠隔ログイン。 パブリックサブネットに配置しIPアドレスを設定。(通常は停止) アクセス元は0.0.0.0/0ではなく特定IPアドレスを指定。 |
サブネット
| 名前 | 概要 | 補足 |
| サブネット | AZ内の小さなネットワーク単位 | 1つのAZ内に複数サブネットを設定できる。 (サブネットはユーザー自身で作成) |
| パブリックサブネット | インターネットと通信可能なサブネット | ルートテーブル内でIGWを指定したもの。 |
| プライベートサブネット | インターネットと通信しないサブネット | – |
| ルートテーブル | サブネットの通信先を決めるもの | 送信先IPアドレスとターゲットが書かれた表。 |
NAT
| 名前 | 概要 | 補足 |
| NAT GW | NAT機能を持つマネージドなGW |
パブリックサブネットに配置。 AZ内で冗長化されているが、AZ間では冗長化されていない。 (Ex.) プライベートサブネットからインターネットにアクセス |
| AZ間冗長化 | それぞれのAZ毎にNAT GWを配置 | NAT GWを複数AZにまたいで使用する場合の構成。 1つのAZで障害が起きても処理を継続できる。 |
| NATインスタンス | NAT機能を持つEC2インスタンス | 利用時には「送信元/送信先チェック」機能を無効化。 (自身へのトラフィックを破棄することが目的) 冗長化の設定はユーザー自身で行う。(やや面倒) |
Direct Connect / Site to Site VPN
| 名前 | 概要 | 補足 |
| Direct Connect | オンプレとAWSを1対1で接続する専用線 (利用には数日かかる) |
高速ネットワーク帯域。安定した通信。 プライベート接続なので安全性も高い。 複数回線で冗長化することもある。(東京・大阪など) VIFを構成して追加で専用線を構築することも可能。 |
| Direct Connect GW | オンプレと複数リージョンのVPCを接続 | オンプレとVPCを1対多で接続。 |
| Site to Site VPN | オンプレとAWSを接続する専用線 (低コストかつ迅速に導入可) |
インターネットを経由するため、 速度や安全性はDirect Connectより劣る。 Direct Connectと併用し、DR対策にも使われる。 |
| VGW (Virtual Private Gateway) |
オンプレとAWSを接続 | Direct Connect, Site to Site VPNの利用前に用意。 |
| 占有型 / 共有型 | 占有型は1Gbps / 10Gbpsの2種類。 それ以外の速度は共有型。 |
占有型はユーザーが物理接続に対して契約。 共有型はキャリアが契約したものを論理的に分割。 |
VPCエンドポイント
| 名前 | 概要 | 補足 |
| VPCエンドポイント | プライベートネットワークからAWSへアクセス (インターネットは経由しない) |
(Ex.) CloudWatch LogsにVPCエンドポイントを指定し、 プライベートネットワークから書き込む。 |
| ゲートウェイ型 (ネットワークレイヤ) |
ルートテーブルに指定されたターゲットを追加 | (Ex.) S3 / DynamoDBに接続 |
| インターフェイス型 (アプリケーションレイヤ) |
APIコールに対してプライベート接続 | (Ex.) CloudWatch / SQSに接続 別名：Private Link。 |
ELB
| 名前 | 概要 | 補足 |
| ELB (Elastic Load Balancing) |
EC2やIPアドレスのトラフィックを分散 (ELB内部は冗長性が確保されている) |
ALB / NLB / CLBの3種類。 トラフィックを複数AZで冗長化。 負荷に応じて自動でスケーリング。 通信のログはS3へ保管できる。 |
| ALB (Application Load Balancer) |
HTTP(S)のトラフィックを分散 (レイヤー7で動作) |
WEBからのリクエストを内容に応じて割り振る。 |
| NLB (Network Load Balancer) |
数百万のトラフィックを分散 (レイヤー4で動作) |
大規模データを高速に処理。 HTTP(S)以外は基本これを使う。 |
| CLB (Classic Load Balancer) |
旧式のロードバランサー (レイヤー4, 7で動作) |
後方互換性のために用意されている。基本使わない。 |
| エンドポイントで接続 | ELBに割り振られたDNS名 | ELBのIPアドレスは変動するので、 エンドポイントを指定して接続する。 |
| SSL復号化 | ELB側でSSL通信を復号化 | インスタンスの負荷軽減。証明書の一元管理。 |
| ヘルスチェック | 正常なインスタンスで処理を継続 | – |
| スティッキーセッション | 特定インスタンスにリクエストを送信 | (Ex.) ユーザー毎のセッション管理 |
| Connection Draining | サーバー処理が完了するまで解除を遅らせる | スケールイン時のエラーを防ぐ。 |
| クロスゾーン負荷分散 | 複数AZの全てのEC2に均等に処理を分散 | AZ毎にインスタンス数が異なる場合でも均等に分散。 |
| 外部ELB | パブリックサブネットに配置したELB | EC2をプライベートに配置しセキュリティを高める。 |
| 内部ELB | プライベートサブネットに配置したELB | 外部と通信しないELBとして利用。 |
Auto Scaling
| 名前 | 概要 | 補足 |
| Auto Scaling | リソースの使用状況に合わせたスケーリング | 予め設定したAMIからEC2を起動。 ユーザーデータを利用してAMIを最新化する。 |
| スケーリングプラン | いつ、どんな条件でAuto Scalingを実行するか | 正常なインスタンス数を維持 / 手動でスケーリング / スケジューリング / CloudWatchのメトリクスに応じた実行。 |
| 起動設定 | Auto Scaling実行時に起動するEC2の情報 | (Ex.) AMI / インスタンスタイプ / セキュリティグループ / キーペア。 |
| Auto Scalingグループ | 起動するインスタンスの最小数 / 最大数 | 起動させるVPCやAZも定義することも可能。 |
| クールダウン | Auto Scalingの待ち時間を設定 | 過剰にEC2インスタンスが増えるのを防ぐ。 (Auto Scalingは新しいEC2を立てるまで数分かかる) |
| ライフサイクルフック | Auto ScalingでEC2起動・終了を一時的に待機 | 待機中にアクションを実行。 (Ex.) 終了時にログを出力 / 起動時にデータを読み込む。 |
Route 53
| 名前 | 概要 | 補足 |
| Route 53 | マネージドのDNS (ホスト名をIPアドレスに変換) |
ホストゾーンは、パブリックとプライベートの2種類。 (Ex.) 独自ドメイン登録 / ヘルスチェック DNSフェールオーバー (Sorryページの表示)。 |
| パブリックホストゾーン | 公開WEBサーバーなどの名前解決 | – |
| プライベートホストゾーン | インターネットを介さない通信の名前解決 | (Ex.) 社内システム |
| ALIASレコード | Route 53独自のDNS機能 | ELBやCloudFrontのエンドポイントを、 CNAMEレコードではなくAレコードで指定。 |
| ルーティングポリシー | 通信を制御 | Route 53がクエリにどう反応するかを定義。 |
| レイテンシールーティング | 低レイテンシーのリソースへルーティング | – |
| 加重ルーティング | 複数のリソースに加重度を設定し、 その比率に応じて処理を分散させる |
– |
| 位置情報ルーティング | 地理的に近い場所へルーティング | リージョンをまたぐこともある |
| フェイルオーバールーティング | リソースのヘルスチェックを行い、 正常なものへルーティング |
– |
| シンプルルーティング | 設定されたレコードへルーティング | – |
| 地理情報近接性ルーティング | ユーザーとリソースの地理情報に応じて トラフィックをルーティング |
– |
| 複数値回答ルーティング | 正常なレコードからランダムに選択し Route 53がクエリに応答 |
– |
CloudFront
| 名前 | 概要 | 補足 |
| CloudFront | エッジロケーションからコンテンツを配信 (S3 / ELB / オンプレなどをオリジンに設定) |
ユーザーから地理的に近いキャッシュサーバーから配信。 高可用性。高パフォーマンス。低レイテンシー。 キャッシュを返した場合、EC2やELBにはログが残らない。 |
| オリジン | キャッシュするコンテンツの提供元 | CloudFrontをおくことでオリジンが直接攻撃されない。 |
| SSL暗号化 | SSL証明証を利用したSSL暗号化通信 | ユーザー独自の証明証を導入できる。 CloudFront配下の通信をSSL暗号化することも可能。 |
| フィールドレベル暗号化 | HTTPSの前にユーザー固有の鍵で暗号化 | 個人情報など機密性が高いデータ向き。 |
| 署名付きURL | 一定時間だけアクセスできるURLを発行 | – |
| カスタムエラーページ | 予め用意したエラーページを表示 | オリジンからエラーコードが返されたときに使う。 |
| 地域制限 | ユーザーの地域情報に応じてブロッキング | – |
| ストリーミング配信 | WEB / 音声/ 映像のストリーミング配信 | – |
WAF / Shield
| 名前 | 概要 | 補足 |
| WAF (Web Application Firewall) |
一般的な攻撃に対するファイヤウォール |
CloudFront / ALB / API Gatewayにアタッチして使う。 送信元IPアドレス / HTTP情報などでフィルタリング。 (Ex.) SQLインジェクション / クロスサイトスクリプティング |
| Shield | DoS・DDoSに対するファイヤーウォール | 無料版：レイヤー3,4 (インフラ) を保護。 有料版：レイヤー3,4,7 (インフラ + アプリ) を保護。 有料版のみDDoS攻撃時のサポートがつく。 |
その他
| 名前 | 概要 | 補足 |
| Global Accelerator | AWSネットワーク網を利用した通信 | インターネット経由より高速。 最適化したトラフィックをエンドポイントに転送。 |
| Elastic IP | 固定のグローバルIPアドレス (リージョンあたりMax 5個まで利用可) |
EC2を停止してもアプリやDNSの設定を変更せずに済む。 EC2にアタッチされていない時やEC2停止時に課金。 |
| RAM (Resource Access Manager) |
組織内でAWSリソースを共有 | Organization内のアカウントでリソースを集約。 運用負荷を下げ、コスト効率を向上させる。 |
| DataSync | オンプレとAWSのストレージ間でデータを転送 | 専用エージェントを導入してAWSへのデータ移行を行う。 MLなどの分析基盤をAWS上に構築することも可能。 転送先はS3 / EFS / FSx for Windowsなど。 |
コンピューティング
EC2
| 名前 | 概要 | 補足 |
| EC2 (Elastic Compute Cloud) |
AWSのコンピューティングクラウド |
EC2を休止するには最初に休止設定を行う。 ＜構築の流れ＞ ①AMIの選択 ②インスタンスタイプの選択 ③インスタンスの詳細設定 ④ストレージの設定 ⑤タグの追加 ⑥セキュリティグループの設定 ⑦キーペアの設定 |
| AMI | EC2を作成する際に利用する仮想マシンイメージ (EBSのスナップショット + EC2の構成情報) |
Marketplaceではサードパーティ製AMIを購入できる。 ＜EC2を別リージョンへ複製する場合＞ ①EC2のAMIをコピーし複製先に別リージョンを指定 ②新しいリージョンでAMIからEC2を起動 |
| インスタンスタイプ | EC2で利用するサーバースペック | vCPUとメモリ容量の組み合わせを選択。 タイプ変更時はインスタンスを停止。 |
| インスタンスの詳細設定 | EC2のネットワーク情報やIAMロールなど | – |
| ストレージ設定 | EBS or インスタンスストア | – |
| タグ | AWSリソースにつけるラベル | 運用の効率化や課金の振り分けを行う。 |
| キーペア | 公開鍵 / 秘密鍵を発行 | 公開鍵はAWSで管理され、EC2起動時にコピーする。 秘密鍵はユーザーが保管し、EC2アクセス時に使う。 紛失時は新しいキーペアを発行して別のEC2を起動。 |
| ユーザーデータ | EC2初回起動時にスクリプトを実行 | AMIからEC2を起動時に、最新コンテンツを反映させる。 |
| インスタンスメタデータ | EC2インスタンス自身のデータ |
(Ex.) インスタンスID / IPアドレス / ホスト名 / 公開鍵。 実行中インスタンスの設定 / 管理。 |
| EBS最適化インスタンス | EBS専用の通信帯域を用意したEC2 (ネットワークの帯域とは別) |
EBSが他のトラフィックの影響を受けなくなる。 |
プレイスメントグループ
| 名前 | 概要 | 補足 |
| プレイスメントグループ | 単一AZ内のEC2を 論理的にグループ化したもの |
EC2インスタンス間の通信を高速化。 クラスタコンピューティングの用途に最適。 |
| クラスター プレイスメントグループ |
1つのAZ内でEC2をグループ化 (EC2は全て同じラックに格納) |
同一ラック内のEC2間の通信を高速化。 低レイテンシー。高スループット。 |
| パーティション プレイスメントグループ |
EC2パーティション単位でグループ化 (パーティション毎のラック分け) |
ラックは独自にネットワークや電源を持つため、 ハードウェア障害時の対策にもなる。 分散環境 (Hadoopなど) 向き。 |
| スプレッド プレイスメントグループ |
EC2が個別に電源とネットワークを持つ (全てのEC2を異なるラックに配置) |
障害発生時の影響を低減できる。 |
Lambda
| 名前 | 概要 | 補足 |
| Lambda | サーバーレスでコードを実行 (サーバーレスアーキテクチャのハブ的役割) |
メモリ容量と実行時間(ミリ秒単位)に対して課金。 実行時間はMax15分なので時間がかかる処理には不向き。 (時間がかかる処理はAWS Batchを使う) |
| ExecutionRole | LambdaにアタッチされたIAMロール | IAMロールに従ってリソースへアクセス。 |
| ロギング | Lambdaの処理結果をCloudWatch Logsに保存 | – |
| Lambda@Edge | CloudFrontのエッジロケーションでLambdaを実行 | 通常のLambdaより待ち時間が短い。 LambdaではなくCloudWatchの機能。 |
コンテナ
| 名前 | 概要 | 補足 |
| ECS (Elastic Container Service) |
マネージドのコンテナオーケストレーション (CPUやメモリなどを論理的に分割) *Dockerという名前の仮想化技術を使用。 |
Dockerコンテナの実行 / 停止 / 管理。 ＜構築の流れ＞ ①クラスター作成 ②タスク定義 ③ELB設定 ④サービス設定 |
| クラスター | EC2を論理的にグループ化したもの | EC2インスタンスタイプ / インスタンス数 / EBSストレージ容量などを設定。 |
| タスク定義 | ECSの実行環境を定義 | Dockerイメージの格納先 / メモリの制限 / ネットワーク / ストレージなどを設定。 |
| サービス設定 | 起動するコンテナの数 / 最大数を定義 | – |
| EKS (Elastic Kubernetes Service) |
マネージドのコンテナオーケストレーション (Kubernetes向け) |
ECSとの違いは、AWS独自のものか、Kubernetesか。 |
| Fargate | サーバーレスコンピューティングエンジン (コンテナ向け) |
ECS・EKSの両方で動作。動的な処理が得意。 Fargateを使う場合、サーバーやクラスタの管理は不要。 (EC2の場合は管理が必要) |
その他
| 名前 | 概要 | 補足 |
| APIゲートウェイ | APIの作成 / 監視 / 保護などを容易に行う | Lambdaとあわせてサーバーレスなシステムを実現。 (Ex.) クライアント→API Gateway→Lambda→S3 |
| EMR (Elastic MapReduce) |
大量のデータを処理するWEBサービス | HadoopやSparkなどの分散処理環境を容易に構築・実行。 |
| VM Import | オンプレのマシンイメージをAWSに取り込む (EC2の機能) |
オンプレで作成した仮想サーバーのマシンイメージをAWSへ。 |
| VM Export | VM Importの逆 | EC2をオンプレで動作する仮想サーバーイメージへ出力。 |
| Lightsail | アプリケーションやWebサイトを手軽に構築 | WordPressなどが使えるサーバーを手軽に起動できる。 |
ストレージ
S3
| 名前 | 概要 | 補足 |
| S3 (Simple Storage Service) |
高耐久・容量無制限のオブジェクトストレージ （ただし1ファイルあたりのサイズ制限有り） |
IDとメタデータでデータを管理。非常に安価。 同一リージョン内の3ヶ所のAZへ自動で複製。 (耐久性は99.999999999%・可用性は99.99%) オンライントランザクションログには不向き。 |
| バージョニング | オブジェクトのバージョン管理 | 誤操作時に前のバージョンに戻す。 復元性は向上するが、応分のコストがかかる。 |
| クロスリージョンレプリケーション | 別リージョンのS3バケットに複製 | 複製先には別のAWSアカウントを指定可能。 複製なので誤操作の対策にはならない。 |
| 結果整合性モデル | データの新規追加では整合性が保証されるが、 更新 / 削除は反映されるまで時間がかかる。 |
– |
| IAMポリシー制御 | IAMユーザー / IAMロールへのアクセス制御 | (Ex.) Read / Get / Put操作の制御 |
| バケットポリシー制御 | IPアドレス / IAMユーザーへのアクセス制御 | S3バケットにJSONを記述。 |
| ACL制御 (Access Control List) |
AWSアカウントレベルでのアクセス制御 | 不特定多数へファイルを公開 / 非公開。 (パブリック / プライベート) |
| ブロックパブリックアクセス制御 | バケットポリシーやACLの設定を一括制御 | 意図せず外部へ公開されることを防ぐ。 |
| AES-256暗号化 |
S3バケットに使われるAESの256bit暗号化 | S3の鍵・KMSの鍵 (SSE) / ユーザー独自の鍵 (CSE) の3種類。 |
| スタンダード | デフォルトのストレージクラス | 99.999999999%の耐久性。 |
| 標準低頻度アクセス | スタンダードと同じ耐久性。 データの読み取りに対して課金。 |
長期保管やバックアップ用途。 アクセス頻度が少ないデータ向き。 |
| 1ゾーン低頻度アクセス | 標準低頻度アクセスより耐久性は劣るが安価。 3つのAZではなく、1つの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ファイルは×) |
WEBサイトのSorryページに利用される。 (Route53のフェイルオーバーと連携) |
| データストア | S3のデータレイク / 分析用データストア | – |
| 署名付きURL | S3へ一定期間許可するURLを発行 | 非AWSユーザーでもS3へアクセス可。 |
| OAI (Origin Access Identity) |
S3への直接アクセスする許可を制限 | (Ex.) CloudFrontのみにアクセスを許可し、 S3でプライベートコンテンツを配信。 |
EBS
| 名前 | 概要 | 補足 |
| EBS (Elastic Block Service) |
EC2にアタッチする永続可能なストレージ。 EC2とネットワーク接続。GBあたりの従量課金。 |
ボリューム作成後、EC2へアタッチ。 (アタッチ可能なインスタンスは1台のみ) EBS単体ではデータへアクセスできない。 データは1つのAZ内で自動的に冗長化。 |
| プロビジョンドIOPS SSD | 最も高パフォーマンスなSSD。最も高価。 | ストレージ容量 + 指定したIOPS に対して課金。 (Ex.) 汎用SSDで対応できないシステム |
| 汎用SSD | デフォルトのボリュームタイプ。SSDを安価で利用。 (容量毎にIOPSが用意されている) |
価格とパフォーマンスのバランスが良い。 (Ex.) 仮想デスクトップ / 開発環境 / 低レイテンシーなアプリ。 |
| スループット最適化HDD | 大量ストレージを安価に利用 | (Ex.) ビッグデータ / DWH / ログ処理 |
| コールドHDD | アクセス頻度が低い大量データの保存に適したHDD | IOPS重視ならSSD。 スループット / コスト重視ならHDD。 |
| マグネティック | 旧世代のボリュームタイプ | アクセス頻度が低いデータ向き。旧型。 |
| バックアップ | 取得した時点のスナップショットを保管。 (取得開始から終了までの変更は反映されない) |
自動的にS3へ保管されるため耐久性が高い。 スナップショットは初回はフルバックアップ。 (2回目以降は増分で取得) |
| サーバーサイドでの暗号化 | ボリューム新規作成時に暗号化設定を行う | ＜既存のEBSを暗号化する流れ＞ ①既存ボリュームのスナップショットを作成 ②①を複製する際に暗号化オプションを指定 ③暗号化済みスナップショットからEBSを作成 ④EC2から既存のEBSをデタッチ ⑤EC2へ暗号化済みEBSボリュームをアタッチ |
EFS / FSx
| 名前 | 概要 | 補足 |
| EFS (Elastic File System) |
複数EC2で使うマネージドな共有ストレージ (プロトコルはNFS) |
EBSより高価だが、可用性・拡張性が高い。 複数AZに冗長化してデータを保管。 (AZをまたいだファイルへもアクセス可) |
| FSx | 複数EC2にアタッチできる共有ファイルシステム | マルチAZに対応。(高可用性) S3へのバックアップ。(高耐久性) 通信は自動で暗号化。 IAMロールやセキュリティグループで制御。 |
| FSx for Windows | WindowsサーバーのSMBプロトコルを利用 (SMB = Server Message Block) |
AD連携やWindowsのACLでアクセス制御。 (Windowsのファイルサーバーとして使われる前提) |
| 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停止 / 起動時はホストが変わってしまう) |
| SGW (Storage Gateway) |
S3へアクセスするサービス (プロトコルは NFS / SMB / iSCSI) |
EC2やオンプレ環境で利用。 種類は以下の4つ。 |
| キャッシュ型ボリュームGW | データはS3に保存。 アクセス頻度の高いものはローカルにキャッシュ。 |
インターフェイスはiSCSI。 (データ転送にTCP/IPを利用する仕組み) |
| 保管型ボリュームGW | データをスナップショットとしてS3に格納 (スナップショットなのでデータ自体は無い) |
インターフェイスはiSCSI |
| テープGW | 物理テープの代替としてデータをS3に格納 | インターフェイスはiSCSI |
| ファイルGW | データをオブジェクトとして直接S3に格納 | インターフェイスはNFS |
| AWS Import AWS Export |
物理ディスクからAWS内のストレージへ転送。 AWSから物理ディスクへ書き出し。 |
短時間で大容量のデータを転送。 移行には高価なディスクが必要。 送信時の耐久性やセキュリティが懸念される。 |
データベース
RDS
| 名前 | 概要 | 補足 |
| RDS (Relational Database Service) |
マネージドのリレーショナルDB | ＜種類＞ AWS独自のDB：Aurora。 他の環境でも使われるDB：PostgreSQL / MySQL / MariaDB / Oracle DB / Microsoft SQL Server。 ＜障害時の挙動 (AZ構成別)＞ シングルAZ：自動で再起動。 マルチAZ：スタンバイDBへフェールオーバー。 |
| Aurora | DBインスタンスでSQL処理。 クラスターボリュームにデータを格納。 |
他のRDSより高性能で安価。 障害時のダウンタイムはほとんど無い。 (1つのAZにつき2つのディスク計6ヶ所へ書き込み) クラスターボリュームは3ヶ所のAZに存在。 → 読み書きを行う プライマリーDBインスタンス 1つ。 → 読み取り専用の Auroraレプリカ 2つ。 |
| パッチ適用 | バグ修正や機能変更など | 指定した曜日・時間毎にAWSが自動でパッチを適用。 (数ヶ月に1回程度) |
| バックアップ | DBとトランザクションログを取得 | DBのスナップショットは、1日1回AWSが自動で取得。 (最大35日間保存) トランザクションログは5分毎に自動でS3に保存される。 |
| リストア | スナップショットからDBを復元 | RDS削除時に「Retain」オプションを有効化する。 (有効化しないとスナップショットも一緒に消えてしまう) |
| ポイントインタイムリカバリ | 特定の日時時点にデータを復元 |
特定時点でのデータを復元。 (スナップショット + トランザクションログを利用) |
| マルチ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セッション・メタデータの管理 / スマホゲーム・IoTデータ用のDB。 |
| API経由での通信 | DynamoDBの通信は SDKやCLI でAPIを使う | – |
| 結果整合性モデル | データが正しく反映されるまで時間がかかる | 3つのAZへの書き込みには時間差がある。 (情報が最新のものでない可能性も) |
| Consistent Read | 書き込みが反映された最新データを読み取る |
– |
| DynamoDBグローバルテーブル | 複数リージョンのDBでデータ整合性をとる | 全てがマスタテーブル。 (1つの変更が全テーブルに影響) |
| DynamoDBストリーム | データ変更の履歴を24時間保持 | DynamoDBに負荷をかけずに集計・分析を行う。 データ変更時に通知を受け取ることも可能。 |
| DAX (DynamoDB Accelerator) |
DynamoDB用インメモリキャッシュ | 100万回以上のアクセスを数ミリ秒で処理。 DynamoDBへのアクセス負荷軽減。 |
| オンデマンド課金 | データの読み書きに対して課金 | トラフィックが事前に予測できない場合、 利用分だけ課金する方が安い場合に最適。 |
| プロビジョニング済課金 | 事前に1秒あたりの読み書きの回数を予測 | トラフィックが予測できる場合、 トラフィック変化が小さい場合に最適。 |
Redshift
| 名前 | 概要 | 補足 |
| Redshift | ペタバイト規模を扱えるマネージドなDWH | BIツールを利用した大量データの集計・分析向き。 (分析にRDSを用いると負荷が集中してしまう) |
| ノード | コンピューティングリソースの集まり (ノードの集まりはクラスター) |
リーダーノードがリクエストを受け取り、 それを複数のコンピュータノードに分散。 |
| バックアップ | スナップショットを作成。 (クラスタのポイントインタイムバックアップ) |
自動スナップショットは一定期間後に削除される。 手動では永続的にバックアップを保存可能。 |
| クロスリージョンスナップショット | スナップショットを別リージョンにも格納 | 通常はクラスターが配置されたリージョンに保存。 |
| Redshift concurrency scaling | 突発的に負荷に対して自動でスケーリング | 事前に設定した範囲でスケールしクエリを処理。 |
| Redshift Spectrum | Redshiftの拡張版。S3のデータも分析可能。 | Athenaと比較される。 |
ElastiCash
| 名前 | 概要 | 補足 |
| ElastiCache | マネージドのインメモリDB (MemcshedとRadisの2種類) |
メモリ上で処理を行うため高パフォーマンス。 RDBの負荷軽減・高速レスポンスが目的。 (Ex.) WEBのセッション / SQLクエリ |
| Memcached | シンプルな構造のデータを一時的にキャッシュ (DBは別途用意) |
ノード間の複製は行われない。 マルチスレッドを持つ大きなノード向き。 |
| Radis | 複雑な構造のデータをキャッシュ (データストアとしても利用可) |
プレイマリ・レプリカ型の構成。 障害時は自動でフェイルオーバー。 (RadisのみマルチAZ構成が可能) データは永続的に保存。 多数のリードレプリカに複製。 暗号化 / 復元 / コンプラ認証などにも対応。 |
その他
| 名前 | 概要 | 補足 |
| Neptune | マネージドのグラフDB | モノ同士の繋がりを示すネットワーク状のデータ構造。 → ノード：データの要素 → エッジ：ノード間の関係 → プロパティ：ノードとエッジの属性 (Ex.) 人と人との繋がり / 鉄道の最短経路算出。 |
| Athena | S3専用のサーバーレスクエリサービス | S3内のデータをSQLで分析 |
| QuickSight | マネージドなBIツール | RDB / S3 / Athena のデータを可視化。 (外部のDBにも対応) |
データ通知 / 連携処理
SES / SNS
| 名前 | 概要 | 補足 |
| SES (Simple Email Service) |
AWSのEメールサービス | SESのAPIを使ったメール配信。 |
| SNS (Simple Notification Service) |
メッセージ通知サービス | 配信先は HTTP(S) / SQS / Lambdaなど。 |
SQS
| 名前 | 概要 | 補足 |
| SQS (Simple Queue Service) |
マネージドなメッセンジャーキュー (デフォルトで4日間保存) |
疎結合なアーキテクチャーを実現。 (Ex.) 複数EC2へ非同期に分散処理 / キューを介したトラフィック毎のフロー制御。 |
| 標準キュー | メッセージ処理の順序が保証されない | (Ex.) 動画のエンコーディング / 順序が関係ない並列バッチ処理。 |
| FIFOキュー | メッセージをキューイングした順序が保証 | (Ex.) 順序性が必要な処理 |
| ショートボーリング | キューが空の場合に”Empty”が返送 | SQSはリクエスト単位で課金されるため、 空振りの場合でも無駄にコストがかかる。 |
| ロングボーリング | キューでメッセージが取得できるまで待つ (1〜20秒) | SQSのレスポンスを減らす。 |
| 可視性タイムアウト | 他の受信者にメッセージを一定時間見せない (30秒) | 処理の重複を防ぎ、リクエストを減らす。 スポットインスタンスと相性が良い。 (強制終了しても他の受信者が処理を引き継ぐ) |
Kinesis
| 名前 | 概要 | 補足 |
| Kinesis | ストリーミングデータの収集・処理・分析 | サーバーレス。ボリュームに応じて拡張。 EC2 + AutoScalingよりも簡単かつ低コスト。 SQSと異なり複数人が同時にメッセージを受信できる。 (Ex.) IoTデータの収集 |
| Kinesis Data Streams | ストリーミングデータの収集 | 大容量データをシャドー単位で分割して処理。 (Ex.) 収集したデータをLambda上のアプリと連携 |
| Kinesis Data Firehouse | ストリーミングデータの保存・配信 | (Ex.) データを分析用としてS3 / Redshiftに保存 |
| Kinesis Data Analytics | ストリーミングデータの分析 | (Ex.) SQLで1分毎のストリーミングデータを集計 |
| Kinesis Video Streams | 動画のストリーミング処理 | – |
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アプリ・サービスの デプロイ / 管理 を容易に行う |
サーバーへのデプロイや実行環境の管理などを自動化。 AWSリソースの展開はCloudFormationを使う。 |
| OpsWorks | サーバー構築作業を自動化 | Elastic Beanstalk同様、リリース後の監視も可能。 Chefを用いてElastic Beanstalkより詳細な設定を行う。 |
| CodeDeploy | アプリのデプロイを自動化 | デプロイ先はFargate / Lambdaなど。 |
| CodePipeline | アプリのビルド, テスト, デプロイの手順を実行 | – |
運用
CloudWatch
| 名前 | 概要 | 補足 |
| CloudWatch | AWSリソースの情報を収集 / 監視 / 可視化 | 利用開始時点からモニタリング。 (Ex.) EC2のCPU使用率が閾値を越えたらアラート。 |
| 標準メトリクス | デフォルトのEC2メトリクス | CPU利用率 / データの読み取り回数 / 読み取りバイト数 / 受信バイト数。 |
| カスタムメトリクス | CloudWatchエージェントを通じたメトリクス | メモリ使用率 / ディスク使用率など独自の指標 |
| 詳細モニタリング | 1分間隔で監視できる有料プラン | 無料版は5分間隔で監視。 (どちらも15ヶ月データを保存) EBS, ELB, RDSは無料版でも1分間隔で監視。 |
| CloudWatchアラーム | メトリクスが閾値をこえた場合にアラーム | アラームと連動してアクションを実行。 (Ex.) CPU利用率が70%の場合、AutoScalingでEC2を追加。 |
| CloudWatch Events | AWSリソースの状態を監視しアクションを実行 | 状態に応じてLambdaやSNSなどを実行。 (Ex.) インスタンス終了→Lambda→新インスタンス起動 |
| CloudWatch Logs | AWSのログを統合的に収集 | EC2のカスタムログを配信させることも可能。 CloudWachエージェントをインストールして使う。 (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リソースの運用状況を可視化 / 制御 | パラメータの一元管理。 運用タスクの制御 / 自動化など。 |
| Trusted Advisor | AWSベストプラクティスと比較するプログラム | コスト最適化 / セキュリティ / 耐障害性 / パフォーマンス / サービスの制限 の5項目 |
| Backup | AWSデータのバックアップを一元化 / 自動化 | ポリシーを設定するとスケジューリングできる。 (Ex.) EFSのバックアップを取得。 |
| Inspector | EC2上のアプリの脆弱性を診断 | セキュリティ関連のレポートを作成することもできる。 |
| 侵入テスト (Penetration Test) |
AWSに事前申請して利用する脆弱性テスト | EC2 / NAT GW / 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などに保存。 |
| QuickSight | AWS上のデータを分析・可視化 | AWSのBIツール |
| Cost Explorer | Cost and Usage Reportのデータを可視化・検索 | (Ex.) EC2使用量やコストを時系列で可視化 |
| Budgets | 予算やリソース使用量を設定し超過時にアラート | – |
サポートプラン
| 名前 | 概要 | 補足 |
| ベーシック | 標準プラン | 技術に関する問い合わせはできない。 Trusted Advisorの4項目のみチェック。 |
| デベロッパー (営業時間内のみ対応) |
学習用途 | 1人だけ技術に関する問い合わせができる。 Trusted Advisorの7項目のみチェック。 |
| ビジネス (年中無休) |
本番環境の運用者向け | 組織の全員が技術に関する問い合わせができる。 Trusted Advisorの全項目をチェック。 |
| エンタープライズ (年中無休) |
ミッションクリティカルなシステムの運用者向け | 専用のTAMが1人つく。 組織の全員が技術に関する問い合わせができる。 Trusted Advisorの全項目をチェック。 |
責任共有モデル
