合格対策 AWS認定ソリューションアーキテクト - アソシエイト資格の知識のまとめ

概要

忘れ始めていた参考書を再勉強した時のメモ、備忘録です^^
独自の勉強結果も載せているので、記載内容に誤りがあれご指摘ください^^;

資格試験対策は以下を参照

AWS初心者がAWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法

前回以前の試験に対する概略／勉強法は以下の投稿を参照

第一回：試験対策重要サービスを分類

第二回（前半）：重要サービスの勉強ポイント（前半）

第二回（後半）：重要サービスの勉強ポイント（後半）

第三回：主要サービスの勉強ポイント

第四回：特徴的サービスの勉強ポイント

参考書

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

リージョン／アベイラビリティゾーンとAWSサービス

３つのサービスレベル

• リージョンサービス：リージョンごとに作成・管理される
• AZサービス：AZごとに作成・管理される
• グローバルサービス：どこのリージョン共通のサービスとして利用できる

サービスレベルごとの代表的なサービス

• リージョンサービス
• S3/DynamoDB/SQS/CloudSearch
• AZサービス
• EC2/RDS/ELB/ElastiCache
• グローバルサービス
• IAM/Route 53/CloudFront

責任分担セキュリティモデルとAWSにおける認証（IAM）

##　責任分担セキュリティモデル

• インフラストラクチャサービス（EC2など）／コンテナサービス（RDSなど）／アブストラクトサービス（S3など）で責任範囲が異なる
• 侵入テストなどは事前申請しないとアカウント停止などの可能性がある

IAM

*　IAMはグループ、ユーザはデフォルトで何も権限が与えられていない
*　許可と拒否のポリシーが相反する場合、拒否のポリシーが優先される
*　SDKの認証情報にはIAMロールが推奨されている
*　IAMロールは、EC2インスタンスに割り当てでき、割り当てられたEC2インスタンス上のプログラムは、認証情報（アクセスキー／シークレットキー）がなくともIAMロールに許可されているので他のサービスにアクセスできる

IDフェデレーション

• 自社のIDブローカー（Active DirectoryやLDAP）とAWSのSecurity Token Service(STS)を使って一時的に認証する
• IDブローカー認証済みのユーザに対し、STSから一時的な認証情報を付与し、AWSサービスの認証情報に使用する
• AWSの使用頻度が低いユーザに対し、IAMアカウントなどを作成せずに済む

AWSにおけるネットワーク（VPC）

EC2インスタンスにAWS外からアクセスができるようにするために、EC2インスタンスにIPアドレスが適切に割り振られ、外部ネットワークからEC2インスタンスに到達できるように適切にルーティングされている必要がある
これを実現しているのがVPC

• サブネットは複数のAZにまたがることができない　サブネットを選択することはAZを選択すること
• デフォルトのルートテーブルは変更することも削除することもできない　つまり、異なるAZに作成されたサブネット間は許可されており、ルーティングルールでは通信を制御することができない
• デフォルトのルートテーブルだけはリージョンサービスのDynamoDBなどにアクセスできない　そのためにNATが必要になる
• NATインスタンスになるにはEC2の「送信元／送信先チェック」の機能を無効化する必要がある

EC2インスタンスのIPアドレス

• プライベートIPアドレスが少なくとも１つ割り振られる
• グローバルIPアドレスには、Public IP/Elastic IPがある
• Public IP：インスタンス終了／起動ごとにランダムに割り振られる
• Elastic IP：アカウントに割り振られた固定のIPアドレスをインスタンスにアタッチ／デタッチする（明示的に開放するまでインスタンスのIPアドレスは変わらない）
• インスタンスのプライベートIPアドレスとグローバルIPアドレスの紐づけはVPCの仮想ネットワークで行われているため、ipconfig等のコマンドではプライベートIPアドレスしか表示されない（メタデータで確認することが可能）

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

IPアドレスやポートを指定して制御する

• セキュリティグループ
• インスタンス単位
• 作成可能なルール：許可のみ
• デフォルトルール：インバウンド：全て拒否、アウトバウンド：全て許可
• 特徴：ステートフル
• ネットワークACL
• サブネット単位
• 作成可能なルール：許可／拒否
• デフォルトルール：インバウンド／アウトバウンド：全て許可
• 特徴：ステートレス

