Go（Gin）APIをECS Fargate・RDS・ALB・Route 53でマルチAZ構成にデプロイする

はじめに

Go（Gin）で作成したWeb APIをAWSへデプロイしました。

コンテナはAmazon ECS on AWS Fargate、データベースはAmazon RDS for PostgreSQLで実行します。Application Load Balancer（ALB）、Route 53、AWS Certificate Manager（ACM）を組み合わせ、独自ドメインからHTTPSでアクセスできるマルチAZ構成にしました。

この記事では、Dockerfileの準備からECR、ECS、RDS、ALB、Route 53の設定までを順番にまとめます。

構築要件

• ECS Fargateでアプリケーションを実行する
• Amazon RDS for PostgreSQLを使用する
• 2つのアベイラビリティゾーンを利用する
• Application Load Balancerを使用する
• Route 53で独自ドメインを管理する
• ACMでSSL/TLS証明書を発行する
• HTTPをHTTPSへリダイレクトする
• ECSタスクのヘルスチェックを有効にする
• RDSをインターネットへ直接公開しない

構成概要

項目	設定
リージョン	東京（ap-northeast-1）
VPC CIDR	10.0.0.0/24
AZ	ap-northeast-1a / ap-northeast-1c
コンテナレジストリ	Amazon ECR
コンテナ実行環境	Amazon ECS on AWS Fargate
ECSサービス	Desired count 2
ロードバランサー	Application Load Balancer
データベース	Amazon RDS for PostgreSQL（Multi-AZ）
DNS	Amazon Route 53
独自ドメイン	my-golang-api.com
証明書	AWS Certificate Manager
アプリケーションポート	8080
PostgreSQLポート	5432

User
  ↓
Route 53
  ↓
Application Load Balancer
  ├─ HTTP:80 → HTTPS:443へ301リダイレクト
  └─ HTTPS:443 → ターゲットグループ
                    ↓
              ECS Fargate
                    ↓
            RDS for PostgreSQL

1. DockerfileをFargate向けに準備する

ビルド環境・開発環境・本番環境を分離するマルチステージビルドを使用しました。

FROM golang:1.26-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server .

FROM builder AS development

RUN go install github.com/air-verse/air@latest
CMD ["air", "-c", ".air.toml"]

FROM alpine:3.20 AS production

WORKDIR /app

RUN apk add --no-cache ca-certificates tzdata curl

COPY --from=builder /app/server /app/server

EXPOSE 8080

CMD ["/app/server"]

マルチステージビルド

Go SDKが必要なのはコンパイル時だけです。本番イメージにはコンパイル済みバイナリだけをコピーし、イメージサイズと不要な依存関係を減らします。

• builder：Goアプリケーションをコンパイル
• development：Airを利用するローカル開発環境
• production：ECSで実行する本番環境

本番用は明示的にproductionを指定します。

docker build --target production -t my-golang-app:v⚪︎ .

⚪︎はビルドする数字を記入する。

OSとCPUアーキテクチャを一致させる

GOOS=linuxはFargateのLinux環境で実行するための指定です。CGO_ENABLED=0により、外部Cライブラリへの依存を減らします。

Apple SiliconのMacでECSタスク定義がX86_64の場合は、次のようにビルドします。

docker buildx build \
  --platform linux/amd64 \
  --target production \
  -t <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/my-golang-app:v2 \
  --push .

Dockerイメージ	ECSタスク定義
linux/amd64	X86_64
linux/arm64	ARM64

不一致の場合、ECSでexec format errorなどが発生します。

ポートを統一する

設定箇所	ポート
Gin	8080
Dockerfile	8080
ECSタスク定義	8080
ターゲットグループ	8080
ECS用セキュリティグループ	8080

EXPOSE 8080だけで通信が許可されるわけではありません。実際の通信可否はECSのポートマッピング、セキュリティグループ、ターゲットグループで決まります。

Ginはコンテナ外部から接続できる状態で待ち受けます。

if err := router.Run(":8080"); err != nil {
    log.Fatal(err)
}

127.0.0.1:8080だけで待ち受けると、ALBから接続できません。

ヘルスチェックを用意する

router.GET("/health", func(c *gin.Context) {
    c.JSON(http.StatusOK, gin.H{"status": "ok"})
})

ECSとALBのヘルスチェックパスを/healthへ統一します。タスク定義のコンテナヘルスチェック例は次のとおりです。

{
  "command": [
    "CMD-SHELL",
    "curl -fsS http://localhost:8080/health || exit 1"
  ],
  "interval": 30,
  "timeout": 5,
  "retries": 3,
  "startPeriod": 30
}

