【SAA-C02】AWSの各サービスの要点をまとめた

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

EC2

• インスタンスの変更は途中で出来ない

インターネットから、VPC内のEC2インスタンスへ接続できない時の原因

• インターネットゲートウェイがサブネットに設定されていない
• ネットワークACLの設定でインターネットアクセスの設定が許可されていない
• セキュリティグループのの設定でインターネットアクセスの設定が許可されていない
• パブリックIPが付与されていない

障害復旧対策

• AMIを取得し、別リージョンへコピーする（実行中でも停止中でも）
• EC2にバックアップ機能はない（代わりにAMI）
• AMIにスナップショットも含まれている(スナップショットはEBSに対する内容)

プレイスメントグループ

• 単一AZ内のインスタンスの間を論理的にグループ化したもの
• 同じAZ内のEC2インスタンスをグルーピング化できるため、異なるAZや、異なるリージョンとの通信よりも高速
• 用途
  • ネットワーク待ち時間が短い
  • 高スループット

Auto Scaling

クールダウン

• 以前のアクティビティの影響が表示される前に、Auto Scaling グループが追加のインスタンスを起動または終了するのを防ぐ

フローログの有効化

• ネットワークのトラフィックログをCloudWatchで取得することができる
• フローログではEC２インスタンスのネットワークトラフィックが取得される

Lambda

• 最大15分の操作制限がある
• Lambda関数を呼び出すたびに使用できる一時ボリューム量の最大は512MB
• 同時実行数：１０００

Lambdaファンクション

• Lambdaファンクションを使用するときに他のリソースにアクセスする必要がある場合は、Lambdaが利用するサービスへのアクセス権限を付与するIAMロールが設定されている必要がある

AWS Fargate

• コンテナ向けサーバーレスコンピューティングサービス
• サーバーやAmazon EC2インスタンスの クラスターを管理することなくコンテナを実行出来る
• アプリケーションがアイドル状態のときにコストは発生しない

○ストレージサービス

EBS

• 1つのEC2インスタンスにしかアタッチ出来ない
• インスタンス間のデータ共有は出来ない
• EBS自体を他のリージョンへ移動して利用することは出来ない

ユースケース

• 単一の EC2 インスタンスから最も低いレイテンシーでデータにアクセスすることが求められるワークロードで性能を発揮

EBSスナップショット

• 取得すると、そのデータは自動でAWSが管理するS3に保存されることになる
  • しかし、AWS上で自動で保存・管理されているもの
  • そのため、S3のライフサイクルポリシーによってバックアップ取得を定期的にすることは出来ない

EBSボリューム

• スナップショットを取得して、インスタンスを停止する事でデータのみを保持出来る

EBSボリュームタイプ

プロビジョンドIOPS

• レイテンシーの影響が大きいトランザクションワークロード向け
• ボリュームごとに最大 64,000 IOPS
• ボリュームあたり、1000MB/秒　スループット

スループット最適化 HDD

• 高いスループットを必要とするアクセス頻度の高いワークロード向け
• ボリュームごとに 500 IOPS に制限
• 1000MiB /sのデータスループット性能

汎用SSD

• ボリュームごとに 16,000 IOPS に制限

コールドHDD

• アクセス頻度の低いワークロード向けに設計された極めて低コストの HDD ボリューム

EBSのRAID構成

	RAID0	RAID1
目的	パフォーマンス向上	冗長性を高める
内容	複数のディスクを1台のように扱い読み書きする高速化技術	2つのボリュームを同時にミラーリングする

EFS

• S3よりもコストが高い
• インターネットからの直接アクセスが出来ない
• 500,000 超の IOPS
• 最大数千台のEC2から同時アクセス可能
• マウントターゲットの作成（AZごと）

EBSボリュームの回復性

回復性とは、「障害から回復し、引き続き機能する能力」
2つのEBSボリューム間でミラーリングすることで回復性が高く、冗長化を達成する事が出来る。

EBSスナップショット

• ボリュームデータをS3にバックアップ出来る
• 1 つの AWS リージョンから別のリージョン、または同じリージョン内にスナップショットをコピーできる
• 増分バックアップ（最後に保存したデータ〜差分のみ保存）
• スナップショットからの復元は一定時間システムの停止を要する

ライフサイクル管理設定について

• データ削除するための設定はない
• 低頻度アクセスデータを低コストなストレージに移すことは可能

S3

• 利用料が不明な場合も、保存した利用料金しか取られない
• 静的webサイトのホスティングが出来る
• セキュリティグループの設定はない
• SFTPプロトコル
• ログファイルの蓄積にも向いている
• イベント機能が備わっている

バージョニング