ステートレス通信では、インバウンド（受信）が許可されていれば、そのアウトバウンド（送信）はルールと関係なくそのまま許可される　逆も同様
ステートレス通信では、インバウンド／アウトバウンドがともに許可されている必要がある
セキュリティグループは、送信元／送信先としてセキュリティグループIDを使用することもできる

VPCピア接続

• VPC内のサブネット同士をPCXというゲートウェイに相当するもので通信する
• ルートテーブルにPCXへの設定を追加する必要がある
• 接続するVPCは同じリージョン内である必要がある
• プライベートIPアドレスで接続するため、接続するVPCのプライベートネットワークアドレス空間が重複してはならない
• VPC間1対1通信となる（三つのVPC間が論理的に繋がっていてもまたがって通信するこはできない）

AWSにおけるコンピューティング（EC2／AMI／EBS／インスタンスストア）

EC2初回起動（作成）手順

• AMIの選択
• AMIにはルートボリューム（OSの格納領域）のテンプレートや、ルートボリューム以外のボリュームのマッピング情報などが含まれる
• 利用者は任意のタイミングで、現在利用しているEC2インスタンスのカスタムAMIを取得可能
• インスタンスタイプの選択
• インスタンスファミリー（汎用（バランス重視）t/m／コンピューティング最適化（CPU重視）c／GPUg／メモリの最適化m／ストレージの最適化i/d）
• tとかmの後の数字は世代、その後の文字はマシンスペック
• large：CPUコア数２、メモリが8GiB？、xlarge：CPUコア数４、メモリが８GiB？
• ネットワーク／IAMロール／ユーザデータなどの設定（インスタンスの詳細設定）
• ユーザデータ：OS起動スクリプトのようなもの
• aws固有のコマンドも使用可能（ElasticIPの付与など）
• その場合、引数のインスタンスIDにはメタデータが使用可能
• メタデータ：ami-id/hostname/iam/security-credentials/role-name/instance-id/local-ipv4/local-ipv6
• ストレージの設定
• デフォルトでEC2インスタンスに接続されているストレージデバイスには、OSがインストールされる
• EBS（起動後でも追加可能）かインスタンスストア（初回起動時のみ追加可能）を追加で付けられる
• インスタンスストアは、インスタンスタイプによって作成できるボリュームサイズと本数が決まっている　インスタンスストアが付けられないインスタンスタイプもある
• タグ付け
• セキュリティグループの設定
• 少なくとも１つのSGを適用する必要がある
• 確認
• キーペアの選択
• 公開鍵はAWS側で保持しSSHの認証／Windowsの場合パスワードの復号化に利用
• 秘密鍵はユーザーがローカルにダウンロードして使用する

EC2インスタンスのライフサイクル

• 状態：running（起動）/stopped（停止）/terminated（削除）
• 遷移トリガー：pending（起動、AMIからの初回起動も）/stopping（停止）/shutting-down（削除）
• runningになっても次の二つのチェックOKになるまでインスタンスにアクセスはできない　チェックOKの場合、[2/2 checks passed]となる
• System Status Checks:インフラストラクチャ（HW、ハイパーバイザー）のチェック
• Instance Status Checks:OSのチェック
• 利用料金は、runningになった時点から発生し、stopped/terminatedになるまで発生する

EBSとインスタンスストア

EBS

• AZ内に作成されるネットワーク接続型のブロックストレージで不揮発性
• 性能：数百～20,000IOPS
• $/GB
• OSをEBSにインストールしたインスタンスをEBS-backedインスタンスという（インスタンスストアとAMIの時点で異なっている）
• インスタンスの停止／起動／再起動／削除可能

インスタンスストア

• 物理ホストの内臓ストレージのため揮発性（デフォルトでインスタンスを停止し起動すると物理ホストが変わる）
• 性能：最大300,000IOPS（高性能）
• 無料（EC2の料金に含まれる）
• OSをインスタンスストアにインストールしたインスタンスをInstance store-backedインスタンスという　s3-backedインスタンスといわれることもある
• インスタンスの再起動／削除のみ可能
• 再起動時にはデータが消えないということ　明示的なOS上の削除に加え、インスタンスの停止時／削除時にはデータごと消える

EBSのタイプ

General Purpose SSD：一般（汎用）

• 最大16TiB
• 性能：3IOPS/GBのベースパフォーマンス、最大10,000IOPS、ベースパフォーマンスが3,000未満の場合、3,000IOPSまでのバースト機能
• 価格：容量のみ

