--- title: "AWS CodeArtifactとは？東京リージョンの料金・アップストリーム設計と認証トークンの扱いを実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/17261/" published: 2026-09-03 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # AWS CodeArtifactとは？東京リージョンの料金・アップストリーム設計と認証トークンの扱いを実装者目線で解説 AWS CodeArtifactは、npmやMavenなどのパッケージを社内に閉じて保管・配布するためのマネージドなアーティファクトリポジトリです。npmjsやPyPIといった公開リポジトリへの外部接続を持たせれば、OSSの取得元も同じエンドポイントに寄せられます。この記事では、ドメインとリポジトリで分かれる保存と権限の境目、直上流10本・外部接続1本という制約から決まるリポジトリ構成、東京リージョンの実単価から見た費用構造、既定12時間の認証トークンをCIでどう扱うか、Rubyだけに効くリクエストの重み付け、そして受託開発で採用する条件と見送る場面までを整理します。数値は2026年9月時点の公式ドキュメントとAWS Price List APIの実測に基づくものです。 ## まとめ：ドメインとリポジトリで分かれる課金と権限の境目 CodeArtifactの構造は二層です。ドメインが保存・暗号化・アカウント間の許可を決める器で、リポジトリがパッケージマネージャーから叩くエンドポイントと外部接続を持つ入れ物になります。同じJARを5つのリポジトリに置いてもドメイン内では1回しか保存されないため、リポジトリを細かく割ってもストレージ費は増えません。 費用の主役はストレージではなくリクエスト数です。東京リージョンの実単価はストレージ0.055USD／GB-月に対し、リクエストは1万件あたり0.065USD。10GBの保管は月0.55USD程度に収まる一方、依存解決のたびに数百件のリクエストが飛ぶCI環境では、こちらが先に膨らみます。採用の分かれ目は「私有パッケージを複数チームや複数アカウントに配る必要があるか」の一点で、単一チームがOSSだけを使う構成なら投資が過剰になります。 ## CodeArtifactの構成要素とドメイン単位で決まる保存・暗号化の範囲 CodeArtifactの語彙は、アセット・パッケージ・パッケージバージョン・リポジトリ・ドメインの5階層に整理できます。この対応関係を先に押さえると、後段の権限設計とコスト計算が短く済みます。 ### 8フォーマット混在を許すポリグロットなリポジトリの設計上の使い分け 対応フォーマットは Cargo・generic・Maven・npm・NuGet・PyPI・Ruby・Swift の8種類です。リポジトリはポリグロットで、1つのリポジトリにnpmパッケージとMavenのJARとPythonのwheelを同居させられます。フォーマットごとにリポジトリを割る必要はありません。 階層名を持つフォーマットでは名前空間が効きます。npmの`@types/node`なら名前空間が types、パッケージ名が node。Mavenでは groupId が名前空間、artifactId がパッケージ名にあたります。PyPIのように階層名を持たないフォーマットでは名前の衝突を避ける手立てが少なく、社内命名規約の側で吸収するしかありません。genericフォーマットだけは名前空間が必須で、ビルド済みバイナリやtar書庫を素のまま置く用途に向きます。 扱う成果物がコンテナイメージであれば、CodeArtifactではなく[Amazon ECRによるイメージレジストリ](https://www.issoh.co.jp/tech/details/2667/)が受け皿になります。パッケージはCodeArtifact、イメージはECR、という切り分けを最初に固定しておくと、リポジトリ設計の議論が短くなります。 ### ドメイン単位のアセット一元保存とKMSキーによる暗号化の範囲 ドメインは複数のリポジトリを束ねる上位の存在で、実際のアセットとメタデータはドメイン側に格納されます。同一のアセット、たとえばMavenのJARファイルは、ドメイン内に何個のリポジトリがあってもドメインごとに1度だけ保存されます。チームごとにリポジトリを分けても保管料が多重にかからない理屈です。 暗号化もドメイン単位です。ドメイン内の全アセットとメタデータは、AWS KMSに置いた同一のKMSキーで暗号化されます。キーを分けたい要件があるなら、リポジトリではなくドメインを分けることになります。リポジトリは所属ドメインを後から変更できないため、この判断は作成前に済ませてください。 クォータは1アカウントあたりドメイン10・1ドメインあたりリポジトリ1,000で、いずれも引き上げ申請ができます。公式ドキュメントは組織で本番用ドメインを1つに寄せる構成を推奨していて、これは「チームを跨いでパッケージを見つけられる状態」を優先した設計指針です。監査単位やKMSキーを分ける実務要件がない限り、ドメインを増やす動機は薄いでしょう。 ### 直上流10本・外部接続1本の制約から決まる3層リポジトリ構成 上流リポジトリと外部接続は、挙動が似ていて上限が違います。1つのリポジトリに設定できる直上流は10本まで。対して外部接続は1本だけです。npmjsとPyPIの両方を1リポジトリに直付けする構成は取れません。 この制約から、実務では次の3層に落ち着きます。 - 公開リポジトリごとの取得用リポジトリ：npmjs用、PyPI用などに外部接続を1本ずつ持たせる - 共有リポジトリ：取得用リポジトリ群を上流に束ね、社内共通ライブラリの公開先も兼ねる - チーム別リポジトリ：共有リポジトリを上流に持ち、開発者とビルドが叩く単一のエンドポイントになる 上流経由で取得されたパッケージは中間のリポジトリにも保持されるため、公開リポジトリ側から消えたバージョンも社内に残ります。左パッケージ削除のような事故でビルドが止まる経路を、この構成が塞ぐ仕組みです。なお解決時に探索される上流は最大25までで、階層を深く積み過ぎると到達しない上流が生じます。 ## パッケージマネージャー接続と認証トークンの寿命を踏まえた運用設計 CodeArtifactのリポジトリは公開できません。取得も公開も、必ず認証トークンを伴います。この一点が、公開レジストリからの移行で最初につまずく箇所です。 ### loginが面倒を見る6ツールとトークン直接取得が必要な形式 `aws codeartifact login`は、トークン取得とパッケージマネージャーの設定書き換えを1コマンドで済ませます。対応するツールは dotnet・npm・nuget・pip・swift・twine の6つです。MavenやGradle、Cargo、Bundler、genericフォーマットは対象外で、`aws codeartifact get-authorization-token`でトークンを取り出し、設定ファイルか環境変数に自分で流し込む必要があります。 設定を壊さずに内容を確認したいときは`--dry-run`が使えます。実行されるコマンドだけを表示して、設定には手を付けません。既存のnpmrcやpip.confを持ち込んだ環境で、上書き前に差分を見るために使います。 ### 既定12時間・最短15分というトークン寿命とCI失効の防ぎ方 トークンの有効期間は既定で12時間、設定できる範囲は15分から12時間です。`--duration-seconds`に渡す値は900から43200が有効で、12時間を超える寿命は指定できません。寿命はトークンを取得した時点から始まります。 ロールを引き受けている場合は挙動が独特です。`--duration-seconds`に0を渡すと、そのロールのセッション残存時間と同じ寿命になります。0を指定しなければ、ロールの最大セッション時間が15分でもトークンは12時間有効です。この非対称を知らないと、短命セッションを前提にした権限設計が実質12時間の窓を開けてしまいます。 トークンは`CODEARTIFACT_AUTH_TOKEN`環境変数に載せる形が推奨されています。ファイルに書き出せば他のプロセスから読める余地が生まれ、うっかりソース管理に入る事故も起こり得るためです。取り消しはトークン単体ではできず、一時credentialならIAMポリシーで拒否を追加する、長期のIAMユーザーなら権限を落とすかユーザーを削除する、という手順になります。rootユーザーはGetAuthorizationTokenを呼べません。 ### ビルドジョブでのlogin実行位置とIAM権限2つの割り当て ビルドの入口でloginを1回実行し、以降のインストールと公開を同じトークンで通すのが基本形です。[CodeBuildのビルド環境](https://www.issoh.co.jp/tech/details/15595/)ならinstallフェーズかpre\_buildフェーズに置きます。12時間を超えるジョブはまず存在しないため、ジョブ内での再取得は通常不要です。 必要な権限は2つあり、片方だけでは通りません。`sts:GetServiceBearerToken`と`codeartifact:GetAuthorizationToken`の両方をIAMユーザーまたはロールに許可します。前者をドメインのリソースポリシー側に書いても効かない仕様なので、必ずアイデンティティ側のポリシーに置いてください。詰まりやすい箇所なので、[IAMのユーザー・ロール・ポリシーの関係](https://www.issoh.co.jp/tech/details/15427/)を先に整理しておくと切り分けが速くなります。 ## 東京リージョンの実単価から逆算するストレージとリクエストの費用構造 CodeArtifactの課金軸はストレージ・リクエスト・データ転送の3つです。単価そのものは小さく、見積もりで外すのはたいていリクエスト件数の桁です。 ### 保存費よりリクエスト課金が効くCI環境のコスト内訳と見積もり AWS Price List APIで2026年9月時点の単価を引くと、東京リージョンはストレージ0.055USD／GB-月、リクエスト0.0000065USD／件でした。1万リクエストあたり0.065USDに相当し、下表のバージニア北部より約1割高い水準です。 | 課金軸 | 東京 | バージニア北部 | | ----- | ------------- | ------------ | | ストレージ | 0.055USD／GB-月 | 0.05USD／GB-月 | | リクエスト | 0.065USD／1万件 | 0.05USD／1万件 | この構造だと、保管量よりビルド回数が費用を決めます。依存パッケージ200個の取得でおよそ数百リクエストが発生し、1日50ビルドを30日回せば月に数十万リクエスト規模へ届きます。それでも金額としては数USDの水準で、料金を理由にCodeArtifactを避ける判断はまず成り立ちません。逆にキャッシュを効かせずに毎回フル解決している構成は、費用よりビルド時間の側で損をしています。 ### 同一リージョン内転送が無償になる条件とデータ転送費の扱い方針 データ転送は原則としてCodeArtifactへの出入りすべてが課金対象ですが、除外が2つあります。インターネットからの受信データ、そして同一AWSリージョン内のCodeArtifactと他AWSサービス間の転送です。 後者は設計に直結する条件です。CodeArtifactのドメインと、パッケージを取りに来るビルド環境を同じリージョンへ揃えれば、取得のたびの転送費が消えます。東京にドメインを置きバージニア北部でビルドを回す構成は、単価差以上にこの転送費で不利になります。開発拠点が国内なら、ドメインとビルド環境をどちらも東京に寄せる形が費用と遅延の両方で扱いやすいでしょう。 ## スロットリングを避けるためのクォータ把握とRuby特有の重み付け 費用より先に当たる壁がレート上限です。CodeArtifactのクォータは操作別に細かく分かれていて、並列ビルドを増やしたときに顕在化します。 ### 読み取り800rps・単一トークン1200rpsという上限の読み方 アカウント単位の上限は読み取り800rps、書き込み100rpsです。個別のAPIにも上限があり、GetPackageVersionAssetが50rps、PublishPackageVersionが10rps、GetAuthorizationTokenが40rps、一覧系のListPackagesやListPackageVersionsが200rps。これらは引き上げ申請の対象です。一方で引き上げできない上限もあります。単一の認証トークンで1,200rps、トークンなしのリクエストはIPアドレスあたり600rpsが固定値です。 パッケージバージョンあたりのアセット数350、直上流10本も引き上げ不可です。実務で最初に当たるのは書き込み側で、モノレポから数十パッケージを一斉に公開するリリースジョブがPublishPackageVersionの10rpsに触ります。公開を直列化するか、リリース単位を分割するかで回避します。 ### Compact Indexでgem数分がカウントされるRubyの落とし穴 Rubyフォーマットだけは、1回のHTTP呼び出しが複数リクエスト分としてクォータに計上される仕様です。依存解決の問い合わせは指定したgem名の数だけカウントされ、Compact Indexの versions と names はリポジトリ内の全gemを返すため、gemが1,000個あれば1回の呼び出しで1,000リクエスト分を消費します。5,000gemを超えるリポジトリではHTTP 400が返ります。 この重み付けはクォータにだけ効き、課金はHTTP呼び出し1回=1リクエストのままです。請求書を見てもスロットリングの原因は読み取れません。並列で複数のbundle installを走らせるCIでは、実効レートがHTTP件数の見た目より一桁上がります。Ruby中心の構成でスロットリングを踏んだら、まず「単一アカウントからの読み取りリクエスト毎秒」の引き上げを申請するのが公式に示された対処です。 ## 依存関係かく乱攻撃を止めるパッケージグループと権限分割の設計 私有パッケージと公開パッケージを同じエンドポイントに混ぜる構成には、固有の攻撃面があります。社内名と同じ名前のパッケージを公開レジストリに置かれ、そちらが解決されてしまう依存関係置き換え攻撃です。 ### パッケージオリジン制御で新規取り込みと公開を止める設定単位の決め方 パッケージオリジン制御は、パッケージごとに「新しいバージョンを外部から取り込むか」「クライアントからの公開を許すか」を切り替える設定です。社内スコープのパッケージは取り込みを禁止し公開のみ許可、OSSは取り込みのみ許可という形に振り分けます。 これをパッケージ1件ずつ設定するのは現実的ではないため、パッケージグループを使います。フォーマット・名前空間・名前のパターンで一致させ、まとめてオリジン制御を当てる仕組みです。npmの社内スコープ全体、Mavenの自社groupId配下といった単位で1本のルールに寄せられます。新しく作った社内パッケージが規約通りの名前空間なら、追加設定なしで保護される状態を作れます。 ### IAMポリシーとドメインポリシーで分けるアカウント間の許可範囲 権限は2層で書きます。誰が何をできるかはIAMのアイデンティティポリシー、どのアカウントがドメインへ入れるかはドメインのリソースポリシーです。マルチアカウント構成では、共有サービスアカウントにドメインを置き、開発アカウントからのアクセスをドメインポリシーで許可する形が扱いやすくなります。他アカウント所有のドメインを叩く場合は、loginやget-authorization-tokenに`--domain-owner`でアカウントIDを渡します。 リポジトリ単位のポリシーでは、チーム別リポジトリへの書き込みをそのチームのロールに限り、共有リポジトリへの公開はリリース用ロールだけに許すという分け方をします。開発者個人に公開権限を残すと、パッケージオリジン制御をどう設定しても内側から破られます。ビルドサービスのロール以外は読み取りのみ、を初期値にしてください。 ## 受託開発での採用条件と他レジストリを選ぶべき場面の切り分け方 ここまでの制約を踏まえて、採否を条件付きで言い切ります。CodeArtifactは「AWS上で私有パッケージを配る」用途に限れば運用負荷がほぼ消える選択肢ですが、それ以外の動機で選ぶと持ち出しが増えます。 ### 他レジストリとの比較から見たCodeArtifactを選ぶ条件 成果物の種類とホスト先の組み合わせで、候補は自然に絞れます。 | レジストリ | 主な対象 | 外部公開 | 向く場面 | | ----------------- | ---------------- | ------ | --------- | | CodeArtifact | 8フォーマットのパッケージ | 不可 | AWS内で私有配布 | | Amazon ECR | コンテナイメージ | パブリック可 | イメージの配布 | | Artifact Registry | Google Cloudの成果物 | 不可 | GCP中心の構成 | | GitHub Packages | GitHub連携の各形式 | 可 | GitHubで完結 | | Nexus・Artifactory | 対応形式が最も広い | 設定次第 | 自前運用の継続 | 採用条件は3つ揃ったときです。ビルドとデプロイがAWS上にある、私有パッケージを2チーム以上または2アカウント以上へ配る、レジストリサーバーを自前で運用したくない。この3つが揃うなら、IAMで権限が閉じる点とドメイン単位の暗号化が効いて、他の選択肢より運用が軽くなります。[AWSのインフラ構築](https://www.issoh.co.jp/service/system/aws/)を外部に任せる場合も、ドメイン設計とオリジン制御の方針だけは発注側で決めておくと、後からの作り直しを避けられます。 ### 単一チーム・OSSのみの構成でCodeArtifactを見送る判断 逆に、次の場面では導入しません。私有パッケージが1つもなく公開OSSしか取得していない構成では、得られるのは取得元の固定と可用性の担保だけで、認証トークンの管理コストが上回ります。単一チームのモノレポで、共通コードをパッケージに切り出さずワークスペース参照で回している場合も同様です。 NexusやArtifactoryを既に運用していて、CodeArtifactが対応しない形式やプロキシ設定に依存しているなら、移行は見送りが妥当です。CodeArtifactは対応8フォーマットの外へは出られません。また、社外のパートナーへパッケージを配りたい要件では選べません。CodeArtifactのリポジトリは公開できない仕様で、クロスアカウント共有はAWSアカウント間だけです。この場合はGitHub Packagesか、公開レジストリへの正規の公開を検討します。パイプライン全体をどう組むかから決めたい段階なら、[CI/CDの仕組みと導入判断の基準](https://www.issoh.co.jp/column/details/13002/)から入ると議論の順番が整います。 ## よくある質問 CodeArtifactの導入検討で実際に問い合わせの多い5点を、判断に必要な結論から答えます。 ### CodeArtifactは無料で使えますか？ ストレージとリクエストには月次のAWS無料利用枠が設定されているため、小規模な検証なら請求が立たないこともあります。枠を超えた分は、東京リージョンでストレージ0.055USD／GB-月、リクエスト1万件あたり0.065USDの従量課金です（2026年9月時点のPrice List API実測）。無料枠の数量は改定されるため、金額の見積もり前に料金ページで時点確認をしてください。 ### ECRとCodeArtifactはどちらを使えばよいですか？ 成果物で決まります。DockerイメージやOCIアーティファクトはECR、npmやMaven、PyPIなどのパッケージはCodeArtifactです。両方を使う構成が普通で、ビルド中にCodeArtifactから依存を取得し、できたイメージをECRへ押し込むという流れになります。どちらかに寄せる必要はありません。 ### 社外のパートナーにパッケージを配布できますか？ できません。CodeArtifactのリポジトリはパブリックに公開できない仕様です。共有の範囲はドメインポリシーで許可したAWSアカウントまでで、パートナーがAWSアカウントを持ち、そのIDを許可対象に加えられる場合に限られます。AWSアカウントを介さない配布が要件なら、別のレジストリを選んでください。 ### 認証トークンの有効期限を12時間より長くできますか？ できません。設定できる上限は43200秒、つまり12時間です。最短は900秒（15分）です。ロールを引き受けている場合に`--duration-seconds`へ0を渡すと、そのセッションの残存時間に揃えられますが、これも12時間を超えることはありません。長時間動くプロセスでは、失効前に取り直す処理を組み込みます。 ### アップストリームと外部接続は何が違いますか？ 接続先が違います。上流リポジトリは同じドメイン内の別のCodeArtifactリポジトリ、外部接続はnpmjsやMaven Centralなどの公開リポジトリを指します。上限も違い、直上流は10本まで設定できますが外部接続は1本だけです。npmjsとPyPIの両方を引きたいなら、外部接続を1本ずつ持つリポジトリを2つ作り、それらを上流に束ねます。 ## 関連記事 - [Artifact Registryとは？Google Cloudの成果物リポジトリの仕組み・料金とContainer Registry移行を実装者目線で解説](https://www.issoh.co.jp/tech/details/15559/)：Google Cloud側の対応物。マルチクラウドで比較するときの対照として。 - [AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説](https://www.issoh.co.jp/tech/details/3107/)：CodeArtifactから依存を取得するパイプライン側の組み立て方。 - [AWS CodeDeployとは？In-Place・Blue/Greenデプロイと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15597/)：ビルドした成果物を配る先の工程。同じCode系サービスの続き。 - [AWS Secrets Managerとは？料金・ローテーションと採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15888/)：認証トークンや資格情報の置き場所を決めるときの選択肢。 - [SBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説](https://www.issoh.co.jp/column/details/16506/)：レジストリに集めた依存関係を棚卸しする側の道具立て。 --- 出典: [AWS CodeArtifactとは？東京リージョンの料金・アップストリーム設計と認証トークンの扱いを実装者目線で解説]()（株式会社一創）