View on GitHub

Today I Learned

Software Engineering Blog

AWSサービス

AWSインフラ全般

リージョンの中にいくつかのアベイラビリティゾーンがある
CloudFrontやRoute 53のデータセンターはエッジロケーションと呼ばれており、世界中でAZを上回る数の拠点を抱えている
AWSサービスの範囲
- グローバルサービス
  - リージョンに依存しない共通のサービス
  - IAM, CloudFront
- リージョンサービス
  - 特定のリージョン内でのみ利用するサービス
  - VPC, DynamoDB, Lambda
- アベイラビリティゾーンサービス
  - 特定のAZでのみ利用するサービス
  - VPCのサブネット, EC2, RDS
責任共有モデル
- AWSとユーザの責任境界を明確にして分担協力しながらセキュリティを強化する方針
- AWSは主に、データセンター、物理ハードウェア、ネットワーク、仮想インフラの管理運用
- ユーザは主に、OSから上のレイヤの管理運用。OS、ミドルウェアのパッチ対応、アカウント権限管理、データ暗号化、仮想ネットワークのセキュリティ設定
購入オプション
- オンデマンドインスタンス
  - 初期費用なしで使用した分だけの従量課金
  - デフォルト設定
- リザーブドインスタンス
  - 長期利用券(1年もしくは3年)による購入割引(最大75%オフ)
  - 支払い方法は、全額前払い、一部前払い、前払いなしの3種類
  - 予約した時間枠内で起動できる購入オプションもある
  - Standardタイプ
    - リージョンやAZを指定して購入
  - Convertibleタイプ
    - あらかじめ指定したインスタンス構成に依存せず、柔軟に構成変更が可能
    - 割引率はStandardより低い
- スポットインスタンス
  - AWSの余っているリソースを安く利用(最大で90%オフ)。強制終了される場合がある
  - 希望の価格で入札し、スポット価格を上回っていればインスタンスが利用できるが、スポット価格の方が高くなった場合は強制終了する
  - 処理が中断されても支障なく再実行が可能なシステムに適用される。メディアのエンコード処理のためのEC2インスタンスやEMRのタスクノードなど
Consolidated Billing(一括請求)
- 複数のAWSアカウントに対する請求を一つにまとめて支払いできる機能
- マスターアカウントに紐付いたメンバーアカウントの請求が統合できる
サポートプラン
- ベーシック
  - 標準で利用可能。技術の問い合わせは不可
- 開発者
  - 主に学習用途。技術問い合わせできるユーザは1名のみ
- ビジネス
  - 本番環境で運用システムを持つユーザ向け
- エンタープライズ
  - ミッションクリティカルなシステムを持つユーザ向け。テクニカルアカウントマネージャへの問い合わせができる
- 日本語対応は平日9:00-18:00

アクセス制御サービス

IAM

AWSへのアクセス制御をするサービス

グローバル・サービスのためリージョンやAZ毎に作成する必要はない
IAMユーザ
- AWSを操作するユーザ
IAMグループ
- AWSを操作するユーザのグループ
- IAMユーザあたり10までのグループに所属することができる
IAMロール
- AWSやアプリケーションに対してAWSの操作権限を付与
IAMポリシー
- IAMユーザやIAMグループ、IAMロールに付与する権限
- IAMユーザやIAMグループは作成直後は権限が付与されていない
- AWS管理ポリシー
  - AWSによって事前に定義されたポリシーのテンプレート群
  - 代表的なポリシー
    - AdministratorAccess
      - すべてのアクセス権限を提供するポリシー
    - PowerUserAccess
      - IAMサービスを除くその他すべてのアクセス権限を提供するポリシー
- カスタマー管理ポリシー
  - AWSユーザが自身で作成・カスタマイズすることが可能なポリシー
- インラインポリシー
  - IAMユーザ、IAMグループ、IAMロールに埋め込まれているポリシーに対して個別にポリシー設定を反映
アクセスキーIDとシークレットアクセスキー
- AWS APIやSDKからAWSを操作するための認証
AWSアカウントのルートユーザのアクセスキーは作成せず、必要ならIAMユーザを作ってアクセスキーを作ることを推奨
IDフェデレーション
- すでに導入されている認証の仕組みとAWSの認証を紐付け、シングルサインオンを実現する仕組み
- SAML2.0やOpenID Connectと互換性のある認証プロトコルをサポート
AD Connector
- 既存のActive Directory環境へ接続するためのプロキシサービス