Provisioned IOPS SSD：DBなどストレージ性能を求めらえる場合

• 最大16TiB
• 性能：容量（GB）の30倍までのIOPSを指定、最大20,000IOPS
• 価格：容量、指定したIOPS
• ネットワークストレージとなるためEC2の業務ネットワークの帯域とディスクIOの帯域の競合がボトルネックになることがある　その対策としてEBS最適化インスタンスを指定すればディスクIO専用帯域が確保され、安定化する
• スループット最適化HDDとCold HDDというボリュームタイプが利用できるようになった？

Magnetic（磁気ディスク）：コスト重視

• 最大1TiB（少ない）
• 性能：平均100IOPS
• 価格：容量、発生したIO数

EBSスナップショット

• 任意のタイミングでS3に保存されるスナップショットの作成可能
• S3に保存されるときは、圧縮、差分バックアップとなるためストレージ費用を抑えることができる
• 基本的にはディスクをアンマウントしてから取得することを推奨している　ただ、最初にEBSデータをすべてキャプチャしてS3に書き込むため、取得完了を待たずにマウントしても大丈夫（キャプチャ後の書き込みは対象外となる）
• S3を利用することで、スナップショットは、別のEC2／EBSタイプ（EBSのディスクサイズが大きい場合も可能）／AZ／リージョンで復元できる
• 別のAZ／リージョンからEBSは参照できないため、別のAZ／リージョンのインスタンスから起動する場合は、スナップショットを取って該当のAZ／リージョンで復元する必要がある（AZ／リージョン間コピーの機能はない）

プレイスメントグループ

• リージョン内のAZは専用線だが多少遅延が発生する　ある単一AZにプレイスメントグループを作成しその中にEC2を作成すると、グループ内のEC2インスタンス間のネットワークが高速化できる
• ただし、冗長化を犠牲にしているので注意が必要

Dedicated(専用) インスタンス

• ソフトウェアのライセンスにハードウェアの専有条件があったり、コンプライアンス上他社のインスタンスと物理ホストを共有できない場合に利用する
• 同じ物理ホストに他アカウントのインスタンスが起動しないことを保証する
• 時間あたりの利用料金に加え、リージョンごとの専有料金が発生する

Dedicated（専用）ホスト

• 参考書では割愛されている、、、

オブジェクトストレージ（S3/Glacier）

S3

• 特定のリージョンにバケットを作成する
• key Value Store形式でファイルをアップロードする
• 上書き／削除に対し結果整合性の問題があるため、頻繁に上書きするファイルは格納先としてS3は適切ではない
• 各オブジェクトにはURLが付与される
• １オブジェクトあたり最大5TBのサイズ制限がある（マルチパートアップロードを使った場合　使わない場合は5GB）
• バケットに格納できるオブジェクト数、データ総量は無制限
• パケット名は全アカウント（全世界）で一意とする必要がある
• ストレージクラスがあり機能がことなる
• スタンダードクラス　11x9　アップロードされると自動的に三か所のデータセンタに複製され、同時に2か所でロストが発生しても大丈夫な仕組みになっている
• 低冗長化クラス(Reduced Redundancy Storage:RRS)　4x9
• 低頻度アクセスS3　S3と同等の耐久性のもの　これが出てからRRSはあまり使われなくなった？

S3の整合性

• PUT（新規書き込み）：書き込みに時間がかかることがあるが完了後は必ず参照できる読み取り整合性
• PUT（上書き）：古いものが参照されることがある結果整合性
• DELETE（削除）：古いものが参照されることがある結果整合性

S3のアクセス制限とセキュリティ

通常オブジェクトを作成したアカウントだけにアクセス権限が与えられているため、以下の方法で制御する

• アクセスコントロールリスト（ACL）
• バケット、オブジェクトに、他AWSアカウントに対する読み取り／書き込みの許可のみを設定可能
• 条件付きアクセス許可や自アカウント内のIAMユーザやグループのアクセス制限は不可
• アクセス拒否も不可
• URLにHTTPSアクセスの許可を与えることはできる
• バケットポリシー
• バケットごとに自アカウント内のIAMユーザやグループのアクセス制限が可能
• 他アカウントに対する制御も可能
• 他のAWSアカウントとIAMユーザを指定したアクセス制限ができるのはこのポリシーだけ
• 条件付きのアクセス許可やアクセス拒否も可能
• IAM（ユーザ）ポリシー
• バケットポリシーと同様のアクセス制御が可能
• 他アカウントに対する制御は不可

