Zenn
😽

AWS学びなおし(+TF)_ECR

2025/03/04に公開
AWS
tech

ECR (Elastic Container Registry) とは

AWSの提供するフルマネージドなDockerコンテナイメージレジストリサービスです。
簡単に言うと、Dockerイメージを保管・管理するための場所であり、AWS環境でコンテナを利用する上で非常に重要な役割を担います。
Docker Hubのようなパブリックレジストリと異なり、ECRはプライベートレジストリとして機能し、セキュアにコンテナイメージを保管できます。

ECRの主な機能

  • プライベートレジストリ: 保管するイメージへのアクセスをIAMロールやポリシーで厳密に制御できます。組織内でのみ利用するコンテナイメージの管理に最適です。
  • 高い可用性と拡張性: AWSのインフラ上で稼働するため、可用性と拡張性が高く、大規模なコンテナ環境でも安定して利用できます。
  • 様々な認証方式: IAMロール、アクセスキー、クレデンシャルヘルパーなど、多様な認証方式に対応し、セキュアなアクセスを実現します。
  • イメージスキャン: コンテナイメージの脆弱性スキャン機能を標準で提供しており、セキュリティリスクを早期に発見できます。
  • ライフサイクルポリシー: 不要になった古いイメージを自動的に削除するライフサイクルポリシーを設定でき、ストレージコストを最適化できます。
  • クロスリージョンレプリケーション: 複数のリージョンにイメージをレプリケーションすることで、可用性向上やレイテンシ削減に貢献します。
  • VPCエンドポイント: VPC内からインターネットを経由せずにECRへアクセスできるVPCエンドポイントに対応し、セキュリティとパフォーマンスを向上させます。
  • OCI (Open Container Initiative) 準拠: Dockerイメージだけでなく、OCI準拠の様々なコンテナイメージフォーマットに対応しています。

なぜECRを使うのか？ (メリット)

  • AWSネイティブサービスとの統合: ECS (Elastic Container Service)、EKS (Elastic Kubernetes Service)、Lambda、CodeBuildなど、他のAWSサービスとの連携がスムーズに行えます。特にECS/EKSとの親和性は非常に高く、コンテナオーケストレーション基盤との連携を容易にします。
  • セキュリティ: IAMによるアクセス制御、VPCエンドポイント、暗号化など、AWSの強力なセキュリティ機能を活用できます。コンテナイメージをセキュアに管理・配布できます。
  • 運用管理の容易さ: フルマネージドサービスであるため、レジストリ自体のインフラ管理 (サーバー構築、メンテナンス、スケーリングなど) が不要です。ユーザーはイメージの管理に集中できます。
  • コスト効率: 利用したストレージ容量とデータ転送量に応じた従量課金制であり、初期費用や固定費を抑えられます。ライフサイクルポリシーによる自動削除でストレージコストを最適化できます。
  • パフォーマンス: AWSの高速ネットワークとインフラを活用し、高速なイメージのPush/Pullを実現します。

ECRを使う上での注意点 (デメリット)

  • ベンダーロックイン: AWS固有のサービスであるため、他のクラウドプロバイダーへの移行やオンプレミス環境との連携には制約が生じる可能性があります。
  • 料金: 利用状況によっては、他のレジストリサービスと比較してコストが高くなる可能性があります。特にデータ転送量が多い場合は注意が必要です。

【実務レベルの内容と重要事項】

実務におけるECRの重要事項

  • IAMポリシー設計: ECRリポジトリへのアクセス制御はIAMポリシーによって行います。最小権限の原則に基づき、必要なユーザーやサービスアカウントにのみ、必要な権限 (Push, Pull, ReadOnlyなど) を付与するように設計することが重要です。
  • VPCエンドポイントの利用: セキュリティを考慮する場合、VPCエンドポイント (特にecr.dkrとecr.api) を必ず設定し、VPC内からのECRアクセスをインターネット経由ではなく、AWSの閉域ネットワーク経由にすることが推奨されます。
  • イメージスキャン設定: 脆弱性スキャンは常に有効化し、定期的にスキャン結果を確認し、脆弱性が見つかった場合は迅速に対応する必要があります。
  • ライフサイクルポリシーの適切な設定: ライフサイクルポリシーを適切に設定することで、不要なイメージを自動削除し、ストレージコストを削減できます。タグに基づいた削除ルールや、イメージの経過日数に基づいた削除ルールなどを検討しましょう。
  • クロスリージョンレプリケーションの検討: DR (災害対策) 対策や、グローバルにサービスを展開している場合は、クロスリージョンレプリケーションを検討し、可用性を高めることが重要です。
  • イメージレイヤーの最適化: Dockerイメージのレイヤー構成を最適化することで、イメージサイズを削減し、Pull時間を短縮できます。マルチステージビルドなどを活用しましょう。
  • タグ戦略: コンテナイメージのタグを適切に管理することで、バージョン管理やロールバックを容易にできます。latestタグの乱用は避け、バージョン番号やGitコミットハッシュなどをタグとして利用することを推奨します。
  • プライベート認証情報の管理: ECRへの認証情報は、ハードコーディングせずに、環境変数、AWS Secrets Manager、IAMロールなどを利用してセキュアに管理する必要があります。
  • モニタリングとロギング: CloudWatch LogsやCloudTrailなどを活用して、ECRの利用状況やエラーログをモニタリングし、問題発生時の早期発見と対応に役立てましょう。