ネットワークサービス

VPC

AWSに独立したプライベートネットワーク空間を作成できるサービス

インターネットゲートウェイ
- VPC内のリソースからインターネットへアクセスするためのゲートウェイ
パブリックサブネット
- デフォルトゲートウェイへのルーティングにインターネットゲートウェイを指定したサブネット
プライベートサブネット
- デフォルトゲートウェイへのルーティングにインターネットゲートウェイを指定していないサブネット
NATゲートウェイ
- プライベートサブネットからインターネットへ接続するためのNAT機能
- NATゲートウェイと比べて可用性に優れており運用管理の手間も節約できるため、一般的なユースケースではNATゲートウェイを使う
NATインスタンス
- インターネットにアクセスできるEC2インスタンス。EC2インスタンスをNATサーバとして利用
Egress-Onlyインターネットゲートウェイ
- IPv6を利用してVPCからインターネットへ接続することができるサービス
VPCフローログ
- VPC内のネットワークインターフェースで通信するトラフィック情報をキャプチャするサービス
Elastic IP
- 固定のグローバルIPアドレスを提供するサービス
- EC2インスタンスを停止するとIPアドレスが変わってしまうため、IPアドレス保持するために利用される
- EC2にアタッチされていない場合や、アタッチされているインスタンスが停止している場合に料金が発生する
VPCピアリング
- 異なるVPC間をプライベート接続するサービス
VPCエンドポイント
- S3やDynamoDBなどに対してインターネットをせずAWS内のプライベート接続を実現するサービス
セキュリティグループ
- インスタンス単位のファイアウォール機能
- デフォルトでインバウンドはすべて拒否、アウトバウンドはすべて許可
- インバウンドに必要な通信許可設定を追加、アウトバウンドには拒否許可それぞれを設定
- ステートフル
  - ルールで許可された通信の戻りの通信も自動的に許可
- 設定後に再起動不要ですぐにルールが適用される
ネットワークACL
- サブネット単位のファイアウォール機能
- ステートレス
  - インバウンドもアウトバウンドも通信制御が必要
- デフォルトでインバウンドもアウトバウンドもすべて許可
セキュリティグループとネットワークACLの双方で通信が許可されていない場合はすべて拒否となる
自動的にスケールしてAWS内部で冗長構成が取られる
VPC内のEC2インスタンスに対して、踏み台サーバ(Bastion)によってリモートからセキュアにアクセスできる

ELB

通信トラフィックを分散するロードバランシングサービス

Classic Load Balancer(CLB)
- 標準的なロードバランシングを提供
Application Load Balancer(ALB)
- CLBに加えリクエストのクエリを判断し設定したパスのルーティングにしたがって振り分ける。L7LB
Network Load Balancer(NLB)
- 低レイテンシで高いスループットを実現する場合に利用する。L4LB
複数のAZに分散可能
ELB自身もスケールアウトする
ターゲットグループにインスタンスを紐付ける
SSL/TLSによる通信の暗号化が利用できる
クロスゾーン負荷分散
- 複数のAZにあるすべてのインスタンスに対して均等にリクエストを分散
オプションでアクセスログをS3に保存できる

Auto Scaling

リソース状況に応じてEC2を自動でスケールアウト、スケールインするサービス

AMIからEC2インスタンスを起動するのでAMIを最新しておくことは重要
ユーザデータを利用してS3やGitからEC2を最新の状態にする
Auto Scaling起動設定
- 起動するEC2のインスタンスタイプを定義する
Auto Scalingグループ
- 起動設定を関連付ける、ヘルスチェックタイプを指定する
Auto Scalingポリシー
- スケール員とスケールアウトの程度を指定する
複数AZがある場合はEC2インスタンス数がAZ間で均等になるように起動する
リソースをモニタリングするサービスであるCloudWatchと組み合わせる

Route 53

可用性の高いDNSを提供するマネージドサービス