その他の方法としてアクセス許可していないオブジェクトに対し、一定期間HTTPSで公開する署名付きURLという方法がある

• AWSアカウントを持っていないユーザ向け
• IPアドレスが特定できないためACLによる制御もできないときに利用（誰にでも公開設定ならACLでできる）

オブジェクトの暗号化とアクセスログ

• 暗号化とアクセスログの取得はデフォルトではなく、ユーザ責任のもと実施する
• 暗号化は鍵の管理（AWS／ユーザ）、暗号化の場所（サーバーサイド／クライアント）の選択が可能
• アクセスログはベストエフォートのため完全性は保証されない　同じ／異なるS3バケットに取得可能　リアルタイムではなく遅延して記録される

S3の静的Webサイトホスティング機能

• バケット名+リージョン名のようなエンドポイントになるため、ドメインでアクセスされるためにはRoute 53などのDNSによって名前解決が必要

S3のバージョニング機能

• S3バケット単位で有効にすることができる
• バージョンIDによって管理する

S3のライフサイクル機能とGlacierへのアーカイブ

• 指定日数が経過した場合、Glacierに移行、または削除するなどライフサイクル機能で利用する
• Glacierのデータは直接参照できないため、取り出したい場合は一度取り出す必要がある
• 取り出し時間は、データの大小に関わらず３～５時間
• 保管している月平均のデータ量の5%までは無料だが、それを超える場合は追加料金がかかる
• そのため、参照はほとんど行われない長期間保管用に使用する

データベース(RDS/ElastiCache/DynamoDB)

マネージド型データベースサービス

• RDS：リレーショナルデータベース
• DyanmoDB：NoSQLデータベース
• ElastiCache：インメモリキャッシュサービス
• RedShift：データウェアハウスサービス

RDS

• Aurora
• MySQL
• MariaDB：MySQLからフォークして作られたOSSのRDS
• PostgreSQL
• Oracle
• Microsoft SQL Server

マルチAZ配置

• Aurora以外は、マスタと異なるAZに同期スタンバイのスレーブを配置
• MySQL、MariaDB、PostgreSQL、Oracleでは同期物理レプリケーションを使う
• SQL Serverは、SQL Serverの機能の同期論理レプリケーションを使う
• データの読み書きはマスタのみ
• スレーブは読み取りもできない完全なスタンバイのため読み取り性能の向上にはリードレプリカを作成するか、ElastiCacheを配置する
• マスタの障害時にはフェイルオーバーが行われる（CNAMEがスレーブになるためAPは意識しない）
• パッチ適用などで手動フェイルオーバーすることもある
• Auroraは、三つのAZにまたがるクラスターボリュームが作成され、各AZにクラスターデータのコピーが格納される
• あるAZに読み書き可能なプライマリインスタンスが作成される　他の２つにはリードレプリカ
• プライマリインスタンスの障害時は、独立したキャッシュを利用しつつ、プライマリインスタンスが瞬時に障害から回復するよう設計されている
• セキュリティグループ、サブネットのルーティングルールによってアクセス制限する

自動バックアップ機能

• RDSの標準機能
• １日１回自動的にバックアップ（スナップショット）を取得する（保存期間が０～３５日で指定可能）
• バックアップ中は多少の処理遅延の可能性があるが、バックアップウィンドウという時間帯を指定できる
• ５分１回のトランザクションログと組み合わせて５分以内のデータ状態でインスタンスの復元が可能
• バックアップとは別に任意のスナップショットも取ることが可能（これは自動的には削除されない）

パッチ適用

• 自動パッチ適用という機能を有効にしておくと自動で行われる
• メンテナンスウィンドウで曜日／時間帯の設定が可能
• 重要なセキュリティパッチの場合、無効にしておいても自動的に適用されることがある

ストレージ

• EBS同様、General Purpose SSD,Provisioned IOPS SSD,Magneticの３タイプがある
• 最小サイズはMagneticが5GB、他は6TB　DBによる異なる
• Auroraは、最小が10GBで使用量に応じて10GB単位で64TBまで拡張される
• 性能はEBSと同様

DynamoDB

