AWS CodeArtifact
npm や Maven、PyPI のパッケージを社内で安全に保存・共有。依存解決を一元管理できる、フルマネージドなアーティファクトリポジトリ CodeArtifact。
- 社内パッケージと承認した外部依存を、同じリポジトリから取得する。
- 上流で取得した版は保持され、公開元の停止後も同じ版を再利用できる。
- 短期トークン、名前空間制御、版の状態管理で依存経路を守る。
AWS CodeArtifact は、アプリケーション開発で利用するソフトウェアパッケージを保存・共有するためのフルマネージドなアーティファクトリポジトリサービスです。npm、Maven、PyPI、NuGet など主要なパッケージ形式に対応し、開発チームが社内で作成したライブラリの配布先としても、パブリックレジストリのパッケージを取得する経路としても利用できます。
解決する課題
アプリケーション開発では、外部のオープンソースパッケージや社内で共有する内製ライブラリへの依存が積み重なります。これらを自前のアーティファクトリポジトリで管理しようとすると、サーバーの可用性確保、ストレージ容量の管理、認証・認可、各パッケージ形式のプロトコル対応など、継続的な運用負担が発生します。
また、ビルドのたびにパブリックレジストリへ直接アクセスする構成では、上流の障害やレート制限、あるいはパッケージが削除されたケースによってビルドが不安定になりがちです。CodeArtifact はマネージドなリポジトリを提供することでこれらの基盤運用から開発者を解放し、上流リポジトリ機能によってパブリックパッケージをキャッシュして依存解決を安定させます。さらに IAM と統合された認証により、認証情報の配布や権限管理を AWS の仕組みに集約できます。
主要概念と用語
- ドメイン: 複数のリポジトリをまとめる最上位の単位。アカウントや組織のポリシー適用、ストレージの重複排除の境界となる。
- リポジトリ: パッケージを保存・取得する単位。形式の異なるパッケージを同一リポジトリに混在させて格納できる。
- 上流リポジトリ: あるリポジトリが依存解決時に参照する別のリポジトリ。複数を連結でき、ローカルに無いパッケージを上流からたどって取得する。
- 外部接続: パブリックレジストリ(npm の公開レジストリや PyPI など)への接続設定。これを介して取得したパッケージはリポジトリにキャッシュされる。
- パッケージ: ライブラリの配布単位。形式ごとに名前空間やバージョンの規則が異なる。
- 認可トークン: クライアントがリポジトリへアクセスするために取得する一時的な認証トークン。有効期間がある。
- ドメインポリシー / リポジトリポリシー: ドメインやリポジトリ単位でアクセスを許可するリソースベースのポリシー。クロスアカウント共有にも使う。
仕様・制限・クォータ
CodeArtifact は npm、Maven、Python、NuGet、Swift、Ruby、Rust、汎用パッケージを扱えます。標準クライアントをリポジトリのエンドポイントへ向け、短期の認可トークンで公開・取得します。パッケージは保管時に暗号化され、転送時も TLS で保護されます。
既定は 1 アカウント・リージョンあたりドメイン 10、1 ドメインあたりリポジトリ 1,000、1 資産 5 GB、1 リポジトリの直接上流 10 です。依存解決で探索する上流は最大 25、1 リポジトリの外部接続は 1 つで、引き上げできない項目もあります。CI の同時取得では、アカウント単位と単一トークン単位の要求上限を分けて監視します。
認可トークンは既定 12 時間で、15 分〜12 時間に設定できます。引き受けたロールの残り時間へ合わせる場合は --duration-seconds 0 を使います。CI では実行ごとに取得し、設定ファイルへ長期保存しません。
内部の仕組み
横にスクロール
リポジトリは依存解決時に、自身に存在しないパッケージを上流リポジトリへ順にたどって探します。上流の先頭に外部接続を設定したリポジトリを置くと、パブリックレジストリのパッケージが見つかった時点でその実体がリポジトリにキャッシュされ、以降は上流へアクセスせずに取得できます。これにより上流の障害やパッケージ削除の影響を受けにくくなります。
パッケージの実体は AWS が管理するストレージに保持され、保管時の暗号化が適用されます。暗号化キーは AWS マネージドの方式と、カスタマー管理のキーを用いる方式から選べます。ストレージはドメイン単位で集約されるため、同一ドメイン内の複数リポジトリが同じパッケージを参照しても実体は重複して保持されず、ストレージ効率が高まります。一度取得・公開したパッケージのバージョンは原則として内容が固定され、同一バージョンの上書きは許されないため、ビルドの再現性が保たれます。
設計パターン / ベストプラクティス
ドメインは組織やアカウント群の単位で設計し、用途や環境(開発・本番など)ごとにリポジトリを分けると管理しやすくなります。外部接続を持つ「取得用」のリポジトリを上流に置き、内製パッケージを公開する「配布用」のリポジトリをその下流に置く構成にすると、開発者は単一のエンドポイントを向けるだけで、内製パッケージとパブリックパッケージの双方を解決できます。
パブリックレジストリへ直接アクセスさせず、必ず CodeArtifact を経由させることで、上流のレート制限や可用性の影響を緩和し、取得したパッケージをキャッシュとして固定できます。クロスアカウントで内製パッケージを共有する場合は、リポジトリポリシーやドメインポリシーで必要最小限の権限を付与します。
外部接続を含む上流リポジトリを連結し、開発者やビルドの向き先を CodeArtifact の単一エンドポイントに統一すると、パブリックと内製のパッケージをまとめて解決でき、依存元の管理がシンプルになります。
運用・監視
CodeArtifact は API 呼び出しを証跡として記録できるため、誰がいつパッケージを公開・取得・削除したかを監査できます。パッケージのバージョンが追加・変更された際のイベントを契機に、後続の通知や自動処理を起動する運用も構成できます。
メトリクスを通じてリポジトリの利用状況やストレージ使用量を把握し、不要になった古いパッケージバージョンを整理することで肥大化を抑えます。CI/CD と連携する場合は、ビルド時に認可トークンを取得して依存を解決し、生成した内製パッケージを公開するまでの一連の流れをパイプラインに組み込み、依存の取得を再現性のあるものにします。
コスト
CodeArtifact の料金は主に、保存しているパッケージのストレージ容量、リクエスト数、そしてリージョン外へのデータ転送量に基づきます。同一ドメイン内ではストレージが重複排除されるため、複数リポジトリで同じパッケージを共有してもストレージコストは抑えられます。
コストを抑えるには、不要になったパッケージバージョンを定期的に削除し、外部接続によるキャッシュを活用して重複した取得を避けることが有効です。具体的な単価は変動するため、最新の料金ページで確認してください。
同一ドメイン内ではパッケージの実体が重複排除されるため、関連する複数リポジトリを同じドメインにまとめると、ストレージコストの増加を抑えられます。
セキュリティ
アクセス制御は IAM ポリシーとリソースベースのポリシーの組み合わせで行います。IAM でプリンシパルごとの権限を定義し、ドメインポリシーやリポジトリポリシーでドメイン・リポジトリ単位の許可やクロスアカウント共有を構成します。最小権限の原則に従い、パッケージの公開と取得の権限を役割ごとに分離するのが望ましい設計です。
保管時の暗号化はカスタマー管理キーを指定でき、鍵の管理やローテーション、アクセスログを統制下に置けます。外部接続を経由したキャッシュにより、信頼できる経路でパブリックパッケージを取り込み、削除や差し替えの影響を抑えられます。VPC からの閉域アクセスが必要な場合は、インターフェース型のプライベート接続を用いることで、インターネットを経由せずにリポジトリへアクセスできます。
内製の機密パッケージを意図せず広く取得可能にしないよう、リポジトリポリシーの共有範囲を厳格に管理してください。また外部接続の取り込み元が信頼できるレジストリであることを確認し、悪意あるパッケージの混入を防いでください。
Well-Architected の観点
セキュリティの柱では、IAM とリソースポリシーによる最小権限、保管時暗号化、外部接続を経由した信頼できる取り込み、閉域アクセスが中心になります。依存パッケージの取得経路を CodeArtifact に集約することで、ソフトウェアサプライチェーンの統制を高められます。
運用上の優秀性の柱では、上流リポジトリによるキャッシュで依存解決を安定させること、API 証跡による監査性、イベント駆動の自動処理、CI/CD への統合が貢献します。マネージドサービスとしてリポジトリ基盤の運用を AWS に委ねられる点も、運用効率の向上につながります。
試験で問われるポイント
- CodeArtifact は npm・Maven・PyPI・NuGet など複数のパッケージ形式に対応する点。
- ドメインが複数リポジトリをまとめ、ストレージの重複排除の境界になる点。
- 上流リポジトリと外部接続により、パブリックパッケージをキャッシュして依存解決を安定させる点。
- リポジトリへのアクセスには有効期間のある認可トークンを取得する点。
- IAM ポリシーとリソースベースのポリシーでアクセス制御し、クロスアカウント共有もできる点。
- 保管時は暗号化され、カスタマー管理キーも指定できる点。
- VPC からはインターフェース型のプライベート接続で閉域アクセスできる点。
関連サービス・比較
CodeArtifact と比較されやすいのは、コンテナイメージを扱う Amazon ECR です。どちらもソフトウェアの成果物を保存・配布するマネージドなリポジトリですが、CodeArtifact はライブラリ単位のパッケージを、ECR はコンテナイメージを対象とする点が大きく異なります。
| 観点 | AWS CodeArtifact | Amazon ECR |
|---|---|---|
| 対象成果物 | npm や Maven などのパッケージ | コンテナイメージ |
| 主な利用者 | アプリ開発者やビルド工程 | コンテナのビルド・実行環境 |
| 上流からの取得 | 外部接続でパブリックレジストリをキャッシュ | プルスルーキャッシュで外部イメージを取得 |
| アクセス制御 | IAM とリソースポリシー | IAM とリポジトリポリシー |
| 主な用途 | 依存ライブラリの保存・共有 | イメージの保存・配布 |
ハンズオン / CLI例
# ドメインとリポジトリを作成
aws codeartifact create-domain --domain my-domain
aws codeartifact create-repository \
--domain my-domain \
--repository my-repo
# 外部接続を追加してパブリック npm レジストリをキャッシュ
aws codeartifact associate-external-connection \
--domain my-domain \
--repository my-repo \
--external-connection public:npmjs
# npm クライアントをリポジトリ向けに設定(認可トークン取得を含む)
aws codeartifact login \
--tool npm \
--domain my-domain \
--repository my-repo
# 認可トークンを個別に取得して環境変数へ
aws codeartifact get-authorization-token \
--domain my-domain \
--query authorizationToken \
--output text
AWS Service
AWS CodeArtifactを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
開発者ツール
比較で見る軸
クラウド: AWS / カテゴリ: 開発者ツール / 難易度: basic
導入後に効く点
上流で取得した版は保持され、公開元の停止後も同じ版を再利用できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- 開発者ツール
- 難易度
- basic
- 関連資格
- DOP-C02 / DVA-C02
- 設計柱
- security / operational
判断チェックリスト
- 自社の用途が「開発者ツール / security」に近いか確認する。
- 強みである「社内パッケージと承認した外部依存を、同じリポジトリから取得する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。