初めに
緊急事態宣言延長になりました。五冠狙います。
学習
ネットワーク ACL ルール
デフォルトのネットワーク ACL に対してルールの追加または削除を行うことができます。また、VPC に合わせて追加のネットワーク ACL を作成することができます。ネットワーク ACL に対してルールの追加または削除を行うと、変更内容は、その ACL に関連付けられているサブネットに自動的に適用
- ルール番号
- タイプ
- プロトコル
- ポート範囲
- 送信元
- 送信先
- 許可/拒否
Classic Load Balancer のトラブルシューティング
- API エラー
- CertificateNotFound: 未定義
- 原因 1: AWS マネジメントコンソールを使用して証明書が作成されると、すべてのリージョンに伝達される際に遅延が発生します。この遅延が発生すると、ロードバランサーの作成プロセスの最終ステップでエラーメッセージが表示されます。
- 解決方法 1: 15 分ほど待ってから、再度試してください。
- 原因 2: AWS CLI または API を直接使用している場合、存在しない証明書の Amazon リソースネーム(ARN)を指定すると、このエラーが返されることがあります。
- 解決方法 2: Identity and Access Management (IAM) のアクション GetServerCertificate を使用して証明書 ARN を取得し、ARN に正しい値を指定
- 原因 1: AWS マネジメントコンソールを使用して証明書が作成されると、すべてのリージョンに伝達される際に遅延が発生します。この遅延が発生すると、ロードバランサーの作成プロセスの最終ステップでエラーメッセージが表示されます。
- OutofService: 一時的なエラー発生
- 原因: Elastic Load Balancing サービスまたはその基盤ネットワーク内に一時的な問題があります。この一時的な問題は、Elastic Load Balancing がロードバランサーとその登録済みインスタンスの状態を照会すると発生する場合があります。
- 解決方法: API 呼び出しを再試行してください。
- 原因: Elastic Load Balancing サービスまたはその基盤ネットワーク内に一時的な問題があります。この一時的な問題は、Elastic Load Balancing がロードバランサーとその登録済みインスタンスの状態を照会すると発生する場合があります。
- CertificateNotFound: 未定義
- HTTP エラー
- HTTP 400: BAD_REQUEST
- 説明: クライアントが無効なリクエストを送信したことを示します。
- 原因 1: クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信しました。たとえば、リクエストの URL にスペースを含めることはできません。
- 原因 2: クライアントが HTTP CONNECT メソッドを使用しました。このメソッドは Elastic Load Balancing でサポートされていません。
- 解決方法: 直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャします。ヘッダーと URL で誤った形式のリクエストを確認します。リクエストが HTTP 仕様を満たすことを確認します。HTTP CONNECT が使用されていないことを確認します。
- 説明: クライアントが無効なリクエストを送信したことを示します。
- HTTP 405: METHOD_NOT_ALLOWED
- 説明: メソッドの長さが無効であることを示しています。
- 原因: リクエストヘッダー内のメソッドの長さが 127 文字を超えています。
- 解決方法: メソッドの長さを確認します。
- HTTP 408: Request Timeout
- 説明: クライアントがリクエストをキャンセルしたか、リクエスト全体の送信に失敗したことを示します。
- 原因 1: ネットワークの中断またはリクエストの構造の問題 (ヘッダーの形式が完全ではない、指定されたコンテンツのサイズが実際に送信されたコンテンツのサイズと一致しないなど)。
- 解決方法 1: リクエストを生成しているコードを調べ、そのコードを実際のリクエストをより詳細に調べることのできる登録済みインスタンス (または開発/テスト環境) に直接送信します。
- 原因 2: クライアントとの接続が閉じています (ロードバランサーは応答を送信できません)。
- 解決方法 2: リクエストを送信するマシンでパケットスニッファーを使用して、応答が送信される前にクライアントが接続を閉じないことを確認してください。
- 原因 1: ネットワークの中断またはリクエストの構造の問題 (ヘッダーの形式が完全ではない、指定されたコンテンツのサイズが実際に送信されたコンテンツのサイズと一致しないなど)。
- 説明: クライアントがリクエストをキャンセルしたか、リクエスト全体の送信に失敗したことを示します。
- HTTP 502: Bad Gateway
- 説明: 登録されたインスタンスから送信された応答をロードバランサーが解析できなかったことを示します。
- 原因: インスタンスからの応答の形式が適切でないか、ロードバランサーに問題があります。
- 解決方法: インスタンスから送信された応答が HTTP 仕様に準拠していることを確認
- HTTP 503: Service Unavailable
- 説明: ロードバランサーまたは登録されたインスタンスが原因でエラーが発生していることを示します。
- 原因 1: ロードバランサーにリクエストを処理する能力が不足しています。
- 解決方法: これは一時的な問題であり、数分以上は継続しません。
- 原因 2: 登録されたインスタンスがありません。
- 解決方法 2: ロードバランサーによる応答が設定された利用可能ゾーンごとに 1 つ以上のインスタンスを登録します。これを確認するには、CloudWatch の HealthyHostCount メトリクスを確認します。各アベイラビリティーゾーンにインスタンスが登録されているかどうかが不明な場合は、クロスゾーン負荷分散を有効にする
- 原因 3: 正常なインスタンスがありません。
- 解決方法 3: ロードバランサーの応答を設定しているすべての利用可能ゾーンに正常なインスタンスがあることを確認します。これを確認するには、HealthyHostCount メトリクスを確認します。
- 原因 4: サージキューがいっぱいです。
- 解決方法 4: インスタンスに、リクエスト率に対応するための十分な容量があることを確認します。これを確認するには、SpilloverCount メトリクスを確認
- HTTP 504: Gateway Timeout
- 説明: リクエストがアイドルタイムアウト期間内に完了しなかったためロードバランサーが接続を閉じたことを示します。
- 原因 1: アプリケーションの応答が、設定されているアイドルタイムアウトよりも長くかかっています。
- 解決方法 1: HTTPCode_ELB_5XX および Latency メトリクスをモニタリングします。これらのメトリクスに増加があった場合は、アイドルタイムアウト期間内に応答しないアプリケーションが原因である可能性があります。タイムアウトしようとしているリクエストの詳細を確認するには、ロードバランサーのアクセスログを有効にし、Elastic Load Balancing によって生成されたログの応答コード 504 を確認します。必要に応じて、キャパシティーを増やしたり、設定されているアイドルタイムアウトを長くしたりして、時間のかかるオペレーション (大容量ファイルのアップロードなど) が完了できるようにします。
- 原因 2: 登録されたインスタンスが Elastic Load Balancing への接続を終了させています。
- 解決方法 2: EC2 インスタンスのキープアライブ設定を有効にし、キープアライブタイムアウトが、ロードバランサーのアイドルタイムアウト設定より大きい値に設定されていることを確認します。
- HTTP 400: BAD_REQUEST
ロードバランサーは、クライアントに送信された HTTP 応答コードのメトリクスを Amazon CloudWatch に送信することで、エラーの原因がロードバランサーなのか、登録済みインスタンスなのかを特定します。CloudWatch からロードバランサーに返されるメトリクスを使用して、問題のトラブルシューティングを行います。
-
応答コードのメトリクス
- HTTPCode_ELB_4XX
- 原因: クライアントからのリクエストが誤った形式であるか、キャンセルされました。
- HTTPCode_ELB_5XX
- 原因: ロードバランサーまたは登録されたインスタンスがエラーの原因であるか、またはロードバランサーが応答を解析できませんでした。
- HTTPCode_Backend_2XX
- 原因: 登録済みインスタンスから正常な応答が返されました。
- HTTPCode_Backend_3XX
- 原因: 登録済みインスタンスからリダイレクト応答が送信されました。
- 解決方法: インスタンスのアクセスログまたはエラーログを確認して、原因を特定します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。
- HTTPCode_Backend_4XX
- 原因: 登録済みインスタンスからクライアントエラー応答が送信されました。
- 解決方法: インスタンスのアクセスログまたはエラーログを表示して、問題の原因を判断します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。
- HTTPCode_Backend_5XX
- 原因: 登録済みインスタンスからサーバーエラー応答が送信されました。
- 解決方法: インスタンスのアクセスログまたはエラーログを確認して、原因を特定します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。
- HTTPCode_ELB_4XX
-
ヘルスチェックの問題
- ヘルスチェックのターゲットページのエラー
- インスタンスへの接続がタイムアウトした
- パブリックキー認証が失敗する
- インスタンスがロードバランサーからのトラフィックを受信しない
- インスタンスのポートが開いていない
- Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する
-
接続の問題
-
インスタンス登録の問題
バージョニングの使用
バージョニングとは、同じバケット内でオブジェクトの複数のバリアントを保持する手段です。バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができます。バージョニングを使用すれば、意図しないユーザーアクションからもアプリケーション障害からも、簡単に復旧できます。バケットのバージョニングが有効な場合、Amazon S3 が同じオブジェクトに対して複数の書き込みリクエストを同時に受信すると、すべてのオブジェクトが保存されます。
バケットのバージョニングを有効にすると、Amazon S3 は保存されるオブジェクトに対して一意のバージョン ID を自動的に生成します。たとえば、1 つのバケット内に、photo.gif (バージョン 111111) と photo.gif (バージョン 121212) のように、キーは同じだがバージョン ID が異なる 2 つのオブジェクトを保持することができます。
- バージョニングが有効なバケットでは、オブジェクトを誤って削除または上書きしても復元できます。
- オブジェクトを削除した場合、Amazon S3 では、オブジェクトを完全に削除する代わりに削除マーカーを挿入し、それが最新のオブジェクトバージョンになります。いつでも以前のバージョンを復元できます。
- オブジェクトを上書きすると、バケット内の新しいオブジェクトバージョンになります。いつでも以前のバージョンを復元できます。
- バケットは、バージョニング無効 (デフォルト)、バージョニング有効、バージョニング停止の 3 つの状態のいずれかに設定できます。
- 一度バケットのバージョニングを有効にすると、バージョニング無効の状態に戻すことはできません。ただし、そのバケットのバージョニングを停止することは可能です。
- バージョニング状態は、バケット内の一部ではなくすべてのオブジェクトに適用されます。最初にバケットのバージョニングを有効にした時点で、バケット内のオブジェクトは常にバージョニングされ、固有のバージョン ID が与えられます。次の点に注意してください。
- 「バージョニングが有効なバケット内のオブジェクトの管理」
- バージョニング状態を設定する前にバケットに格納されているオブジェクトには、バージョン ID null が付けられています。
- 「バージョニングが停止されたバケットのオブジェクトの管理
- 「バージョニングが有効なバケット内のオブジェクトの管理」
AWS Rekognitionを使用してサービスを開発
- ソース
- S3
- kinesis video streams
- Amazon Rekognition Video
- コンシューマ
- kinesis data streams KCL
- Kinesis Client Libraryを実案件でつかってみて
- https://qiita.com/okuda_h/items/17408af9df73a5a6aa7e
- kinesis data streams KCL
AWS DMSの設定方法
- AWS DMSによりデータベースを移行する際の最初のタスク
- ソースデータベースからターゲットデータベースにデータを割り当てて移行するタスクを実行するのに十分なストレージと処理能力を持つレプリケーションインスタンスを作成すること
- AWS コンソールを使用してレプリケーションインスタンスを作成
- ソースデータベースからターゲットデータベースにデータを割り当てて移行するタスクを実行するのに十分なストレージと処理能力を持つレプリケーションインスタンスを作成すること
- ソースとターゲットのエンドポイントを指定する
- EC2
- RDS
- オンプレ
- タスクを作成
- 移行するテーブルを指定
- ターゲットスキーマを使用してデータをマッピング
- ターゲットデータベースに新しいテーブルを作成
- 移行のタイプ
- 既存のデータの移行
- 既存のデータの移行と継続的な変更のレプリケート
- データ変更のみのレプリケート
- 使用するオプション
- タスク名
- タスクの説明
- ソースエンドポイント
- ターゲットエンドポイント
- レプリケーションインスタンス
- 移行タイプ
- 作成時にタスクを開始
- タスクをモニタリングする
ゲームアプリケーションに推奨できるキャッシュ利用方法
Memcached は、データをミリ秒で検索できる、オープンソースの分散型メモリ内キー値ストアです。Memcached でサイトのインフォメーションを得ることによって、コストを管理しつつ、サイトのパフォーマンスとスケーラビリティを向上することができるようになります。セッションデータ管理など単純な処理を高速化する際はRedisではなく、Memcachedの方が運用が容易であり望ましいユースケースとなりますが、今回のようなリアルタイムデータの計算処理には、Redisを選択する方が良いユースケースとなります。
ゲームやるならredis.単純な読み取りならmemcashed
Kinesis Data Streams のアーキテクチャの概要
以下の図に、Kinesis Data Streams のアーキテクチャの概要を示します。プロデューサーは継続的にデータを Kinesis Data Streams にプッシュし、コンシューマーはリアルタイムでデータを処理します。コンシューマー (Amazon EC2 上で実行されるカスタムアプリケーションや Amazon Kinesis Data Firehose 配信ストリームなど) は、Amazon DynamoDB、Amazon Redshift、Amazon S3 などの AWS のサービスを使用して、その結果を保存できます。
- Amazon Kinesis Data Streams へのデータの書き込み
- Amazon Kinesis Producer Library を使用したプロデューサーの開発
- Amazon Kinesis Data Streams プロデューサーは、ユーザーデータレコードを Kinesis data stream に配置する (データの取り込みとも呼ばれます) アプリケーションです。Kinesis Producer Library (KPL) を使用すると、プロデューサーアプリケーションの開発が簡素化され、開発者は Kinesis data stream に対する優れた書き込みスループットを実現できます。
- Amazon Kinesis Data Streams API と AWS SDK for Java を使用したプロデューサーの開発
- Kinesis Data Streams API について説明し、AWS SDK for Java を使用してストリームにデータを追加 (入力) します。
- Kinesis エージェントを使用した Amazon Kinesis Data Streams への書き込み
- Kinesis エージェントはスタンドアロンの Java ソフトウェアアプリケーションで、データを収集して Kinesis Data Streams に送信する簡単な方法を提供します。このエージェントは一連のファイルを継続的に監視し、新しいデータをストリームに送信します。エージェントはファイルのローテーション、チェックポイント、失敗時の再試行を処理します。タイムリーで信頼性の高い簡単な方法で、すべてのデータを提供します。また、ストリーミング処理のモニタリングとトラブルシューティングに役立つ Amazon CloudWatch メトリクスも出力します。
- Amazon Kinesis Producer Library を使用したプロデューサーの開発
Amazon Kinesis Data Streams からのデータの読み取り
コンシューマーは、Kinesis データストリームからのすべてのデータを処理するアプリケーションです。コンシューマーで拡張ファンアウトを使用すると、独自の 2 MB/秒の読み取りスループットが割り当てられ、その読み取りスループットを他のコンシューマーと競合することなく、複数のコンシューマーが並行して同じストリームからデータを読み取ることができます。
ファンアウト使わない案件は少ないのでは
- AWS Lambda を使用したコンシューマーの開発
* - Amazon Kinesis Data Analytics を使用したコンシューマーの開発
- SQL または Java により Kinesis ストリーム内のデータを処理および分析できます。
- Amazon Kinesis Data Firehose を使用したコンシューマーの開発
- Kinesis Data Firehose を使用して Kinesis ストリームからレコードを読み取り、処理できます。Kinesis Data Firehose は、Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk などの送信先にリアルタイムのストリーミングデータを配信するためのフルマネージド型サービスです。データを変換し、レコード形式を変換してからデータを送信先に配信するよう Kinesis Data Firehose を設定することもできます。
- Amazon S3
- Amazon Redshift
- Amazon Elasticsearch Service
- Splunk
- Kinesis Data Firehose を使用して Kinesis ストリームからレコードを読み取り、処理できます。Kinesis Data Firehose は、Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk などの送信先にリアルタイムのストリーミングデータを配信するためのフルマネージド型サービスです。データを変換し、レコード形式を変換してからデータを送信先に配信するよう Kinesis Data Firehose を設定することもできます。
- スループット共有カスタムコンシューマーの開発
- ファンアウト使わない人
- スループット専有 (拡張ファンアウト) カスタムコンシューマーの開発
- ファンアウト使う人
データベースにカスタムドメイン名を割り当てる
A または AAAA レコードを作成し (例: db.example.com)、データベースサーバーの IP アドレスを指定
【Route53】プライベートホストゾーンを使って初めて理解した3つのこと
Route53を利用してVPCの中と外で名前解決の結果を変える
Resdshift 長時間かかるデータ処理
データウェアハウスシステムのアーキテクチャ
ワークロード管理
Amazon Redshift のワークロード管理 (WLM) を使用すると、ユーザーは、ワークロード内の優先順位を柔軟に管理して、短くて実行速度の速いクエリが実行時間の長いクエリの後に溜まらないようにできます。Amazon Redshift WLM は、サービスクラスに従って実行時にクエリキューを作成します。サービスクラスでは、内部システムキューやユーザーアクセス可能キューなどのさまざまな種類のキューに対する設定パラメータが定義されています。ユーザーから見た場合、ユーザーアクセス可能サービスクラスとキューは機能的に同じものです。一貫性を保つため、このドキュメントでは、ユーザーアクセス可能サービスクラスとランタイムキューを表すために、キューという用語を使用します。
ユーザーがクエリを実行すると、WLM は、ユーザーのユーザーグループに従ってクエリをキューに割り当てるか、キューの設定でリストされているキューグループとユーザーが実行時に設定したキューグループラベルを照合することによってクエリをキューに割り当てます。
デフォルトのパラメータグループを使用するクラスターのデフォルトでは、自動 WLM を使用します。自動 WLM は、クエリの同時実行数とメモリの割り当てを管理します。
- 手動 WLM では、Amazon Redshift は、同時実行レベルが 5 (最大 5 個のクエリを同時実行) の 1 つのキューと、同時実行レベルが 1 の定義済みスーパーユーザーキューを設定します。最大で 8 個のキューを定義できます。各キューの同時実行レベルは最大で 50 に設定できます。すべてのユーザー定義キュー (スーパーユーザーキューは含みません) の同時実行レベルの合計の最大値は 50 です。
- WLM の設定を変更する最も簡単な方法は、Amazon Redshift マネジメントコンソールを使用すること
Amazon Redshiftワークロード管理(WLM)を使用すると、ユーザーはワークロード内の優先順位を柔軟に管理できるため、短時間で高速に実行されるクエリが、長時間実行されるクエリの背後にあるキューによって処理がつまることがなくなります。
他のサービスで Amazon Redshift を使用する
- Amazon Redshift と Amazon S3 の間のデータの移動
- Amazon Simple Storage Service (Amazon S3) は、クラウドにデータを保存するウェブサービスです。Amazon Redshift は、並列処理を活用して、Amazon S3 バケットに保存されている複数のデータファイルからデータを読み出してロードします。
- 並列処理を使用して、Amazon Redshift データウェアハウスから Amazon S3 の複数のデータファイルにデータをエクスポートすることもできます。
- Amazon Redshift を Amazon DynamoDB に使用する
- COPY コマンドで、1 つの Amazon DynamoDB テーブルのデータを使用して Amazon Redshift テーブルをロードすることができます。
- SSH によるリモートホストからのデータのインポート
- Amazon Redshift で COPY コマンドを使用して、Amazon EMR クラスター、Amazon EC2 インスタンス、その他のコンピュータなど、1 つ以上のリモートホストからデータをロードすることができます。COPY を実行すると、SSH を使用してリモートホストに接続し、リモートホストでコマンドを実行してテキスト出力を生成します。Amazon Redshift では、複数の同時接続がサポートされます。COPY コマンドでは、複数のホストのソースからの出力を並列で読み取ってロードします。
- AWS Data Pipeline を使用したデータのロードの自動化
- AWS Data Pipeline を使用して、Amazon Redshift との間のデータの移動や変換を自動化できます。AWS Data Pipeline に組み込まれたスケジューリング機能を使用して、定期的にジョブを繰り返し実行させることができ、複雑なデータ転送や変換ロジックを自分で書く必要がありません。
- 再帰ジョブを設定して定期的にデータを Amazon DynamoDB から Amazon Redshift へ自動的にコピーすることができます。
- AWS Data Pipeline を使用して、Amazon Redshift との間のデータの移動や変換を自動化できます。AWS Data Pipeline に組み込まれたスケジューリング機能を使用して、定期的にジョブを繰り返し実行させることができ、複雑なデータ転送や変換ロジックを自分で書く必要がありません。
- AWS Database Migration Service を使用したデータの移行 (AWS DMS)
- AWS Database Migration Service を使用して Amazon Redshift にデータを移行できます。AWS DMS は、Oracle、PostgreSQL、Microsoft SQL Server、Amazon Redshift、Aurora、DynamoDB、Amazon S3、MariaDB、MySQL など、幅広く使用されている商用およびオープンソースデータベースとの間でデータを移行できます。
インプレースアップグレードと並行アップグレードの説明
より新しいバージョンの Windows に Amazon EC2 Windows Server インスタンスをアップグレードする
インスタンスで実行している旧バージョンの Windows Server をアップグレードするには、インプレースアップグレードと移行 (並行アップグレードとも呼ばれる) の 2 通りの方法があります。インプレースアップグレードはオペレーティングシステムファイルをアップグレードし、個人の設定およびファイルは維持されます。移行では、設定、構成、データを取り込み、この情報を新しい Amazon EC2 インスタンス上のより新しいバージョンのオペレーティングシステムに移行します。
- インプレース
- インプレースアップグレードはオペレーティングシステムファイルをアップグレードし、個人の設定およびファイルは維持
- 平行
- 移行では、設定、構成、データを取り込み、この情報を新しい Amazon EC2 インスタンス上のより新しいバージョンのオペレーティングシステムに移行します。
インスタンスメタデータとユーザーデータ
インスタンスメタデータのカテゴリ
- iam/info
- インスタンスに関連付けられた IAM ロールがある場合、インスタンスの LastUpdated の日付、InstanceProfileArn、InstanceProfileId など、インスタンスプロファイルが更新された最終時刻に関する情報が格納されます。そうでない場合は、なしになります。
Oracle Recovery Manager(Oracle RMAN)復元
あらゆるOracleデータ形式の高度なパフォーマンス要求や、管理性の高いバックアップおよびリカバリへの要望に応える製品
RMAN の復元は Amazon RDS for Oracle の DB インスタンスでサポートされていないため、利用にはEC2インスタンスにOracleサーバーをセットアップすることが必要
コンテンツがエッジキャッシュに保持される期間の管理 (有効期限)
ウェブディストリビューションで CloudFront がキャッシュにオブジェクトを保持する期間の指定
ウェブディストリビューションで、Cache-Control または Expires ヘッダーと共に、CloudFront の最小、最大、デフォルトの TTL 値を使用することで、CloudFront が別のリクエストをオリジンに転送するまでにキャッシュにオブジェクトを保持する期間 (秒) を制御できます。ヘッダーの値によって、ブラウザが別のリクエストを CloudFront に転送するまでにオブジェクトをキャッシュに保持する期間も決まります。
全てのTTLを0に設定することで、コンテンツは変更されるとすぐにオリジンから配信されます。
Oracle RAC構成バックアップ
Oracle Real Application Cluster(RAC)は、1つのデータベース(複数のデータファイルのセット)を1台、もしくは複数のサーバインスタンスで構成し、複数クライアントから同時にアクセス可能にするOracle社によるシェアードエブリシング型のデータベースクラスターテクノロジーです。RACを使用すると、Oracle Databaseをクラスター化できます。Oracle RACでは、インフラストラクチャとしてOracle Clusterwareを使用し、複数のサーバーを関連付けてそれらが単一のシステムとして動作するように構成します。
- 現在、RACはAWSではサポートされておらず、RDSを利用してORACLEをデータベースエンジンとしてもRACを使用することはできませんが、AWSマーケットプレイス上のAMIを使ってRACをAmazon EC2上にデプロイすることが可能になりました。Oracle RACをAmazon EC2上にデプロイすることで、Amazon Web Serviceの柔軟性とスケーラビリティを活用することが可能になります。Amazon EC2環境でOracle RACにノードを追加することはいくつかのAPIコールもしくはコマンドを実行するだけで簡単に実行できます。バックアップを取得するには、RAC用に展開されたEC2のEBSボリュームスナップショットの形式でバックアップを取得する必要があります。
Amazon S3 バケットから配信するコンテンツへのアクセスを制限する
CloudFront 署名付き URL または署名付き Cookie を作成して Amazon S3 バケット内のファイルへのアクセスを制限してから、オリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成して配布に関連付けます。次に、CloudFront が OAI を使用してファイルにアクセスしてユーザーに提供できるようにアクセス許可を構成します。
AWSに対してSAML 2.0 によるエンタープライズ ID プロバイダーを使用したサインインが実施
Amazon Cognito
ウェブアプリケーションおよびモバイルアプリに素早く簡単にユーザーのサインアップ/サインインおよびアクセスコントロールの機能を追加できます。Amazon Cognito は、数百万人のユーザーにスケールし、Facebook、Google、Amazon などのソーシャル ID プロバイダー、および SAML 2.0 によるエンタープライズ ID プロバイダーを使用したサインインをサポート
AWS Single Sign-On (SSO)
社内の既存の Microsoft Active Directory (AD) の ID を使用して、アカウントとアプリケーションへの SSO アクセスを管理できます。AWS SSO は AWS Directory Service を通じて AD と統合されるため、ユーザーを該当する AD グループに追加するだけでアカウントとアプリケーションへの SSO アクセスをユーザーに許可できます。
AWS OrganizationsのSCPはサービスにリンクされたIAMロールには影響しない
AWS Organizationsのサービスコントロールポリシー (SCP) は、組織を管理するために使用できるポリシーのタイプです。SCP は、組織内のすべてのアカウントの最大使用アクセス権限を一元的に管理できる機能を提供し、アカウントが組織のアクセスコントロールガイドラインに沿って活動することを確実にします。SCP は、すべての機能が有効になっている 組織でのみ使用できます。 SCPはサービスにリンクされたロールには影響しないようになっています。 サービスにリンクされたロールにより、他のAWSサービスをAWS組織と統合でき、SCPによって制限することはできません。したがって、ECSに付与されたIAMロールによってアクセス許可はそのECSを利用しているAWSアカウントへのSCPによっては制限できない
サービスにリンクされたロール
サービスにリンクされたロールは、AWS サービスに直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、サービスによって事前定義されており、お客様の代わりにサービスから他の AWS サービスを呼び出す必要のあるアクセス権限がすべて含まれています。
プライベートネットワークを介したリージョンを跨いだVPCアクセス
Direct Connect ゲートウェイ
AWS Direct Connect ゲートウェイを使用して VPC を接続します。AWS Direct Connect ゲートウェイは、次のいずれかのゲートウェイに関連付けます。
- 同一リージョン内に複数の VPC がある場合は トランジットゲートウェイ
- 仮想プライベートゲートウェイ
irect Connect ゲートウェイによって、米国東部(バージニア北部) リージョンの AWS Direct Connect 接続を使用し、米国東部(バージニア北部) と 米国西部 (北カリフォルニア) の両方のリージョンでご自身のアカウントの VPC にアクセスできます。
アカウント間の仮想プライベートゲートウェイの関連付け
Direct Connect ゲートウェイを所有している Direct Connect 所有者 (アカウント Z) のシナリオを考えてみます。アカウント A とアカウント B は Direct Connect ゲートウェイの使用を希望しています。アカウント A とアカウント B はそれぞれ、関連付け提案をアカウント Z に送信します。アカウント Z はこの関連付け提案を承諾し、必要に応じて、アカウント A の仮想プライベートゲートウェイまたはアカウント B の仮想プライベートゲートウェイから許可されるプレフィックスを更新します。アカウント Z が提案を承諾すると、アカウント A とアカウント B はそれぞれの仮想プライベートゲートウェイから Direct Connect ゲートウェイにトラフィックをルートできるようになります。また、アカウント Z はゲートウェイを所有しているため、顧客へのルーティングを所有します。
全部乗せ
DXGTWから他リージョンもいける
S3内のデータ検索
CloudSearch は AWS クラウドにおけるマネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできます。S3のネイティブ検索エンジンはアプリケーションサービス向けとして利用するには性能的に不十分です。
クロスゾーン負荷分散
クロスゾーン負荷分散を使用すると、Classic Load Balancer の各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンの登録されたインスタンスにリクエストを均等に分散します。クロスゾーン負荷分散が無効の場合は、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録されたインスタンスにのみリクエストを均等に分散します。
クロスゾーン負荷分散により、有効な各アベイラビリティーゾーンに等しい数のインスタンスを維持する必要性が軽減され、1 つ以上のインスタンスの消失を処理するアプリケーションの能力が向上します。ただし、耐障害性を高めるために有効な各アベイラビリティーゾーンにおよそ等しい数のインスタンスを維持することをお勧めします。クライアントが DNS ルックアップをキャッシュする環境では、着信リクエストがいずれかのアベイラビリティーゾーンを優先する場合があります。クロスゾーン負荷分散を使用すると、リクエスト負荷がリージョン内の利用可能なすべてのインスタンスに分散されて不均衡が是正され、不適切に動作しているクライアントによる影響が軽減されます。
Amazon Rekognition
Amazon Rekognitionは、画像分析機能を容易に実現することができるAPIサービスです。 Rekognitionを使用すると、画像内のオブジェクト、シーン、顔を検出できます。 顔を検索して比較することもできます。 AWS CLI または Rekognition API を使用するを使用すると、強力な視覚的検索と発見をアプリケーションに簡単に組み込むことができます。 Amazon Rekognitionを使用すると、分析した画像と保存した顔のメタデータに対してのみ料金を支払います。
API GatewayとLambdaファンクションを統合して実行するための方法
- Lambdaプロキシ統合
- 楽
- Lambda カスタム統合
- プロキシ統合のセットアップ手順に加えて、受信リクエストデータがどのように統合リクエストにマッピングされるか、統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定
すべてのアカウントからのイベントログを表示する
- AWS Organizationsを利用
- AWS Organizationsを利用してマスターアカウントのCloudTrailにおいて組織の証跡を有効化することで、全てのメンバーアカウントでのログ取得を可能
- 各AWSアカウントに関連するログをプライマリアカウントの単一のS3バケットに配信する設定も可能
- 利用しない場合
- ログファイルの配信先S3バケットのバケットポリシーに最初に有効化したCloudTrail にクロスアカウントのアクセス権限を付与することで、クロスアカウントでのログ取得が可能
RDS Proxy
必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑える機能
プロキシを利用してLambda関数によってRDSからデータ取得と集計を実施するサーバレスアプリケーションを構築することができます。
AWSリソースに対してタグを作成するように強制する
AWS Organizationsを使用すると、すべてのAWSアカウントを統合し、ビジネスユニットを個別の組織ユニット(OU)にグループ化できます。OUメンバーの既存のIAMポリシーを修正して、ForAllValues修飾子を使用しOUごとにタグ付けを要求する設定とします。このIAMポリシーの設定としては、ForAllValues修飾子を使用してポリシーで定義されているすべてのタグを適用する場合にのみ、ユーザーがEC2インスタンスを起動してEBSボリュームを作成できるようにIAMポリシーを設定できます。ユーザーがポリシーに含まれていないタグを適用すると、アクションは拒否されます。
EC2インスタンスベースのMySQLデータベースの移行方法
- RDS
- スナップショット
- backup
- EC2インスタンスベースやオンプレミスサーバーにインストールされたMySQLデータベース
- MySQLデータベースの機能であるmysqldump を使用してMySQL データをエクスポートとして移行先にインポートすることで移行する
- Direct Connect
- IPSec VPN接続
- MySQLデータベースの機能であるmysqldump を使用してMySQL データをエクスポートとして移行先にインポートすることで移行する
デプロイポリシー
- All at once
- 新しいバージョンをすべてのインスタンスに同時に展開します。 環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止します。 これは、展開に必要な合計時間を最短にする方法です。
- Rolling(ローリング)
- Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイするため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になります。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。
- Rolling with additional batch
- 新しいバージョンをバッチで展開しますが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保します。
- Immutable
- 変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動します。[Immutable] デプロイは、部分的に完了したローリングデプロイにより発生する問題を防止できます。新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残します。
IPSecの特徴
- Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか
- IPSecトンネル経由で送信されるデータの整合性を保持
- IPSecトンネルを経由して送信されるデータは暗号化
- IPSecはインターネット経由で送信中のデータを保護
- IPSecトンネルのセットアップ中にIDが認証
- VPNゲートウェイ(VPG)とカスタマーゲートウェイ(CGW)の間にIPSecトンネルが確立
Origin Protocol Policy
ウェブディストリビューションでは、オブジェクトのリクエストでビューワーがHTTPや HTTPS を使用するように CloudFront を設定して、CloudFront とビューワーとの通信で接続を設定するポリシーを利用することができます。これをOrigin Protocol Policyと呼びます。
- HTTP Only
- HTTPS Only
- Match Viewer
- CloudFrontはビューアーリクエストのプロトコルに応じてHTTPまたはHTTPSを使用してオリジンと通信
RedshiftクラスターのDRと暗号化
Amazon Redshiftクラスターを起動するときに、AWS KMSのマスターキーで暗号化することを選択できます。その際の AWS KMSキーはリージョンに固有となります。DR元リージョンにおいてAWS KMSで暗号化されたクラスターのクロスリージョンスナップショットコピーを有効にすることで、DR対象となるリージョンに対して、Redshiftクラスターのスナップショットをコピーして移転させることができます。
CFnとEB併用
CloudFormationを利用してAWS OpsWorksによるインフラ処理を実行することができます。CloudFormationテンプレート内でOpsWorksコンポーネントをモデリングし、それらをCloudFormationスタックとしてプロビジョニングできます。これにより、OpsWorksの構成を文書化、バージョン管理、および共有できます。
統一されたCloudFormationテンプレートまたは個別のCloudFormationテンプレートを使用して、OpsWorksコンポーネントおよびAmazon VPCやAWS Elastic Load Balancerなどの他の関連AWSリソースを柔軟にプロビジョニングできます
キャッシュヒット率を高める設定
クエリ文字列パラメータに基づいてキャッシュするように CloudFrontを設定する場合、オリジンが一意のオブジェクトを返すクエリ文字列パラメータのみを転送するようにCloudFront を設定するなどしてキャッシュを改善
Cache-Control max-age ディレクティブをオブジェクトに追加し、max-ageに対して最も長い実用的な値を指定するようにオリジンを設定することによって、キャッシュヒット率を向上させる
EC2インスタンスがIPv6を介してインターネットと通信
/16 の IPv4 CIDR ブロックを持つ VPC を作成し、/56 の IPv6 CIDR ブロックを VPC と関連付けます。IPv6 CIDR ブロックのサイズ (/56) は固定されており、IPv6 アドレスの範囲は、Amazon の IPv6 アドレスのプールから自動的に割り当てられます (独自の IPv6 アドレス範囲を指定することはできません)。
cfn-signalヘルパースクリプト
- UpdatePolicy 属性
- UpdatePolicy 属性を使用して、AWS CloudFormation が、AWS::AutoScaling::AutoScalingGroup、AWS::ElastiCache::ReplicationGroup、AWS::Elasticsearch::Domain、または AWS::Lambda::Alias のリソースに対する更新を処理する方法を指定
SSL証明書をIAMにアップロードされた証明書に置き換える
- IAM API を使用して証明書を取得する
- get-server-certificateコマンドを使用して、証明書のARNを取得
- set-load-balancer-listener-ssl-certificateコマンドを使用
CloudWatchメトリクス
- SpilloverCount
- サージキューがいっぱいなため、拒否されたリクエストの総数
- SurgeQueueLength
- 正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数を提供
- HealthyHostCount
- ロードバランサーに登録された正常なインスタンスの数
- UnHealthyHostCount
- ロードバランサーに登録された異常なインスタンスの数
- RequestCount
- 指定された間隔 (1 分または 5 分) の間に完了したリクエストの数、または接続の数
The request could not be satisfied.Bad Request.
リクエストに失敗しました。無効なリクエストです。)" というエラーメッセージは、クライアントからのエラー
- リクエストが HTTP を通じて開始されたが、CloudFront ディストリビューションは HTTPS のリクエストだけを許可するように設定
- リクエストされた代替ドメイン名 (CNAME) が CloudFront ディストリビューションと関連付けられていない。
AWS SAM構文において、SAMバージョンを指定する必要があるテンプレートでリソースを宣言する
CloudFormationのオプションの Transform セクションでは、CloudFormation テンプレートを処理するために使用するマクロを 1 つ以上指定します。Transform セクションではテンプレート内で 1 つ以上のマクロを宣言できます。マクロは、AWS CloudFormation によって、指定された順序で実行されます。変更セットを作成すると、AWS CloudFormation は処理されたテンプレートコンテンツを含む変更セットを生成します。その後、変更内容を確認して変更セットを実行できます。
Amazon SQS に基づくスケーリング
SQSキューイング処理に対してAutoScalingを設定する場合は、CloudWatch カスタムメトリクスによってキューの最適なメトリクスを設定して、それに応じてAutoScalingが実行できるように設定
つかれた。。。