パブリックホストゾーン
- 外部向けDNS。インターネットに公開されたDNSドメインのレコードを管理するコンテナ
プライベートホストゾーン
- 内部向けDNSVPCに閉じたプライベートネットワーク内のDNSドメインのレコードを管理するコンテナ
ALIASレコード
- Route 53固有の仮想リソースレコード
- DNSクエリに対してAWSサービスのエンドポイントのIPアドレスを直接返す。通常はCNAMEを利用
- Zone Apexが利用可能
Zone Apex
- 管理しているDNSドメインの頂点(Apex)となるノード
- サブドメインを含まないドメイン名。example.comドメインにおけるexample.com自身
- ELBやCloudFrontに対して、Zone ApexレコードをAレコードで指定する
ルーティングポリシーでクライアントからのトラフィックを要件に応じて適切に転送する
- レイテンシベースルーティング
  - 最もレイテンシが低いリソースへルーティング
- 加重ルーティング
  - 複数のリソースに対して重みを設定し、その比率に応じて分散させる
- 位置情報ルーティング
  - クライアントの場所に基づいて地理的に近い場所へルーティング
- フェイルオーバールーティング
  - ヘルスチェックを行い、利用できるリソースへルーティング
- シンプルルーティング
  - 設定されたレコードの情報に従ってルーティング

Direct Connect, インターネットVPN

オンプレ環境とAWSの間を専用線で接続するサービス

Direct ConnectはインターネットVPNと比較して品質は高いが高コスト、使用開始まで時間がかかる
可用性の高い回線環境の構築
- Direct Connect冗長化パターン
  - Direct Connectを2回線用意して冗長化
  - 回線にかかるコストは高い
- Direct ConnectとインターネットVPNの併用パターン
  - Direct Connect障害児のバックアップ回線としてインターネットVPNを採用
  - インターネットVPNへフェールオーバーしてパフォーマンスに影響が出る場合がある

CloudFront

エッジロケーションからコンテンツを配信するCDNサービス

オリジンとしてELB, EC2, S2などを指定できる
署名付きURLを使って、一定期間だけ特定のユーザのみアクセスができるURLを発行できる
ユーザの地域情報からアクセス制御ができる。これによって特定地域のユーザにコンテンツを配信したりブロックしたりできる
予期できないアクセスに対して有効
最も近いエッジロケーションにキャッシュを確認→なければリージョン別のエッジキャッシュを確認→なければCloudFrontに取得しにいきオリジンからのデータが返される
ユースケース
- 静的コンテンツを配信する場合は、S3と組み合わせる
- 動的コンテンツを配信する場合は、ELBを経由してEC2にアクセス

コンピューティングサービス

EC2

仮想サーバを提供するサービス

ユーザデータ
- EC2インスタンスの初回起動時に1回だけスクリプトを実行できる機能
インスタンスメタデータ
- EC2自身に関するデータで実行中のインスタンスを設定管理するために使用される
- インスタンスID、プライベートIPアドレス、パブリックIPアドレス、ローカルホスト名、公開鍵の情報が取得できる
プレイスメントグループ
- 単一のAZ内のインスタンスを論理的にグルーピングしたもの
- 異なるAZや異なるリージョン感の通信よりも高速な処理が可能になる

AMI

EC2インスタンスを作成する際に使用する仮想マシンイメージ

EBS-Backed
- EBSをOSのルート領域として利用したEC2インスタンス
- 不揮発性で永続化可、停止時もデータが残る
- EC2インスタンスを利用する場合はEBS-Backedが使われる場合が多い
Instance Store-Backed
- インスタンスストアをOSのルート領域として利用したEC2インスタンス
- 揮発性で永続化不可、停止時にデータ消失
- 再起動時はデータが残る

Lambda

サーバレスのサービス

API Gateway

APIの作成、配布、保守、監視、保護を簡単に行えるサービス

VM Import/Export

オンプレ環境に作成した仮想サーバのマシンイメージをEC2にインポートや、その逆ができるサービス

ストレージサービス

S3

高耐久・大容量のオブジェクトストレージサービス

