Aws ecs service connect ipv6
Skill h3y6e/agent-skills/.vendor/skills/aws-ecs-service-connect-ipv6
ECS Service Connect の DNS alias が IPv6 アドレスを返して、IPv4-only の Fargate task から `network is unreachable` で接続できない問題の回避策。OTel Collector → Tempo の OTLP gRPC で頻出。From its SKILL.md
npx -y skills add h3y6e/agent-skills --skill aws-ecs-service-connect-ipv6Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
ECS Service Connect の IPv6 alias で詰まったとき
症状
Fargate task の中から Service Connect alias (<service>.<namespace>.local:<port>) に接続しようとして次のエラー:
dial tcp [2600:f0f0::3]:<port>: connect: network is unreachable
2600:f0f0::3 は AWS Service Connect Envoy proxy が listen する IPv6 アドレス。
原因
ECS Service Connect は service alias に IPv4 + IPv6 の両方を登録する (Envoy proxy が dual-stack listen)。一方 Fargate awsvpc task は IPv4 only がデフォルト。grpc-go や他の dual-stack client が DNS の最初に返ってきた IPv6 を選ぶと、IPv6 outbound 経路が無いので unreachable。
回避策(楽な順)
A. プロトコルを HTTP に切り替える
OTLP gRPC (4317) の代わりに OTLP HTTP (4318) を使う。HTTP client (Go の net/http 等) は IPv4 を試行することが多く、dual-stack dial の問題を踏みにくい。
OpenTelemetry Collector の例:
exporters:
# 旧: otlp (gRPC) で IPv6 で詰まる
# otlp/tempo:
# endpoint: tempo.study-aws.local:4317
# 新: otlphttp で OK
otlphttp/tempo:
endpoint: http://tempo.study-aws.local:4318
tls:
insecure: true
service:
pipelines:
traces:
exporters: [otlphttp/tempo]
target 側の Service Connect 設定は HTTP port (4318) も alias にしておく:
service_connect_configuration {
service {
port_name = "otlp-grpc"
discovery_name = "tempo"
client_alias { port = 4317; dns_name = "tempo.study-aws.local" }
}
service {
port_name = "otlp-http"
discovery_name = "tempo-http"
client_alias { port = 4318; dns_name = "tempo.study-aws.local" }
}
}
B. Cloud Map private DNS namespace + A record (IPv4 only)
Service Connect (aws_service_discovery_http_namespace) ではなく Service Discovery (aws_service_discovery_private_dns_namespace) + aws_service_discovery_service で A record を直接登録。Envoy proxy が挟まらず Cloud Map の A record (IPv4) が直接返る。AWS::ServiceDiscovery::Service の DnsConfig.DnsRecords を A のみにする。
ECS Service の service_registries 経由で attach する。Service Connect の機能 (Envoy mesh) は使えなくなるが、IPv6 issue は出ない。
C. クライアント側で IPv4 を強制
Go なら GODEBUG=netdns=go+1 で gai.conf 設定を有効化、/etc/gai.conf に precedence ::ffff:0:0/96 100 で IPv4 priority。container env で渡せる。
ただし build-once な image だと毎度の再 build 必要、Service Connect 設定変更より重い。
診断
ECS Task の中から DNS resolve を確認:
aws ecs execute-command --cluster <c> --task <t> --container <name> --interactive --command "/bin/sh -c 'getent hosts tempo.study-aws.local'"
IPv6 が返るなら本症状確定。
関連
- gRPC は HTTP/2 ベースだが、
grpc-goの resolver は IP family の優先順を制御しにくい appProtocol = "grpc"を Service Connect の portMappings に書くと Envoy が gRPC として handle するが、IPv6 issue は別問題
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.