--- title: "Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】" url: "https://www.issoh.co.jp/tech/details/2667/" published: 2024-06-19 updated: 2026-10-01 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】 Amazon ECR（Amazon Elastic Container Registry、通称AWS ECR）とは、Dockerなどのコンテナイメージを保存・管理・配布するための、AWSのフルマネージドなコンテナレジストリです。自前でレジストリサーバーを運用せずに、Amazon ECSやEKS、AWS Lambdaへそのままイメージを渡せます。この記事では、ECRの基本とECS・Docker Hubとの違い、2026年10月時点の料金、リポジトリ作成から`docker login`とイメージのpush・pull、push時のリポジトリ自動作成やレイヤー共有といった新しい設定、そして運用で外せないライフサイクルポリシーまでを、ap-northeast-1（東京リージョン）の実コマンド付きで解説します。 ## まとめ：Amazon ECRとは何か・料金・push手順と運用設定の要点 ECRはコンテナイメージ専用の倉庫で、Docker Hubの代わりにAWS内へイメージを置く場所だと考えると分かりやすいでしょう。イメージを動かす相手がECS・EKS・Lambdaなら、認証・権限・通信がすべてAWS内で完結するため、ECRが第一候補になります。 - **ECRは「置く場所」、ECSとEKSは「動かす場所」**。両者は競合せず、ECR→ECSの順に連携する。 - 料金はプライベートリポジトリの**ストレージ1GBあたり月0.10USD**と、AWS外へのデータ転送で決まる。同一リージョン内のAWSサービスへの転送は無料。 - pushは「リポジトリ作成 → `get-login-password`でログイン → build → tag → push」の流れ。認証トークンは**12時間**で失効する。 - 2025年12月からは**push時のリポジトリ自動作成**、2026年1月からは**リポジトリ間のレイヤー共有**が使える。どちらもレジストリ側の設定を入れて初めて動く。 - 運用開始時に**ライフサイクルポリシー**と**プッシュ時スキャン**を入れておくと、ストレージ課金の膨張と古い脆弱なイメージの残存を防げる。 最短のpush手順は次の4ステップです。詳しい前提と各手順は本文で順に説明します。 | ステップ | コマンドの要点 | | -------- | ------------------------ | | 1\. ログイン | 一時パスワードでDocker認証 | | 2\. ビルド | docker build -t my-app . | | 3\. タグ付け | my-app:latestにECR URIを付与 | | 4\. プッシュ | ECR URIを指定してpush | ## Amazon ECRとは：レジストリ・リポジトリ・イメージの3階層と主な特徴 ECRはAmazon Elastic Container Registryの略で、Dockerイメージ（およびOCIイメージ、Helmチャート）を保存するレジストリサービスです。レジストリ・リポジトリ・イメージの3階層で構成され、1つのAWSアカウントの各リージョンに既定のプライベートレジストリが1つ用意されます。その中にアプリごとのリポジトリを複数作り、各リポジトリにタグ付きのイメージを格納する、という入れ子の関係です。レジストリという仕組みそのものの位置づけは[コンテナレジストリの種類と選び方を解説した記事](https://www.issoh.co.jp/tech/details/13259/)で、コンテナの基礎は[コンテナと仮想マシンの違いから整理したコラム](https://www.issoh.co.jp/column/details/13000/)で扱っています。 特徴は大きく3つあります。第一に、サーバー管理が不要なフルマネージドである点。第二に、IAMポリシーで誰がどのリポジトリをpush・pullできるかを細かく制御できる点。第三に、ECS・EKS・Lambdaが追加の認証情報なしで直接pullできる点です。とくに3つ目が効くのは、デプロイ先がAWSにそろっている場合でしょう。AWS外へ配るだけならDocker Hubでも足りますが、AWS内で完結するならECRが素直な選択になります。 設定を確認するときに押さえたいのは、多くの項目が「リポジトリ単位」と「レジストリ単位」に分かれている点です。タグの上書き可否やライフサイクルポリシーはリポジトリごとに、レプリケーション・プルスルーキャッシュ・スキャン方式・レイヤー共有はレジストリ（アカウント×リージョン）ごとに設定します。リージョンが変わるとレジストリも別物になるため、東京と大阪で同じ設定を使いたいときは両方に入れる必要があります。 用語の混同に注意したい点として、ECRは「イメージを置く場所」であり、イメージを「動かす場所」ではありません。動かす役割はECSやEKSが担います。この役割分担を次の章で整理します。 ## ECRとECS・EKS・Docker Hubの違いと、ACR・GHCRとの使い分け ECRとECSは名前が似ていて混同されやすいサービスです。結論から言うと、ECRは保管庫、ECSは実行環境で、役割がまったく異なります。下表で対比します。 | サービス | 役割 | 扱う対象 | | ---- | -------------- | -------- | | ECR | イメージの保存・配布 | コンテナイメージ | | ECS | コンテナの実行・運用 | 稼働中のコンテナ | | EKS | Kubernetesでの実行 | 稼働中のPod | 実際のデプロイでは、ECRに置いたイメージをECSのタスク定義やEKSのマニフェストから参照します。つまりECRとECSは競合ではなく、ECR→ECSの順で連携する関係です。ECS側の詳細は[AWSのコンテナオーケストレーションサービスECSの解説記事](/tech/details/3870/)、Kubernetesで動かす場合は[Amazon EKSの仕組みと料金モデルの解説](https://www.issoh.co.jp/tech/details/15437/)で扱っています。サーバー管理まで任せたいなら[AWS Fargateの解説](https://www.issoh.co.jp/tech/details/3304/)もあわせて読むと、ECRのイメージをどこで動かすかの見取り図ができます。実行基盤そのものを選ぶ段階なら、[ECS・EKS・Fargate・Lambdaを比較したAWSのコンテナサービス比較](https://www.issoh.co.jp/tech/details/17869/)から入るのが近道です。 保管庫としての比較相手はDocker Hubです。Docker Hubは公開イメージの入手に強く、オープンソースの公式イメージはまずここから取得します。一方、自社の非公開イメージをAWS上のECS・EKSへ配布するならECRが有利です。理由は、Docker Hubの匿名pullに課されるレート制限を避けられること、そしてイメージ転送がAWSネットワーク内で完結することの2点にあります。社外公開しない業務用イメージはECR、汎用の公開イメージはDocker Hub、と使い分けるのが実務上の基本です。 レジストリの選定では、他クラウドや開発基盤のレジストリとの比較も判断材料です。Azure側の対応物として、[Azure Container Registry（ACR）の仕組みと料金プランを解説した記事](https://www.issoh.co.jp/tech/details/15653/)と読み比べると、どのクラウドのレジストリに寄せるかの判断材料になります。ソースコードとCIをGitHubに置いているなら、[GitHub Container Registry（ghcr.io）の料金とECR比較](https://www.issoh.co.jp/tech/details/7315/)も候補に入ります。扱う成果物がコンテナイメージではなくnpmやMavenのパッケージであれば、[AWS CodeArtifactによるパッケージレジストリ](https://www.issoh.co.jp/tech/details/17261/)が対応する側です。 ## ECRの料金体系：ストレージ単価・無料枠・転送料金とレイヤー共有の効き方 ECRの課金はシンプルで、保存したイメージのストレージ量と、AWS外へ出ていくデータ転送量で決まります。[Amazon ECRの公式料金ページ](https://aws.amazon.com/ecr/pricing/)によると、プライベートリポジトリのストレージは1GBあたり月0.10USDで、新規顧客向けにプライベートリポジトリのストレージ月500MBを1年間無料とする枠が記載されています（2026年10月時点）。パブリックリポジトリには月50GBの常時無料ストレージがあります。 ただし、AWSの無料利用の仕組みは2025年7月に、6か月・クレジット制の無料プランを選ぶ方式へ改定されました。料金ページのECR無料枠と新しい無料プランの関係は同ページに明記されていないため、自分のアカウントでどの枠が効いているかは請求コンソールの無料利用枠ページで確かめるのが確実です。新しい無料プランの期限と範囲は[AWSを無料で使える範囲と6か月の期限をCLIで確認する手順](https://www.issoh.co.jp/tech/details/17636/)で整理しています。 転送料金は方向で変わります。同一リージョン内のAWSサービス（同リージョンのECSなど）へのpullは転送料金がかからない一方、インターネット向けの送信データには通常のAWSデータ転送料金が発生します。デプロイ先のECSとECRのリージョンをそろえるだけで、転送コストもレイテンシも下げられるということです。 2026年1月には、同一レジストリ内のリポジトリ間で共通レイヤーを共有する[クロスリポジトリのレイヤー共有（blob mounting）](https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-ecr-cross-repository-layer-sharing/)が発表されました。これは自動では有効にならず、レジストリ設定での有効化が前提です。[blob mountingのドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/blob-mounting.html)では、同一アカウント・同一リージョンのレジストリ内でのみ動くこと、共有するリポジトリ同士で暗号化方式と鍵が同じである必要があること、プルスルーキャッシュで作られたイメージは対象外であることが条件として挙がっています。有効化は次の1行です。 ``` aws ecr put-account-setting --name BLOB_MOUNTING --value ENABLED --region ap-northeast-1 ``` 効き方を試算してみます。共通ベースイメージ700MBの上に固有レイヤー300MBを載せたサービスが20リポジトリある構成では、共有なしなら20GBで月2.0USD前後、共有ありならベース0.7GB＋固有6GBの6.7GBで月0.67USD前後という計算になります（単価0.10USDで概算、無料枠は考慮せず）。ストレージ自体の金額は小さいので、効果が大きいのはリポジトリ数が多いマイクロサービス構成と、pushの高速化の側です。料金の最新値と各リージョンの差は変動するため、見積もりの最終確認は公式の料金ページで行ってください。 ## ECRリポジトリをAWS CLIで作成し、push時の自動作成設定まで入れる イメージをpushする前に、受け皿となるリポジトリを作成します。GUIで作るならマネジメントコンソールのECR画面で「リポジトリを作成」を選び、リポジトリ名を入力するだけです。手順を自動化したい場合はAWS CLIが速く、次のコマンドで東京リージョンに作成できます。タグの上書き禁止とプッシュ時スキャンもこの時点で指定しておくと、後から設定し忘れることがありません。 ``` aws ecr create-repository \ --repository-name my-app \ --image-tag-mutability IMMUTABLE \ --image-scanning-configuration scanOnPush=true \ --region ap-northeast-1 ``` 作成後、後続のtag・pushで使うリポジトリURI（`.dkr.ecr.ap-northeast-1.amazonaws.com/my-app` の形式）を控えておきます。URIは次のコマンドで取得できます。 ``` aws ecr describe-repositories --repository-names my-app --query "repositories[0].repositoryUri" --output text ``` 事前条件はAWS CLIとDockerのインストール、そして`aws configure`での認証情報設定の3点です。CLIは`get-login-password`を使うためにバージョン2を推奨します（理由は次章で述べます）。 リポジトリが増えてくると、毎回`create-repository`を打つのが手間になります。2025年12月に[push時にリポジトリを自動作成する機能](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-ecr-creating-repositories-on-push/)が追加され、存在しないリポジトリへpushしたときにECRが代わりに作れるようになりました。ただし[リポジトリ作成テンプレートのドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html)にあるとおり、push先に合致するテンプレートが無い場合、ECRは既定値でリポジトリを作りません。テンプレートの用途に`CREATE_ON_PUSH`を指定して、プレフィックスごとの初期設定を先に決めておきます。 ``` aws ecr create-repository-creation-template \ --prefix apps \ --applied-for CREATE_ON_PUSH \ --image-tag-mutability IMMUTABLE \ --region ap-northeast-1 ``` この例では`apps/`で始まるリポジトリ（例：`apps/api`）へ初めてpushした時点で、タグ上書き禁止のリポジトリが作られます。全リポジトリを対象にしたいときはプレフィックスに`ROOT`を指定します。テンプレートはライフサイクルポリシーやリポジトリポリシーも持てるので、自動作成されたリポジトリにも運用ルールを最初から効かせられるのが利点です。 ## DockerイメージのECR登録に向けたログイン・ビルド・タグ付け・pushの手順 ECRを使う作業の中心がここです。ログインとpushを順に確実に押さえます。 ### aws ecr get-login-passwordによるdocker login ECRへの認証は、一時パスワードを発行する`get-login-password`を`docker login`にパイプする方法が標準です。[AWS CLIのget-login-passwordリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ecr/get-login-password.html)には、発行される認可トークンの有効期間は12時間と記載されており、期限が切れたら再実行します。このコマンドはAWS CLIバージョン2、またはバージョン1なら1.17.10以降で利用できます。 ``` aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin .dkr.ecr.ap-northeast-1.amazonaws.com ``` 「Login Succeeded」と表示されれば成功です。旧来の`aws ecr get-login`はパスワードがコマンド履歴に残るなどのリスクがあり、現在は`get-login-password`に置き換えるのが推奨です。CI/CDの中で毎回ログインを自動化する場合も、この1行をスクリプト先頭に置くだけで済みます。pushする側のIAMロールには`ecr:GetAuthorizationToken`に加え、レイヤーのアップロード系の権限が要ります。権限設計の考え方は[AWS IAMのユーザー・ロール・ポリシーの違いを解説した記事](https://www.issoh.co.jp/tech/details/15427/)を参照してください。 ### ECRのURIを指定したdocker build・tag・pushの手順 ログイン後は、ローカルでイメージをビルドし、ECRのURIをタグとして付与してからpushします。タグ付けを忘れるとpush先がDocker Hubになってしまうため、URIの付与が要点です。 ``` docker build -t my-app . docker tag my-app:latest .dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest docker push .dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest ``` pushが完了すると、コンソールのリポジトリ一覧に新しいタグのイメージが表示されます。CI/CDでは`latest`固定ではなく、コミットハッシュやビルド番号をタグに使うとロールバックが容易になります。前章のようにタグ上書き禁止（IMMUTABLE）にしたリポジトリでは、同じタグへの再pushが拒否されるため、コミットハッシュのタグ運用と組み合わせるのが前提です。Dockerfileの書き方は[Dockerfileの主要命令とベストプラクティスの解説](https://www.issoh.co.jp/tech/details/3315/)、アプリを丸ごとコンテナ化する例は[DockerでFastAPIとReactをコンテナ化する解説記事](/tech/details/2980/)が参考になります。 ## ECRからイメージをpullする手順とECR Public・プルスルーキャッシュ pushしたイメージを別環境で使うときはpullします。pull前にも`get-login-password`でのログインが必要で、ログイン済みであれば次の1行で取得できます。 ``` docker pull .dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest ``` 誰でも使える公開イメージを配布したい場合に、その配布先となるのは、プライベートのECRではなくAmazon ECR Publicです。ECR Publicのイメージはログイン不要でpullでき、たとえばAmazon Linuxの公式イメージは `public.ecr.aws/amazonlinux/amazonlinux:latest` のように取得します。社内配布はプライベート、広く配布したいOSSイメージはPublic、と置き場所を分けて考えます。 もう一つ知っておくと便利なのが[プルスルーキャッシュ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html)です。Docker HubやECR Public、GitHub Container Registryなどの上流レジストリのイメージを、自分のプライベートレジストリ経由でpullしてキャッシュする仕組みで、ベースイメージの取得をAWS内で完結させられます。Docker HubやGHCRのように認証が必要な上流では、名前が`ecr-pullthroughcache/`で始まるSecrets Managerのシークレットに認証情報を置く必要があります。キャッシュ済みのタグは少なくとも24時間に1回、上流の更新が確認される仕様です。なお、Lambdaはプルスルーキャッシュ経由のイメージ取得に対応していない点に注意してください。 ## ライフサイクルポリシーのJSONと脆弱性スキャンを初期設定で入れる手順 pushできた後に放置するとストレージ課金が膨らみ、古い脆弱なイメージが残り続けます。push手順だけで終わらせず、運用の仕組みまで作り込んでおくと後の手戻りが減ります。運用開始時の初期設定として、最低限入れておきたいのが、以下で説明する保存ルールと脆弱性検査の2つです。 1つ目はライフサイクルポリシーです。「タグなしイメージは1日後に削除」「全体では最新10世代のみ保持」といったルールを設定すると、古いイメージが自動で消え、ストレージコストが青天井になりません。マイクロサービスのように毎日pushする構成では、これが無いと半年でリポジトリが肥大化します。[ライフサイクルポリシーの公式例](https://docs.aws.amazon.com/AmazonECR/latest/userguide/lifecycle%5Fpolicy%5Fexamples.html)の構文に沿うと、次のJSONになります。 ``` { "rules": [ { "rulePriority": 1, "description": "Expire untagged images older than 1 day", "selection": { "tagStatus": "untagged", "countType": "sinceImagePushed", "countUnit": "days", "countNumber": 1 }, "action": { "type": "expire" } }, { "rulePriority": 2, "description": "Keep only the latest 10 images", "selection": { "tagStatus": "any", "countType": "imageCountMoreThan", "countNumber": 10 }, "action": { "type": "expire" } } ] } ``` ファイルに保存したら、次のコマンドでリポジトリに適用します。ルールは`rulePriority`の小さい順に評価され、上位のルールで判定済みのイメージは下位のルールでは数えられません。 ``` aws ecr put-lifecycle-policy \ --repository-name my-app \ --lifecycle-policy-text file://lifecycle.json \ --region ap-northeast-1 ``` 削除せずに残しておきたいイメージには、アクションに`transition`を指定してアーカイブ用のストレージクラスへ移す選択肢もあります。公式例では「90日pullされていないイメージをアーカイブへ移す」ルールが示されていますが、アーカイブしたイメージは最低90日間の保存期間があり、それより早く削除しても90日分が課金されます。監査で過去イメージを残す必要がある場合に限って使うのが無難です。 2つ目はイメージスキャンです。[ECRのベーシックスキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning-basic.html)はAWSネイティブの技術でOSパッケージのCVEを検出し、リポジトリで「プッシュ時スキャン」を有効化すると、pushのたびに既知脆弱性を調べます。同じイメージのスキャンは24時間に1回までという制限があります。OSだけでなくプログラミング言語のパッケージまで継続的に検査したい場合、切り替え先となるのはAmazon Inspectorと連携する拡張スキャンです。Inspector側の対応範囲と料金は[Amazon Inspectorの対応スキャンと料金の解説](https://www.issoh.co.jp/tech/details/15894/)にまとめています。「push後にCriticalな脆弱性が出たらデプロイを止める」という運用を組み込めば、脆弱なイメージが本番へ流れるのを防げます。 デプロイ自動化と組み合わせるなら、AWSが移行先として案内する[ECS Express Modeでデプロイを自動化する解説記事](/tech/details/9958/)が出発点になります（旧来の[AWS Copilot](/tech/details/6801/)は2026年6月12日にサポート終了済みのため、新規採用は避け参考にとどめてください）。 ## ECRのpush・loginでよくあるエラーと原因を切り分けるコマンド つまずきやすいのは認証とリージョンの2点に集中します。代表的なエラーと原因を整理します。 | 症状 | 主な原因 | 対処 | | ------------------------- | -------------- | ---------------------- | | no basic auth credentials | 未ログイン／トークン期限切れ | get-login-passwordを再実行 | | get-login-passwordが無い | AWS CLIが古い | CLIをv2へ更新 | | denied / not authorized | IAM権限不足 | ecr:対象権限をポリシー付与 | | repository does not exist | リージョン違い／未作成 | –regionとURIを再確認 | | tag invalid（上書き拒否） | タグ上書き禁止の設定 | 新しいタグでpushする | とくに多いのが、ログインしたリージョンとpush先URIのリージョンが食い違うケースです。`aws --version`でCLIのバージョンを、`aws sts get-caller-identity`で使っているアカウントを確認すると、原因の切り分けが速く済みます。push時の自動作成を当てにしている場合、「repository does not exist」は、テンプレートに指定したプレフィックスとpush先のリポジトリ名が合っていないことを示すサインでもあるのです。トークン期限切れは時間経過で必ず起きるので、CI/CDでは毎回ログインから始める前提で組んでおくと安定します。 ## ECRを採用する条件と見送る場面：Docker Hub・GHCRに残すべきケース ここまでの内容を踏まえ、ECRに寄せるかどうかの判断を条件付きで言い切ります。 **ECRを採用すべきなのは、デプロイ先がECS・EKS・Lambdaのいずれかで、イメージを社外に公開しない場合です。**IAMで権限を一元管理でき、同一リージョン内の転送が無料で、Docker Hubのレート制限も気にしなくて済みます。複数アカウント・複数リージョンへ同じイメージを配る構成でも、レプリケーションとリポジトリ作成テンプレートで運用ルールをそろえられます。 **見送ってよいのは、次のような場面です。**第一に、実行環境がAWS以外（オンプレミスや他クラウド）に散らばっている場合。この場合はAWS外への転送料金がかかり、ECRを選ぶ理由が薄れます。第二に、ソースコードとCIがGitHubに集約されていて、イメージもGitHub Actionsから配るだけの小規模構成。GHCRのほうが認証設定が少なく済みます。第三に、OSSとして誰にでも配りたいイメージ。これはプライベートECRではなく、ECR PublicかDocker Hubに置くべきです。 移行の順番としては、まず本番のECS・EKSが参照するイメージだけをECRへ移し、ベースイメージの取得はプルスルーキャッシュで段階的にAWS内へ寄せるのが安全です。ECRへのリポジトリ設計、ECS・EKSのデプロイパイプライン、IAMの権限設計までまとめて整えたい場合は、一創の[インフラ構築（AWS・Google Cloud・Azure）サービス](https://www.issoh.co.jp/service/system/aws/)でご相談いただけます。 ## Amazon ECRのよくある質問：料金・ECSとの違い・ログイン・Public ### Amazon ECRとは何ですか？ECSとの違いは？ Amazon ECRとは、コンテナイメージを保存・配布するAWSのフルマネージドなレジストリです。ECSはそのイメージを実際に動かす実行サービスで、役割が分かれています。ECRに置いたイメージをECSのタスク定義から参照してデプロイする、という連携で使うため、両者は競合せず、ECR→ECSの順で組み合わせます。 ### ECRの料金はいくらですか？無料枠を超えると高いですか？ 公式料金ページでは、プライベートリポジトリのストレージは1GBあたり月0.10USDで、新規顧客向けに月500MBを1年間無料とする枠が記載されています（2026年10月時点）。無料枠を超えても、たとえば常時10GBを保存して月1USD程度とストレージ自体は小さく、コストは主にインターネット向けのデータ転送が占めます。同一リージョンのAWSサービスへのpullは転送無料なので、ECSとリージョンをそろえるのがコスト面の基本です。2025年7月以降の新しい無料プランとの関係は、請求コンソールで確認してください。 ### get-login-passwordとget-loginはどちらを使うべきですか？ `get-login-password`を使います。旧来の`get-login`はパスワードがコマンド履歴に残るなどのリスクがあり、現在は非推奨です。`get-login-password`はAWS CLIバージョン2（またはv1.17.10以降）で利用でき、標準入力経由でDockerに渡すためより安全です。 ### docker loginのトークンはどれくらい有効ですか？ ECRの認証トークンは発行から12時間有効です。期限が切れると「no basic auth credentials」などのエラーになるため、再度`get-login-password`を実行してログインし直します。CI/CDではジョブ実行のたびにログインから始める構成にしておくと安定します。 ### ECR Publicとプライベートリポジトリの違いは何ですか？ プライベートリポジトリはIAMで権限管理された非公開のイメージ置き場で、社内やAWS内のデプロイに使います。ECR Publicは誰でもログイン不要でpullできる公開ギャラリーで、OSSイメージを広く配布したい場合に適した置き場所です。パブリックリポジトリには月50GBの常時無料ストレージがあり、社外公開しないイメージはプライベート、広く配布したいイメージはPublic、と使い分けます。 ## 関連記事 - [ECS: AWSの強力なコンテナオーケストレーションサービス](/tech/details/3870/) - [コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](https://www.issoh.co.jp/tech/details/13259/) - [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](https://www.issoh.co.jp/tech/details/17869/) - [AWS Copilotとは何か？その基本概念と提供される価値](/tech/details/6801/) - [ECS Express Modeとは何か – AWS ECSの新機能でコンテナデプロイを自動化して容易化する機能](/tech/details/9958/) - [Dockerを用いたFastAPIとReactのコンテナ化とデプロイ方法](/tech/details/2980/) --- 出典: [Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】]()（株式会社一創）