データの更新および削除に対して結果整合性モデルが採用されている
バケット名はグローバルでユニークである必要がある
オブジェクトキーのプレフィックスにランダムな16進数を付与し、インデックスパーティションを分散している
ライフサイクルポリシーによって、オブジェクトの削除やアーカイブの期間を設定する
署名付きURL
- S3上のデータに対して一定時間だけアクセスを許可するためのを発行することができる
- Webサーバを経由せずに直接S3へ格納することができるため、Webサーバのトラフィックを避けることができる
クライアントサイドでの暗号化
- ユーザがファイルを暗号化してからアップロード、もしくはAWS SDKでアップロード時に暗号化
サーバサイドでの暗号化
- バケットのデフォルト暗号化オプションを設定、もしくはAWS SDKやAWS CLIで暗号化を指定
ストレージクラス
- スタンダード
  - 複数箇所にデータを複製して99.999999999%の耐久性を実現
  - デフォルトのクラス
- 標準低頻度アクセス(Standard-Infrequent Access)
  - データの読み出し容量に対しても課金されるため、アクセス頻度が低い場合に適している
  - スタンダードクラスと同等の耐久性があり、かつデータの格納コストはスタンダードクラスと比較して安価
- 1ゾーン低頻度アクセス(One Zone-Infrequent Access)
  - 1つのAZのみに保存。スタンダードと比べてコストを20%削減
低冗長化ストレージ(Reduved Redundancy Storage)
- 耐久性が99.99%で、データを安価に一時格納する目的で利用
Glacier
- アーカイブ目的で利用されるストレージであり、上記と比べて最も安価
- 耐久性はスタンダードと同等
- データの取り出しには通常3-5時間かかる
- 復元方法
  - 迅速(Expedited)
    - 取り出しに1-5分程度
    - 高コスト
  - 標準(Standard)
    - 取り出しに3-5時間程度
  - 大容量(Bulk)
    - 取り出しに5-12時間程度
    - 低コストで復元可能
データの更新削除は結果整合性モデルが採用されている
- オブジェクトのPUT処理(新規追加)
  - 書き込み後の読み込み整合性
- オブジェクトのPUT処理(更新)
  - 結果整合性
- オブジェクトのDELETE処理(削除)
  - 結果整合性
アクセス制御
- IAMポリシー
  - IAMユーザやIAMロールからRead, Get, Put操作に対する制御をする
- バケットポリシー
  - S3バケットに対してJSONコードを記載してアクセス制御
- ACL
  - AWSアカウントレベルのアクセス制御

EBS

永続可能なブロックストレージサービス

外付けハードディスク的なやつ。EC2からはあたかもローカルに接続されたハードディスクのように見えるが、実際はネットワーク経由で接続されたストレージ
1台のEC2インスタンスと接続可能
ストレージタイプ
- 汎用SSD(General Purpose SSD: gp2)
  - 価格とパフォーマンスのバランスが良いボリュームタイプ
  - 仮想デスクトップ、低レイテンシアプリケーション、開発テスト環境などで利用
- プロビジョンドIOPS SSD(PIOPS SSD: io1)
  - 汎用SSDでは対応できないミッションクリティカルな低レイテンシかつ高スループットに適したボリュームタイプ
  - EBS最適化インスタンスでの起動が推奨
  - 高スループットが必要なアプリケーション、大規模データベース環境(RDBMS, NoSQL)などで利用
  - ストレージ容量だけでなく、指定したIOPS数に対しても課金される
- スループット最適化HDD(st1)
  - スループットが高く低コストなHDD
  - ビッグデータやデータウェアハウス、ログ処理などのアクセス頻度が高い用途で利用
  - SSDと比較して安価
- コールドHDD(sc1)
  - アクセス頻度が低い用途に適したHDD
  - 大量データを保存するストレージなどで利用
- マグネティック
  - 旧世代のEBEのタイプ。汎用SSDの前のデフォルト
スナップショットによるバックアップ
- スナップショットはS3へ保管
- 初回はフルバックアップ、以後は増分で取得
- 取得開始から完了までの間に変更があった場合はスナップショットに反映されない
- AMI登録した状態でスナップショットを削除できず、スナップショット削除前にAMI登録解除が必要
単一のAZ内で冗長化される、アベイラビリティゾーンサービス
EC2停止時にデータは消失しない
EBS最適化インスタンスを作成することで、EC2-EBS感のネットワーク帯域が確保されるため、EBSのパフォーマンスを最大限発揮できる
RAID0で高速なI/Oが実現できる。RAID5,RAID6は、IOPSがパリティデータ書き込み処理に消費されるためAWSでは推奨されていない
レバシーサー場をAWSに移行する際に使用される
クライアントサイドでの暗号化
- ユーザがファイルシステム全体を暗号化してからデータを保存
サーバサイドでの暗号化
- ボリューム作成時に暗号化を設定
- 既存EBSボリュームを暗号化ボリュームに変更する際は、スナップショットを作成し、複製する際に暗号化オプションを指定する必要がある

