はじめに

本記事では、AWS ECS をプライベートサブネットで運用している際に Firebase Authentication がタイムアウトする問題について、
原因を切り分け、最終的に Redis Serverless（Valkey）の仕様に行き着いた過程と解決策を解説します。
Firebase 側の問題に見えて、実際は Redis の接続仕様が原因というケースは非常にハマりやすいため、同様の構成で困っている方の参考になれば幸いです。

この記事でわかる・できること

ECS（プライベートサブネット）から Firebase Auth に接続できない原因の切り分け方法
「ECS Exec は成功するのにアプリは通信できない」理由
ElastiCache Redis Serverless（Valkey）の罠仕様
問題を確実に解消するための実践的な解決策

この記事の対象者

ECS + Rails API を使っている人
Firebase Authentication をバックエンドで検証している人
ElastiCache（特に Serverless / Valkey）を初めて使う人
「ネットワークは通っているはずなのに Timeout する」問題で詰まっている人

動作環境・使用するツールや言語

OS：Amazon Linux（ECS Fargate）
AWS：ECS Fargate（Private Subnet）, ElastiCache
言語：Ruby 3.4.4
フレームワーク：Rails 8.0.2
Firebase Authentication
redis / firebase_id_token gem

1. 発生した問題の概要

ECS（プライベートサブネット）上で稼働する Rails API において、
Firebase Authentication を使ったリクエストが常にタイムアウトしてしまいました。

ログ上では以下のようなエラーが出力されていました。

証明書の取得に失敗しました: Connection timed out

一見すると、

Firebase 側の障害
ECS からインターネットに出られない
DNS / NAT / VPC Endpoint の設定ミス

などが疑われます。

2. ECS Exec は成功するのに、なぜアプリは通信できないのか

まず混乱しやすいポイントとして、ECS Exec は問題なく成功していました。

ECS Exec ✅ 成功
コンテナ内で curl htps://www.googleapis.com/...(Firebaseのドメイン) ✅ 成功

ここで多くの人がこう考えます。

「Firebase へは到達できている。じゃあ、どこのネットワークが悪い？」

しかし、これが落とし穴でした。

3. Firebase Auth は「直接通信」だけでは完結しない

Rails で Firebase Authentication を扱う際、多くの場合、

firebase_id_token gem

を利用します。

この gem で取得した公開鍵(証明書)をRedisにキャッシュする設計としていました。
処理は以下の流れになっています。

Google から公開鍵（証明書）を取得
Redis にキャッシュ
次回以降は Redis から読み込み

firebase_id_token gemを使った場合のplantUML図

つまり、
Redis に接続できないと Firebase Auth も失敗する
という構造です。

4. 真犯人は Redis Serverless（Valkey）の仕様

今回使用していた Redis は以下でした。

ElastiCache Serverless
エンジン：Valkey 8.x
転送中の暗号化：有効（必須）

Redis Serverless の重要な仕様

項目	Redis Serverless
ポート	6379
TLS	必須
平文接続	❌不可
対応クライアント	TLS 対応必須

Rails 側では以下のように初期化していました。

Redis.new(url: ENV["REDIS_URL"])

これは TLS 非対応（平文）接続です。

何が起きていたか

TCP 接続は成立
Redis 側は TLS を待つ
クライアントは平文を送信
お互いに一切応答せず timeout

結果として、以下の状態となっていました。

redis.ping → Redis::TimeoutError
Firebase 証明書キャッシュ失敗
認証エラー

5. なぜ気づきにくいのか（ハマりポイント）

この問題が厄介な理由は以下です。

セキュリティグループ ✅ 正しい
DNS ✅ 正常
Google への curl ✅ 成功
ECS Exec ✅ 成功

👉 「ネットワークは全部 OK」に見えます。
しかし実際は、

Redis Serverless の TLS 強制仕様

というサービス固有の制約が原因でした。

6. 解決策（確実に直す方法）

解決策は大きく分けて 2 つあります。

方法① Redis OSS（非Serverless）に切り替える（おすすめ）

MVP・個人開発ではこれが最短・最安定です。

ElastiCacheからRedis OSS キャッシュに移行します。

転送中の暗号化：OFF
REDIS_URL だけで接続可能

Redis.new(url: ENV["REDIS_URL"])

設定がシンプルで移行コストも最小化できます。

方法② Redis Serverless を使い続ける場合

TLS を明示的に指定する必要があります。

Redis.new(
  url: ENV["REDIS_URL"],   # 接続先RedisのURL（環境変数REDIS_URLから取得）
  ssl: true,               # SSL（暗号化通信）を有効化
  ssl_params: {            # SSLの詳細パラメータ指定
    verify_mode: OpenSSL::SSL::VERIFY_PEER
  })

※ 本番では CA 証明書を使った検証が推奨です。

まとめ

今回の問題は、Firebase の障害でも、ECS のネットワーク設定でもなく、Rails の実装ミスでもありませんでした。

原因は 「Redis Serverless（Valkey）は TLS 必須」 という仕様です。

本記事のポイント

Redis Serverless は平文接続できない
MVP では Redis OSS の方が圧倒的に楽
「Timeout」はネットワーク以外が原因のことも多い

同じ構成で悩んでいる方の助けになれば幸いです。