AWSからBuildへの移行

まだ検討段階の方へ。2つのプラットフォームの違いと、それぞれどのようなチームに適しているかはBuildとAWSの比較をご覧ください。このページでは、移行したときに技術的に何が変わるかを説明します。

AWSはインフラを組み立てるための部品を提供し、チームがそれらを組み合わせて自社のプラットフォームを作ります。Buildは、そのプラットフォームをあらかじめ組み上げたものです。したがって移行作業は、アプリケーションそのものの移行というより、その周辺にあるサービスの置き換えになります。GCPとAzureにも同じことが当てはまります。

AWSのサービスに相当するBuildの機能

AWSのサービス	Buildの機能
EC2、ECS、EKS	Dyno。仮想マシンと、自身のネームスペースへのkubectlアクセスも利用可能
RDS、ElastiCache	Buildが自社インフラ上で運用するマネージドアドオン
VPC、ロードバランサー、Route 53	プラットフォームのネットワーキング。標準でプライベート
IAM	プラットフォームレベルのロールベースのアクセス制御
CloudWatch	標準搭載のメトリクス、ログ、アクティビティ履歴
CodePipeline、CodeDeploy	パイプライン、レビュー環境、ワンクリックロールバック
AWS WAF	アプリ単位のウェブアプリケーションファイアウォール（標準搭載）
Inspector、ECRのスキャン	ビルドごとのSPDX形式のソフトウェア部品表（SBOM）と、イメージの脆弱性スキャン（標準搭載）
SSM Session Managerのログ	記録・再生可能なシェルセッション
AWS Artifact	SOC 2レポート（すべてのプランに付属）

コンテナ化されたアプリケーションは、書き換えなしでDockerfileからデプロイできます。作業が発生するのはアプリケーションではなく、その周辺のサービスです。

引き続き制御できること

BuildはAWSより方針の定まったプラットフォームですが、下位のレイヤーには引き続き手が届きます。

• 自身のKubernetesネームスペースへのkubectl直接アクセス
• 標準のDynoワークロードと並べて動かせる仮想マシン
• Dockerfileによるビルドと、設定で変更できるランタイムの挙動（設定を参照）

他に代替のないAWSサービスは、Buildと併用できます。

手放すことになるもの

• サービスの幅。 AWSのカタログは他に類を見ない規模です。専門的なAWSサービスに依存しているアプリケーションは、そのサービスを使い続けるか、AWSに留まる方が適している場合があります。
• リージョン。 Buildは米国・欧州・日本で提供しています。AWSが展開するリージョンは、これよりはるかに広範です。リージョンをご覧ください。
• サービス単位の制御。 Buildがプラットフォームレベルで既定値を決めるのに対し、AWSでは各サービスを個別に設定できます。

セキュリティとコンプライアンス

AWSは必要な部品を一通り揃えており、SOCレポートもAWS Artifactから無償で入手できます。ただしコンプライアンスは、それらをどう設定したかで決まります。

Buildは、SOC 2認証、プライベートネットワーキング、監査ログ、アプリ単位のWAF、ビルドごとのSPDX形式のソフトウェア部品表（SBOM）、イメージの脆弱性スキャン、記録済みのシェルセッションを、すべてのプランに含めています。いずれも設定済みで、サービス単位の設定作業は発生しません。セキュリティをご覧ください。

課金モデル

AWSはコンピュート、データベース、ストレージ、ネットワーキング、データ転送、可観測性を、サービス単位・従量単位・リージョン単位で個別に課金します。Buildは月間のDyno時間プールで課金し、アドオンクレジットと人数無制限のシートを同じ金額に含めています。

実務上変わるのは、キャパシティを計画する単位と頻度です。AWSではサービスごとに調整しますが、Buildでは月に一度、Dyno時間のプール全体を見て決めます。AWSで続けてきたコスト最適化の作業、たとえばインスタンスサイズの適正化、リザーブドキャパシティの確保、データ転送量の見直しは、Buildでは不要になります。サービス単位に最適化する対象が残らないためです。

エンジニアの工数を含めた総コストの考え方はBuildとAWSの比較を、プランごとのキャパシティはBuildの料金をご覧ください。

移行

コンテナ化されたアプリケーションは、書き換えずにDockerfileからデプロイできます。自身のネームスペースにkubectlでアクセスできるため、下位のレイヤーに直接手を入れる手段も残ります。エンジニアによる移行サポートは、エンタープライズプランのすべてのお客様に標準で含まれています。Buildへの移行をご覧ください。

よくある質問

BuildはAWS上で動いていますか？

いいえ。Buildが動いているのは、自社で所有・運用するベアメタルです。ハイパースケーラーから借りたキャパシティは使っておらず、アプリケーションの実行環境までを自社で運用しています。

AWSのサービスをBuildと併用できますか？

はい。Buildでアプリケーションを動かしていても、他に代替のないAWSサービスを併用できます。

BuildのDynoに相当するAWSのサービスは何ですか？

最も近いのはECSのタスクかEC2のインスタンスです。ただし、いずれもBuildのDynoに付随するデリバリー、可観測性、コンプライアンスの層は含みません。

これはGCPやAzureにも当てはまりますか？

はい。どちらもインフラの部品を提供するところまでで、その上のプラットフォームはチームに委ねています。

BuildでKubernetesにアクセスできますか？

はい。自身のネームスペースへのkubectlアクセスを、すべてのプランで提供しています。

既存のIAMポリシーはどうなりますか？

引き継がれません。Buildのアクセス制御はプラットフォームレベルのロールベースのアクセス制御です。サービスごとの設定は不要で、アカウント単位で一度だけ設定します。

最終確認日: 2026年9月7日