EFS

スケーラブルな共有ストレージサービス

複数のEC2インスタンスと接続可能
自動で複数のAZに冗長化される
ストレージ容量を自動的に拡張および縮小する
EBSのようにスナップショットを取得することはできないため、別途バックアップを行う仕組みを検討する必要がある
EBSと比べて高い

インスタンスストア

特定のEC2インスタンスタイプで利用できる無料のストレージサービス

エフェメラルディスクとも呼ばれる
ローカル領域を利用しているため高パフォーマンスではあるが、EC2停止時にデータが消失する

SGW

S3へNFS, SMB, iSCSIといった標準プロトコルでアクセスできるサービス

EC2インスタンスだけでなくオンプレサーバにS3をマウントして使用することが可能
ストレージタイプ
- キャッシュ型ボリュームゲートウェイ
  - Storage Gateway経由でS3にアクセス。アクセス頻度が高いデータをキャッシュ
- 保管型ボリュームゲートウェイ
  - データをスナップショットとしてS3に格納
- テープゲートウェイ
  - 物理テープ装置の代替としてS3に格納
- ファイルゲートウェイ
  - NFSインターフェースを使用し、データをS3に直接オブジェクトとして格納

AWS Import/Export

ユーザから送付された物理ディスクのデータをAWS内のストレージへ転送したり、ユーザの物理ディスクに書き出したりするサービス

移行のために高価なディスクが必要

データベースサービス

RDS

マネージド型のRDB

マルチAZで構築が可能
障害児には自動フェイルオーバーする
1日1回自動バックアップを実施し、データベースとトランザクションログを取得する
RDSインスタンスにはSSHできない。マネジメントコンソールからパラメータグループを変更する
リードレプリカ
- マスターデータベースと同じデータベースを複製し、読み取り専用として構築。読み取りのスループット向上。マルチAZや異なるリージョンで作成可能
SSLを利用してデータベースインスタンスに接続可能
- MySQLでは接続コマンドのオプションに --ssl-ca=公開鍵のフルパス を指定
マルチAZのマスターRDSに障害が発生した場合
- 自動的にスレーブへフェイルオーバーしてスレーブのRDSがマスターに昇格する
- データはマスターとスレーブで常に同期されている
- フェイルオーバー中はわずかにダウンタイムが発生
バックアップ
- シングル構成の場合、ディスクIOは短時間中断される
- マルチAZの場合、スナップショットはスタンバイから取得
RDS DBインスタンスのストレージサイズを増やす場合、少なくとも元サイズに対して10%増やす必要がある

Amazon Aurora

AWSが開発したフルマネージド型のRDBMS

PostgreSQL, MySQLと互換あり、性能は上
データ量に応じてストレージを自動化拡張する機能がある
データは3つのAZに格納、各AZで2箇所のディスクに保存される

DynamoDB

マネージド型のNoSQL

データは3つのAZに格納
高い信頼性とパフォーマンスを維持できるため、可用性が求められる大量データ処理などに向いている
JSONドキュメントを含む構造化データまたは半構造化データを管理できる
結果整合性モデル
- 書き込んだデータは時間が経てば正しく反映されるが、データの読み取りのタイミングによっては書き込んだデータが反映されていない状態になる
- Consistent Readのオプションを使えば、書き込みが反映された最新データを読み取ることができる
DAX(Amazon DynamoDB Accelerator)
- DynamoDB用インメモリキャッシュ

Redshift

マネージド型のデータウェアハウス

スナップショットでバックアップを作成。自動バックアップを有効にしている場合は8時間毎もしくは5GBの更新があったタイミング
自動バックアップの保持期限がすぎると削除されるため、永続化したい場合は手動でバックアップを作成する必要がある
クロスリージョンスナップショット
- 別リージョンにスナップショットを保存してバックアップできる。デフォルトはRedshiftのクラスタが配置されているリージョンに保存される
マルチAZの設定不可

ElastiCache

