AWSからBuildへの移行
まだ検討段階の方へ。2つのプラットフォームの違いと、それぞれどのようなチームに適しているかはBuildとAWSの比較をご覧ください。このページでは、移行したときに技術的に何が変わるかを説明します。
AWSはインフラの構成要素を提供し、チームがそれらを組み合わせて自社のプラットフォームを作ります。Buildは、そのプラットフォームがすでに組み上がったものです。したがって移行作業は、アプリケーションそのものの移行というより、その周辺にあるサービスの置き換えになります。GCPとAzureにも同じことが当てはまります。
何が何を置き換えるか
Section titled “何が何を置き換えるか”| AWSでは | Buildでは |
|---|---|
| EC2、ECS、EKS | ダイノ。必要に応じてVMと自身のネームスペースへのkubectlアクセスも利用可能 |
| RDS、ElastiCache | Buildのインフラ上で動く自社マネージドアドオン |
| VPC、ロードバランサー、Route 53 | プラットフォームのネットワーキング。デフォルトでプライベート |
| IAM | プラットフォームレベルのロールベースアクセス制御 |
| CloudWatch | 標準搭載のメトリクス、ログ、アクティビティ履歴 |
| CodePipeline、CodeDeploy | パイプライン、レビュー環境、ワンクリックロールバック |
| AWS WAF | アプリ単位のWebアプリケーションファイアウォール（標準搭載） |
| Inspector、ECRのスキャン | ビルドごとのSPDX SBOMとイメージ脆弱性スキャン（標準搭載） |
| SSM Session Managerのログ | 記録・再生可能なシェルセッション |
| AWS Artifact | SOC 2レポート（すべてのプランに標準搭載） |
コンテナ化されたアプリケーションは、書き換えなしでDockerfileからデプロイできます。作業が発生するのはアプリケーションではなく、その周辺のサービスです。
引き続き制御できること
Section titled “引き続き制御できること”BuildはAWSより方針の定まったプラットフォームですが、下位のレイヤーには引き続き手が届きます。
- 自身のKubernetesネームスペースへのkubectl直接アクセス
- 標準のダイノワークロードと並べて動かせる仮想マシン
- Dockerfileによるビルドと、設定可能なランタイムの挙動。設定をご覧ください
他に代替のないAWSサービスは、Buildと併用して使い続けることもできます。
手放すことになるもの
Section titled “手放すことになるもの”- サービスの幅。 AWSのカタログは他に類を見ない規模です。専門的なAWSサービスに依存しているアプリケーションは、そのサービスを使い続けるか、AWSに留まる方が適している場合があります。
- リージョン。 Buildは米国、欧州、日本で提供しています。AWSの拠点数ははるかに多くなります。リージョンをご覧ください。
- サービス単位の制御。 Buildはプラットフォームレベルの既定値を設定します。AWSは各サービスを個別に設定できます。
セキュリティとコンプライアンス
Section titled “セキュリティとコンプライアンス”AWSはあらゆる構成要素を提供し、SOCレポートもAWS Artifactから無償で入手できます。ただしコンプライアンスは、それらをどう設定したかの結果として決まります。
BuildではSOC 2認証、プライベートネットワーキング、監査ログ、アプリ単位のWAF、ビルドごとのSPDX SBOM、イメージの脆弱性スキャン、記録済みのシェルセッションが、すべてのプランで設定済みかつ標準搭載です。これらにサービス単位の設定作業は発生しません。セキュリティをご覧ください。
AWSはコンピュート、データベース、ストレージ、ネットワーキング、データ転送、可観測性を、サービスごと・単位ごと・リージョンごとに個別に課金します。Buildは月間のダイノ時間プールで課金し、アドオンクレジットと人数無制限のシートを含めています。
実務上の変化は、キャパシティをサービスごとに調整するのではなく、月に一度まとめて計画する形になることです。インスタンスの適正化、リザーブドキャパシティ、データ転送量の見直しといったコスト最適化の作業は引き継がれません。サービス単位で最適化する対象がなくなるためです。
エンジニアの工数を含めた総コストの考え方はBuildとAWSの比較を、プランごとのキャパシティはBuildの料金をご覧ください。
コンテナ化されたアプリケーションは書き換えなしでDockerfileからデプロイでき、自身のネームスペースへのkubectlアクセスによって低レイヤーへの逃げ道も確保されています。エンジニアによる移行サポートは、エンタープライズプランのすべてのお客様に標準で含まれています。Buildへの移行をご覧ください。
よくある質問
Section titled “よくある質問”BuildはAWS上で動いていますか？
いいえ。Buildは借りたハイパースケーラーのキャパシティではなく、自社で所有・運用するベアメタル上で、アプリケーションの実行環境まで動かしています。
AWSのサービスをBuildと併用できますか？
はい。Buildでアプリケーションを動かしていても、他に代替のないAWSサービスを併用できます。
Buildのダイノに相当するAWSのサービスは何ですか？
最も近いのはECSのタスクかEC2のインスタンスです。ただし、いずれもBuildのダイノに付随するデリバリー、可観測性、コンプライアンスの層は含みません。
これはGCPやAzureにも当てはまりますか？
はい。どちらもインフラの構成要素を提供し、その上のプラットフォームはチームに委ねられています。
BuildでKubernetesにアクセスできますか？
はい。自身のネームスペースへのkubectlアクセスを、すべてのプランで提供しています。
既存のIAMポリシーはどうなりますか？
そのままは引き継がれません。Buildのアクセス制御はプラットフォームレベルのロールベースアクセス制御であり、サービスごとではなくアカウント単位で一度設定します。
最終確認日: 2026年9月7日