翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
VPC ネットワークのトラブルシューティング
ネットワークのモニタリングとトラブルシューティング
CloudTrail ロギング
VPC ネットワークを使用した設定 API オペレーションとワークフロー実行はすべて CloudTrail に記録されます。CloudTrail を使用して設定変更を監査し、VPC ネットワークを使用する実行を追跡します。
ENI フローログを使用したトラブルシューティング
ワークフローの実行時にインターネット経由で外部リソースにアクセスする場合、VPC フローログを使用して接続を検証し、問題を診断できます。HealthOmics は、VPC サブネットに Elastic Network Interface (ENIs) をプロビジョニングして、ワークフロータスクからのトラフィックをルーティングします。これらの ENIs のフローログを調べることで、外部送信先との間のネットワークトラフィックをトレースできます。
VPC フローログのコスト管理
VPC フローログは、特に VPC レベルで大きなコストが発生する可能性があります。コストを最小限に抑えるには:
トラブルシューティング後にフローログを削除します。接続の問題を解決したら、フローログを削除して料金の発生を停止します。
長期ストレージには、CloudWatch Logs の代わりに Amazon S3 を使用します。Amazon S3 ストレージは CloudWatch Logs よりも大幅に安価です。コンプライアンスまたはセキュリティ分析のためにログを保持する必要がある場合は、フローログを設定して Amazon S3 に発行します。
CloudWatch Logs の保持ポリシーを設定します。CloudWatch Logs を使用する場合は、無期限のストレージコストを防ぐために、自動ログの有効期限 (7 日間など) を設定します。
トラブルシューティングには ENI レベルのフローログを使用します。1 回限りのデバッグの場合は、VPC 全体ではなく、特定のカスタマー ENI にフローログを作成します。
トラブルシューティング用のフローログの設定
オプション 1: VPC レベルのフローログ (継続的なモニタリング用)
VPC のフローログを有効にして、すべての HealthOmics ワークフロー実行からのトラフィックを自動的にキャプチャします。これは、多数のワークフロー実行があり、個々の ENIs を追跡せずに包括的な可視性が必要な場合に最適です。
-
VPC フローログを有効にします。Amazon VPC コンソールで:
VPCs を選択し、HealthOmics 設定で使用される VPC を選択します。
フローログタブを選択する
フローログの作成を選択する
すべてのトラフィック (受け入れられたトラフィックと拒否されたトラフィックの両方) をキャプチャするようにフローログを設定する
クエリを容易にするために CloudWatch Logs を送信先として選択する
-
ワークフロー実行を開始します。VPC ネットワークを有効にしてワークフロー実行を開始します。後でフローログをフィルタリングするための実行 ID と開始時刻を書き留めます。
時間枠、送信先 IP、またはトラフィックパターン別に CloudWatch Logs Insights を使用してフローログをクエリします。特定の ENI IDs を識別する必要はありません。
オプション 2: ENI レベルのフローログ (ターゲットを絞ったトラブルシューティング用)
アカウントにいくつかの ENIs しかない場合ENIs のフローログを有効にします。 HealthOmics これは最も費用対効果の高いアプローチであり、特定のワークフロー実行のトラフィックを簡単に分離できます。
-
お客様の ENI を見つけます。Amazon EC2 コンソールで:
ネットワークインターフェイスの選択
タグでフィルタリング
Service: HealthOmicsして、HealthOmics によって作成された ENIs のみを表示するオプションで、HealthOmics 設定のサブネット ID でさらにフィルタリングします。
ENI ID とプライベート IP アドレスを書き留めます。
-
ENI でフローログを有効にします。
ENI を選択し、フローログタブを選択します。
フローログの作成を選択する
すべてのトラフィックをキャプチャするようにフローログを設定する
送信先として CloudWatch Logs を選択する
注記
フローログは、有効にした時点からのトラフィックのみをキャプチャします。VPC レベルのフローログの場合は、ワークフローを実行する前に有効にします。ENI レベルのフローログの場合、ENI で有効にすると、同じフローログが、その ENI を使用する今後のすべてのワークフロー実行のトラフィックをキャプチャします。
VPC フローログの形式について
VPC フローログは、次のフィールドを含むスペース区切り形式を使用します。
version account_id interface_id srcaddr dstaddr srcport dstport protocol packets bytes start end action log_status
フィールドの説明:
バージョン — フローログ形式バージョン (通常は 2)
account_id — AWS アカウント ID
interface_id — ENI ID (eni-0e57c5476efeac402 など)
srcaddr — ソース IP アドレス
dstaddr — 送信先 IP アドレス
srcport — ソースポート番号
dstport — 送信先ポート番号
プロトコル — IANA プロトコル番号 (6=TCP、17=UDP、1=ICMP)
パケット — フロー内のパケットの数
bytes — フロー内のバイト数
start — フロー開始時刻 (Unix タイムスタンプ)
end — フロー終了時刻 (Unix タイムスタンプ)
アクション — 承諾または拒否
log_status — OK、NODATA、または SKIPDATA
フローログエントリの例:
2 074296239033 eni-0e57c5476efeac402 10.0.130.58 13.226.238.96 40565 443 6 13 1502 1774338927 1774338929 ACCEPT OK 2 074296239033 eni-0e57c5476efeac402 13.226.238.96 10.0.130.58 443 40565 6 8 1024 1774338928 1774338930 ACCEPT OK
これらのエントリは、双方向 HTTPS 通信の成功を示します。キー IPs: 10.0.130.58 はアカウントの HealthOmics によって作成されたカスタマー ENI であり、13.226.238.96 はワークフローがアクセスしている外部パブリックドメインです。最初のエントリはアウトバウンドトラフィックで、2 番目のエントリはリターントラフィックです。どちらも ACCEPT と表示され、トラフィックがセキュリティグループによって許可されたことを示します。
CloudWatch Logs Insights でのフローログのクエリ
フローログが CloudWatch Logs に公開されたら、CloudWatch Logs Insights を使用してデータをクエリおよび分析します。
拒否されたトラフィックを検索する (ここから開始)
fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action | filter action = "REJECT" | sort @timestamp desc
結果が返された場合は、接続に問題がある可能性があります。拒否されたエントリは、セキュリティグループまたはネットワーク ACLs によってブロックされているトラフィックを示します。
特定の外部 IP へのトラフィックを検索する
まず、 nslookupまたは を使用してドメインを IP アドレスに解決しますdig。
$ nslookup ftp.ncbi.nlm.nih.gov Server: 127.53.53.53 Address: 127.53.53.53#53 Non-authoritative answer: ftp.ncbi.nlm.nih.gov canonical name = ftp.wip.ncbi.nlm.nih.gov. Name: ftp.wip.ncbi.nlm.nih.gov Address: 130.14.250.10 Name: ftp.wip.ncbi.nlm.nih.gov Address: 130.14.250.11
上部の「Server」と「Address」は DNS リゾルバーです。「非権威回答」 (130.14.250.10 および 130.14.250.11) のアドレスは、ドメインの実際の IP です。 IPs
プレフィックスを使用してフローログをクエリし、その範囲内の任意の IP に一致させます。
fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action | filter dstAddr like "130.14.250" | sort @timestamp desc
これは、130.14.250 で始まるすべての IP に一致し、そのサブネット内のすべての IPsをキャプチャします。
外部送信先への HTTPS トラフィックを検索する
fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action | filter dstPort = 443 and protocol = 6 | filter not (dstAddr like /^10\./ or dstAddr like /^172\./ or dstAddr like /^192\.168\./) | sort @timestamp desc
2 番目のフィルターはプライベート IP 範囲を除外し、外部 (パブリック) 送信先へのトラフィックのみを表示します。
注記
プロトコル番号: 6=TCP、17=UDP、1=ICMP。負荷分散されたサービス (CloudFront など) の場合、DNS は異なる IPs を返す可能性があるため、IP アドレスではなく送信先ポートでフィルタリングします。
一般的なフローログのパターンと問題
- アウトバウンドトラフィックが拒否されました
-
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 13.226.238.96 40565 443 6 1 60 1774338927 1774338929 REJECT OK原因: セキュリティグループは、送信先ポートまたは IP 範囲へのアウトバウンドトラフィックを許可しません。
解決策: セキュリティグループにアウトバウンドルールを追加します。
HTTPS の場合: TCP ポート 443 から 0.0.0.0/0 を許可する
HTTP の場合: TCP ポート 80 から 0.0.0.0/0 を許可する
より広範なアクセスの場合: すべての TCP/UDP を 0.0.0.0/0 に許可する
- 拒否されたトラフィックを返す
-
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 8.8.8.8 54321 53 17 1 64 1774338927 1774338929 ACCEPT OK Return: 2 074296239033 eni-0e57c5476efeac402 8.8.8.8 10.0.130.58 53 54321 17 1 64 1774338928 1774338930 REJECT OK原因: ネットワーク ACL がリターントラフィックをブロックしています。セキュリティグループ (ステートフル) とは異なりACLs はステートレスであり、双方向に明示的なルールが必要です。
解決策: VPC コンソールで、サブネットのネットワーク ACL を確認し、インバウンドルールが外部ソースからのエフェメラルポート (1024-65535) でのトラフィックを許可していることを確認します。必要に応じてルールを追加する: 0.0.0.0/0 から TCP/UDP ポート 1024-65535 を許可する
- リターントラフィックの欠落
-
Outbound: 2 074296239033 eni-0e57c5476efeac402 10.0.130.58 8.8.8.8 54321 53 17 1 64 1774338927 1774338929 ACCEPT OK原因: NAT ゲートウェイ/インターネットゲートウェイが正しく設定されていないか、ENI がインターネットに接続されていません。
解決策:
ルートテーブルに NAT ゲートウェイへのルートがあることを確認する (0.0.0.0/0 → nat-xxxxx)
Elastic IP を使用して NAT ゲートウェイが AVAILABLE 状態であることを確認します。
NAT Gateway がインターネットゲートウェイへのルートを持つパブリックサブネットにあることを確認する
- 予想されるトラフィックのフローログエントリがない
-
原因: トラフィックが ENI に到達しないか、フローログが正しく設定されていません。
解決策:
フローログが有効で、すべてのトラフィックをキャプチャするように設定されていることを確認します。
CloudWatch Logs のワークフローログをチェックして、ワークフローが外部リソースにアクセスしようとしていることを確認します。
ルートテーブルに NAT ゲートウェイへのルートがあることを確認する (0.0.0.0/0 → nat-xxxxx)
Elastic IP を使用して NAT ゲートウェイが AVAILABLE 状態であることを確認します。
フローログのトラブルシューティングのベストプラクティス
-
トラブルシューティングを開始する前に、フローログを有効にします。フローログは、有効になってからのトラフィックのみをキャプチャします。ワークフローを実行する前に、HealthOmics 設定のすべてのサブネットでそれらを有効にします。
-
分析には CloudWatch Logs Insights を使用します。CloudWatch Logs Insights は、フローログの強力なクエリ機能を提供します。一般的に使用されるクエリを保存して、すばやくアクセスできるようにします。
-
時間枠でフィルタリングします。ワークフロー実行がアクティブだった特定の時間枠にフローログクエリを絞り込んで、ノイズを減らし、クエリのパフォーマンスを向上させます。
-
トラフィックの両方向を探します。アウトバウンドトラフィックとリターントラフィックの両方に ACCEPT が表示されていることを確認します。接続には双方向通信が必要です。
-
検出結果を文書化します。接続の問題をトラブルシューティングするときは、お客様の ENI ID、IP アドレス、ポート、フローログエントリを文書化します。この情報は、サポートケースや今後のトラブルシューティングに役立ちます。
-
まずシンプルなワークフローでテストします。複雑なワークフローを実行する前に、外部リソースへのアクセスを試みて結果をログに記録するシンプルなワークフローで接続をテストします。これにより、ネットワーク問題をワークフローロジックの問題から分離できます。
設定のトラブルシューティング
CREATING ステータスで設定がスタックする
原因: ネットワークリソースのプロビジョニングには数分かかる場合があります。
解決策: 最大 10 分待ちます。ステータスが ACTIVE に変わらない場合は、以下を確認してください。
サブネットとセキュリティグループが存在し、同じ VPC にあります。
必要な IAM アクセス許可があります。
サービスにリンクされたロールが正常に作成されました。
実行が VPC ネットワークで開始されない
原因: 設定が ACTIVE ではないか、ネットワーク接続に問題がある可能性があります。
解決策:
を使用して、設定ステータスが ACTIVE であることを確認します
GetConfiguration。セキュリティグループルールで、必要なアウトバウンドトラフィックが許可されていることを確認します。
サブネットが HealthOmics が動作するアベイラビリティーゾーンにあることを確認します。
設定を削除できません
原因: 設定はアクティブなワークフロー実行で使用されています。
解決策: 設定を使用してすべての実行が完了するまで待ってから、削除を再試行してください。
サービスにリンクされたロールは削除できません
原因: アクティブな VPC 設定がアカウントに存在します。
解決策: まずすべての VPC 設定を削除してから、サービスにリンクされたロールを削除します。
ワークフローが外部リソースに接続できない
原因: セキュリティグループまたはルートテーブルの設定ミス。
解決策:
VPC フローログを有効にして拒否されたパケットを識別する
セキュリティグループのアウトバウンドルールが送信先へのトラフィックを許可することを確認する
ルートテーブルに NAT Gateway へのルートがあることを確認する (0.0.0.0/0 → nat-xxxxxx)
クロスリージョン AWS サービスアクセスの場合は、送信先リージョンに到達可能であることを確認します。
同じサブネット内の Amazon EC2 インスタンスからの接続をテストする
ネットワークパフォーマンスの問題
症状: データ転送またはワークフローのタイムアウトが遅い。
原因: ネットワークスループットの制限または NAT ゲートウェイの飽和。
解決策:
ネットワークスループットは ENI あたり 10 Gbps から始まり、持続的なトラフィックで 60 分間で最大 100 Gbps までスケールします。
即時の高スループット要件があるワークフローについては、 サポートにお問い合わせください。 AWS
CloudWatch で NAT Gateway メトリクスをモニタリングして飽和度を特定する
スループットを高めるために、追加の NAT ゲートウェイを複数のアベイラビリティーゾーンにデプロイすることを検討する
ワークフローがインターネットにアクセスできない
原因: プライベートサブネットに NAT ゲートウェイへのルートがないか、セキュリティグループルールがアウトバウンドトラフィックをブロックしている可能性があります。
解決策:
プライベートサブネットのルートテーブルに NAT ゲートウェイへのルート (0.0.0.0/0 → nat-xxxxxxxxx) が含まれていることを確認します。
セキュリティグループルールで、必要なポートでのアウトバウンドトラフィックが許可されていることを確認します。
NAT ゲートウェイがインターネットゲートウェイへのルートを持つパブリックサブネットにあることを確認します。
ワークフロー実行が接続エラーで失敗する
原因: ネットワークトラフィックがブロックされているか、設定が間違っている可能性があります。
解決策:
を使用して、設定がまだ ACTIVE ステータスであることを確認します
GetConfiguration。VPC 内の ENIs に VPC フローログを作成して、トラフィックを検査します。詳細については、「Amazon VPC ユーザーガイド」の「VPC フローログを使用した IP トラフィックのログ記録」を参照してください。
REJECT エントリのフローログを確認します。拒否されたパケットが表示された場合は、セキュリティグループのルールを更新して、必要なアウトバウンドトラフィックを許可します。
フローログに根本原因が明らかになっていない場合は、 AWS サポートにお問い合わせください。