キーバリュー型のNoSQLデータベースサービス

MemcachedとRedisをデータストアとして利用できる
ユースケース
- RDBのパフォーマンス向上のために利用

データ通知・連携処理サービス

Data Pipeline

データのETL処理など順次処理(パイプライン処理)ができるサービス

ETLのスケジューリング、パイプライン処理をワークフローで定義、処理の成功失敗のイベント通知、オンプレ環境との連携、などができる
ユースケース
- 1日1回DynamoDBからデータを取り出し、S3にバックアップした後、取り出し元のDynamoDBのテーブルを削除
- 複数拠点のWebサーバからアクセスログをS3に定期的に保存、加工し、S3からRedshiftへデータをロード

SQS

メッセージキューイングのマネージドサービス

アプリケーション間でメッセージをキューイングすることによって、疎結合なアーキテクチャを実現できる

Kinesis

ストリーミングデータの収集・処理・リアルタイム分析を行うサービス

キューの機能を備えたシンプルなサービスはSQS、大量のデータを扱う場合はKinesis
以下の3サービスから構成される
- Kinesis Data Streams
  - ストリームデータを各サービスで処理して保存できるサービス
- Kinesis Data Firehose
  - ストリームデータを各サービスに簡単に配信・保存できるサービス
- Kinesis Data Analysis
  - ストリームデータに対しSQLクエリを実行し、リアルタイム分析を行うサービス

構成管理サービス

Cloud Formation

インフラリソースを自動でプロビジョニングできるサービス

テンプレートに基づいてプロビジョニングしてスタックを作成する
プロビジョニングのみ
テンプレート
- CloudFormationの設定ファイル。プロビジョニングしたいAWSリソースをJSON, YAMLで記述
スタック
- テンプレートでプロビジョニングされるAWSリソースの集合
主要な設定項目
- Parameters
  - テンプレート実行時に利用できる値を指定
- Resources
  - プロビジョニングしたいAWSリソースとその設定を記述

Elastic Beanstalk

Webアプリケーションやサービスをサーバにデプロイでき、実行環境の管理もできるサービス

デプロイとプロビジョニング
対応アプリケーション
- Java, .NET, PHP, Node.js, Python, Ruby, Go
対応サーバ
- Apache HTTP Server, Nginx, Passenger, Microsoft IIS

OpsWorks

ChefやPuppetを利用した構成管理サービス

デプロイとプロビジョニング

CodeDeploy

アプリケーションのデプロイを自動化できるサービス

Codeシリーズ
- CodeCommit
  - コード作成、管理
- CodeBuild
  - ビルド、テスト
- CodeDeploy
  - デプロイ
CodeDeployはデプロイのみ

運用管理サービス

CloudWatch

AWS上で稼働するサービスのリソース情報を収集、監視、可視化するサービス

標準メトリクスはAWSでデフォルトで用意されている監視項目、カスタムメトリクスは独自に定義する監視項目
メモリ使用率、ディスク使用率はカスタムメトリクスが必要
基本モニタリングは5分間隔、詳細モニタリングは1分間隔の監視。どちらも最大15ヶ月保存
CloudWatchアラーム
- アラームのしきい値とアクションを指定
- メトリクスが監視対象
  - CPU使用率80%以上を5分間持続した場合にアラームを送信など
CloudWatch Events
- AWSのリソースを監視し、あるイベントをトリガにアクションを実行する機能
- 状態変化などのイベントがトリガになる
  - EC2のステータス変化、スケジュール間隔、Auto Scalingの成功失敗など

CloudWatch Logs

CloudTrailやVPCフローログなど、AWSのさまざまなログを統合的に収集するサービス

CloudTrail

AWSで利用された操作(APIコール)をログとして記録するサービス

デフォルト90日でログが保存されている
すべてのリージョンで利用可能

VPCフローログ

VPC内のネットワークインターフェース間で行き来する通信の内容をキャプチャする機能

Trusted Advisor

コスト最適化のヒントを推奨するサービス

AWSのベストプラクティスに基づいて、コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限の5項目絵利用状況をチェックし、改善事項を推奨する

KMS

AWS上で鍵管理を提供できるマネージドサービス

