#はじめに
16日に試験受けます！
#学習
個別のコンポーネントに2つの個別のSSL証明書を実装したい
単一のEC2インスタンスにElastic Network Interface（ENI）を使用して複数のIPアドレスを付与することで達成できます。Elastic Network Interfaceは、仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです。
AWS Database Migration Services（AWS DMS）を利用してデータベース移行する際にデータソースが古いか、サポートされていない
CSV形式でデータをエクスポートできれば、データを移行またはプラットフォーム変更できます。S3にアップロードした後、CSVファイルを使用
AWS Organizations CloudTrail
ログ設定すべての機能を選択すると、CloudTrailコンソールの設定機能で「組織の証跡」を有効化する> 設定が表示されるようになります。これを有効化すると、メンバーアカウントに対するCloudTrailによるログ設定が実施されるようになります。その上で、メンバーアカウントではAWS CloudTrailを非有効化できない権限を設定する実施
パフォーマンスを向上させるためにDynamoDBテーブルに設定するべき方法
一般に、パーティションキー値の総数に対するアクセスされたパーティションキー値の比率が高いほど、プロビジョニングされたスループットをより効率的に使用します。カーディナリティの高い属性を持つパーティションキーを使用することが挙げられます。これには、各項目に多数の異なる値があります。テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティといい、「カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い」といいます。
Amazon CloudSearch
AWS クラウドにおけるマネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできます。Amazon CloudSearch は、34 言語をサポートし、ハイライト表示、自動入力、地理空間検索などの人気のある検索機能を備えています。
Elasticsearch Service と CloudSearch どっちを選べば良いの？
##Oracle DatabaseをAWSで使う際のクライアントの注意点
http://blog.serverworks.co.jp/tech/2018/04/06/oracle-client/
Proxy Protocolヘッダー
バックエンド接続にTCPを使用するロードバランサーがある場合に、クライアントのIPアドレスを識別するのに役立ちます。ロードバランサーはクライアントとインスタンス間のトラフィックをインターセプトするため、インスタンスからのアクセスログには、発信元クライアントではなくロードバランサーのIPアドレスが含まれます。リクエストの最初の行を解析して、クライアントのIPアドレスとポート番号を取得できます。
クロスゾーンロードバランシング
クライアントのIPアドレスを提供しない
SSE-S3暗号化方法の仕組み
Amazon S3 サーバーサイド暗号化は、利用可能な最も強力なブロック暗号の 1 つである 256 ビットの Advanced Encryption Standard (AES-256) を使用してデータを暗号化します。サーバー側の暗号化では、オブジェクトのメタデータではなく、オブジェクトデータのみが暗号化されます。
- 各オブジェクトは、強力な多要素暗号化を使用する一意のデータキーで暗号化されます。
- SSE-S3 は、定期的に回転するマスタキーを使用してデータキーを暗号化します。
- S3 のサーバー側の暗号化は、256ビット高度な暗号化標準 (AES-256)、データを暗号化するために利用可能な最強のブロック暗号のいずれかを使用
IAMロールをアプリケーションに関連付け
アプリケーションインスタンスのインスタンスプロファイルプロパティにおいて、そのロールを参照することでアクセス許可が実行される
複数値回答ルーティング
DNSクエリに応答して、WebサーバーのIPアドレスなどの複数の値を返すようにAmazon Route 53を構成できます。 ほとんどすべてのレコードに複数の値を指定できますが、複数値の回答ルーティングでは各リソースの正常性も確認できるため、Route 53は正常なリソースの値のみを返します。 ロードバランサーの代わりにはなりませんが、複数のヘルスチェック可能なIPアドレスを返す機能は、DNSを使用して可用性とロードバランシングを改善する方法です。
数値回答ルーティングを設定する際はALIASレコードに「NO」と設定
##1 つの CloudWatch ダッシュボードを使用して複数のリージョンにある AWS リソースをモニタリング
1 つの CloudWatch ダッシュボードを使用して複数のリージョンにある AWS リソースをモニタリングできます。したがって、各リージョンにて個別にCloudWatchを設定する必要はありません。
WAFの設置の仕方
WAFレイヤーを2つのELBの間に配置して、すべてのトラフィックを処理できるようにする必要があります。WAFにより悪意のあるリクエストをフィルタリングし、フィルタリング後の悪意のないリクエストを送信する別のELBで悪意のないリクエストを受信し、処理のためにEC2インスタンスに送信します。
DDoS攻撃に対処する WAF サンドイッチ構成とは
DAX
DAXはキャッシュを利用したテーブル内のデータ処理を高パフォーマンス化する機能です。これは一時的な高パフォーマンスではなく、DAXが起動している間定常的にパフォーマンスをキープする
AWS CodePipelineをAWS OpsWorksスタックで使用する詳細な手順
- AWS OpsWorks Stacksでスタック、レイヤー、およびインスタンスを作成する
- アプリコードをAmazon S3バケットにアップロードする
- アプリをAWS OpsWorksスタックに追加する
- AWS CodePipelineでパイプラインを作成する
- S3からソースを取得
- AWS OpsWorks Stacksでのアプリのデプロイの確認する
Oracle RACデータベース 移行
RDSではなくEC2インスタンスにのみ移行できる
Amazon DLM
https://dev.classmethod.jp/articles/ec2-snapshot-by-amazon-dlm/
【初心者向け】DLM (Data Lifecycle Manager)で周期的にEC2スナップショットを作成してみた
SCPとIAMポリシーの違いと設定方法
SCPで枠だけ決めてIAMロールで実行権限を渡す
Amazon EBS ボリュームをバックアップする為のSnapshotの生成 → 保存 → 削除のライフサイクルを自動化
移行方式について
- リプラットフォーム
- リプラットフォームでは既存アプリケーションのコアアーキテクチャを変更せずにクラウドプラットフォームへと切り替えを行います。たとえば、これはAmazon Relational Database Service（RDS）などの管理されたリレーショナルデータベースサービスに移行する、またはAWS Elastic Beanstalkなどの完全に管理されたプラットフォームにアプリケーションを移行することにより、データベースインスタンスの管理に費やす時間を削減したい場合に利用されれます。
- リホスト
- リフトシフト
- 再購入
- 再購入とは移行に際して別の製品に移行する決定であり、組織が使用している既存のライセンスモデルを変更する場合に用いられます。
- リファクタリング/リアーキテクト
- リファクタリングはアプリケーションの既存環境では達成することが困難な機能やスケール、またはパフォーマンスを追加する強いビジネスニーズによって推進されます。例えば全体のアーキテクチャ構成を大きく変更し、サービス指向アーキテクチャ（SOA）に移行することで俊敏性を高め、ビジネスの継続性を改善する場合などがあります。
- リタイア
- 廃止
- リテイン
- 塩漬け
AWS Database Migration Service の実施プロセス
AWS Schema Conversion Toolを使用してソーススキーマとコードをターゲットデータベースのそれに一致するように変換し、次にAWS Database Migration Serviceを使用してソースデータベースからターゲットデータベースにデータを移行
FGAC（Fine Grained Access Control）
DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能です。具体的には、テーブル所有者は誰（呼び出し元）がテーブルのどの項目や属性にアクセスでき、どのようなアクション（読み込み/書き込み）を実行できるかを指定できます。FGAC はIAMと組み合わせて使用されます。セキュリティ認証情報および対応するアクセス権限の管理は、IAM で行います。
このシナリオでは、30万人分のユーザーの設定データをAWS上で保存して、ソーシャルログインによるモバイル認証を実現することが要件となっています。AWSでソーシャルログインの使用するためにウェブIDフェデレーションを利用します。ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP)を使用してサインインすることができます。認証トークンを受け取ったら、そのトークンを AWS アカウントのリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。IdP を使用すると、アプリケーションで長期的なセキュリティ認証情報を埋め込んで配布する必要がないため、AWS アカウントの安全性の維持に役立ちます。
ユーザー認証データはDynamoDBテーブルに保存することで、強固なセキュリティによる高速な認証処理を実現することが可能です。DynamoDBテーブルのFGAC (Fine Grained Access Control）は DynamoDBがセキュリティ、アクセス制限を実現する仕組みで、これにより、ソーシャルログイン対応とあわせて、モバイルユーザが直接DynamoDBを利用することが可能となります。
OpsWorksの自動ヒーリング
インスタンスが Amazon EC2 ヘルスチェックに合格した場合でも、スタック内にある異常なインスタンスまたは失敗したインスタンスを再起動します。スタックのレイヤー設定では、自動ヒーリングがデフォルトで有効化されています。自動ヒーリングが有効になっている場合、ポータルのダウンタイムを回避するために、失敗したEC2インスタンスは自動的に置き換えられます。
##オンプレミス環境にあるWEBサーバーとデータベースサーバーのバックアップをAWS Storage Gatewayの保管型ボリュームを利用して実施している場合に、オンプレミス環境が停止した場合のAWS上での復元方法が
まずは、ApacheサーバーとOracleサーバーをELBターゲットグループに設定されたいくつかのEC2インスタンスを利用して設定していくことになります。特にOracleサーバーはRMANオラクルバックアップを利用する構成ですので、RDSのOracleエンジンを利用することができないことに注意して下さい。
Apacheサーバーを復元するためには保管型ストレージゲートウェイを使用してEBSボリュームを生成してデータを復元する必要があります。ボリュームゲートウェイは、iSCSIプロトコルを使用してアプリケーションにブロックストレージを提供します。ボリューム上のデータはAmazon S3に保存されます。 AWSでiSCSIボリュームにアクセスするには、EBSボリューム作成に使用できるEBSスナップショットを利用します。
##RDS トラブルシューティング
MySQLでは、エラーログ、スロークエリログ、一般ログの3つのログをモニタリングできます。MySQL エラーログはデフォルトで生成されます。DB パラメータグループのパラメーターを設定することで、スロークエリと一般ログを生成できます。ログの中でも、トラブルシューティングのために実行に時間がかかったすべてのSQLステートメント内容を収集することができるのはスロークエリログであり、これを有効化することが求められます。
- 一般ログ
- mysqld の実行内容の一般的な記録です。サーバーは、クライアントが接続または接続解除したときに情報をこのログに書き込み、クライアントから受け取った各 SQL ステートメントをログに記録します。一般クエリーログは、クライアント側でエラーが疑われるとき、クライアントが mysqld に送信した内容を正確に知りたい場合に非常に役立つことがあります。
- エラーログ
- エラーログには mysqld が開始および停止された時期を示す情報と、サーバーが実行中に発生したあらゆるクリティカルエラーが格納されます。自動的にチェックまたは修復することが必要なテーブルが mysqld で検出された場合、エラーログに警告メッセージが書き込まれます。
- スロークエリログ
- スロークエリーログは、実行に要した時間が long_query_time 秒を超え、少なくとも min_examined_row_limit 行を検査する必要があった SQL ステートメントで構成されます。long_query_time の最小値およびデフォルト値は、それぞれ 0 および 10 です。値はマイクロ秒の精度まで指定できます。ファイルへのロギングの場合、時間はマイクロ秒の部分も含めて書き込まれます。テーブルへのロギングの場合、時間の整数部のみ書き込まれ、マイクロ秒の部分は無視されます。
ElastiCacheクラスターフォールトトレラントキャッシングレイヤーを構築
ElastiCache Redisクラスターは、キャッシュデータのディザスターリカバリーまたはフォールトトレランスを実装するために以下のような機能を提供しています。
- 自動バックアップ
- Redis AOFを使用した手動バックアップ
- データの耐久性が必要な場合、Redis の AOF (Append-Only File) 機能を有効にすることができます。この機能を有効にすると、キャッシュノードは、キャッシュデータを変更するすべてのコマンドを Append-Only File に書き込みます。ノードが再起動され、キャッシュエンジンが起動すると、AOF が「再生」されます。 その結果、すべてのデータがそのままのウォーム Redis キャッシュが作成されます。
- AOF はデフォルトでは無効になっています。Redis を実行しているクラスターで AOF を有効にするには、appendonly パラメータを yes に設定してパラメータグループを作成する必要があります。次に、そのパラメータグループをクラスターに割り当てます。appendfsync パラメータを変更して、Redis が AOF ファイルに書き込む頻度を制御することもできます。
- 自動フェイルオーバーを備えたマルチAZのセットアップ
読み込みキャパシティーユニット（RCU）の計算方法
1 つの読み込みキャパシティーユニットは、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを表します。 例えば、10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルを作成するとします。これにより、最大 4 KB の項目について、1 秒あたり 10 回の強い整合性のある読み込み、または 20 回の結果的に整合性のある読み込みを行えます。
4 KB を超える項目の読み込みには、より多くの読み取りキャパシティーユニットを消費します。たとえば、8 KB (4 KB × 2) の項目の強い整合性のある読み込みは、2 ユニットの読み込みキャパシティーユニットを消費します。同じ項目の結果的に整合性のある読み込みは、読み込みキャパシティーを 1 ユニットしか消費しません。
したがって、RCUは10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルに対して、 20 回の結果的に整合性のある読み込みを行えるため、10RCUが正しい設定となります。
書き込みキャパシティーユニット（WCU）の計算方法
1 つの書き込みキャパシティーユニットは、最大サイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表します。
例えば、10 ユニットのプロビジョニングされた書き込みキャパシティーでテーブルを作成するとします。これにより、1 秒あたり最大でサイズが 1 KB の項目について、1 秒あたり 10 回の書き込みを行えます。
書き込みの項目サイズは、次の 1 KB の倍数に切り上げられます。たとえば、500 バイトの項目の書き込みは、1 KB の項目の書き込みと同じスループットを消費します。
したがって、WCUは30 ユニットのプロビジョニングされた読み取りキャパシティーのテーブルに対して、 1 秒あたり最大でサイズ1 KB の項目について、1 秒あたり 30 回の書き込みを行えます。
amazon kinesis拡張
- kinesisから拡張できる
- forehose
- s3
- Amazon Redshift
- splunk
- Amazon Elasticsearch Service
- kcl
- connecter
- redshift
- dyanmodb
- s3
- elastic search
- connecter
- forehose
APIコールの応答性とLambda関数の実行状況をモニタリングするCloudWatchの設定方法
CloudWatchを使用してAPIの実行を監視できます。CloudWatchは、API Gatewayから生データを収集して処理して、リアルタイムで確認可能なメトリックに変換して2週間記録します。ユーザーはこの履歴情報にアクセスして、Webアプリケーションまたはサービスのパフォーマンスを正確に把握できます。デフォルトでは、API Gatewayメトリックスデータは1分間隔でCloudWatchに自動的に送信されます。
- WS/ApiGateway 名前空間には、以下のメトリクスが含まれます。
- 4xx
- client error
- 5xx
- server error
- CacheHitCount
- 指定された期間内に API キャッシュから配信されたリクエストの数
- CacheMissCount
- API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数
- Count
- 指定された期間内の API リクエストの合計数
- IntegrationLatency
- API Gateway がバックエンドにリクエストを中継してから、バックエンドからレスポンスを受け取るまでの時間。
- Latency
- API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。
- 4xx
EC2インスタンスにMACアドレスを使用する
常にElastic Network Interface（ENI）の使用を検討してください。EC2がそのENIを持っている限り、MACアドレスは変更されません。Elastic Network Interface (このドキュメントではネットワークインターフェイスと呼びます) は、仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです。 ネットワークインターフェイスには以下の属性を含めることができます。
・VPC の IPv4 アドレス範囲からのプライマリプライベート IPv4 アドレス
・VPC の IPv4 アドレス範囲からの 1 つ以上のセカンダリプライベート IPv4 アドレス
・プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4)
・1 つのパブリック IPv4 アドレス
・1 つ以上の IPv6 アドレス
・1 つ以上のセキュリティグループ
・MAC アドレス
・送信元/送信先チェックフラグ
起動後に問題なく動いていたたはずのRedshiftで、しばらくしてクエリがまったく応答しなくなるトラブルの原因
クエリがハングする 」ことへの対処が必要となる可能性が高い
- データベースへの接続が中断された 最大送信単位 (MTU) のサイズを小さくします。
- MTU サイズにより、ネットワーク接続を介して 1 つのイーサネットフレームで転送できるパケットの最大サイズ (バイト単位) が決まります。
- データベースへの接続がタイムアウトした COPY コマンドなどの長いクエリを実行すると、データベースへのクライアント接続がハングまたはタイムアウトしているように見えます。この場合、Amazon Redshift コンソールにはクエリが完了したと表示されますが、クライアントツール自体はまだクエリを実行しているように見えることがあります。接続がいつ停止したかに応じて、クエリの結果がないか、不完全になる可能性があります。この効果は、中間ネットワークコンポーネントによってアイドル接続が終了すると発生します。
- MTU サイズにより、ネットワーク接続を介して 1 つのイーサネットフレームで転送できるパケットの最大サイズ (バイト単位) が決まります。
- ODBC 使用時にクライアント側のメモリ不足エラーが発生する
- クライアントアプリケーションが ODBC 接続を使用し、クエリで作成される結果セットが大きすぎてメモリが足りなくなる場合、カーソルを使用して、結果セットをクライアントアプリケーションに渡すことができます。
- JDBC 使用時にクライアント側のメモリ不足エラーが発生する
- JDBC 接続で大規模な結果セットを取得しようとすると、クライアント側のメモリ不足エラーが発生する可能性があります。
Kinesisシャードが不十分な場合
- リシャーディングによりシャードを分割するか
- シャードの分割では１ つのシャードを 2 つシャードに分けます。シャードの結合では、2 つシャードを 1 つのシャードに組み合わせます。リシャーディングは、1 回のオペレーションでシャードに分割できる数と 1 回のオペレーションで結合できるシャードの数が 2 個以下に限られるという意味で、常にペアワイズです。リシャーディングオペレーションの対象となるシャードまたはシャードペアは、親シャードと呼ばれます。リシャーディングオペレーションを実行した結果のシャードまたはシャードペアは、子シャードと呼ばれます。 分割によりストリーム内のシャードの数が増え、したがってストリームのデータ容量は増えます。シャード単位で請求されるため、分割によりストリームのコストが増えます。
- インスタンスサイズを増強するかで対応することでパフォーマンスを向上させる
- Kinesisストリーム内のインスタンスのサイズとシャードの数を増やすことで、インスタンスがインスタンス内で並行して実行されるより多くのレコードプロセッサを処理できるようにします。 また、ストリームが送信されるデータのレートに適切に対応できるようにします。ストリームのデータ容量は、ストリームに指定するシャードの数の関数です。
DNS フェイルオーバーの設定
- アクティブ/パッシブ
- Route 53 はプライマリリソースをアクティブに返します。エラーが発生すると、Route 53 はバックアップリソースを返します。フェイルオーバーポリシーを使用して設定されます。 プライマリリソースまたはリソースグループをほとんどの時間で利用可能にして、すべてのプライマリリソースが使用できなくなった場合に備えて、セカンダリリソースまたはリソースグループをスタンバイ状態にする場合は、フェイルオーバー (アクティブ/パッシブ) 設定を使用します。クエリへの応答で Route 53 が返すのは、正常なプライマリリソースのみです。すべてのプライマリリソースで異常が発生した場合、Route 53 は、DNS クエリへの応答として、正常なセカンダリリソースのみを返します。
- アクティブ/アクティブ
- Route 53 は複数のリソースをアクティブに返します。エラーが発生すると、Route 53 は正常なリソースに戻します。フェイルオーバー以外のルーティングポリシーを使用して設定されます。 フェイルオーバー (アクティブ/アクティブ)はすべてのリソースをほとんどの時間で利用できるようにするに使用します。リソースが利用できなくなると、そのリソースを Route 53 が異常として検出し、以後、クエリへの応答に含めることを控えます。すべてのリソースをほとんどの時間で利用できるようにするに使用します。リソースが利用できなくなると、そのリソースを Route 53 が異常として検出し、以後、クエリへの応答に含めることを控えます。
- 組み合わせ
- 複数のルーティングポリシー (例: レイテンシーベース、加重) は、複雑 DNS フェイルオーバーを設定するためにツリーに組み合わされています。
DNS フェイルオーバーに Route 53 ヘルスチェックを使用するにはどうすればよいですか?
アクティブ/パッシブフェイルオーバー:1 つのプライマリリソースと 1 つのセカンダリリソースを使用する最も簡単な方法
アクティブ/アクティブフェイルオーバー:複数のリソースを DNS クエリに返します。1 つのリソースに異常がある場合には、Route 53 は別のリソースにフェイルオーバーします。
組み合わせフェイルオーバー:複数のルーティングポリシーとヘルスチェックを組み合わせると、Route 53 が適切なレコードを返す前に複数層のレコードを通過する複雑なフェイルオーバーメカニズムを作成することもできます。
AWS Application Discovery Service
ADSはオンプレミスデータセンターに関する情報を収集し、移行プロジェクト計画を立案することを支援するAWSサービスです。データセンター移行計画には何千ものワークロードが存在し、多くの場合それらが相互に深く依存しあっています。サーバーの使用率データや依存関係のマッピングは、移行プロセス初期の重要なステップです。ADSでは、サーバーの設定データ、使用状況データ、動作データが収集されて、ユーザーに提供されます。これにより、ユーザーはワークロードを十分に把握することができます。
収集されたデータは、ADS のデータストアに暗号化形式で保存されます。このデータを CSV ファイルとしてエクスポートし、AWS で稼働した場合の総所有コスト (TCO) の見積もりや、AWS への移行計画に使用できます。また、このデータは AWS Migration Hub でも利用できます。このサービスでは、検出したサーバーを AWS に移行し、AWS に移行する際の進捗を追跡できます。
###Migration Hub
AWS およびパートナーの複数のソリューション間におけるアプリケーション移行の進行状況を 1 つの場所で追跡できます。Migration Hub を使用すると、ニーズに最も適する AWS およびパートナーの移行ツールを選択でき、アプリケーションのポートフォリオ全体で移行状態の可視性が得られます。Migration Hub では、移行にどのようなツールが使われていても、個々のアプリケーションの主要なメトリクスと進行状況を取得することもできます。
API Gatewayと統合したLambdaアプリケーション上でのHTTP 504エラ
INTEGRATION_FAILUREまたはINTEGRATION_TIMEOUTのどちらかを意味しています。
Lambda関数が基本は正常に機能しているが、ときどき処理が遅れる場合がある
Lambdaファンクションが実行しない場合にのみINTEGRATION_TIMEOUTエラーが発生していると考えます。
統合タイムアウトの範囲は、Lambda、Lambdaプロキシ、HTTP、HTTPプロキシ、AWS統合を含むすべての統合タイプの50ミリ秒から29秒
m3.largeインスタンスタイプを起動しているVPCとサブネットに対してIPv6を使用できるようにする
- m3.largeインスタンスタイプはIPv6をサポートしないため、インスタンスのサイズを、サポートされているインスタンスタイプ（m4.largeなど）に変更する必要があります。
- IPv4を利用しているVPCに対して、IPv6を有効にするためには、IPv6 CIDRブロックをVPCおよびサブネットに関連づけることで、IPv6が利用可能になります。
- IPv6 CIDRブロックをVPCおよびサブネットに関連付ける
- ルートテーブルを更新する
- セキュリティグループルールを更新する
- インスタンスタイプの変更
- インスタンスにIPv6アドレスを割り当てる
- インスタンスでIPv6を構成する
- DHCPv6を使用するように構成されていないAMIからインスタンスを起動した場合、インスタンスに割り当てられたIPv6アドレスを認識するようにインスタンスを手動で構成する必要があります
Amazon CloudWatch でクライアント側のメトリクスデータの集約が可能に
Amazon CloudWatch でクライアント側のメトリクスデータを集約して、単一の PutMetricData API コールでパブリッシュできるようになりました。これにより、大量のメトリクスデータを効率よくインジェストしながら、API コール数が減ることでコストを削減することもできます。
クライアント固有のIPアドレスを取得する
ELBはクライアントの IP アドレスを X-Forwarded-For リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。 したがって、 X-Forwarded-For リクエストヘッダーを確認することでクライアント個別にIPアドレスを取得する
HTTP リクエストと HTTP レスポンスは、ヘッダーフィールドを使用して HTTP メッセージに関する情報を送信します。ヘッダーフィールドはコロンで区切られた名前と値のペアであり、キャリッジリターン (CR) とラインフィード (LF) で区切ります。HTTP ヘッダーフィールドの標準セットが RFC 2616 の「Message Headers」で定義されています。アプリケーションで広く使用されている標準以外の HTTP ヘッダーもあります。標準以外の HTTP ヘッダーには X-Forwarded というプレフィックスが付いている場合があります。クラシックロードバランサー は、次の X-Forwarded ヘッダーをサポートしています。
X-Forwarded-For リクエストヘッダーは、HTTP または HTTPS ロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント/サーバー間のトラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認するには、X-Forwarded-For リクエストヘッダーを使用します。