ヘルスチェックで使用するcurlやwgetが本番イメージに存在しないと、アプリケーションが動いていてもタスクはUNHEALTHYになります。

機密情報を含めない

DBパスワードやAWSアクセスキーをDockerfileのENVへ書いてはいけません。削除後もイメージレイヤーに残る可能性があります。本番のDB認証情報はSecrets Managerに保存し、ECSタスク定義から参照します。

.dockerignoreも用意します。

.git
.gitignore
.env
.env.*
README.md
tmp
coverage.out
*.log
.DS_Store

2. VPCとサブネットを作成する

• VPC名：my-golang-app-vpc
• IPv4 CIDR：10.0.0.0/24
• DNS解決：有効
• DNSホスト名：有効

用途ごとに6つのサブネットを作成します。

用途	AZ	CIDR
Public subnet	1a	10.0.0.0/27
Public subnet	1c	10.0.0.32/27
ECS Private subnet	1a	10.0.0.64/27
ECS Private subnet	1c	10.0.0.96/27
DB Private subnet	1a	10.0.0.128/27
DB Private subnet	1c	10.0.0.160/27

ALBとNAT GatewayはPublicサブネット、ECSはECS用Privateサブネット、RDSはDB用Privateサブネットへ配置します。

3. Internet GatewayとNAT Gatewayを設定する

Internet GatewayをVPCへアタッチします。Publicルートテーブルには0.0.0.0/0 → Internet Gatewayを追加し、2つのPublicサブネットへ関連付けます。

PrivateサブネットのECSは、ECRからのイメージ取得やCloudWatch Logsへの送信にアウトバウンド通信が必要です。そのため、各AZのPublicサブネットへNAT GatewayとElastic IPを配置します。

• ECS Private 1a → 1aのNAT Gateway
• ECS Private 1c → 1cのNAT Gateway

DB用PrivateサブネットはVPC内部の通信だけでよいため、インターネット向けデフォルトルートを追加しません。すでに適切なルートテーブルが関連付けられている場合、重複して作成する必要はありません。

4. セキュリティグループを作成する

ALB用

プロトコル	ポート	ソース
HTTP	80	0.0.0.0/0
HTTPS	443	0.0.0.0/0

ECS用

プロトコル	ポート	ソース
TCP	8080	ALB用セキュリティグループ

RDS用

プロトコル	ポート	ソース
PostgreSQL	5432	ECS用セキュリティグループ

接続元にはIPアドレスではなくセキュリティグループを指定します。

5. RDS for PostgreSQLを作成する

異なるAZのDB用Privateサブネットを登録したDBサブネットグループを作成します。

• 名前：my-golang-app-db-subnet-group
• DB識別子：my-golang-app-db
• エンジン：PostgreSQL
• DBクラス：db.t4g.micro
• Multi-AZ：有効
• パブリックアクセス：なし
• ストレージ暗号化：有効
• ポート：5432
• セキュリティグループ：RDS用

アプリケーションはRDSエンドポイントへ接続します。

6. Secrets ManagerへDB接続情報を登録する

{
  "host": "<RDS_ENDPOINT>",
  "port": "5432",
  "dbname": "appdb",
  "username": "<DB_USER>",
  "password": "<DB_PASSWORD>"
}

ブログやスクリーンショットへ実際の値を掲載しないよう注意します。

7. ECRへDockerイメージをpushする

ECRにmy-golang-appリポジトリを作成し、認証します。

aws ecr get-login-password --region ap-northeast-1 \
  | docker login \
      --username AWS \
      --password-stdin \
      <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com

docker buildx build \
  --platform linux/amd64 \
  --target production \
  -t <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/my-golang-app:v2 \
  --push .

latestだけでなく、バージョンやGitコミットハッシュなど、デプロイ内容を識別できるタグを使います。

ECRイメージタグv2とECSタスク定義リビジョンmy-golang-app:2は別の概念です。

8. ECSクラスターとタスク定義を作成する

• クラスター：my-golang-app-cluster
• 起動タイプ：Fargate
• タスク定義ファミリー：my-golang-app
• リビジョン：2
• ネットワークモード：awsvpc
• コンテナポート：8080
• ロググループ：/ecs/my-golang-app
• DB認証情報：Secrets Manager
• コンテナヘルスチェック：有効

タスク実行ロールには、ECRからの取得、CloudWatch Logsへの送信、対象シークレットの読み取りに必要な権限を付与します。

9. ターゲットグループを作成する

