公開日：
AWS SAA試験に出てくる単語まとめ（AWS用語編）
エンジニアのkouです！
ようやく暖房の出番がなくなってきましたね…
前回に続きAWSのSAA試験の単語のまとめになりまして、
今回はAWSのサービスに関する用語をまとめていこうと思います！
AWS用語
・Accelerated サイト間 VPN
オンプレミスネットワークから利用者のゲートウェイデバイスに最も近いAWSエッジロケーションにトラフィックをルーティングするサービス。
Global Accelerator を利用したサイト間VPN。VPNの通信はAWSグローバルネットワークを経由して接続されるため、
高可用性・高パフォーマンスが維持される。VPCにおいてAccelerationを有効にすると、AWS グローバルネットワークを使用してパフォーマンスを
向上させることができる。カスタマーゲートウェイデバイスのトラフィックは、最も近い AWS エッジロケーションを経由してルーティングされ
AWS グローバルネットワークを通過して、AWSのVPNエンドポイントに到達する。
・AD Connector
IAMとオンプレミス環境のADとを連携するのに利用する。
AD ConnectorはIAM側のディレクトリ・リクエストをオンプレミスの Microsoft Active Directory へとリダイレクトするのに使用する
ディレクトリゲートウェイ。この機能により、Active DirectoryとIAMとを連携することができる。
既存のオンプレミスのMicrosoft Active Directoryと連携してSSOを実現できる。
ADとロールに割り当てられたIAMポリシーに基づいてユーザーのAWSサービスへのアクセスを制御する。
・Simple AD
AWSに簡易なディレクトリサービスを立ち上げることができる。
AWSの仮想デスクトップサービスなどへの簡易なアクセスを外部ユーザーに許可する場合などに利用される。
・ALB(Application Load Balancer)
HTTP / HTTPS トラフィックの負荷分散に最適なロードバランサ。
Webサイトのロードバランサとして使用する場合はこのロードバランサが推奨される。L7レイヤーで負荷分散する。
高度なルーティング機能、マイクロサービス、およびコンテナベースのアーキテクチャが必要なアプリケーションに最適。
URL パスに基づいてリクエストを転送するルールを持つリスナーを作成できる。この方式をパスルーティングと呼ぶ。
複数のタスクを実施するEC2インスタンスグループを有している場合は、
パスルーティングを使用して1つのALBで複数のバックエンドサービスにトラフィックをルーティングすることができる。
標準でWebSocketプロトコル機能に対応しているため、HTTP/HTTPSリスナーで受けてHTTP/1.1 から
UpgradeでWebSocket 通信を開始することができる。
・ALBの特徴
– L7に対応
– URLのパスに基いてルーティングが可能なパスベースルーティングが可能
– WebSocketとHTTP/2のリクエストが利用可能
– 1インスタンスに複数ポートを登録可能
– EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、
ポートを利用するコンテナをロードバランシング可能
– ターゲットグループでのヘルスチェックが可能
– アクセスログが取得できる
– EC2と同様に削除保護が可能
– ALB自体が自動的にキャパシティを増減する
・ALB DNS名の指定
Aliasターゲットの IP アドレスを伴う A レコード (IPv4 アドレスの場合) または AAAA レコード (IPv6 アドレスの場合) を設定する。
・CLB(Classic Load Balancer)
複数のAmazon EC2インスタンスにおける基本的な負荷分散を行うのに最適なロードバランサ。
L4レイヤーで負荷分散するため、HTTPやHTTPS以外のTCPプロトコル上で動作するプロトコルにも対応することができる。
ただし、 クラシックロードバランサは現在は使用を推奨されていない。
・NLB(Network Load Balancer)
OSIモデルの第 4 層で機能する毎秒数百万のリクエストを処理できる高性能なロードバランサー。
レイヤー 4 の TCP で動作するため、ヘッダーを変更せずにリクエストをバックエンドインスタンスに転送することができる。
パスルーティングは実行可能であり、かなりの大規模システム向けの高性能なELBである。
・ELB クロスゾーン負荷分散
ロードバランサーノードは有効な全てのアベイラビリティゾーンの登録済みターゲットにトラフィックを分散する。
・ELB リクエストルーティング
ホストベースのルーティング機能であり、ホストのヘッダーを使用してトラフィックを
任意のターゲットグループにルーティングするようにルールを設定する。
・Connection Draining
インスタンスが登録解除されるか異常が発生した場合に、
そのバックエンドインスタンスへの新規リクエスト送信を中止する機能。
・SSL Termination
ELBにSSL Terminationを設定して、ロードバランサー側でSSL認証を行う機能。
・クロスゾーンロードバランシング
AZ間の分散を均等に実施することができる。
・スティッキーセッション
セッション中に同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能。
・プロキシプロトコル
ELBを介してやり取りをしていても、AWSリソース側のIPアドレスを確認する。
・Aurora Global Database
高速で性能への影響を最小限にDR環境を構築可能なAuroraのレプリケーション機能。
RPOが5秒、RTOが1分のDBクラスタを構築で、Aurora独自のストレージにより実現されている。
・Aurora Serverless
Aurora用のAutoScaling設定のこと。アプリケーションのニーズに応じてコンピューティング性能を変更してくれる。
例：期間限定セールでDBへのクエリが一時的に増加する場合、わざわざDBサーバーを新しく作らなくてもアクセスが多くなると自動で作ってくれる。
DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成して、最小と最大のキャパシティーを設定する。
Aurora Serverlessはデータベースエンドポイントがプロキシフリートに接続される。このプロキシフリートでは、
ワークロードをルーティングする先のリソースのフリートがオートスケーリングされる。プロキシフリートを使用すると、
最小と最大のキャパシティー仕様に基づいてAurora Serverlessがリソースを自動的にスケールするため、接続が途切れることはない。
したがって、処理負荷が一定ではないケースにはAurora Serverlessを利用することが有効となる。
・Aurora リーダーエンドポイント
リーダーエンドポイントを使用して別のアベイラビリティーゾーンにある複数の Aurora レプリカを配置し、
読み取りワークロードの読み取り専用エンドポイントに接続すれば DB クラスターからの読み取り専用クエリで高可用性を確保することができる。
また、リーダーエンドポイントは DB クラスターにある Aurora レプリカへの接続を負荷分散する。
・Auto Scaling
Webアプリをモニタリングし障害や不具合が起こることなく安定して運用できるように
サーバーへのアクセス数やCPUの使用量に応じてAWSのEC2インスタンスの数を
自動的に増減させてくれるもの
・AutoScaling Desired capacity
Desired capacityのインスタンス数を増加させることで、一時的なリクエスト流入増加に備えて、現在のインスタンス数を手動で増やすことができる。Desired capacityを設定することで、既存の Auto Scaling グループのサイズはいつでも手動で変更して、稼働するインスタンス数を増減させることができます。
・AutoScaling 起動設定
起動設定とは、EC2 インスタンスを起動するために Auto Scaling グループで使用されるインスタンスの設定テンプレート。
起動設定では、スケーリングの条件に該当した場合に何を起動するかを設定する。起動設定を作成する際、起動したいインスタンスの情報を指定する。
指定する情報には、Amazon マシンイメージ (AMI) の ID、インスタンスタイプ、キーペア、1 つ以上のセキュリティグループ、ブロックデバイスマッピング
などがある。
・Auto Scaling 手動スケーリング
既存の Auto Scaling グループのサイズをいつでも手動で変更できる。
手動スケーリングは負荷時期が明確なオートスケーリング設定としては不適切。
・Auto Scaling 動的(ダイナミック)スケーリング
処理負荷を確認するためにCPU利用率の状況に応じた自動スケーリングも有効にする。
・Auto Scaling スケジュールドスケーリングポリシー
時間指定して、スケーリングすることで、負荷向上する前にEC2インスタンス数を増やして処理できるようにする。
・Auto Scaling ステップスケーリングポリシー
一連のスケーリング調整値 (ステップ調整値) に基づいて、Auto Scaling グループの現在の容量を増減させる。
段階スケーリングポリシーは、CloudWatchメトリクスから得られる値（CPU使用率やSQSキューサイズなど）の閾値を超えて発せられるアラームに
対して、値ベースでスケーリングアクションを個別設定できる機能。
・Auto Scaling ヘルスチェック
Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行する。
このへルスチェックにはEC2タイプとELBタイプの2つのタイプがある。
EC2タイプでは、EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断する。
ELBタイプでは、インスタンスのステータスチェックとELBのヘルスチェックからインスタンスの状態を判断する。
impaired = 障害
・Auto Scaling クールダウン期間
前のスケーリングアクティビティが実行される前に、 Auto Scaling グループが追加のインスタンスを起動または削除することが、一定期間できなくなる。この期間の長さは、インスタンスのウォームアップ期間やその他のアプリケーションのニーズに基づいて設定できる。
デフォルト設定は300秒で設定されている。
クールダウン期間が設定されることで、Auto Scalingグループは前のスケーリングタスクを完了させる前に、EC2インスタンスを停止させることはしない。
・Auto Scaling スケーリングクールダウン
もし、クールダウンを設定していないと、すぐさま次のインスタンス起動が始まってしまう。
スケーリングクールダウンは、Auto Scalingが連続で実行されないようにするための待ち時間である。
従って、Auto Scalingを設定していても、即時で問題は解決されず数分程度かけて改善されていく。
・AutoScaling ターミネーションポリシー
デフォルトのポリシーを利用するとOldestLaunchConfigurationから実行される。
OldestInstance
→ 古いインスタンスから削除を実行するターミネーションポリシー。
既存のEC2インスタンスから削除される。
NewestInstance
→ 新しく設置されたインスタンスから削除されるポリシー設定。
AutoScalingによって起動された新しいEC2インスタンスから削除する。
OldestLaunchConfiguration
→ もっとも古い起動設定から設定されたインスタンスから削除するため、
既存のEC2インスタンスから削除される可能性が高い。
・AWSリソースのタグ付け戦略
1リソースあたりにつけることが出来るタグの最大数は 50個まで。
AWSリソースのタグ付け戦略のベストプラクティスは以下の通り。
– タグには常に標準化された大文字と小文字を区別する形式を使用し、全リソースタイプにわたって一貫して利用する。
– リソースアクセス制御、コスト追跡、自動化、および組織の管理機能をサポートするためのタグディメンションを検討する。
– リソースタグの管理に役立つ自動化ツールを実装します。 Resource Groups Tagging APIはプログラムによるタグの制御を実施し、
タグとリソースの自動管理、検索、フィルタリングが簡単になる。
– AWSリージョンごとに1つのAPIコールを使用することで、サポートされているすべてのサービスのタグデータのバックアップを簡素化する。
– タグを多く使いすぎてはいけない。
– ビジネス要件の変化に対応するためにタグを変更する際は、タグベースのアクセス制御、自動化、
またはアップストリーム請求レポートに関連する影響を考慮して必要がある。
・AWS 暗号化SDK (Software Development Kit)
言語固有のSDKとは別の暗号化専用のライブラリ。
この暗号化ライブラリを使用すると、開発中のアプリケーションに対して暗号化のベストプラクティスをより簡単に実装できる。
AWS暗号化SDKはAmazon S3専用ではなく、任意の場所にデータを保存または復号するために使用できる。
・AZ(Availability Zone)
リージョンよりも小さな区分け。
原則として、１リージョンの中に複数のアベイラビリティゾーンが存在している。
データセンターの集まりであり、リージョン内で物理的に区分され独立している。
発電機や冷却装置などの一般的な障害ポイントとなる設備は可用性ゾーン間で共有されない。
AZは物理的に分離されているため、火災、竜巻、洪水などの極端な災害は単一のアベイラビリティーゾーンのみに影響する。
・CSE(Client Side Encryption)
ユーザーが独自の暗号化キーを利用して暗号化したオブジェクトをS3に保存して、
暗号化キーの生成・監理はクライアントで実行する形式。
・CloudFormation セクション
Resources
→ EC2インスタンスなどのスタックリソースとそのプロパティを指定する。
Parameters
→ 実行時にテンプレートに渡す値を指定する。
Description
→ そのテンプレートに関するコメントを指定する。
・CloudFormation エクスポート
１つのスタックの出力値を別のスタックに提供することで、スタック間を連動させてインフラを構成することが可能になる。
スタック間で情報を共有するにはスタックの出力値をエクスポートする。スタックの出力値をエクスポートするには、
スタックのテンプレートの Output セクションの Export フィールドを使用する。
・CloudFormation インポート
CloudFormation スタックに既存のリソースをインポートすることが可能。
これはエクスポートされた出力値を別スタック側が利用する際に使われる。
・CloudFormation ドリフト
実際のリソースとCloudFormationテンプレートの内容に乖離があることをドリフトと言う。
・CloudFormation スタックセット
CloudFormation テンプレート内に AWS リソースの設定を定義して、１つのテンプレートにより複数の AWS アカウントやリージョンに
リソースを展開できる。クロスアカウントやクロスリージョンのシナリオを解決するAWS機能のベースラインレベルのセットアップに
この機能を活用できる。一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができる。
・CloudFormation テンプレート
テンプレートからAWSリソースを自動構築するための一連のセット様式のこと。
テンプレートはJSON または YAML 形式で記述されている。
– Resources セクション
必ず記載しなければならない AWS のリソース (EC2 や S3) 及びプロパティを含むセクション。
– Parameters セクション
実行時に (スタックを作成または更新するとき)、テンプレートに渡すことができる値を指定する。
– Description セクション
テンプレートの説明を記入するセクション
– Outputs セクション
スタックのプロパティを確認すると返される値について説明する。
・CloudFormation 変更セット
CloudfFormationのテンプレート内容の変更を行う仕組み。スタックを更新する必要がある場合は、
変更の実装前に実行中のリソースに与える影響を理解することで、安心してスタックを更新できる。
変更セットを使用すると、スタックの変更案が実行中のリソースに与える可能性がある影響 (たとえば、変更によって重要なリソースが
削除されたり置き換えられたりしないか) を確認できる。
・CloudFormation 設定
パブリックサブネット内に対してSSHによるアウトバウンドの通信許可設定が必要な場合、SSHによるアウトバウンドトラフィック通信を
ネットワークACLによって許可する設定が必要。そのためには、 PortRange:で22ポートの設定をすることが必要。
Egress: trueとすることでアウトバウンドトラフィック設定となる。
Egress: falseとすることで、インバウンドトラフィックを設定することができる。ネットワークACLはステータスレスであるため、
SSHによって送信と受信をどちらも設定したい場合は、アウトバウントとインバウンドの両方の設定が必要。
・CloudFront エッジロケーション
低レイテンシーを達成するためのキャッシュコンテンツを配信するための地理的ロケーションとなる。
これはリージョンやAZとは独立して配置されている。CloudFrontはエッジロケーションを使用して、
キャッシュされたコンテンツを最も近いロケーションに配信し、待ち時間を短縮する。
エッジロケーションと呼ばれるデータセンターのグローバルネットワークを通じてコンテンツを配信する。
オリジンからファイルを取得するときに、CloudFront は各エッジロケーションでファイルを圧縮する。
ビューワーがリクエストヘッダーに Accept-Encoding: gzip を含めるようのリクエストした場合は、
CloudFront はファイルを圧縮して、ファイルを供給するように設定できる。コンテンツが圧縮されるとファイルが小さくなるため、ダウンロード時間が
短縮される。これにより場合によっては、オリジナルの 4 分の 1 以下のサイズになることがある。特に、JavaScript および CSS ファイルでは、
ダウンロード時間が短縮されると、ユーザーにウェブページが表示されるまでの時間が短縮される。また、CloudFront のデータ転送コストは供給された
データの総量に基づくので、圧縮ファイルを供給すると、非圧縮ファイルを供給するよりもコストが安くなる。
・CloudFront キャッシュ保持期間
短縮してしまうと、キャッシュの有効期限が短くなり、オリジンサーバーからのファイル取得が多くなることでコストが高くなる。
・CloudFront 地域制限 (地理的ブロッキング)
CloudFront ウェブディストリビューションを通じて配信しているコンテンツについて、特定地域のユーザーによるアクセスを回避できる。
・CloudFront ディストリビューション
フェールオーバーオプションが提供されている。CloudFrontへのフェールオーバーは従来はRoute 53のDNSフェイルオーバーを利用して実装することが
必要だったが、CloudFront側でフェイルオーバのコントロールが出来るようになった。
CloudFrontフェールオーバーオプションはサイト単位でのフェイルオーバではなく、オブジェクト単位でのフェイルオーバになる。
・CloudWatch Logs
取得したログを集約することができ、EC2インスタンスのログ管理を実施することができる。
アプリケーション、AWS サービスからのログを一元管理できる、スケーラビリティに優れたサービス。
たとえば、CloudWatch Logs はアプリケーションログに存在するエラーの数をトラッキングし、
エラー率が指定のしきい値を超えたときに管理者に通知を送ることができる。
・Cloudwatch Logs サブスクリプション機能
Lambdaへログを連携することができる。
これにより特定のログが発生した場合に、Lambda関数で処理を実行するような構成を実装することができる。
・CloudWatch 標準メトリクス
OSの外から測定できるメトリクスしか取得できない。
また、よく混同されがちなケースだが、メモリ利用率などといったOS内でしか測定できないメトリクスは
カスタムメトリクスで取得する必要があるので基本的な監視項目を検討する場合にはカスタムメトリクスを設定する。
・CloudWatch TunnelState メトリクス
AWS VPN のステータスを、CloudWatch のメトリクスデータでモニタリングできる。
VPNの状態は、CloudWatch メトリクスの TunnelState のブール値として定義されている。
ブール値が 0 の場合はトンネルがダウン状態、1 の場合はトンネルがアップ状態であることを示す。
・CloudWatch エージェント
このエージェントを対象のEC2インスタンスにインストールすることで、
CloudWatchによりサーバー内部の詳細なログが取得できるようになる。
・DynamoDB
NoSQL型データベース。
1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエスト処理が可能。
DynamoDB はキーバリュー型のれ属した単純なデータ形式を高速で処理にするのに適しており、IoTデータやセッションデータ管理などに用いられる。
また、DynamoDBのTime-to-Live（TTL）メカニズムにより、アプリケーションのWebセッションを簡単に管理できる。
主キーでインデックス付けされた構造化データを格納することができる。
それにより、1バイトから最大400KBまでの範囲の項目への低レイテンシーの読み取りおよび書き込みアクセスが可能であり、メタデータの保存に最適。
DynamoDBにAuto Scalingを設定することで、一時的な負荷に対して処理性能をスケーリングすることで高負荷に対応することができる。
ファイルロックはできない。S3内のデータを解析することはできない。
高可用性リレーショナルデータベースという要件には合致しない。リードレプリカはない。
DynamoDBをマルチAZ構成で起動する機能はない。ALBのアクセスログをDynamoDBに配信するように設定することはできない。
・DynamoDB Accelerator (DAX)
DynamoDBテーブルに対してキャッシュレイヤーを前面に構成することで、高速なデータ処理を可能にする。
有効化することで、1 秒あたりのリクエスト数が数百万件になる処理に対しても、
ミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現する。
・DynamoDB Auto Scaling
DynamoDBにAuto Scalingを設定することで、一時的な負荷に対して処理性能をスケーリングすることで高負荷に対応することができる。
・DynamoDB ストリーム
DynamoDB テーブル内の変更を取得し、最大 24 時間ログに保存する。これをモニタリングすることで、変更管理を実施できる。
DynamoDBストリーム自体はモニタリングをするための機能ではない。
あくまでも変更情報をキャプチャして、その情報を別で利用するという使い方をする。
過去２４時間以内にそのテーブルのデータに対して行われた変更のストリームすべてにアクセス可能で、
２４時間経過したストリームデータは削除される。
例えば、ユーザーがデータを DynamoDBテーブルに追加した際に、このイベントを起点にして、
データ管理者にメールを送信してDynamoDBの変更を通知するといった機能を作ることができる。
Lambda関数は最大512MBまでのデータ容量を扱うことができる。
・DynamoDB グローバルセカンダリインデックス
クエリ処理の柔軟性を高めるための機能。
・EBS DeleteOnTermination属性
インスタンスを停止すると、EC2 は接続されていた各 EBS ボリュームの DeleteOnTermination 属性 を使用して、ボリュームを存続させるべきか、削除すべきかを判断する。デフォルトでは、インスタンスのルートボリュームの DeleteOnTermination 属性が有効化されており、EC２インスタンスの削除とともにEBSも削除されるが、その他のボリュームタイプではDeleteOnTermination 属性は非有効化されています。インスタンスが停止してもルートボリュームを維持したい場合は、ルートボリュームの DeleteOnTermination 属性を非有効化することが必要。それによって、インスタンス削除後にデータを存続させることが可能。
・EBS Multi-Attach
基本的にEBSは複数のEC2インスタンスにアタッチすることができないストレージタイプだったが、2020年2月よりMulti-Attach 機能が追加された。
Amazon EBS プロビジョンド IOPS io1またはio2 ボリュームを利用している場合のみMulti-Attach を有効化して、
単一のボリュームを同じアベイラビリティーゾーン内の最大 16 個のAWS NitroシステムベースのEC2インスタンスに同時にアタッチできる。
Multi-Attach を使用すると、複数のライターからのストレージの一貫性を管理するアプリケーションの可用性を簡単に高めることができる。
アタッチされた各インスタンスには、共有ボリュームに対する完全な読み込み／書き込み権限がある。
マルチアタッチを使用するアプリケーションは、ストレージの一貫性のために IO フェンスを提供する必要がある。
・EBS RAID0構成
単一のボリュームよりも高い I/O性能を実現するため、RAID 0 では複数のボリュームをまとめてストライピング構成が実施できる。
ボリュームを追加すると、スループットと IOPS を追加することになり、スループットが向上する。
・EBS RAID1構成
耐障害性が I/O パフォーマンスより重要な場合に利用されるストレージ構成。
１つのEBSボリュームが故障したとしてもデータの消失を防ぐことができ、RTO1分以内の回復が可能。
EBSはインスタンスでの冗長性確保のため、RAID1では 2 つのボリュームを同時にミラーリングできる。
EBSボリュームのデータは、同じアベイラビリティーゾーン内の複数のサーバーにレプリケートされる。
これは、コンポーネントの 1 つに障害が発生したことが原因でデータが失われるのを防ぐためである。
このレプリケーションにより、一般的なコモディティディスクドライブに比べてEBS ボリュームの信頼性は10 倍に高まる。
・EBS スナップショット
EBSスナップショットはリージョンを跨いでコピーすることができる。
スナップショットは増分バックアップである。つまり、最後にスナップショットを作成した時点から、
ボリューム上で変更のあるブロックだけが保存される。
また、スナップショットは取得開始時点のデータを取得する。そのため取得中に変更した内容はスナップショットに反映されない。
EBSスナップショットは、Amazon S3内に保存される。
・EBS ボリュームの種類
プロビジョンドIOPS SSD
→ コストは最も高いが、スループットとIO性能が最も高いボリューム。
プロビジョンドIOPSボリュームの一部は複数のEC2インスタンスにアタッチするマルチアタッチが利用可能。
スループット最適化 HDD
→ 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストのHDD。
汎用 SSD
→ さまざまなワークロードに対応できるコスト効率の高いストレージ。
同じAZ内のインスタンスにのみアタッチできる。別のAZのEBSにはアタッチできない。
コールド HDD
→ アクセスの頻度の低いデータをサポートするように設計されている。
・EC2インスタンスタイプ
メモリー最適化インスタンス
→ メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されている。
ストレージ最適化インスタンス
→ ストレージ最適化インスタンスは、ローカルストレージの大規模データセットに対する高いシーケンシャル読み取りおよび書き込みアクセスを
必要とするワークロード用に設計されている。ストレージ最適化インスタンスは、数万回の低レイテンシーとランダム I/O オペレーション/秒 (IOPS) を
アプリケーションに提供するように最適化されている。
コンピューティング最適化インスタンス
→ 高パフォーマンスプロセッサの恩恵を受けるコンピューティングバウンドなアプリケーションに最適。
このファミリーに属するインスタンスは、バッチ処理ワークロード、メディアトランスコード、高性能ウェブサーバー、
ハイパフォーマンスウェブサーバー、ハイパフォーマンスコンピューティング (HPC)、科学モデリング、専用ゲームサーバーおよび広告サーバーエンジン、機械学習推論などのコンピューティング負荷の高いアプリケーションに最適。
汎用インスタンス
→ バランスの取れたコンピューティング、メモリ、ネットワークのリソースを提供し、多様なワークロードに使用できる。
汎用インスタンスは、ウェブサーバーやコードリポジトリなど、インスタンスのリソースを同じ割合で使用するアプリケーションに最適。
高速コンピューティングインスタンス
AI機能にはGPUを利用することが最適である。GPUを選択するには高速コンピューティングインスタンスを利用する。
高速コンピューティングインスタンスはハードウェアアクセラレーター を使用して、浮動小数点計算、グラフィックス処理、データパターン照合などの
機能を、CPU で実行中のソフトウェアよりも効率的に実行する。ゲーミング処理やグラフィック処理、機械学習の処理にはこのインスタンスが最適。
リザーブドインスタンス
→ 「１年間」「３年間」と期間を決めてEC2インスタンスを「Reserved(予約)」する事で通常にEC2インスタンスを立ち上げるよりも
格安にインスタンスを使うことができる。
負荷が常時一定で、リソースの増強が不要（インスタンスタイプを変更する可能性が低い）な場合に適している。
リザーブドインスタンス（スタンダード）
→ 途中でインスタンスファミリー／OS ／テナンシー／支払オプショ ンの変更が不可能。
リザーブドインスタンス（コンバーティブル）
→ インスタンスファミリー／OS ／テナンシー／支払オプショ ンの変更が可能。
コンバーティブルのみで変更可能な内容は以下の通り。
– インスタンスファミリー
– OS
– テナンシー
– 支払オプション
スケジュールドリザーブドインスタンス
→ 日次、週次、月次と３パターンのスケジューリングされた買い方ができる。
月一回だけバッチ処理で利用したいなどの要望に利用できる。
スケジュールドリザーブドインスタンスは今後AWSで使用できなくなり、代わりに「オンデマンドキャパシティー予約」を使用することが求められる。
オンデマンドインスタンス
→ 利用時間に応じて、決められた料金を支払う通常のインスタンス利用形態。
スポットインスタンス
→ オンデマンド価格より低価で利用できる未使用の EC2 インスタンス。スポットインスタンス では未使用の EC2 インスタンスを
割引で購入できるため、Amazon EC2 のコストを大幅に削減できる｡
AWS の予備リソースを使用して起動でき、リソース状況によっては中断されてしまう可能性のある購入オプション。
一方でオンデマンドインスタンスと比較し、最大 90% オフの節約が可能。また、今回のアプリケーションのように、
単独で実行される（ステートレス）かつ、停止した場合でも再実行で整合性を保証できる（フォールトトレラント）、
柔軟性の高いアプリケーションに適している。
Dedicated Host dedicate = 専用
→ 物理的にサーバーを占有するインスタンスタイプ。ユーザーはライセンス条項の範囲で、
ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できる。
IAMユーザーやIAMグループが同じAWSアカウントに属していたとしても、
権限が異なる別のIAMユーザーやIAMグループとは物理サーバーを共有しない。
ハードウェア専有インスタンス
→ ホストハードウェアのレベルで、他のAWSアカウントに属するインスタンスから物理的に分離するが、
同じAWSアカウントのインスタンスとはハードウェアを共有する可能性がある。
ベアメタルインスタンス
→ アプリケーションの基盤となるサーバーのプロ セッサーとメモリーに直接アクセス可能なインスタンス。
通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなどにアクセスが可能となる。
これにより、ユーザーは詳細なパフォーマンス分析ツールを利用するアプリケーションや、ベアメタルのインフラストラクチャへの
直接アクセスを必要とする特殊なワークロード、仮想環境ではサポートされないレガシーのワークロード、
そしてライセンス制限のあるティア1のビジネスクリティカルなアプリケーションを動かすことができる。
・EC2 インスタンスの種類
起動構成は作成後に変更不可。
A1 インスタンス
→ 汎用インスタンスの１つ。旧世代のインスタンスタイプ。
アウト型のArmベースのワークロードに最適なインスタンスタイプであり、大幅なコスト削減を実現できる。
ビッグデータ処理向けのインスタンスではない。
T3 インスタンス
→ 汎用インスタンスの１つ。ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、
いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えている。これもビッグデータ処理向けのインスタンスではない。
クラスタープレイスメントグループによる設定ができないインスタンスタイプ。
M5 インスタンス
→ 汎用インスタンスの１つ。このファミリーは、バランスの取れたコンピューティング、メモリ、およびネットワークのリソースを提供し、
多くのアプリケーションに適している。これもビッグデータ処理向けのインスタンスではない。
R5 インスタンス
→ メモリバウンドのワークロードに最適なインスタンスタイプ。
優れたネットワークスループットおよびパケット率パフォーマンスを活用できるアプリケーションにおいて理想的なインスタンス。
このインスタンスは、高パフォーマンスデータベース、ウェブ規模の分散型インメモリキャッシュ、中規模インメモリデータベース、
リアルタイムビッグデータ分析、その他のエンタープライズアプリケーションなどに利用する。
したがって、ビッグデータデータセットをリアルタイムで処理するワークロードに最適なインスタンス。
I3 インスタンス
→ ストレージ最適化インスタンスの一つ。ストレージ最適化インスタンスは、数万回の低レイテンシーとランダム I/O オペレーション/秒 (IOPS) を
アプリケーションに提供するように最適化されている。その中でも I3 は、NoSQL データベース や リレーショナルデータベース、
高頻度オンライントランザクション処理 (OLTP) システムなどが利用用途として推奨されている。
・EC2 インスタンスの多数起動
効率的にEC2インスタンスを多数起動させるためには、ブートストラップとゴールデンイメージの活用が求められる。
ブートストラップ（ユーザーデータの利用）
→ Amazon EC2インスタンスをAWSリソースを起動するとき、ユーザーデータを利用してBashシェルスクリプトを利用して
自動で設定を反映することができる。これを利用して、ソフトウェアをインストールしたり、データをコピーしておいたりと
インスタンスの設定を自動化することができる。
ゴールデンイメージ（既存のリソースのスナップショット）
→ Amazon EC2インスタンス、Amazon RDS DBインスタンス、Amazon EBSボリュームなどの特定のAWSリソースタイプにおいて
ユーザーにとって最適な状態を保持することをゴールデンイメージと呼ぶ。ブートストラップアプローチと比較すると、
ゴールデンイメージは起動時間を短縮し、構成サービスまたはサードパーティのリポジトリへの依存関係を削除する。
これは、需要の変化への応答として追加のリソースを迅速かつ確実に起動できるようにする自動スケーリング環境で重要。
・EC2 DisableApiTermination属性
インスタンスの削除保護を有効にできる。デフォルトでは、インスタンスの削除保護は無効になっている。
・EC2 インスタンスストア
インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュなど) の一時ストレージに最適。無料。
EC2で利用される一部のインスタンスタイプはインスタンスストアと呼ばれる直接接続されたブロックデバイスストレージを利用する。
インスタンスストアのボリュームに格納されているデータは、インスタンスの停止、終了、またはハードウェアの障害によって永続化されないため、
インスタンスストアは一時記憶に利用される。
一方で、一時的ではないデータ保存の場合、またはデータを暗号化したい場合はEBSボリュームを使用することが必要。
EBSボリュームはインスタンスが停止してもデータを保持することができ、EBSスナップショットで容易にバックアップし、
暗号化を実施することができる。
・EC2 インスタンスフローログ
有効化することで、ネットワークのトラフィックログをCloudWatchで取得することができる。
・EC2 キーペア
EC2 は安全にインスタンスにログインするため、公開鍵（パブリックキー）と秘密鍵（プライベートキー）のキーペアによる接続を提供する。
EC2は公開鍵暗号を使用して、ログイン情報の暗号化と復号を行う。公開鍵暗号は公開鍵を使用してデータを暗号化し、
受信者は秘密鍵を使用してデータを復号する。この場合、パスワードの代わりに秘密鍵を使用して、安全にEC2インスタンスにアクセスできる。
インスタンスを作成するときに関連付けるキーペアを指定する。このとき、既存のキーペアまたは起動時に作成する新しいキーペアを指定できる。
なお、公開鍵は~/.ssh/authorized_keys内に配置される。インスタンスにログインするには、インスタンスに接続する際に秘密鍵を指定する必要がある。
・EC2 ユーザーデータ
EC2でインスタンスを設定時にユーザーデータを設定することで、インスタンス起動時にスクリプトを実行できる。AWSではシェルスクリプトと cloud-init ディレクティブという2 つのタイプのユーザーデータをEC2に渡すことができる。また、このデータはプレーンテキスト、ファイルまたは base64 でエンコードされたテキスト (API コールの場合) として、起動ウィザードに渡すこともできる。
・EFS IA(低頻度アクセスストレージクラス)
毎日アクセスしないファイルに対して最適化されたコスト効率の料金/パフォーマンスを提供する。
ファイルシステムでEFSライフサイクル管理を有効にするだけで、選択したライフサイクルポリシーに従ってアクセスしないファイルは、
自動的かつ透過的にEFS IAに移されます。EFS IAストレージクラスの費用は、たったの 0.025 USD/GB-月。
・EFS 設定
汎用モード
→ ファイルシステムオペレーション単位で最小レイテンシーを実現するだけでなく、
ランダムまたはシーケンシャル IO パターンでも同じ結果を得ることができる。
最大 I/O モード
→ ファイルオペレーションのレイテンシーがわずかに長くなる代わりに、
より高いレベルの集計スループットと 1 秒あたりの操作にスケールできる。
バーストスループットモード
→ EFSでは突然アクセスが増加するケースにはバーストスループットモードを選択する。バーストスループットモードではスループットが
ファイルシステムのサイズに合わせてスケールされ、ファイルベースの多数のワークロードの不規則な性質に対応するために、
必要に応じて動的にバーストされる。これによって、EFSは一時的な高負荷に対応できるパフォーマンスを発揮することができる。
プロビジョンドスループットモード
→ デフォルトのバーストモードより高い専用スループットを必要とするアプリケーションをサポートするように設計されており、
ファイルシステムに格納されているデータの量とは関係なく設定することができる。
・ElastiCache Redis
Redisはpub/sub機能を提供し、シングルスレッドで動作するインメモリキャッシュDBであり、全てのデータ操作は排他的。
複雑なデータ型を設定できる。
インメモリデータセットのソートまたはランク付けが可能である。
データをリードレプリカにレプリケートできる。
pub/sub機能を提供する。
自動的なフェイルオーバーができる
キーストアの永続性が必要である。
バックアップと復元の機能がある。
・ElastiCache Memcached
マルチスレッドであるため、複数の処理コアを使用できる。
これは、コンピューティング性能をスケールアップすることで、より多くの操作を処理できることを意味する。
複数のコアまたはスレッドを持つ大きなノードを実行する。
システムでの需要の増減に応じてノードを追加または削除するスケールアウトおよびスケールイン機能が利用できる。
データベースなどのオブジェクトをキャッシュできる。
キーストアの永続性はない。
バックアップと復元の機能がない。
複数のデータベースを利用できない。
複数のデータベースをサポートしている。
・Elastic IP
リージョンあたり5つのElastic IP アドレスに制限されている。
次の条件が満たされている限り、Elastic IP アドレスに料金は発生しない。
– Elastic IP アドレスが EC2 インスタンスに関連付けられている。
– Elastic IP アドレスに関連付けられているインスタンスが実行中である。
– インスタンスに 1 つの Elastic IP アドレスしか添付されていない。
・IAMユーザー (Identity and Access Management)
AWSを利用するアカウント。
IAMユーザは、デフォルトで全ての権限が付与されていない。AWSが定める責任モデルに基づき、適切に権限を付与する必要がある。
AWS管理者はロールやポリシーを作成してIAMユーザに割り当てることでアクセス権を付与することができる。
・IAMロール
ユーザーやグループでなく、EC2などのAWSサービスや他のアカウントに対してAWSの操作権限を付与するための仕組み。
・IAMポリシー
IAMユーザーやIAMロールにアタッチすることができる。
AWSリソースへの操作権限を設定する機能。
・IAMポリシータイプ
AWS管理ポリシー
→ AWS が作成および管理するスタンドアロンポリシー。スタンドアロンポリシーとは、ポリシー名を含む独自の Amazon リソースネーム (ARN) の
付いたポリシーのこと。AWS 管理ポリシーは、多くの一般的ユースケースでアクセス許可を提供できるように設計されており、
管理者権限ポリシーを付与したIAMユーザーによってIAM管理権限が利用される。通常IAMポリシーを設定する際に、
AWS 管理ポリシーが既にある場合は、それを利用することが推奨されている。
管理者権限ポリシーはAWS管理ポリシーとして用意されているため、それを利用することが優先される。
インラインポリシー
→ 1 つのプリンシパルエンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシー。
これはプリンシパルエンティティに固有。プリンシパルエンティティの作成時、またはそれ以降で、ポリシーを作成して
プリンシパルエンティティに埋め込むことができる。
通常、インラインポリシーではなく、管理ポリシーを使用することが推奨されており、これを利用することは適切ではない。
カスタマー管理ポリシー
→ ユーザーの AWS アカウントで管理できるスタンドアロンのポリシーとなる。
これによって管理者権限を利用することも可能だが、管理者権限ポリシーはAWS管理ポリシーとして用意されているため、
それを利用することが優先される。
・IAM Access Analyzer
外部エンティティと共有されている Amazon S3 バケットや IAM ロールなど、組織とアカウントのリソースを識別する。
これにより、S3の外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認することができる。
・IAM アクセスレベル
IAMを利用して最適なセキュリティ上のベストプラクティスに沿うためにはアクセスレベルを使用して、IAM 権限を確認することが必要。
・IAM クロスアカウントアクセス
AWSのIT ガバナンス(企業のIT資産の監視・規律を守る仕組み）を提供し、一括請求を使用して部門アカウントを
親企業のマスターアカウントにリンクすることで、コストの監視が可能。
・IAM データベース認証
IAM データベース認証は MySQL および PostgreSQL で動作する。
この認証方法では、DB インスタンスに接続するときにパスワードの代わりに認証トークンを使用する。
認証トークンは、有効期間が15分でありAWS 署名バージョン 4 を使用して生成される。
認証は IAM を使用されるため、ユーザー認証情報をデータベースに保存する必要はない。
・IAM パスワードポリシー
パスワードの長さや複雑さなどを強制するためのパスワードポリシーを定義できる（すべてのユーザーに適用）。
パスワードを変更する機能を制限するIAMポリシーをユーザーを含むグループにアタッチする必要がある。
・Lambda Layer
複数のLambda関数でライブラリを共有できる仕組みであり、一定の機能をLayerとしてまとめて利用することができる。
これまでは同じライブラリを利用する関数が複数あった場合、全ての関数に対してライブラリを含めてパッケージングすることが必要だった。
それを、ライブラリをLayerとしてアップロードしておくことで、個々の関数は共通のLayerを使用することができる。
・Lambda エッジ
サーバー管理を行わなくても、ウェブアプリケーションをグローバルに分散させ、パフォーマンスを向上させることができる。
・Invocation
Lambda関数の名前空間にあるメトリクス。
イベントまたはAPI呼び出しに応じて呼び出される関数の回数を測定する。
・NATゲートウェイ(NAT = Network Address Translation)
VPC内に構成した「プライベートサブネット」からインターネットに接続するためのゲートウェイ。
プライベートサブネットのインスタンスからインターネットに接続するためのアドレス変換を実施するルーティングサービス。
NATインスタンスをNATゲートウェイへと変換することで、容易にパフォーマンスを向上し、
ボトルネックを解消できる。プライベートサプネットにあるEC2インスタンスへのアクセスに利用する。
NATゲートウェイは、パブリックサブネットに設置して、プライベートサブネットのルートテーブルに設定するべきもの。
サイト間接続には利用できない。
・Oracle RMAN
Oracle が作成したOracleデータベース用に提供されるバックアップおよびリカバリマネージャ。
データベースのバックアップ、復元、および回復機能を提供し、高可用性と災害復旧の懸念に対処する。
これを利用すればOracleデータベースのバックアップは自動化することができる。
AWSではRMANを利用したバックアップ設定は可能だが、RDSはDBインスタンスへのシェルアクセスを提供していない。
また、高度な特権を必要とする特定のシステムプロシージャやテーブルへのアクセスを制限している。
・OU(Organizations Unit)
アカウントをまとめてグループ化し、単一のユニットとして管理できる。
・Principal
AWSに認証されたユーザーやサービス、 アカウントのこと。AWSに特定のアクションの実行をリクエストできる。
システムのアクセス許可を割り当てて、データベースが認証できるようにする対象（ユーザーやサーバー、アプリケーションなど）を意味する。
・RAID0
複数のディスクを1台のディスクのように扱い、読み書きを高速化する。
・RAID1
ミラーリング構成とすることで、冗長性、及び耐障害性を提供することができる。
・RDS for Oracle
Oracleデータベースのデプロイメントのセットアップ、運用、スケーリングを容易にする完全マネージド型の商用データベース。
RDSにオラクルデータベースタイプのインスタンスを起動して、マルチAZ構成を実現することで、
データベースサーバーに障害が発生した場合でもWebサイトの可用性を高めることが可能。
・RDS IAM DB認証
RDSユーザーやEC２インスタンスへのアクセスを実施するEC２インスタンスなどはIAM ユーザーまたはIAMロールの認証情報と認証トークンを使用して、RDS DB インスタンスまたはクラスターに接続することができる。
これはRDSインスタンスの作成時に「Enable IAM DB Authentication」= IAMのDB認証を有効化することで利用できる。
・RDS オートスケーリング
データ容量が不足した際にストレージ容量を自動でスケーリングする機能。
・RDS プロキシ
必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑える機能。
アプリケーションとRDSデータベースの間の仲介役として機能する。
Lambda関数はRDSエンドポイントではなくRDSプロキシを利用して接続することが求められる。
RDSプロキシはLambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングする。
これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、
既存のコネクションを再利用できる。 RDSプロキシを利用せず、エンドポイントを利用すると
Lambda関数によってコネクションが多数発生して処理が上手くいかなくなってしまう。
・RDS マルチAZ
DB インスタンスの高可用性およびフェイルオーバーサポートを提供する。RDS コンソールを使用すると、
DB インスタンスを作成する際にマルチAZを有効化するだけでマルチAZ配置を作成できる。
コンソールを使用し、DB インスタンスを変更してマルチAZオプションを指定することで、既存の DB インスタンスをマルチAZ配置に変換できる。
AWS CLIまたはAmazon RDS APIを使用してマルチAZ配置を指定することもできる。
Route53を利用したフェールオーバー構成によって、マルチリージョンな構成も可能だが、AZ障害への対応にはマルチAZ構成で十分。
マルチリージョン構成は２つのリージョンを利用して、スタンバイしているアプリケーション構成へとフェールオーバーを設定する構成になる。
リージョンそのものの災害対応に利用するものであり、単一AZ障害に利用するために設定するものではなく、またコスト効率も悪いため、
AZ障害対応には不適切な対応。
マルチAZ構成は一方のAZのRDSが停止した際にもう一方のRDS DBに移行することが出来るという冗長化構成であり、
読み取り速度の性能が向上することはない。
・RDSリードレプリカ
データベース（DB）インスタンスのパフォーマンスと耐久性を強化する。この機能により、読み取りが多いデータベースワークロードの場合、
単一のDBインスタンスの容量の制約を超えて柔軟にスケールアウトできる。既存のDBインスタンスに対してRDSマネジメントコンソール画面から
容易に追加することが可能。
・Redshift WLM(Work Load Management)
クエリ処理を実施する際に、照会内容をキューに経路指定することが可能。
WLMはRedshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定する機能。
事前にWLMとしてキューを用意しておき、キューに対して割り当てるメモリの割合や並列度、
タイムアウトの時間を指定することでクエリに対するリソース配分を決定したり、
長時間実行されるクエリを止めてクラスタリソースを無駄遣いしないようにすることができる。
・Redshift 拡張VPC ルーティング
クラスターとデータリポジトリ間のすべてのCOPYとUNLOADトラフィックが VPCを通るよう強制できる。
これにより、VPC セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、VPC エンドポイント、VPC エンドポイントポリシー、
インターネットゲートウェイ、ドメインネームシステム (DNS) サーバーなどのVPCの機能をRedshiftで使用することができる。
これらの機能を使用して、Redshift クラスターと他のリソースの間のデータフローを詳細に管理できるようになり、
VPCフローログを使ってCOPYとUNLOADトラフィックを監視することができる。
・Redshiftクラスター クロスリージョンスナップショット
プライマリクラスターがダウンした場合に備えて即座に利用できる構成を維持することができる。
クラスターのスナップショットを自動的に別のリージョンにコピーするように Amazon Redshift を設定できる。
RedshiftはマルチAZに対応していないため。
・Route53 DR環境の方式
コールドスタンバイ
→ Amazon S3をバックアップデータの格納先として利用する。事前にシステムイメージをクラウド上に準備。
災害発生時にクラウド上のシステムを起動し、Route53で切り替えることで復旧する。
投資コストを抑えられ、手軽に始めることができる。
ウォームスタンバイ
→ クラウドのスタンバイ環境にデータを常時レプリケーションする。
通常は、スタンバイ環境を最少構成で稼働させ、災害発生時は必要なキャパシティに変更します。
スタンバイ環境の運用が常時必要になるが、Route53でシステム切り替えを素早く実行することができる。
・Route53 バイアス
バイアスという値を指定することで、特定のリソースにルーティングするトラフィックの量を変更できる。
・Route53 パブリックホストゾーン
インターネット上に公開されたDNSドメインレコードを管理するコンテナのこと。
ここにはexample.comなどのドメインのトラフィックをインターネットまたは特定のドメインでルーティングする情報を保持している。
・Route53 プライベートホストゾーン
VPC同士が相互アクセス可能であればリージョンの異なるVPCでも、同じホストゾーンを利用可能。
プライベートサブネット内にあるドメインをルーティングすることが可能。
・Route53 ヘルスチェック
Route53のヘルスチェック機能を使うことで、EC2の状態をチェックして異常が検知された場合には対象のインスタンスに
アクセスを振り分けないようにすることができる（フェイルオーバー）。
・Route53 ルーティング設定
シンプル
→ ドメインで特定の機能を実行する単一のリソースがある場合に使用する。シンプルルーティングではトラフィックを複数インスタンスなどに分散してルーティングして、ランダムに制御される。
加重ルーティング
→ 単一のドメイン名 (example.com) またはサブドメイン名 (acme.example.com) に複数のリソースを関連付け、各リソースにルーティングされるトラフィックの数を選択できる。これは負荷分散や新しいバージョンのソフトウェアのテストなど、さまざまな目的に有用。
レイテンシールーティング（遅延ルーティング）
→ 複数の AWSリージョンでアプリケーションがホストされている場合、
ネットワークレイテンシーが最も低いAWS リージョンに基づいてリクエストを処理することで、
ユーザーのパフォーマンスを向上させることができる。
レイテンシーの最も小さいリソースにトラフィックをルーティングする場合に使用する。
フェイルオーバールーティング
フェイルオーバーによって異常なリソースへのルーティングを停止して、正常なリソースに対してトラフィックをルーティングすることができます。
フェールオーバーによる可用性が高めることができるが、最適なパフォーマンスを達成するわけではない。
位置情報ルーティングポリシー
→ ユーザーの位置情報、つまりDNSクエリの発信位置に基づいてトラフィックを処理するリソースを選択できる。
コンテンツをローカライズして、ユーザーの言語でウェブサイトの一部またはすべてを表示できる。
位置情報ルーティングはDNSとIPアドレスの位置情報に基づいてルーティングするため、
リソースの近さに基づいてルーティングする設定ではない。例えば、ドイツの位置情報にいるユーザーに対してはドイツ語を表示するように
ドメインを構成するといったり、位置情報に応じた表示変更やサーバー設定などが可能となる。
これは処理能力に基づいたルーティングではない。
地理的近接性ルーティングポリシー
→ CloudFrontのリソースをユーザー近くのリソースにルーティングするためには地理的近接性ルーティングポリシーを利用して、
リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをリソースから別の場所のリソースに移動するように構成する。 Amazon Route 53 はユーザーとリソースの地理的場所に基づいてリソースのトラフィックをルーティングする。
マルチバリュー(複数値回答)ルーティングポリシー
→ Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できる。
複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースに値のみを返すことができる。
したがって、EC2インスタンス単位での正常・非正常を判断してルーティングすることができる。
これはロードバランサーに置き換わるものではないが、Route53が設定したインスタンスのトラフィックが正常であることを
ヘルスチェックした上で複数の IP アドレスを返すことができ、DNS を使用してアベイラビリティーとロードバランシングを向上させることができる。
ランダムに選ばれた最大 8 つの正常なレコードを使用してDNS クエリに応答することができる。
・Route53レコード
標準のDNSレコードを使用する。
CloudFrontなどのAWSリソースを構築する場合は、ALIASレコードを利用することが必要。
・ALIASレコード
ELBやCloudFrontなどのエンドポイントをドメインに関連付けることができるレコード。
・CNAMEレコード
ドメイン名から別のドメイン名を参照するレコード。
ドメインを別のドメインに関連付けるにはCNAMEレコードを利用する。
CNAMEレコードは別名に対する正式名を指定するためのリソースレコード。
ホスト名には、正式名以外に、別名を付けることができる。DNSの名前解決では、CNAMEリソースレコードが見つかった場合、
ドメイン名を正式名に置き換えて名前解決を継続する。したがって、CNAMEレコードを使用して名前を別の名前にマッピングできる。
・Aレコード
ドメインまたはサブドメインをIPアドレスに紐づけるために利用する。
ドメイン名を切り替える設定の場合はAレコード上でドメイン設定を切り替えることでも対応可能だが、
ドメインとドメインの関連付けには利用できない。
・AAAAレコード
DNSで定義されるそのドメインについての情報の種類の一つで、特定のホスト名に対応するIPv6アドレスを定義するレコード。
・NSレコード
DNSで定義されるそのドメインについての情報の種類の一つで、ドメインのゾーン情報を管理するDNSサーバを定義するレコード。
・MXレコード
対象ドメイン宛のメール配送先ホスト名を定義するレコード。
・S3 Standard
S3の中で最もコストが高い頻繁に利用するデータ向けのストレージ。
・S3 Standard – IA (Infrequent Access) infrequent = 稀な
アクセスが頻繁でないデータをコストを抑えて保存するのに最適なストレージ。
One Zoneと似た特徴を持つ。保存するデータの重要度が高い場合に使用する。
・S3 One Zone – IA (Infrequent Access)
アクセスが頻繁でないデータをコストを抑えて保存するのに最適なストレージ。
Standard IAとは異なり複数AZにオブジェクトを分散しないため可用性が低い、値段が安いストレージタイプ。
したがって、重要ではないデータを保存するのに利用するべきもの。
耐久性を提供しない。
・Glacier (迅速読取)
コストは安いが迅速読取といえど、アクセスに数分要するので、即時対応には向かない。
・S3 Access Analyzer
AWSアカウントの外部からアクセスできるリソースを特定する総合的な解析結果を生成する。
・S3 ACL (Access Control List)
バケットとオブジェクトへのアクセスを管理することができます。
Amazon S3の各バケットとオブジェクトには、サブリソースとして ACL がアタッチされている。
リソースに対するリクエストを受信すると、Amazon S3 は該当する ACL を調べて、必要なアクセス許可がリクエスタにあることを確認する。
・S3 CORS(Cross-Origin Resource Sharing)
既にドメインが設定されているS3バケットを他のドメインに共有することが可能となる。
CORSは特定のドメインにロードされたクライアントウェブアプリケーションが異なるドメイン内のリソースと通信する方法を定義する。
これによって、S3を使用して機能豊富なクライアント側ウェブアプリケーションを構築し、S3リソースに対するクロスオリジンアクセスを
選択的に許可することができる。
・S3 Effect エレメント
Allow = 許可、 Deny = 拒否
・S3 Intelligent-Tiering
アクセスパターンが変化したときに 4 つのアクセス階層の間でオブジェクトを移動することで、
自動的にコストを削減する唯一のクラウドストレージクラス。保存するデータが予測不能なアクセスパターンを持っている場合は、
S3 Intelligent-Tieringを利用することで最適なストレージ利用を自動化することができる。
・S3 MFA Delete
有効にすると削除時に追加認証を求められるようにすることができ、誤削除を予防できる。
・S3 Select
オブジェクトからデータの一部分のみを取り出すことができる。
S3 Selectを利用すれば、クエリ (query-in-place) サービスを使用して、S3 オブジェクト (および AWS の他のデータセット) 全体に対してデータ分析を
実行する。S3 Select はオブジェクト全体ではなくオブジェクトデータのサブセットを取得することで、
クエリのパフォーマンスを最大 400% 向上させることもできる。
・S3 Transfer Acceleration
クライアントへの長距離にわたるファイル転送を高速、簡単、安全に行えるようになる。
Transfer Accelerationは、CloudFrontの世界中に分散したエッジロケーションを利用している。
エッジロケーションに到着したデータは、最適化されたネットワークパスでS3にルーティングされる。
これによりグローバルに効果的なファイル転送が可能となる。
・S3 アクセスポイント
S3の共有データセットへの大規模なデータアクセスの管理を簡素化する機能。
アクセスポイントは、バケットにアタッチされた名前付きのネットワークエンドポイントで、
S3 オブジェクトのオペレーション (GetObject や PutObject など) を実行するために使用できる。
各アクセスポイントは基になるバケットにアタッチされたバケットポリシーと連動して機能するカスタマイズされた
アクセスポイントポリシーを適用してアクセスを制御することが可能。
・S3 クロスリージョンレプリケーション
DR 対策として有効。複数リージョンに冗長化する際に利用する。
レプリケーション設定の要件として、レプリケート元及びレプリケーション先でバージョニング設定を有効化する必要がある。
アップロードとは無関係。
・S3 サーバーアクセスログ
バケットに対するリクエストの詳細が記録される。
・S3 事前署名付きURL
URLの有効期限内での特定プロジェクトの共有ができる。これはアクセス制御全般を実施するのではなく、オブジェクトの制限付き共有で利用するもの。
・S3 ストレージクラス分析
ストレージアクセスパターンを分析し、適切なデータをいつ適切なストレージクラスに移行すべきかを判断できる。
・S3 静的WEBホスティング
HTMLオブジェクトにアクセスする際にオブジェクトの読み取りアクセス許可が付与されていない場合は、
ウェブサイトエンドポイントから HTTP レスポンスコード 403 (Access Denied) が返される。
静的WEBホスティングを利用するためには、S3静的ウェブホスティング機能を有効化する。
次にIndex.htmlを設定することでWEBサイトの設定が完了する。しかしながら、加えてインターネットからのアクセスが許可される
アクセス管理設定が必要となる。したがって、パブリックアクセスブロックの無効化することと、バケットポリシーの設定により、
インターネットからのバケットへのs3:GetObject を設定する必要がある。
xxxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com
・S3 バージョニング
同じバケット内でオブジェクトの複数のバリアントを保持する手段。
・S3 バケットポリシー
バケットに対してユーザーアクセス権限を設定するバケットに関するポリシー。
オブジェクト単位でのアクセス権限のコントロールにはACLを利用する。
・S3 パブリックアクセス設定機能
バケットレベルまたはアカウントレベルで、すべてのオブジェクトへのパブリックアクセスをブロックできる。
この機能でブロックを有効化することでS3バケット全体に対してパブリックアクセスを拒否することができる。
・S3 マルチパートアップロード
大容量オブジェクトをいくつかに分けてアップロードできるようになる。
マルチパートアップロードを利用してアップロードできる個々のAmazon S3オブジェクトのサイズの範囲は最小0バイトから最大5テラバイト。
1つのPUT操作でアップロードできる最大オブジェクトは5ギガバイト。
・S3 ライフサイクルポリシー
古くなったファイルを自動的に削除したり、退避することが可能。
・Savings Plans
1年間または3年間にわたって、1時間につき何ドル分AWSを使うという契約を結ぶ代わりに、使用料金が割引になる制度。
・SNS エンドポイント
SNSから送信されるメッセージの受信方法のことを指している。
エンドポイントには、HTTP/HTTPS、AWS Lambda、Eメール、SQS、SMS、モバイルプッシュ通知を利用することができる。
XMLは利用することができない。
・SQS ショートポーリング
キューからのメッセージを処理するプロセスは、ショートポーリング使用するか、ロングポーリングを使用するかによって異なる。
SQS はデフォルトでショートポーリングを使用して、サーバーのサブセットに対して(重み付けされたランダム分散に基づいて) クエリを実行し、
利用できるメッセージがあるかどうかを調べる。
・SQS ロングポーリング
ロングポーリング を使用すると、キューが到着するとすぐにメッセージを受信できるようになる。
・SSE-C (SSE = Server Side Encryption)
ユーザーが管理する鍵により暗号化を実施できる。これにより、S3上に置かれたコンテンツを柔軟に保護できるようになる。
ユーザーが用意した暗号化キーでのSSE-Cを使用すると、独自の暗号化キーを設定できる。
・CSE (Client Side Encryption)
クライント側で暗号キー管理を実施して、鍵をS3にインポートして利用するタイプの暗号化。
AWS SDKなどを利用すればS3に利用可能だが、デフォルト暗号化として用意されたものではない。
・SSE-S3
S3 で管理された暗号化キーにより実施されるサーバーサイド暗号化。ユーザーがキーに対するアクセス管理はできないが、
署名バージョン4によりアクセス制限が設定され、所有者であるAWSアカウントID以外からのアクセスを拒否する。
SSE-S3は暗号化と復号化をS3が自動で実施してくれる。
・SSE-KMS
暗号化キーの管理機能をマネージドサービスで提供してくれる。
そのため、CloudTrailによりアクティビティの証跡ログが取得可能であり、証跡が必要な場合はSSE-KMSを利用する。
SSE-KMSの暗号化キーの指定を失敗すると、暗号化自体の設定が有効化されないため、一部データの暗号化失敗の理由にはならない。
・SCP (Service Control Policy)
AWSの子アカウントのアクセス権を制御することができる。
AWSのマスターアカウント管理者は、サービスコントロールポリシー (SCP) を使用して、組織内のメンバーアカウントのアクセス権限を設定できる。
SCP を使用すると、各メンバーアカウントのユーザーとロールがどの AWS サービスリソースおよび個々の API アクションにアクセスできるかを
制限することができる。AWS Organizations がメンバーアカウントのサービス、リソース、または API アクションへのアクセスをブロックすると、
そのアカウントのユーザーまたはロールはアクセスできない。
このブロックは、メンバーアカウントの管理者が IAM ポリシーで明示的にそのようなアクセス許可をした場合でも有効。
・SQS FIFO(First In, First Out)キュー
オペレーションやイベントの順序が重要である場合、
または重複不可の場合などにアプリケーション間のメッセージングを強化する。
・SQS 標準キュー
標準キューから送られるメッセージはFIFO(First In, First Out)キューと異なり、順序を保証しない。
しかし、厳密ではない FIFO機能が備わっているため、負荷が低い状況の場合はキューにデータが詰められた順番通りにメッセージが配信される。
標準キューの方がFIFOキューよりも優れていない様に感じるが、その分ほぼ無制限のトランザクションをサポートしている。
順序がそれほど大事ではないが、大量のリクエストが送られることが予想される場合は標準キューを利用する。
・SQS デッドレターキュー
正常に処理 (消費) できないメッセージの送信先として他の (ソース) キューが使用できるキュー。
・STS 設定
ウェブ ID フェデレーション
→ カスタムのサインインコードを作成したり、独自のユーザー ID を管理したりする必要がなくなる。その代わりに、アプリのユーザーはGoogleなどの外部 ID プロバイダーを使用してサインインすることができる。認証トークンを受け取ったら、そのトークンを AWS アカウントのリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。IdP を使用すると、アプリケーションで長期的なセキュリティ認証情報を埋め込んで配布する必要がないため、AWS アカウントの安全性の維持に役立ちます。
クロスアカウントアクセス
→ 別のAWSアカウントのリソースへのアクセス許可を設定する方法。
SAML IDフェデレーション
→ IdP を使用するにはIAMのID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立する。
IAM は、OpenID Connect または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートする。
したがって、SAML フェデレーションを使用しても、一時的な AWS セキュリティ認証情報を作成し、AWS リソースへのアクセスを提供することが可能。
ただし、OpenID Connect を利用する場合は、ウェブ ID フェデレーションを利用する。
・TI(Terminate Instances)
インスタンスの削除。
・VPCエンドポイント
PrivateLinkによってサポートされているAWSサービス及びVPCエンドポイント関連のサービスに接続できる。
インターネットを介さずに、VPCのサービスからVPC外のAWSサービスに接続することができる。
トラフィックを制御することはできない。VPCとVPCの接続は提供していない。
プライベートリンク型（インターフェイスエンドポイント）とゲートウェイ型の２種類がある。
・VPCエンドポイント（ゲートウェイ型）
ルートテーブルの指定されたターゲットとなるゲートウェイ。
サポートされる AWS のサービスを宛先とするトラフィックをVPC内外で接続する際に使用する。
S3とDynamoDBに対して使う。
・VPCエンドポイント（インタフェース型）
対象サービスを宛先とするトラフィックのエントリポイントとなるプライベート IP アドレスを持つ Elastic Network Interface。
・VPCピアリング接続
２つのVPC間でプライベートなトラフィックのルーティングを可能にするネットワーキング接続。
どちらのVPCインスタンスも同じネットワーク内に存在しているかのように、相互に通信できる。
VPCピアリング接続はエッジ間ルーティングをサポートしていない。 つまり、ピアリング関係となっているVPCに
次のような接続がある場合に、それらの接続に対してはピアリング関係を拡張することはできない。
– 企業ネットワークへのVPN接続またはAWS Direct Connect接続
– インターネットゲートウェイを介したインターネット接続
– NATデバイスを介したプライベートサブネット内のインターネット接続
– AWSサービス(S3など)へのVPCエンドポイント
– (IPv6)ClassicLink接続。
・VPCフローログ
VPC のネットワークインターフェイスを通過するネットワークトラフィック情報を保存する機能。
フローログデータはCloudWatch Logs と Amazon S3 を使用して保存される。
フローログのデータは、CloudWatch Logs を使用して保存することで、トラフィック情報の表示や異常を監視する。
フローログは、特定のトラフィックがインスタンスに到達していない場合のトラブルシューティングに役立つ。
また、セキュリティツールとしてフローツールを使用し、インスタンスに達しているトラフィックを監視することも可能。
CloudFrontに設定するといった対応はできない。
・VPN (Virtual Private Network)
オンプレミスネットワーク、リモートオフィス、クライアントデバイス、および AWS グローバルネットワーク間に安全な接続を確立する。
・Well-Architected フレームワーク
以下の５つの柱で構成されている。
・運用上の優秀性
・セキュリティ
・信頼性
・パフォーマンスの効率
・コスト最適化
このフレームワークを通じて、アーキテクチャーに関するベストプラクティスを学ぶことができるようになっている。
・カスタマーゲートウェイデバイス
ユーザー側でオンプレミスネットワークで所有または管理している物理アプライアンスまたはソフトウェアアプライアンス。
これをAWS側の仮想プライベートゲートウェイに接続することで、サイト間VPNが接続できるようになる。
・拡張ネットワーキング
EC2インスタンスに対して高いI/Oパフォーマンスと低いCPU使用率を提供できる。
・責任共有モデル
AWSでは、セキュリティに関する方針として責任共有モデルを定義しており、AWSと利用者でセキュリティ対策の責任境界を明確化している。
仮想化を実現する基盤（ハイパーバイザー・ホストOS）の管理・運用は、AWSの責任範囲。
IaaS/PaaS/SaaSなどのサービス形態によっても変わってきますが、最も利用者の責任範囲の広いIaaSの場合、
OSより上のレイヤーは利用者が責任を持ち、OSより下のレイヤーはAWSが責任を持つ。
AWS利用者は、データの管理 (暗号化を含む)、アセットの分類、IAM を利用した適切な権限の適用について責任を負う。
AWSはセキュリティの観点から、データセンターの所在を明らかにしていない。
また、AWSが提供するサービスに脆弱性が発見され、セキュリティパッチを当てなければならないといった場合には、AWSの責任の元、実行される。
大枠の方針としては、AWSが管理する物はAWS側に責任があり、AWSの利用者が独自に追加・保存したリソースの管理責任は利用者側にある。
※例えば情報漏洩が発生した場合、適切なアクセス管理がされていなかった・誰でもアクセスできる様になっていた事が原因であれば
利用者の責任となる。反対に、AWSの脆弱性を突いたハッキングが行われた場合は、AWSの責任となる。
・セキュリティグループ
インスタンスのトラフィックを制御する仕組み。インスタンス単位で設定するファイアウォール。
デフォルトセキュリティグループは同じセキュリティグループ内通信のみ許可する。
セキュリティグループはステートフルという特徴がある。
セキュリティグループは全てのルールを適用する。
URLに基づいてリクエストをフィルタリングすることはできない。
・ネットワークACL
サブネット単位で設定するファイアウォール。
1 つ以上のサブネットのインバウンドトラフィックとアウトバウンドトラフィックを制御するファイアウォールとして動作する、
VPC 用のセキュリティのオプションレイヤー。セキュリティの追加レイヤーを VPC に追加するには、
セキュリティグループと同様のルールを指定したネットワークACLをセットアップできる。
ネットワークACLルールは低い値から高い値にかけて評価され、
一致する許可/拒否ルールが設定されるとすぐに実行される。
上から番号順にルールが適用される。
URLに基づいてリクエストをフィルタリングすることはできない。
ステートレスである。 ステート(state) = 状態
・バックアップ＆リストア
スナップショットやAMIを別リージョンに保持しておくこと。
最もコストがかからないDisaster Recovery対応として利用される。
・フローティングIP
EC2インスタンスにELBやRoute53を構成していると、特定のEC2インスタンスに障害が発生した際に、ダウンタイムを最小にして待機系インスタンスに切り替える。その際にホスト名を待機系のIPアドレスに向け直すと、DNS情報が伝播するまでに一定のダウンタイムが発生する可能性がある。
これを防止するためには、フローティングIPを利用してElastic IPアドレスをフローティングすることで即時に別のEC2インスタンスへとトラフィックを切り替えることができます。障害発生時には稼動系からElastic IPアドレスを外し、待機系インスタンスに割り当て直すことで瞬時にトラフィックの向け先を変更できる。
・プレイスメントグループ
単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したもの。プレイスメントグループを設定すると、
グループで設定されたインスタンス間のネットワーク遅延を最小限に抑えることができる。
設定は同じリージョン内のVPCにまたがって設定することができる。
プレイスメントグループには、「クラスター」「スプレッド」「パーティション」の3つの種類がある。
ネットワーク遅延の最小化、ネットワークスループットの最大化、またはその両方から利点が得られるアプリケーションや、
ネットワークトラフィックの大部分がグループのインスタンス間で発生するような場合、クラスタープレイスメントグループが推奨される。
クラスタープレイスメントグループ
– アベイラビリティーゾーン内でインスタンスをまとめる。この戦略により、ワークロードは、
HPC アプリケーションで典型的な緊密に組み合わされたノード間通信に必要な低レイテンシーネットワークパフォーマンスを実現できる。
– パーティションプレイスメントグループ
インスタンスを複数の論理パーティションに分散させ、1 つのパーティション内のインスタンスのグループが基盤となるハードウェアを
別のパーティション内のインスタンスのグループと共有しないようにする。
この戦略は、Hadoop、Cassandra、Kafka などの大規模な分散および複製ワークロードで一般的に使用される。
スプレッドプレイスメントグループ
– それぞれに独自のネットワークおよび電源がある異なるラックに別々に配置できるインスタンスのグループ。
・ホットスタンバイ
稼働可能な状態となっているインフラを準備し、アクティブにするだけで切り替えることができる
スタンバイ構成のこと。
・ボールト
アーカイブを格納するコンテナ。
・ボールトロック(Vault Lock)
ファイル削除などの変更を禁止し、そもそも消えないという状況を作る。
・リザーブド購入オプション
AWSサービスの中には1年~3年などの一定期間利用を予約することを前提に割引価格で購入可能になるオプションがある。
– EC2リザーブドインスタンス
– RDSリザーブドインスタンス
– ElastiCacheリザーブドノード
– DynamoDBリザーブドキャパシティ
– Redshiftリザーブドノード
終わりに
このパートが文字数が一番多くなりました(^-^;
よく試験に出てくる単語はある程度は固まってきますが、模試などやっていると出くわす単語も書いてあります。
たまに出てきたときなど、この記事を参考いただければと思います。
次回で最後になりまして、AWSのSAA試験に出てくるITの用語編となります。
今までと比較して、そこまでのボリュームにはなりませんので、ご安心を笑
