DevelopersIO基盤を「パブリックサブネットレス」なECS構成に移行してみた
当ブログ（DevelopersIO）のバックエンド基盤について、以前より検証を進めていた Regional NAT Gateway と CloudFront VPC Origin を利用したパブリックサブネットレス構成への移行を行い、本番稼働を開始しました。
本記事では、パブリックサブネットを完全に排除したネットワーク構成の詳細、ARMアーキテクチャ（Fargate/Graviton）の導入検証、およびコスト最適化に向けた検討について紹介します。
1. 構成概要：パブリックサブネットレスへの移行
以前の記事で検証した、パブリックサブネットレスなVPCを採用したアーキテクチャをベースに、本番・開発・DRの各環境を整備しました。
全体構成
最大の特徴は、VPC内からパブリックサブネットを廃止。すべてのコンピュートリソースをプライベートサブネットに配置した点です。
- Regional NAT Gateway: マルチAZ冗長化に対応しつつ、従来のNAT Gateway配置に必要なパブリックサブネットを不要にしました。
- ECS + Internal ELB: コンテナおよびロードバランサーは全てプライベート領域で稼働します。
- CloudFront VPC Origin: CloudFrontからInternal ALBへの接続を行い、インターネットからの直接アクセスを遮断しました。
開発環境：ECS Express Modeの活用
開発・テスト環境においては、コスト効率とデプロイ速度を最優先し、ECS Express Modeを採用しました。
- 共用ELB: 10前後の実行環境（Express Mode適用サービス）に対し、単一のELBを共用させる設定を投入しました。これにより、サービスごとにALBを作成する場合と比較して固定費を大幅に抑制しています。
- SSL証明書の挙動: CloudFront VPC Originを利用するにはHTTPSが必須となりますが、検証の結果、Express Modeでは「aws」ドメインの証明書が自動提供されることを確認しました。これによりDNSレコード（ACM用）の追加作業が不要となり、環境払い出しのリードタイム短縮に寄与しています。
2. パフォーマンス検証：ARMアーキテクチャの採用とGraviton4の導入
本番環境の構築にあたり、x86アーキテクチャとARMアーキテクチャのどちらを採用すべきか、性能とコストの両面から検証を行いました。
Fargateにおける x86 vs ARM 比較
まず、Fargate環境(vCPU 1, メモリ 2GB, 月間730時間稼働)にてコストと、ALBのアクセスログより応答性能の比較を実施しました。
| 環境 | 平均応答時間 | 月額コスト (概算) |
|---|---|---|
| x86 Fargate (On-Demand) | 0.149 - 0.182秒 | 約$45 |
| ARM Fargate (On-Demand) | 0.163 秒 | 約$36 |
| ARM Fargate (Spot) | --- | $11.23 |
ARM Fargate Spotを利用した場合、x86オンデマンドと比較して応答時間の差は僅か（0.01-0.02秒程度）に留まりました。
一方でコストは大きく抑制できることが判明したため、本番環境では積極的にSpotとARMアーキテクチャを採用する方針を固めました。
EC2 Graviton世代別ベンチマーク
上記の方針に基づき、通常のECS（EC2起動タイプ）についてもGravitonファミリーを選定対象とし、各世代（Graviton2, 3, 4）のパフォーマンステストを実施しました。
条件: vCPU 1, メモリ 2GB, 1インスタンス/1タスク
| インスタンス | CPU世代 | 平均応答時間 | P90応答時間 | スポット節約率 |
|---|---|---|---|---|
| m8gd.large | Graviton4 | 0.150秒 | 0.398秒 | 66.95% |
| m7gd.large | Graviton3 | 0.160秒 | 0.422秒 | 66.68% |
| im4gn.large | Graviton2 | 0.193秒 | 0.497秒 | 77.51% |
ログ分析の結果、以下の結論に至りました。
- Graviton4 (m8gd) の採用: 最新世代が最も低遅延であることを確認しました。また、m8gd（ディスク付き）と m8g（ディスクなし）の価格差も微小であるため、本番環境ではm8gdを中心に採用し、内蔵のインスタンスストア（NVMe SSD）を
/tmpおよびswap領域としてマウント・活用する設定を行いました。 - Graviton2 (im4gn) の不採用: 応答時間が m8g、m7g 世代と比較して劣る事が確認できたため、一旦採用を見送りました。
3. 本番運用の可用性確保：ハイブリッド構成
本番環境ではコスト削減と可用性維持を両立させるため、EC2とFargateのハイブリッド構成を組みました。
在庫切れ対策:
スポットインスタンスの中断リスクに備え、以下の分散設定を適用しています。
- 複数AZ: 3AZ全てでタスク起動を許可。
- インスタンスタイプの多様化: m7gd, m8gd, r8gd 等、複数のファミリーを候補として設定。
4. ネットワークコストの最適化検証
専用ELBの採用
本番環境では専用ELB（Internal ALB）を配置しました。Internal ALBはIPv4課金（Public IPv4アドレス利用料）が発生しないため、3AZ対応の高可用性構成でも固定費用の追加を抑制できました。これにより、アクセスログやメトリクスの分離が容易になり、障害調査効率が向上しています。
NAT Gateway vs VPC Endpoints
ECR等のAWSサービスへの通信経路として、Interface VPC Endpoint (VPCE) を利用するか、NAT Gatewayを利用するか比較検討しました。
- VPCEの場合:
- 3サービス × 3AZ × $75〜$90/月額固定コスト増加
- NAT Gatewayの場合:
- ECRなどの通信量は月間数十GBの見込み。処理データ料金も月額数ドルに収まる試算になりました。
今回のトラフィック規模ではVPCEを導入するよりもNAT Gateway経由の方が圧倒的に安価であると判断しました。また、将来的なIPv6 DualStack対応によるEgress-Only Internet Gateway利用（NAT Gateway通信費の削減）も見据えた構成としています。
5. 運用改善とDR戦略
ECS Express Modeのデプロイ短縮
ECS Express Modeのデプロイにおいて、デフォルト設定では完了までに時間を要する事象を確認しました。CodeDeployの設定を手動で変更し、検証を行いました。
- Canaryベイク時間: 3分 → 0分
- デプロイベイク時間: 3分 → 0分
この設定変更により、デプロイ時間を最大6分短縮できることを確認しました。
DR環境：App Runnerの再登板
2023年よりフロントエンド運用に利用していたApp Runnerですが、アクセスログ取得の難易度やWAFコストの観点から、メイン環境からは外す判断をしました。現在は以下の構成で「バージニアリージョンへのDR（待機系）」として稼働させています。
- App Runner: 月額$10前後で待機系環境を維持。
- ECR Replication: 東京からバージニアへのイメージ同期を自動化。
- StepFunctions: SDK統合でLambdaレスでのApp Runnerデプロイ実現
- CloudFront Failover: 500系エラー検知時の自動切り替え。
BCP対策として、極めて高いコストパフォーマンスを発揮しています。
まとめ
Regional NAT GatewayとECS Express Modeを活用した新基盤へ移行し、以下の成果を確認しました。
- 構成: パブリックサブネットレスなセキュアVPC構成を本番環境で実現しました。
- 性能: 最新のGraviton4 (m8gd) を採用、ARMアーキテクチャによるコスト効率と高性能の両立を実現しました。
- コスト: スポットインスタンス活用と不要なVPCE、IPv4利用の最小化により、VPC、ECSを採用した環境でも、コスト増加を最小限に留めました。
AWSのIPv6サポート範囲が広がり、NAT Gateway費用の抑制や、最終的にはNAT Gateway、VPCエンドポイントレスなVPCネットワーク利用に期待したいと思います。