暗号化鍵の作成、保存、有効無効の管理、ローテーション、削除を行う
クライアントサイドでの暗号化(CSE: Client Side Encryption)
- AWSへデータを送信保存する前に、ユーザの環境でデータを暗号化
サーバサイドでの暗号化(SSE: Server Side Encryption)
- AWSが自動的にファイルの暗号化処理を行う
連携したAWSサービス
- AWS SDK, CLIを利用したクライアントアプリケーション
- S3, EBS, RDS, Redshiftなどのストレージやデータベースサービス

CloudHSM

AWSのデータセンター内に配置されるユーザ専有のハードウェアアプライアンス

連携したAWSサービス
- Redshift, RDS for Oracle

試験対策

AWSサービス全体の概要

アクセス制御サービス

IAMユーザ作成後にアクセスキーIDとシークレットアクセスキーを作成することで、AWSを操作するAPIがAWS SDKから使用可能となります

ネットワークサービス

パブリックサブネットとプライベートサブネットの定義
NATインスタンスの特徴を覚えておく
EIPはどのような場合に課金されるか覚えておく
セキュリティグループとネットワークACLの違いを覚えておく
Auto ScalingでAMIを最新化することやユーザデータなどを利用する考え方は重要
Route 53には、パブリックホストゾーンとプライベートホストゾーンの2種類の利用方法がある
Route 53は、ELBなどのエンドポイントをエイリアスとして指定することができる。そのため、エンドポイントはCNAMEレコードではなくAレコードとして指定する
Zone ApexレコードをRoute 53で利用するケースを覚える
CloudFrontのオリジンに指定できるサービスを抑えておく。EC2, ELB, S3といったAWSサービスが指定できるが、オンプレミスのサーバも指定可能

コンピューティングサービス

署名付きURLによるアクセス制御の機能は重要
CloudFrontは地域制限によるアクセス制御ができることを覚えておく
EBS-Backedインスタンスはデータを永続化できるが、Instance Store-Backedインスタンスは揮発性のためインスタンス停止時にはデータが削除される
メタデータで取得できる情報と、ユーザデータの用途を覚えておく

ストレージサービス

S3の各機能で何ができるかを押さえておく
インスタンスストアはエフェメラルディスクとも呼ばれるので、どちらの名称も覚えておく
AWS Import/ExportとVM Import/Exportは別のサービスなので、混同しないように注意

データベースサービス

Auroraの特徴を覚えておく
RDSはSSL接続を利用できる。接続に使用するコマンドのオプションを覚えておく
DynamoDBのデータ構造や、格納できるデータの種類を覚えておく
DynamoDBのデータの保持方法と、結果整合性の仕組みを理解しておく
Redshiftのバックアップの特徴を覚えておく

データ通知・連携処理サービス

DataPipelineを利用する主なユースケースを押さえておく
Elastic Beanstalkが対応しているアプリケーションとサーバを覚えておく
EC2のメモリ使用率やディスク使用率を監視するには、カスタムメトリクスの設定が必要
基本モニタリングと詳細モニタリングでは、収集したデータの監視間隔が異なる
CloudWatchアラームとCloudWatch Eventsの特徴の違いを押さえておく
運用管理に関連するサービス群の役割の違いを押さえておく

AWSにおける高可用アーキテクチャ

ネットワークにおける高可用性の実現

各ルーティングポリシーで何が実現できるかを覚えておく。位置情報ルーティングでは、リージョンに関わらず地理的に近い場所へ名前解決を行うなど
Route 53のレコードタイプの中で、ドメインからIPアドレスを参照するAレコードと、ドメイン名から別のドメインを参照するCNAMEレコードは重要
Direct ConnetとインターネットVPNの特性やユースケースを覚えておく

コンピューティングストレージにおける高可用性の実現

マルチAZのRDSでフェイルオーバーが発生したときの動きは重要

ストレージにおける高可用性の実現

EBSとEFSの違いを覚えておく
EBSスナップショットには、取得開始時点のものが保管される。取得開始から取得完了までに変更があった場合はスナップショットに反映されない

AWSにおけるパフォーマンス

ネットワークサービスにおけるパフォーマンス

CloudFrontの利用目的とユースケースを理解しておく
プレイスメントグループの仕組みと活用例を理解しておく

コンピューティングサービスにおけるパフォーマンス

CloudWatchとAuto Scalingを利用することで、パフォーマンスを効率的に管理できることを覚えておく