• ストレージ容量が必要に応じて自動的に拡張
• テーブルごとに秒間のIO性能（スループット）を指定できる（変更可）
• ストレージはSSDのみで安定したIO性能を提供
• データを３つのデータセンタに複製することで高可用性と耐久性を提供
• 読み込み整合性の強弱により、性能と整合性のバランスを選択可能　強い整合性とするとスループットが半減する
• １つ１つの項目のサイズは400KBを超えることができない
• ユースケース
• セッションデータ
• ゲームの点数
• 買い物リスト
• センサーデータ
• リージョンサービスであるためサブネットからのアクセスにはNATが必要
• IAMによりテーブル／項目単位のアクセス管理が可能　セキュリティグループでは制御できない

ElasticCache

• インメモリキャッシュ　Memcached/Redisのキャッシュエンジンを選択可能
• MemCached：Key Value Store形式　マルチノードキャッシュクラスタを構成
• Redis：Key Value Store形式　マスタスレーブ構成
• AZサービスで、サブネットをグループ化したサブネットグループに配置する
• アクセス制御はセキュリティグループとルーティングルール　IAMではできない

AWSにおける監視と通知(CloudWatch/SNS)

CloudWatchによるモニタリング

• CPU利用率、ディスクIOなどをメトリックスとして監視
• 保持期間は２週間のため、それ以降のデータは破棄される　レポートが必要な場合はダウンロードしておく
• モニタリング間隔はAWSリソースによってさまざま
• EC2では、基本モニタリング（３種類のステータスチェック（OS／インフラストラクチャ／両方）は１分、他は５分間隔）、詳細モニタリング（すべて１分間隔　ただし追加料金が必要）

EC2のモニタリング

• エージェントなどから情報をCloudWatchに送信する必要がある
• マネージドサービスはAWS側デフォルトで様々なモニタリングデータを送るエージェントがインストールされている
• マネージドサービスではないEC2はデフォルトでハイパーバイザーが収集できるモニタリングデータのみ総信している⇒標準（デフォルト）メトリックス
• CPU利用数/CPU累積数/CPU利用率/Disk読込み/書込み回数/インスタンスストレージの読取り/書込みバイト数/送受信バイト数/OS、インフラステータスチェック
• OSにインストールしたエージェントが取得して送信する⇒カスタムメトリックス
• メモリの利用率など

アラーム

• ３つの状態がある
• OK/ALARM/INSUFFICIENT_DATA（データ不足）

SNS

• メッセージ：通知するメッセージ
• サブスクライバ：受信者を差し、メール、モバイルプッシュ、HTTP、SQS、Lambda等をサポート
• トピック：単一／複数のサブスクライバをまとめたもの

CloudWatchなどからトピックに通知されるとサブスクライバとして登録したものにメッセージを通知する

AWSにおける拡張性と分散／並列処理(ELB/Auto Scaling/SQS/SWF)

ELB

• 複数のAZにまたがる負荷分散
• EC2インスタンスのヘルスチェック（再起動などの瞬断に対し自動再登録が可能になった）
• ELB自体の自動スケーリング（DNS名とIPアドレスを関連付けされる　IPアドレスはVPC内のIPアドレス　実態はサブネットの中に作成される）
• SSLのオフロード（SSL通信する場合は証明書をE2ではなくELBに配置して一元管理できる）
• Connection Draining（EC2の登録解除の場合に新規は受け付けず処理中のものは完了まで待つ機能　手動のEC2登録解除やAuto Scalingでの自動解除にも有効）
• アクセスログ記録（S3に保存することでアクセスログを一元管理できる）
• スティッキーセッション（セッション維持等の目的でクライアントを特定のEC2に毎回割り振る機能　ステートフルとなる伸縮自在性の実装に影響するためユースケースに注意が必要）

スケールアップの４つの問題

• インスタントタイプの変更にはインスタンスの停止が伴う
• インスタントタイプにはスペックの限界がある
• 高性能な１台構成の場合、可用性が下がる（単一障害点となる）
• スケールダウンの場合にもインスタントの停止が伴う

Auto Scaling

• ユースケース
• 負荷に基づいた利用（アクセス数急増、ランダム要求によるバッチ処理）
• スケジュールに基づいた利用（毎月決まったタイミングのバッチ処理、チケット販売などの一時的な高負荷）
• 正常なEC2インスタンスの台数を維持するための利用（数分のダウンタイムは許容される１台構成）

３つのコンポーネント