• 謝って消してしまった場合でも以前のバージョンへ復元することが出来る
• (ちなみに、S3にスナップショット機能はない）

レプリケーション

• クロスリージョンレプリケーションを有効にするためには、バージョニング機能の有効化が必要
• レプリケート元と、レプリケート先で必要なもの
  • リージョンの有効
  • バージョニングの有効
  • アクセス許可

バケットポリシー

• 特定のユーザー単位でのアクセス制御が出来る

データを頻繁に利用するケース

• Standardクラスを使用

低頻度アクセス

• S3 Standard IA
  • 重要なデータを保存する際に適したストレージタイプ（マスターデータなど）
• One-zone-IA（S3 Standard IAよりも可用性が落ちる）
  • 重要度の低いデータを保存（ログファイルなど）

S3 Transfer Acceleration

• エッジロケーションを使用して（送信元から離れていても）データを Amazon S3 にコピーする事でより迅速にアップロードする

マルチアップロード

• 巨大なファイルをより高速にアップロード
• 転送時、データ量を分割する事で高速に
• AWSは100 MB 以上のオブジェクトの場合に使用の推奨をしている

S3 分析

• ストレージクラス分析
  • ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断出来る

S3 Access Analyzer

• AWS アカウントの外部からアクセスできるリソースを特定する総合的な解析結果を生成する
  • S3バケットに対する外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認出来る

Glacier

• 「標準」「迅速」「大容量」の3種類
  • 迅速： 1～5 分以内
  • 標準：3～5 時間以内
  • 大容量：ペタバイト規模であっても、データの重要な部分にコスト効率よくアクセス出来る
• 最低保持期間は９０日

Glacier Deep Archive

• Glacier よりもコストが低く、全てのストレージクラスで最も低コスト
• 最小保存期間は180日で、最低180日よりも前にオブジェクトを削除した場合、180日分課金される
• 復元オプションの標準取り出しで12時間以内、一括取得で48時間以内待つ必要がある

ボールトロック

ボールトロックポリシーを用いて、Glacierのコンプライアンス管理を簡単に適応するもの

○データベース

RDS

• リードレプリカを利用した、フェイルオーバー構成は無い（Auroraは可能）

リードレプリカ

• 「インスタンスのパフォーマンスと,耐久性」を強化する
• 回復性を優先する場合は早い
• 別リージョン間での移行も容易

スナップショット

• 別リージョンでの回復もできるが、遅い

インスタンスタイプ、サイズ、ストレージタイプの変更が出来る

• スケールアップ、パフォーマンスの向上が見込める
• ストレージタイプ：IO処理が多い場合IOPSに変更できる
• インスタンスサイズ：サイズを高性能なものにすることで、パフォーマンス向上

向いている処理

• 業務データ向き（セッションデータの高速処理は向かない）
• データを中長期処理する際（データ処理を行って、短期間でデータを削除するといったライフサイクル管理には向いていない）

DynamoDB

• キーバリューのレコードをサポートする NoSQL データベース
• インデックスを付けることができる

格納データ

• セッションデータ
• メタデータ
• ユーザー設定
  などの高速処理に向く

DAX：Amazon DynamoDB アクセラレーター

• マイクロ秒単位で応答時間を提供
• DynamoDB と互換性のあるキャッシュサービス
• キャッシュDBであるため高コスト

DynamoDBストリーム

• DynamoDBテーブルの変更イベントをトリガーにして、Lambda関数などを起動する
• DynamoDBテーブルへの変更を監視
  • 登録、変更をトリガーにしてLambdaを動作させることが出来る
• DynamoDB テーブル内の項目レベルの変更の時系列シーケンスをキャプチャ
• 最大 24 時間ログに保存

Auto Scaling

• テーブルとグローバルセカンダリインデックス（GSI）に対する性能強化を自動化
• アプリケーショントラフィックの変化に応じて自動的にスループットを調整
• 一時的な負荷増加に対して、DynamoDBテーブル処理パフォーマンスの管理が容易になる
• 可用性を最大化
• コスト削減

リードレプリカはそのままでは利用できない

• DAXの有効化が

ElastiCache

• Redis および Memcached のマネージドキャッシングサービス
• RDSなどのデータベース処理の高速処理化に利用
• ユースケース
  • ユーザーの行動データの高速処理
  • メタデータ
  • セッション管理

特徴

• 高スループットかつ低レイテンシー
• インメモリデータストアからデータを取得
• セッションデータの高速処理
• フルマネージド

○ネットワーキングとコンテンツ配信

VPC

サブネットのインスタンスでインターネットのアクセスを有効にするには？

以下の設定が必要

• VPC にインターネットゲートウェイをアタッチ
• サブネットのルートテーブルがインターネットゲートウェイに繋がっている
• サブネットのインスタンスに、グローバルIPが割り当てられている
• ネットワークACLと、セキュリティグループルールがインスタンス間で関連するトラフィックを許可している

NATゲートウェイの設定

• パブリックサブネットに設定
• プライベートサブネットのルートテーブル（ネットワーク経路を記載されたテーブル）にNATゲートウェイを設定

NATゲートウェイと、NATインスタンスの違い

	NATゲートウェイ	NATインスタンス
管理	AWS	ユーザー
踏み台/ポート転送	×	○
グローバルIP	EIPのみ	パブリックIP or EIP
セキュリティグループ	×	○（実態はEC2）

VPC Site-to-Site VPN

• VPC からリモートネットワークへのアクセスを有効にする際に使用（VPCと、オンプレ間）

VPN接続

• AWS グローバルネットワーク間に安全な接続を確立する
• 接続に必要なコンポーネント（VPN接続のトンネル）
  • カスタマーゲートウェイ
  • 仮装プライペートゲートウェイ
• データセンターを、VPCにリンクする
• カスタマーゲートウェイ（接続の作業者側のアンカー）に、静的ルートテーブルを構成することで実現できる

VPC ピアリング

• 他のVPCとの接続を可能にする
  • 自分の AWS アカウントの VPC 間
  • 他の AWS アカウントの VPC との間
  • 異なるリージョン間

VPCエンドポイント

• VPCと、サポートされているリソース間の接続が有効になる
• パブリックに公開されることがない
• S3や、DynamoDBに利用

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

項目	ステートフルorステートレス	範囲
セキュリティグループ	ステートフル（戻りの通信は行きの通信が許可されている限り自動的に許可）	インスタンス単位
ネットワークACL	ステートレス（インバウンドと、アウトバウンドの設定が必要）	サブネット単位

ALB

パスベースルーティング

• 複数のサービスが1つのALB上の同じリスナーポートを使用出来る
• URLパスに基づいてALBが特定のターゲットグループにリクエストを送信する

Route53

フェイルオーバールーティング

• プライマリインスタンスに障害が発生した場合、バックアップインスタンスにトラフィックをルーティングできる

加重ルーティング

• 指定した比率でトラフィックをインスタンスにルーティング出来る

CloudFront

• エッジロケーションによる配信
• クライアント間の高速配信を実現する（EC2インスタンス間は ×）

○分析

Amazon kinesis

• リアルタイムに流れてくる大量のデータを処理するサービス

kinesisストリーム

• IoTなどのストリーミングデータ（数千もの大量のデータソースによって継続的の生成されるデータ）の処理に利用
• デフォルトで24時間以内までアクセス出来る様に設定されている
• ほぼリアルタイムで解析

kinesis Data Firehose

• S3や、RDSに保存できる

Amazon Kinesis Data Analytics

• ストリーミングデータをリアルタイムで分析することができる

○Amazon Redshift

• 高速でシンプルかつ費用対効果の高いデータウェアハウスサービス
• 列指向データベース
• レポーティングやBIに活用

障害回復→クラスターをすぐに利用できるようにするには

• クロスリージョンスナップショット
  • プライマリクラスターがダウンした場合に備えてすぐに利用できるようにする

特徴

• シングル AZ 配置のみをサポート

Redshiftスペクトラム

• S3に保存されたデータを直接分析することができる

Amazon Athena

• S3 内のデータを標準 SQL を使用して簡単に分析できる。
• サーバレス

○マネジメントとガバナンス

CloudWatch

• アプリケーションの可用性
• 問題発生時
• リソース変更時のシステムイベントにほぼリアルタイムで対応できる

EC2インスタンスのデフォルトメトリクス以外の詳細なログ情報の取得をする場合

• CloudWatchエージェント
  • 対象のEC２インスタンスにインストールすることで、CloudWatchによりサーバー内部の詳細なログが取得できるようになる
• CloudWatch Logs
  • 取得したログを集約することができ、EC2インスタンスのログ管理を実施することができる

上記の二つが必要

CloudTrail

• AWS インフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持する
  *

Amazon EMR

オープンソースのフレームワークである Apache Spark と Hadoop を使用して、膨大な量のデータを迅速かつコスト効率よく処理して分析するサービス

OpsWorks

・Chef や Puppet のマネージド型インスタンスを利用できるようになる構成管理サービス

・コードを使用してサーバーの構成を自動化できるようにするためのオートメーションプラットフォーム

CloudFormation

• インフラをコードとして扱う
• IaaS　インフラの管理自動化
  • アプリケーションの開発に注力できる

○ハイブリッドストレージ統合

AWS Storage Gateway

• オンプレミスから実質無制限のクラウドストレージへのアクセスを提供するハイブリッドクラウドサービス
• キャッシュ型ボリュームを利用すると、頻繁にアクセスされるデータをローカルに保持しながらS3をプライマリーローカルストレージとして使用できる

キャッシュ型ボリューム

• AWSのS3をプライマリーとする

保管型ボリューム

• プライマリーストレージをオンプレミスに置いたままS3へと拡張することが出来る

○アプリケーション統合

SQS

• ソフトウェアコンポーネント間でメッセージを送信（顧客にメッセージを送信できない点に注意）
• キューに優先順位をつけることが出来る（FIFO機能とは別）
• システムの分離にも利用される
• メッセージ重複排除IDを利用することで重複メッセージを防ぐ設計が可能
• 非同期処理が可能

SQSを利用する理由

• システム分離のため

FIFOキュー

• メッセージが順不同に処理された場合に発生する問題を解決する
• 突然のボリューム増加時にパフォーマンスを向上することは出来ない

SQSキューイング

• メッセージング処理の確実な実施や、分散並行処理による処理性能の向上によって、ワーカープロセスの信頼性を高めることが出来る

水平方向のスケーリング

• 質ではなく、数が増加

※注意

• 作成後、キューの交換は出来ない

SNS

• アプリケーション間通信およびアプリケーション対人の通信のためのフルマネージド型のメッセージングサービス
• サービス上のメッセージ通知機能

○ウェブアプリの実行と管理

Elastic Beanstalk

AWS Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするための、使いやすいサービス

• WEBアプリケーションのデプロイ管理ツール
• コードをアップするだけ
• フルマネージド

ユースケース

• Webアプリケーションや、ワーカー環境の構築
• 複雑なアプリケーションを簡単にワーカーアプリケーションとして実装する際に利用する

○Webとモバイルのフロントエンド

Amazon SES

デベロッパーが任意のアプリケーションでメールを送信できるようにする、費用対効果の高い、柔軟でスケーラブルなメールサービス

• AWS上で提供するサービス
• デベロッパーがマーケティング、通知、トランザクションに関するEメールを送信できるように設計された、クラウドベースのEメール送信サービス

○セキュリティ

IAM

IAMロール

• リソース間のトラフィック制御（EC2と、DB間は×）
• 特定のIPのEC2インスタンスからのアクセス制御が出来る

IAMユーザー / IAMグループ

• サービス単位でのアクセス権限
  • EC2インスタンス単位での設定はIAMユーザーではなく、タグに応じてアクセス権限の付与を行う

AWS STS（security Token Service）

• AWS リソースへのアクセスを制御できる一時的セキュリティ認証情報を持つ

API認証情報

• API認証情報を保持することで、漏洩リスクが発生する
  • 対策）API認証情報を利用しない方式をとる

AWS Shield

• DDos攻撃（大きな負荷をかけて妨害）から保護

AWS WAF

• SQL インジェクションやクロスサイトスクリプティングなどの一般的な攻撃パターンをブロックするセキュリティルールを作成できる

○セキュリティ、アイデンティティ、コンプライアンス

CloudHSM

• クラウドベースのハードウェアセキュリティモジュール
• 専用のハードウェアで暗号化キーを保管
• フルマネージド

データ暗号化

	SSE-S3	AWS KMS
管理	暗号化と復号化をS3が自動で実施	マネージド型（ただし、KMS上でのキー作成と管理の実施が必要）
管理の楽さ	勝	負

Amazon Inspector

• ○自動化されたセキュリティ評価サービス
  • ソフトウェアの脆弱性や意図しないネットワークのエクスポージャーがないか継続的に AWS ワークロードをスキャンする自動脆弱性管理サービス

○クラウド財務管理

AWS Cost Explorer

• 現在利用中であるAmazon EC2 インスタンスなどのリソースに関するコスト状況は推奨事項を把握することができる

AWS Budgets

• カスタム予算を設定して、コストまたは使用量が予算額や予算量を超えたとき (あるいは、超えると予測されたとき) にアラートを発信できる

○フロントエンドとウェブのモバイル

○その他

AMI

AMIに含まれているもの

• 1 つまたは複数の EBS スナップショット、または、instance-store-backed AMI、インスタンスのルートボリュームのテンプレート (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)
• 起動許可 (AMI を使用してインスタンスを起動する権限を特定の AWS アカウントに与える)
• インスタンスの起動時にインスタンスにアタッチするボリュームを指定するブロックデバイスマッピング

AWS CLI

• AWS CLIを利用するには、対象サービスの操作権限が付与されたIAMロール、もしくはアクセスキーとシークレットアクセスキーが必要
• セキュリティの観点からアクセスキーでの認証より、IAMロールでの認証の方が適切

AWSのVPCとオンプレミス環境とをネットワーク接続するための方法

VPN、もしくは、Direct Connect