実務で考慮すべき高度な内容

  • PrivateLink: より高度なセキュリティ要件がある場合、PrivateLinkを利用して、VPCからECRへのアクセスを完全にプライベートネットワーク経由にすることが可能です。
  • クロスアカウントアクセス: 複数のAWSアカウント間でコンテナイメージを共有する必要がある場合、クロスアカウントアクセスを設定することで、セキュアにイメージを共有できます。
  • イメージ署名と検証: コンテナイメージの改ざん防止のため、イメージ署名と検証を導入することで、サプライチェーンセキュリティを強化できます。
  • 拡張スキャン: 標準の脆弱性スキャンに加え、より詳細な脆弱性スキャンやコンプライアンスチェックを行いたい場合は、AWS Marketplaceで提供されているサードパーティ製のスキャンツールとの連携を検討できます。

【実務でどの程度使用されるのか】

ECRは実務において 非常に広く利用されています。
コンテナ技術の普及に伴い、コンテナイメージレジストリの需要は増加しており、AWS環境でコンテナを利用する場合、ECRは事実上の標準的な選択肢となっています。

利用頻度が高い理由

  • AWS環境との親和性: ECS/EKSなどのコンテナオーケストレーション基盤との統合が容易であり、AWSエコシステムの中でシームレスに利用できます。
  • セキュリティと信頼性: AWSのセキュリティ基盤と高い可用性を活用でき、エンタープライズレベルの要件を満たすことができます。
  • 運用管理の容易さ: フルマネージドサービスであるため、運用負荷が低く、開発者はコンテナアプリケーションの開発に集中できます。
  • コスト効率: 従量課金制であり、初期費用を抑えられ、スモールスタートが可能です。

ECRが利用される主なユースケース

  • ECS/EKSでのコンテナアプリケーション実行: 最も一般的なユースケースであり、ECRに格納されたコンテナイメージをECS/EKSでデプロイ・実行します。
  • Lambda関数のコンテナイメージデプロイ: Lambda関数をコンテナイメージとしてデプロイする場合、ECRにイメージを格納し、Lambda関数から参照します。
  • Fargateでのサーバーレスコンテナ実行: Fargateを利用してサーバーレスにコンテナを実行する場合も、ECRにイメージを格納します。
  • CI/CDパイプラインでの利用: CodeBuildやCodePipelineなどのCI/CDツールと連携し、ビルドしたコンテナイメージをECRにPushし、デプロイパイプラインに組み込みます。
  • オンプレミス環境との連携: オンプレミス環境からECRにアクセスし、コンテナイメージをPullして利用することも可能です。

競合サービスとの比較

  • Docker Hub: パブリックレジストリとして広く利用されていますが、プライベートレジストリとしてはECRの方がセキュリティ、統合性、運用管理の面で優位性があります。
  • Google Container Registry (GCR), Azure Container Registry (ACR): それぞれGCP、Azureのコンテナレジストリサービスであり、ECRと同様の機能を提供します。クラウドプロバイダーの選択によって使い分けられます。
  • Harbor, Nexus Repository, Artifactory: オンプレミスやマルチクラウド環境で利用可能なコンテナレジストリです。ECRと比較して、柔軟性やカスタマイズ性が高い一方、運用管理の負荷は高くなります。

結論として、ECRはAWS環境でコンテナを利用する上で不可欠なサービスであり、実務において非常に高い頻度で使用されています。 特にAWSネイティブサービスとの統合性、セキュリティ、運用管理の容易さから、多くの企業で採用されています。

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

基本的なECRリポジトリ作成 (Terraform)

resource "aws_ecr_repository" "example" {
  name = "my-repository" # リポジトリ名
}

このコードは、最も基本的なECRリポジトリを作成するTerraformコードです。
resource "aws_ecr_repository" "example" でリソースを定義し、name 引数でリポジトリ名を指定します。