• 起動設定(Launch Configuration)
• どんなEC2を起動するか？AMI／インスタンスタイプ／IAMロール／CloudWatch詳細モニタリング／ユーザデータ／ストレージ／SG／キーペア／IPアドレスなど
• Auto Scaling Group
• どこに、どんな規模のグループ？サブネット／ELB／初期インスタンス数／最小最大グループサイズなど
• Auto Scaling ポリシー
• いつ、何台増減されるか？アラームXが発生した場合／特定の日時／N台追加削除／猶予時間（次の追加削除までの猶予時間）
• Step scalingという条件を複数step定義できるポリシーが追加されている

２つの特徴

• 正常なインスタンスを希望する台数(Desired Capacity)維持するためインスタンスのヘルスチェックをかけている
• Auto Scaling グループが複数のAZにまたがるとき、AZ間でインスタンス数を均等にする

減らす順番のデフォルト

• 起動している台数が最も多いAZのインスタンス
• 起動設定(Launch Configuration)が最も古いインスタンス
• 次の課金タイミングが最も近いインスタンス

SQS

• Pull型（APからポーリングされる必要がある）
• 順序性の保証はしない（FIFOが保証されない　耐障害性の複数に保存されているため）
• 最低１回配信保証（処理が終わったらAP側で削除する方針）
• 可視性タイムアウト（デフォルト30秒　この間は別のAPが拾わないようになっている）
• メッセージサイズは最大256KB
• リージョンサービスのためプライベートサブネットからの操作にはNATが必要
• IAMでアクセス管理を行うため、EC2上のAPはIAMロールをEC2に設定してアクセスする

SWF(Amazon Simple Workflow)

• マネージド型のタスクコーディネータ
• 厳密に１回限りで順序性が求められる処理に適している（発注／請求のワーフローなど）
• ３つの要素
• ワークフロースターター：ワークフローを開始する
• ディサイダー：ワークフロー中の各処理を調整する
• アクティビティワーカー：ワークフロー中の各処理を実行する

DNSとコンテンツ配信（Route 53／CloudFront）

エッジロケーション

• リージョンとAZとは異なるデータセンター
• Route 53/CloudFront/AWS WAF(Web Application Firewall)が動作
• 世界50か所以上

Route 53

• 正／逆引きの名前解決（ゾーン管理）の他、ドメインの登録も可能
• ゾーン／ドメイン情報を登録すると4か所のエッジロケーションのDNSに情報が格納されるためSLAは100%となる
• 問い合わせに対しては問い合わせを行ったユーザに最も近いDNSが応答する
• 利用料金は、管理しているホストゾーン（従来のDNSゾーンファイル）の数とクエリ回数など
• レコードタイプはA/AAAA(IPv6)/CNAME/MX/NS/PTR/SOA/SPF/SRV/TXT/ALIAS（AWS独自レコード）をサポート

ALIASレコード

• CNAMEレコードでは対応できないZone Apex（ゾーンの頂点）の名前解決をサポートする
• ELBのDNS名やS3のエンドポイント名を自ドメインのZone Apexに関連付けたい場合に使用する
• DNSの仕様として（レコードタイプの異なる？）同じ名前のCNAMEを定義することができないため

名前解決方法

• 加重ラウンドロビン
• 重みづけ／比率を定義する
• レイテンシーベースルーティング
• レイテンシーの低いレコードを返す
• 位置情報ルーティング
• クライアントのIPアドレスを元に地理データベースでクライアントの接続元地域を特定し近いレコード値を返す
• ヘルスチェックとフェイルオーバー
• ヘルスチェックをしているため事前にフェイルオーバー先を設定していればそのレコードを返す

CloudFront

• CDN(Contents Delivery Network)サービス
• エッジロケーションにコンテンツをキャッシュし地理的に近いエッジロケーションからダウンロードすることができる
• アクセス回数とデータ転送量による課金
• 利用時の流れ
• コンテンツを、S3、EC2／ELB、オンプレミスサーバーに格納（オリジンサーバという）
• CloudFrontディストリビューション（ドメイン名）を作成しオリジンサーバを設定する
• ユーザがディストリビューションにアクセスするとDNSの名前解決の際に地理的に最も近いエッジロケーションのレコードが返却される
• 返却されたエッジロケーションにキャッシュがあれば利用し、なければオリジンサーバから取得／キャッシュする
• １つのディストリビューションに複数のオリジンサーバを設定してコンテンツの拡張子で振り分ける（静的／動的など）ことが可能
• 個々のキャッシュ時間の設定も可能
• SSL通信も可能
• CloudFrontのキーペアを使ってCloudFrontの署名付きURLでアクセスすることも可能　その場合、S3などのバケットポリシーにCloudFrontユーザを意味するOriginal Access Identity(OAI)を作成しOAIからのアクセスだけ許可する