• 名前：my-golang-app-tg
• ターゲットタイプ：IP
• プロトコル：HTTP
• ポート：8080
• ヘルスチェック：/health

Fargateのawsvpcでは、ターゲットタイプに「インスタンス」ではなく「IP」を指定します。

10. ALBを作成する

• 名前：my-golang-app-alb
• スキーム：インターネット向け
• サブネット：Public subnet 1a / 1c
• セキュリティグループ：ALB用

最初はHTTP:80からターゲットグループへ転送し、ALB経由でアプリケーションへ到達できることを確認します。

11. ECSサービスを作成する

• サービス：my-golang-app-service
• タスク定義：my-golang-app:2
• Desired count：2
• サブネット：ECS Private subnet 1a / 1c
• パブリックIP：無効
• セキュリティグループ：ECS用
• ターゲットグループ：my-golang-app-tg
• コンテナポート：8080

次の状態を確認します。

Desired tasks: 2
Running tasks: 2
Pending tasks: 0

ECSのHealth statusと、ターゲットグループの2つのIPターゲットがHealthyになれば正常です。

12. Route 53とACMを設定する

Route 53でmy-golang-api.comを取得し、Public Hosted Zoneを確認します。

ACMを東京リージョンへ切り替え、次のドメインで証明書をリクエストします。

my-golang-api.com
*.my-golang-api.com

DNS検証を選択し、Route 53へ検証用CNAMEを追加します。ALBとACM証明書は同じリージョンに作成する必要があります。

13. ALBにHTTPSリスナーを追加する

• HTTPS:443 → my-golang-app-tgへ転送
• 証明書：東京リージョンのACM証明書

HTTP:80リスナーはHTTPSへリダイレクトします。

項目	設定
アクション	URLへリダイレクト
プロトコル	HTTPS
ポート	443
ホスト	#{host}
パス	/#{path}
クエリ	#{query}
ステータス	HTTP 301

完全なURLを入力する画面では次の形式です。

https://#{host}:443/#{path}?#{query}

14. Route 53のA AliasをALBへ設定する

• レコード名：空欄（ルートドメイン）
• タイプ：A
• エイリアス：有効
• ルーティング先：Application Load Balancer
• リージョン：東京
• ALB：my-golang-app-alb
• ポリシー：シンプル

ALBには通常の固定IPではなくAliasレコードを使用します。

15. 動作確認

curl -I http://my-golang-api.com

301 Moved PermanentlyとHTTPSのLocationが返れば正常です。

curl -i https://my-golang-api.com/albums

HTTP 200とAPIレスポンスが返れば、Route 53、ACM、ALB、ECS、RDSを経由する通信が成功しています。

トラブルシューティング

ECSタスクが起動しない

• ECRのイメージURIとタグを確認する
• イメージとタスク定義のCPUアーキテクチャを一致させる
• タスク実行ロールを確認する
• ECS PrivateサブネットからNAT Gatewayへ到達できるか確認する
• CloudWatch Logsを確認する
• Secrets Managerの読み取り権限を確認する

ターゲットがUnhealthyになる

• アプリケーションが0.0.0.0:8080で待ち受けているか
• ECS用SGがALB用SGからTCP 8080を許可しているか
• ターゲットグループのポートが8080か
• ヘルスチェックパスがHTTP 200を返すか
• コンテナにヘルスチェックコマンドが存在するか

ECSのHealth statusがUNKNOWNになる

ALBのターゲットがHealthyでも、タスク定義にコンテナヘルスチェックがないとECSのHealth statusはUNKNOWNになることがあります。ヘルスチェックを追加した新しいタスク定義リビジョンでサービスを更新します。

RDSへ接続できない

• RDS用SGの接続元がECS用SGか
• PostgreSQLの5432番ポートが許可されているか
• RDSエンドポイントとDB名が正しいか
• ECSとRDSが同じVPCか
• RDSがavailableか

HTTPS証明書を選択できない

ALBとACM証明書のリージョンを確認します。今回は両方とも東京リージョンです。

まとめ

ALBだけをPublicサブネットへ配置し、ECSタスクとRDSをPrivateサブネットへ配置しました。

• インターネット → ALB：80、443
• ALB → ECS：8080
• ECS → RDS：5432

ALB、ECSタスク、NAT Gateway、RDSを2つのAZへ分散し、独自ドメインからHTTPSでアクセスできる構成になりました。

Dockerfile、DockerイメージのCPUアーキテクチャ、コンテナポート、ヘルスチェックコマンドをAWS側の設定と一致させることが、ECRからECSへのデプロイをスムーズに進めるポイントです。