実務レベルのTerraformコード (ECRリポジトリ)

resource "aws_ecr_repository" "example" {
  name                 = "my-repository"
  image_tag_mutability = "IMMUTABLE" # イメージタグのイミュータブル設定
  force_delete         = true        # リポジトリ削除時にイメージも削除

  image_scanning_configuration {
    scan_on_push = true # Push時にイメージスキャンを有効化
  }

  tags = {
    Environment = "Production"
    Project     = "WebApp"
  }
}

# リポジトリポリシー (IAMポリシー)
data "aws_iam_policy_document" "repository_policy" {
  statement {
    sid = "AllowPushPull"
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/ecs-task-execution-role"] # ECSタスク実行ロール
    }
    actions = [
      "ecr:GetDownloadUrlForLayer",
      "ecr:BatchGetImage",
      "ecr:BatchCheckLayerAvailability",
      "ecr:PutImage",
      "ecr:InitiateLayerUpload",
      "ecr:UploadLayerPart",
      "ecr:CompleteLayerUpload"
    ]
  }
}

resource "aws_ecr_repository_policy" "example" {
  repository = aws_ecr_repository.example.name
  policy     = data.aws_iam_policy_document.repository_policy.json
}

# ライフサイクルポリシー
resource "aws_ecr_lifecycle_policy" "example" {
  repository = aws_ecr_repository.example.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "Keep last 10 images"
        action       = { type = "expire" }
        selection    = {
          tagStatus   = "any"
          countType   = "imageCountMoreThan"
          countNumber = 10
        }
      }
    ]
  })
}

実務レベルのTerraformコードのポイント解説

  • image_tag_mutability = "IMMUTABLE": イメージタグのイミュータブル設定。タグを上書きできなくなり、意図しないイメージの変更を防ぎます。実務では IMMUTABLE を推奨。
  • force_delete = true: リポジトリ削除時にイメージも強制的に削除する設定。Terraformでリポジトリを完全に管理する場合に有効。
  • image_scanning_configuration: Push時に自動でイメージスキャンを実行する設定。セキュリティ対策として必須。
  • tags: リソースにタグを付与することで、リソース管理やコスト管理を容易にします。環境名やプロジェクト名などのタグを付与することが推奨されます。
  • data "aws_iam_policy_document" "repository_policy": IAMポリシーをJSON形式で記述する代わりに、Terraformの data ブロックと aws_iam_policy_document を利用することで、より構造的で可読性の高いポリシー定義が可能です。
  • resource "aws_ecr_repository_policy" "example": 作成したIAMポリシーをECRリポジトリに適用します。ここではECSタスク実行ロールにPush/Pull権限を付与する例を示しています。
  • resource "aws_ecr_lifecycle_policy" "example": ライフサイクルポリシーを設定し、古いイメージを自動削除することで、ストレージコストを削減します。ここでは最新10個のイメージを残すルールを設定しています。
  • jsonencode(): ライフサイクルポリシーはJSON形式で記述する必要があるため、Terraformの jsonencode() 関数を利用して、TerraformのオブジェクトをJSON文字列に変換しています。

さらに実務的なTerraformコードの考慮事項

  • モジュール化: ECRリポジトリの作成コードをモジュール化することで、再利用性を高め、コードの可読性を向上させることができます。
  • 変数化: リポジトリ名、タグ、ライフサイクルポリシーの設定値などを変数化することで、柔軟性を高め、環境ごとの設定変更を容易にできます。
  • Backend設定: Terraform StateファイルをリモートBackend (S3, Terraform Cloudなど) で管理することで、複数人での共同作業やStateファイルの安全な管理を実現します。
  • State管理: Terraform Stateファイルを適切に管理し、Stateの競合や破損を防ぐための対策 (ロック機能など) を講じることが重要です。
  • バージョン管理: TerraformコードをGitなどのバージョン管理システムで管理し、変更履歴を追跡できるようにすることが必須です。
  • CI/CDパイプラインとの連携: TerraformコードをCI/CDパイプラインに組み込み、自動的にインフラ構築・変更を適用できるようにすることで、効率的なインフラ管理を実現します。

まとめ

TerraformでECRリポジトリを記述する場合、基本的なリソース定義だけでなく、セキュリティ、運用性、コスト効率などを考慮した設定を行うことが実務上重要です。IAMポリシー、ライフサイクルポリシー、イメージスキャンなどの設定を適切に行い、モジュール化や変数化などのTerraformのベストプラクティスを適用することで、より堅牢で管理しやすいインフラ環境を構築できます。

Discussion