AWSサービスのプロビジョニング／デプロイ／構成管理（CloudFormation/Elastic Beanstalk/OpsWorks）

CloudFormation

• 料金はプロビジョニングしたリソースの利用料金のみに発生
• テンプレート：プロビジョニングリソースを規定するJSON形式のテキストファイル（VPCから定義可能）
• スタック：テンプレートを元にプロビジョニングされるリソースの集合／管理単位
• スタック単位でリソースの更新や削除が可能でテンプレートによってバージョン管理が可能
• テンプレートはCloudFormerというツールを利用して作成できる（自アカウントのリソースをテンプレート化してくれる）　サンプルも提供される
• テンプレートには可変項目として、パラメータ（作成時に指定できる）やマッピング（リージョンとリージョンIDのマッピングなど）を指定可能
• 作成途中で失敗した場合はロールバックされる
• 並列にリソースを作成していくため作成順序や依存関係にはDependsOnセクションを利用する
• ユーザデータを指定可能（時間がかかりそうな場合終わったらシグナルを送って次をする等の制御も可能）、条件式（本番用／検証用／開発用など）も記載可能
• Elastic BeanstalkやOpsWorksを呼び出すことができる

Elastic Beanstalk

• APのデプロイツール
• ELB/EC2/S3/RDS（オプション）などのリソースを利用できる
• APのバージョン管理可能
• 利用は無料でプロビジョニングしたリソースの利用料金が発生

OpsWorks

• サーバの構成管理ツール
• ELBやEC2インスタンスを作成し、その後にChefのレシピを実行してSWのインストールや設定が自動化できる
• アプリケーションの接続先のDBとしてRDSの設定するといったAPの設定を行う

EC2の料金モデル（オンデマンドインスタンス／リザーブドインスタンス／スポットインスタンス）

オンデマンドインスタンス

１時間あたりの料金は、次の３つの要素で決まる

• リージョン
• インスタンスタイプ
• OS

リザーブドインスタンス

• １年あるいは３年契約を結ぶことにより安く利用できるが、起動停止に関わず使用料金がかかり、契約期間中に新しいインスタンスタイプの発表や値下げが行われても適用されないとうデメリットもある
• 料金メリットの他に確実にリソースを確保できるというITリソースキャパシティの予約の面もある
• EC2/RDS/ElastiCache/Redshiftで利用できRIと記載されることがある
• DynamoDB（テーブル容量の予約など）/CloudFront（データ転送量の予約など）にも同様の割引方式がある
• 全額前払い（１年or３年）／一部前払い（１年or３年）／前払いなし（１年）がある
• 一部前払いは少額を前払いし、その後の契約期間中、リザーブドインスタンスの割引利用単価に支払い月の時間数をかけた額を支払う
• 最大75%程度割引されることがある　年間稼働率が70%を超える場合RIの方が割安といわれている

スポットインスタンス

• 入札価格とスポット価格（市場価格）で決まるインスタンス
• スポット価格は、AZ／インスタンスタイプ／OSごとに設定されている
• 最大でオンデマンドインスタンスの90%程度割引されることがある
• スポット価格が入札価格を下回るとスポット価格でインスタンスが起動する
• スポット価格が入札価格を上回るとインスタンスはターミネート（終了）する
• 突然の終了によりデータが保持されないため、頻繁にチェックポイントを設けてS3やEBS、DynamoDBにデータを書きだしたり、終了2分前のインスタンスのメタデータへの通知をトリガーにデータ保持の仕組みを起動する必要がある
• 突然の終了時の最後の１時間は課金対象にはならない
• スポットブロックオプションを有効にすると１～６時間の間でスポット価格によらずに継続して利用できる（スポット価格より割高になる）
• 最低限のインスタンス（リザーブドインスタンス）、時間帯により負荷予測ができるインスタンス（オンデマンドインスタンス）、その後の不規則な負荷に対応するAutoScalingインスタンス（スポットインスタンス）という使い方が適している？