AWSサービス早見表

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

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

責任共有モデル