ストレージサービスにおけるパフォーマンス

S3内でオブジェクトキーがどのように管理されているか、パフォーマンス向上のためにどのような対応策があるか
EBSでパフォーマンス(IOPS)が低い場合の改善方法を押さえておく
EBSの各ボリュームタイプの特徴とユースケースを押さえておく
処理速度を速くすることができるRAID構成を覚えておく

データベースサービスにおけるパフォーマンス

DynamoDBの特徴とユースケースを覚えておく
DAXの特徴を覚えておく
ElastiCacheが利用されるユースケースを覚えておく

AWSにおけるセキュリティ設計の考え方

AWSにおけるセキュリティ設計

責任共有モデルにおける、AWSとユーザのセキュリティに関する責任分担の考え方は重要

アイデンティティ管理とアクセス管理

IAMユーザあたりのグループ所属数には上限があるので注意
IAMユーザとIAMグループの作成直後には権限が付与されていないので注意
AWS管理ポリシーで提供されている代表的なポリシーは重要なので覚えておく
アクセスキーIDとシークレットアクセスキーを用いた認証と、iAMロールによる認証方式の違いを押さえる
SAML2.0によるAWSとのIDフェデレーション連携は重要
Directory ServiceのAD Connectorを利用することで、企業内の既存のActive Directoryとの認証連携を行うことができる

ネットワークセキュリティ

セキュリティグループの特徴を押さえる。特に、設定が即時反映される点、ステートフルな制御が可能である点は重要
ネットワークACLはステートレスであるため、インバウンド通信とアウトバウンド通信の双方で通信制御を行うことが重要
セキュリティグループとネットワークACLの双方で許可されていない場合は、すべて拒否となることを押さえておく
踏み台サーバ(Bastion)の役割と構成は重要

データの保護

ELBやRDSなどのサービスの通信時には、SSL/TLSによる通信の暗号化が利用できる
クライアントサイド暗号化(CSE)とサーバサイド暗号化(SSE)の特徴の違いを覚える。特に、EBSとS3のユースケースは重要
ユーザの鍵をAWS KMSで管理することで、サーバサイド暗号化やクライアントサイド暗号化が可能
AWS KMSとCloudHSMで暗号化処理の連携がサポートされているAWSサービスは重要

セキュリティ監視

CloudTrailでは様々なサービス(EC2, IAM, KMS, ELBなど)の操作ログを収集することで、セキュリティインシデントに関する操作を監視できる点が重要
CloudWatch Logsによる各サービスからのログ収集とログ監視・通知の連携は重要
ユーザ側でAWSへの脆弱性スキャンや侵入テストを行うには、事前申請が必要。インスタンスの種類によってはテストできない点も押さえておく

AWSにおけるコスト最適化

コストが高いリソースの選定

リザーブドインスタンスの主な用途、支払い方法と、2種類のタイプ(StandardとConvertible)の違いを理解する
スポットインスタンスの主な適用用途と、強制終了される場合の条件(スポット価格が入札価格を上回る)は重要
用途に合わせた適切なインスタンスファミリーの選択と、インスタンス世代サイズの変更によりコスト最適化を実現できる
S3の5種類のストレージクラスの用途・特徴に応じた使い分けを整理する
EBSの5種類のタイプの特徴と用途の違いを押さえておく。特に、SSDタイプとHDDタイプの用途の違いは重要
プロビジョンドIOPS SSDでは、実際に利用しているストレージ容量に対する課金に加え、IOPSにも課金されるため、コスト面で注意が必要

需要と供給のマッチングによるコスト最適化

SQS, Kinesisのバッファリング処理の特徴と利用用途の違いは重要
Kinesisはリアルタイムに処理する。Kinesisの3つのサービスの違いを押さえておく

コストの管理

Consolidated Billing(一括請求)におけるアカウントの種類(マスターアカウントとメンバーアカウント)と、利用した場合の利点を押さえておく
Trusted Advisorでチェック可能な5つの項目(コスト最適化、セキュリティ、対象外性、パフォーマンス、サービスの制限)は重要なので覚えておく。特に、コスト最適化の観点では、EIPが課金される条件とコスト削減の方法は重要

AWSにおける運用管理

作業の自動化

CloudFormationテンプレートの記述方法を覚えておく