MongoDB Atlasとは、MongoDBの開発元が提供する運用込みのデータベースサービスです。AWS・Google Cloud・Azureのいずれかの上に冗長化されたクラスタを配置し、パッチ適用や監視やバックアップまで込みで動かせます。自分でEC2やVMを並べてレプリカセットを組む代わりに、画面とAPIから階層を選んで動かす提供形態だと考えてください。製品そのものの構造やデータモデルはMongoDBとは？ドキュメント指向データベースの構造と使い方入門にまとめてあるため、この記事で扱うのは配置と運用の判断に絞ります。どの階層に置き、どの経路で繋ぎ、費用がどう積み上がり、壊れたときにどこまで戻せるか、です。手を動かす部分はコマンドとコードで載せるので、無料クラスタを1つ作って読み進める形でも構いません。数値と仕様はいずれも2026年9月時点のAtlas公式ドキュメントに当たって確認したものです。
まとめ｜Atlasは運用の代行と検索の拡張を買う選択で、費用は階層で決まる
先に結論を置きます。Atlasが売っているのは「MongoDBの運用作業を持たずに済むこと」と「同じデータの上で全文検索とベクトル検索まで回せること」の二つ。支払うのは、階層の時間課金にストレージ・バックアップ・転送が積み上がる従量費用と、設定の自由度への制約です。
階層は、費用よりも先にバックアップの可否で切ると迷いません。無料クラスタはバックアップ対象外で検証と学習の砂場に限られ、Flexは日次スナップショットが自動で有効になり月額30ドルで頭打ちになるため小規模な実サービスまでは持ちこたえるでしょう。復旧時点の細かい指定・シャーディング・専用ネットワークのいずれかが立った時点で専有クラスタへ移ります。本番設計ならM30以上が推奨線です。M10とM20はバースト性能インフラのため、高負荷が続くとCPUが抑えられる点を織り込んでおいてください。
設計上、最初に固定すべきはリージョンと接続経路です。IPアクセスリストは既定で全遮断であり、公開IPの登録・ピアリング・プライベートエンドポイントのどれを選ぶかで、その後のネットワーク設計とアプリの配置先が決まります。階層は後から上げられますが、リージョンと経路は動かしにくい。この順序を守るだけで移行のやり直しは大きく減ります。
作業の入口としては、画面よりもAtlas CLIのほうが再現しやすい。無料クラスタの作成・アクセスリストへの登録・ユーザー作成・シェル接続までを1コマンドで通せるため、検証環境を何度も作り直す前提の作業に向いています。本番相当の構成まで進んだら、後述のTerraformで宣言に落として画面操作を減らす形が扱いやすいでしょう。
MongoDB Atlasとは何か｜マネージド提供で代行される運用の範囲
Atlasが代行する作業｜配置・冗長化・監視・更新の自動化の中身
Atlasが引き受けるのは、インフラ寄りの反復作業です。クラスタの払い出し、レプリカセットの構成、ノード障害時の入れ替え、ストレージ拡張、メトリクス収集と閾値アラート、スナップショットの取得と保持、マイナーバージョンのパッチ適用。自前運用の経験があれば、そのまま「夜間に起こされる原因の上位」だと分かるはずです。おかげで専任のDBA相当を置けない小規模チームでもレプリカ3ノード構成を維持できますが、代わりにOS層やmongod.confの直接編集はできず、調整は画面とAPIで公開された範囲に限られます。どこまでがサービス側の責務かはAtlasのアーキテクチャセンターに設計指針としてまとまっているため、社内の運用分担を書くときの下敷きに使えます。
利用側に残り続ける責務｜データモデルとインデックスと権限の設計
代行されないものを誤解すると、導入後に「思ったより遅い」「思ったより高い」という結末になります。残り続けるのは四つ。ドキュメントのスキーマ設計（埋め込みと参照の使い分け）、インデックス設計、データベースユーザーとロールの設計、そしてクエリの書き方そのものです。なかでも索引は階層を上げて誤魔化しがちな箇所で、M10で遅いからM30に上げたら直った、という対処は費用を三倍にしただけで原因が残ります。張り方と検証手順はMongoDBのインデックス完全ガイドを先に一周してください。選択肢そのものの整理はデータベースとは？種類とRDBとNoSQLの選び方にあります。
3クラウド提供とバージョン｜無料とFlexは8.0系、専有は選択制
配置先はAWS・Google Cloud・Azureから選べ、同一クラスタを複数リージョンへ広げる構成も取れます。この選択肢があること自体が、単一クラウド事業者のマネージドDBとの分かれ目です。
版の扱いは階層で違います。クラスタ管理の公式ドキュメントでは、2026年9月時点で無料クラスタとFlexが 8.0 固定、専有クラスタが 7.0 と最新リリースの選択制と案内されています。つまり「古い版に留まる」余地があるのは専有階層だけで、無料枠やFlexで検証した挙動がそのまま旧版の本番に当てはまるとは限りません。ここで一つ、移行時に効く仕様があります。「最新版へ自動でアップグレードする」設定を選ぶと、マイナーとパッチが自動で上がる代わりにLive Migrationとmongosyncが非対応になる点。他所からのデータ移送をこれらで予定しているなら、移送が終わるまで版を固定しておいてください。
まず無料クラスタを作って繋ぐ｜CLIの導入から疎通確認までの手順
Atlas CLIを入れて認証する｜atlas setupが作る一式の中身
読むだけで判断が固まる話ではないため、先に手を動かす経路を通しておくのが近道です。Atlas CLIは2026年9月時点で 1.58 系のドキュメントが公開されており、Homebrewやパッケージマネージャから入ります。導入したら atlas setup を叩くだけで、アカウント認証・無料クラスタの作成・サンプルデータの投入・自分の送信元IPのアクセスリスト登録・データベースユーザーの作成・シェル接続までが一続きに走ります。画面を10回ほどクリックする代わりの1コマンドだと考えてください。
brew install mongodb-atlas-cli
atlas setup
atlas auth login
atlas projects list検証を何度もやり直すなら、この時点で atlas projects create でプロジェクトを分けておくと後片付けが楽になります。プロジェクト単位でアクセスリストとユーザーが独立するため、検証用の全開放設定を本番プロジェクトへ持ち込む事故を構造的に防げます。
クラスタを明示して作る｜atlas clusters createの引数選び
階層やリージョンを自分で決めて作る場合は atlas clusters create を使う形です。公式のコマンド仕様では --tier の既定値が FLEX、--members の既定値が 3 と明記されており、明示しなければFlexの3ノード構成になります。専有階層で検証したいときは --tier を M10 以上に、版を固定したいときは --mdbVersion を渡します。
atlas clusters create dev-docs \
--provider AWS \
--region AP_NORTHEAST_1 \
--tier M10 \
--members 3 \
--mdbVersion 8.0 \
--diskSizeGB 10 \
--watch
atlas accessLists create --currentIp
atlas dbusers create --username appuser --role readWriteAnyDatabase--watch を付けると作成完了までコマンドが待つため、CIやスクリプトから叩く場合はこれを入れておくと後続処理が空振りしません。同じ操作はAtlas Administration APIでも書けるので、社内の払い出し基盤に組み込むならHTTP経由に寄せる選択もあります。
mongoshで繋いで確かめる｜接続文字列と初回の疎通の見かた
接続確認はmongoshが手早い。接続文字列は画面かCLIから取得でき、SRVレコード形式のホスト名にレプリカセットの構成情報が入っています。繋がったら、まず db.hello() でどのノードに繋がったかを見て、書き込みが通るかを1件試します。
atlas clusters connectionStrings describe dev-docs
mongosh "mongodb+srv://[email protected]/appdb"
db.hello().me
db.docs.insertOne({ title: "疎通確認", createdAt: new Date() })
db.docs.find().limit(1)
db.docs.getIndexes()ここで繋がらない場合の切り分けは後述のFAQに置きました。第一にアクセスリスト、第二に認証情報、第三に送信元IPの実際の出口。CLIで atlas accessLists list を見れば登録内容がそのまま並ぶため、画面を開くより早く原因に辿り着けます。
クラスタ階層の選び方｜無料枠とFlexと専有クラスタの使い分け基準
無料クラスタ（旧M0）｜512MBの検証枠で本番に使えない理由
無料クラスタは、プロジェクトごとに1つ持てる砂場のレプリカセットです。公式の制限一覧には、ストレージ0.5GB・同時接続500・毎秒100操作・7日間のローリング期間で入出それぞれ10GBの転送上限・ソート時のメモリ32MB・データベース100件とコレクション500件・30日間接続がなければ自動一時停止、と数値で並んでいます。学習やPoC、CIから叩く一時的な検証になら十分でしょう。
ただし本番に置けない決定的な理由があります。Atlasのバックアップ対象外であることです。退避したいなら mongodump と mongorestore を自分で回す必要があり、その時点で「運用を持たない」という導入目的が崩れます。加えて、シャーディング・ネットワークピアリング・プライベートエンドポイント・顧客管理鍵・Performance Advisorがいずれも使えません。実データが乗る瞬間にFlex以上へ上げる、と決めておいてください。
Flexクラスタ｜月30ドル上限の小規模枠と旧階層からの移行先
Flexは2025年2月に一般提供が始まった階層で、共有階層と旧サーバーレスの後継にあたります。公式の料金ページでは 0.011 ドル毎時、継続して使った場合の月額は 8 ドルから 30 ドルの範囲で、上限が 30 ドルと示されています。ストレージは5GB、日次スナップショットが自動で有効になり無効化できません。
この「上限が固定される」性質が実務では効きます。従量課金のデータベースで最も怖いのは、想定外のクエリやループでその月の請求が跳ねること。Flexではその事故が構造的に起きません。社内ツールや管理画面のバックエンド、トラフィックが読めない初期サービスなど、上振れの怖さが機能要件より優先する場面に向きます。
専有クラスタM10・M20｜バースト型CPUの上限と用途の見極め
M10から専有クラスタになり、自分たちのためのインスタンスが割り当てられます。専用VPC（AzureならVNet）が付き、ピアリングやプライベートエンドポイント、顧客管理鍵といった企業要件がここで解禁されます。構成はレプリカセットのみで、シャーディングはできません。公式の料金ページでは専有階層の起点が 0.08 ドル毎時・月額 56.94 ドルからと提示されています。
注意すべきはCPUの性質でしょう。M10とM20はバースト性能インフラを使っており、バーストを使い切ると上限が掛かって性能が絞られます。日中ずっとCPUを踏み続ける処理や、長時間回すバッチ集計をここに置くと、突然遅くなる現象として現れます。低トラフィックの本番、あるいは本番同等の検証環境という位置づけが実態に合うはずです。
M30以上の本番構成｜シャーディングと世代差で変わる入出力の性能
M30以上が、公式にも本番環境として推奨される層です。クラスタ管理のドキュメントでもシャーディング対応は M30 以上と明記され、水平分割で書き込みとデータ量を分散できます。CPUもバースト依存ではなくなります。AWSではさらにGen1とGen2の世代差があり、ストレージ設定のドキュメントのとおりGen2は標準IOPSとストレージ容量を別々に増減でき、標準IOPSの上限は80kです。容量は小さいがランダム読み書きが多い負荷なら、余分な容量を買わずに入出力だけを引き上げられます。読み書きの実測値があるなら、階層を一段上げる前に世代を確認してください。
| 階層 | バックアップ | 構成 | 主な用途 |
|---|---|---|---|
| 無料（旧M0） | 対象外 | 共有基盤・8.0固定 | 学習・PoC・一時検証 |
| Flex | 日次・無効化不可 | 上限付き従量・8.0固定 | 社内ツール・初期サービス |
| M10・M20 | クラウドバックアップ | レプリカセット・版選択可 | 低トラフィック本番・検証 |
| M30以上 | クラウドバックアップ | 分割構成も可・版選択可 | 本番・継続負荷 |
料金の数え方｜階層費用に加算されるストレージと転送とバックアップ
課金要素の分解｜階層の時間課金に対して何がどれだけ積み上がるか
専有クラスタの費用は、大きく五つの合計です。クラスタの時間課金、ストレージ、バックアップの保存量と保持期間、リージョンをまたぐ転送と下り転送、検索専用ノードなどの追加コンポーネント。複数リージョンへ広げれば、その分ノードが増えて時間課金も転送も増えます。内訳の定義は請求ドキュメントのクラスタ構成費用に項目ごと分けて書かれているため、社内の見積書と突き合わせるときはここを基準にしてください。
目安として、M10相当の単価は0.08ドル/時、公式提示では月額56.94ドルから。ここにストレージ・バックアップ・下り転送が乗ると月75〜85ドル程度になるという外部の集計値が複数あります。公式の提示価格ではなく第三者の実測レンジなので桁感の確認に留め、確定見積りは自分の構成で計算してください。それでも「時間課金の3割前後が付帯費用として乗る」という感覚は、社内の予算取りで役に立ちます。
見積りの手順｜ピーク時の作業量から階層と保持期間を逆算する流れ
手順は四段階です。第一に、ピーク時の秒間クエリ数と書き込み量、ワーキングセット（頻繁に触るデータ量）を出す。これがメモリに乗り切るかどうかが階層選定の実質的な基準になります。第二に、総データ量と索引サイズからストレージを見積もる。索引は設計次第でデータ本体に匹敵します。第三に、バックアップの保持期間を決める。保持を伸ばせば保存量がそのまま費用になるため、監査要件がないなら短く始めるのが無難でしょう。第四に、アプリとDBのリージョン一致を確認してください。ずれていると転送費用が毎月静かに積み上がります。
接続とセキュリティ設計｜既定は全遮断で、経路の選択が最初の作業
IPアクセスリストの登録｜既定は全遮断で、通す経路を明示的に足す
Atlasはプロジェクトのアクセスリストに登録された経路からの接続だけを通します。IPアクセスリストの公式ドキュメントのとおり、繋ぐ方法は三つ。公開IPアドレスをリストに追加する、ピアリングで私設IPから入る、プライベートエンドポイントを追加する、のいずれかです。開発初期に 0.0.0.0/0 を登録して全開放し、そのまま本番へ移ってしまう事故がよく起きます。認証は別途あるとはいえ、全世界からの接続試行を受ける状態を残す理由はありません。検証中に全開放したなら、本番切り替えのチェックリストに「アクセスリストの棚卸し」を必ず入れてください。
暗号化と認証方式｜TLS必須と保存時の暗号化、四つの認証手段
通信はTLSが必須で、平文接続という選択肢自体がありません。セキュリティFAQには、証明書が発行から90日有効で期限の42日前にローテーションされると書かれています。ドライバ側で証明書を固定的に埋め込む実装をしているとこのローテーションで切れるため、標準のCA検証に任せる形が無難でしょう。
保存時は、ストレージとスナップショットの両方がAES-256で暗号化され、鍵はクラウド事業者側で自動管理されます。鍵を自社で握る要件があるなら、AWS KMS・Azure Key Vault・Google Cloudによる顧客管理鍵へ切り替えてください。認証はデータベース認証の設定ドキュメントにあるとおりSCRAMに加え、X.509クライアント証明書（Atlas管理と自己管理の双方）、AWS IAMロール、LDAPが選べます。EC2やECSからIAMロールで繋ぐ形にすると、接続文字列にパスワードを埋め込む運用を消せます。
アプリから繋ぐコード｜Node.jsドライバとIAM認証の書き方
アプリ側の接続は、各言語の公式ドライバがそのまま使えます。Node.jsドライバのドキュメントと実装リポジトリを見ると、接続文字列とクライアントの再利用がほぼ全部で、Atlas固有の初期化はありません。押さえるのは、クライアントを1プロセスに1つ持ってプールを使い回すこと、接続文字列を環境変数から読むこと、そして再接続をドライバに任せることの三点です。
import { MongoClient } from "mongodb";
const client = new MongoClient(process.env.MONGODB_URI, {
maxPoolSize: 20,
serverSelectionTimeoutMS: 5000,
retryWrites: true
});
async function findRecentDocs(limit) {
await client.connect();
const col = client.db("appdb").collection("docs");
return col.find({}).sort({ createdAt: -1 }).limit(limit).toArray();
}EC2やECS、EKSから繋ぐならAWS IAM認証に寄せると、パスワードの管理そのものを消せます。接続文字列の認証メカニズムに MONGODB-AWS を指定し、資格情報は実行ロールから取らせる形です。ローカル検証時だけアクセスキーを環境変数に置き、本番はロールに任せる切り分けにしておくと、コードは1本で済みます。
# 本番（EC2やECSの実行ロールから資格情報を取得）
MONGODB_URI="mongodb+srv://cluster0.abcde.mongodb.net/appdb?authSource=%24external&authMechanism=MONGODB-AWS&retryWrites=true"
# ローカル検証のみ環境変数で渡す
export AWS_ACCESS_KEY_ID=AKIAEXAMPLE
export AWS_SECRET_ACCESS_KEY=secretexample
export AWS_SESSION_TOKEN=tokenexample専用ネットワーク経路｜ピアリングとプライベート接続の使い分け
M10以上の専有クラスタを持つプロジェクトには、専用のVPC（AzureはVNet）が割り当てられます。ここから先の経路は二択です。ネットワークピアリングは自社VPCとAtlas側VPCを相互接続する方式で双方向の到達性を持ち、プライベートエンドポイントはAWS PrivateLink・Azure Private Link・GCP Private Service Connectを使って自社側から一方向で入る方式です。AWS側の課金や設計の勘所はVPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較に整理してあるので、費用の比較まで含めて決めたい場合はあわせて読んでください。
判断の目安はこうです。CIDRの重複を避けられ、少数のVPCから繋ぐだけならピアリングで足ります。アカウントやVPCが多くCIDR設計を揃えられない、あるいは「Atlas側から自社網へ入れる経路を作らない」という要件があるならプライベートエンドポイントを選ぶ。組織が大きいほど後者へ寄る、と覚えておけば大きく外しません。
バックアップと復旧の設計｜階層別の取得方式と復元先バージョン制約
階層別のバックアップ｜専有はクラウド保全、Flexは日次取得
専有のM10以上ではクラウドバックアップが使え、取得されたスナップショットは既定でイミュータブル、つまり変更できません。さらにバックアップコンプライアンスポリシーを有効にすると、すべてのユーザーに対して削除と保持設定の変更を禁じられます。管理者権限を奪われた場合でもバックアップを消させない、という要件への備えです。
Flexクラスタでは日次スナップショットが自動で取得され、無効化できません。復元先はFlexクラスタ、またはM10以上の階層。つまりFlexで運用しておいて、有事に専有クラスタへ引き上げながら戻す復旧経路が取れます。無料クラスタだけがこの仕組みの外にあり、mongodump による自前退避に頼ることになります。
復元の制約｜復元先の版とバージョンの前後関係、停止時間の扱い
見落とされやすいのが、復元先バージョンの制約です。バックアップから戻せるのは、同一メジャーで同等以上のマイナーを持つクラスタ、または次のメジャーのクラスタに限られます。8.1系で取ったスナップショットは8.1系や8.2系へは戻せますが、8.0系へは戻せません。古い版のクラスタを避難先として用意しておく、という発想が通らない点に注意してください。
もう一つ、復元中は対象クラスタへ書き込めません。本番クラスタに直接復元をかける手順は、その間の停止時間をそのまま受け入れることを意味します。停止を短くしたいなら、新しいクラスタへ復元してから接続先を切り替える。切り替え先をアプリの設定値として持てるようにしておく準備が、復旧時間を左右します。
無料枠の自前退避｜mongodumpとmongorestoreを回す手順
無料クラスタやローカル検証環境のデータを持ち出す場合は、Database Toolsのmongodumpを使います。接続文字列を --uri に渡し、出力先ディレクトリを指定するだけです。圧縮まで掛けるなら --gzip を足し、コレクションを絞るなら --collection を付けます。定期実行するなら、CIのスケジュール実行かcronから叩いてオブジェクトストレージへ置く形が扱いやすい。
mongodump \
--uri="mongodb+srv://[email protected]" \
--db=appdb \
--gzip \
--out=./dump-20260907
mongorestore \
--uri="mongodb+srv://[email protected]" \
--gzip \
--nsFrom="appdb.*" \
--nsTo="appdb_restored.*" \
./dump-20260907復元時は --nsFrom と --nsTo で名前空間を差し替えられるため、本番の隣に検証用のデータベースとして戻して中身を確かめる、という手順が取れます。本番へ直接 mongorestore を掛ける運用は、書き込み中の整合性を自分で保証することになるので避けてください。手段としての退避が使えるかどうかを、実データを載せる前に一度通しておくのが安全です。
検索機能の拡張｜全文検索とベクトル検索を同じクラスタで回す設計
同一クラスタ内での検索｜全文検索とベクトル検索の実装の置き場所
Atlasには全文検索の索引と、ベクトル検索という二つの検索機能が内蔵されています。業務データが入っているコレクションに対して索引を張り、集約パイプラインの一段として検索を書けます。別の検索エンジンを立てて同期パイプラインを組む構成と比べると、同期の遅延やずれを設計から消せる点が大きな差です。専用のベクトルデータベースを別立てにする案と迷うなら、ベクトルデータベースのおすすめは？3タイプ比較とRAG用途の選び方に3タイプの比較を置いてあるので、そちらで自社の要件がどの型に寄るかを先に見ておくと判断が早くなります。
索引を定義して検索する｜索引の作成と集約パイプラインの記述例
索引の定義はJSONで、画面・CLI・シェルのいずれからも作成可能です。全文検索側は動的マッピングで全フィールドを対象にする書き方が手軽で、フィールドを絞るなら静的に列挙します。ベクトル側はベクトル索引の型ドキュメントに沿って、格納先のパス・次元数・類似度の指標を宣言します。次元数は使う埋め込みモデルの出力に合わせるため、モデルを差し替えると索引を作り直す点は覚えておいてください。
db.docs.createSearchIndex("docs_text", { mappings: { dynamic: true } })
db.docs.createSearchIndex(
"docs_vec",
"vectorSearch",
{ fields: [ {
type: "vector",
path: "embedding",
numDimensions: 1536,
similarity: "cosine"
} ] }
)
db.docs.getSearchIndexes()検索そのものは集約パイプラインの先頭に置きます。ベクトル検索では候補数と返却件数を別に指定でき、候補数を増やすと精度が上がって計算量も増える関係です。スコアはメタデータとして取り出せるため、しきい値で切る処理をアプリ側に書けます。
db.docs.aggregate([
{ $vectorSearch: {
index: "docs_vec",
path: "embedding",
queryVector: qv,
numCandidates: 200,
limit: 10
}},
{ $project: { title: 1, score: { $meta: "vectorSearchScore" } }}
])生成AIの検索拡張生成（RAG）を組む場合、埋め込みベクトルと元の業務データを同じドキュメントに持てるため、検索結果から本体の属性へ辿り直す処理が不要になります。ベクトルストアを別立てにした構成でよく起きる「IDだけ返ってきて本文を引き直す」往復が消えるわけです。
検索専用ノードの分離｜業務クエリと検索の負荷を分ける判断と費用
検索の負荷は通常のCRUDとは性質が違い、索引の構築と更新はCPUとメモリを継続的に使います。同じノードに同居させると業務クエリの遅延が揺れるため、Atlasには検索専用ノードを分離して割り当てる仕組みがあります。踏み切る目安はこうです。検索が補助的で対象データが小さいうちは分離しません。検索がサービスの主機能である、索引対象が数百万ドキュメントを超える、業務クエリの応答時間にSLOを置いている、のいずれかに該当したら分離する。費用が乗るぶん、判断は「揺れが観測されてから」で構いません。
構成をコードで固定する｜Terraformで階層と経路を宣言する手順
プロバイダと最小構成｜クラスタと接続元をコードで宣言する書き方
検証が済んだら、画面で作った状態をコードへ移す段階です。Terraform Registryのmongodbatlasプロバイダと実装リポジトリが公式提供で、プロジェクト・クラスタ・アクセスリスト・データベースユーザー・プライベートエンドポイントまでリソースとして書けます。AWS側の資材と同じリポジトリに置くなら、認証とステート管理の型はTerraformでAWSを構築する手順｜aws 6系の認証とS3バックエンド設計で扱った構成をそのまま流用できます。プロバイダは2026年9月時点で 2.17.0 が最新で、1系から上げるときは replication_specs の記法がブロックからリスト属性へ変わっているため、公式の移行ガイドに沿って既存の記述を直してください。
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
version = "~> 2.0"
}
}
}
resource "mongodbatlas_advanced_cluster" "app" {
project_id = var.project_id
name = "app-prod"
cluster_type = "REPLICASET"
replication_specs = [
{
region_configs = [
{
electable_specs = {
instance_size = "M30"
node_count = 3
}
provider_name = "AWS"
priority = 7
region_name = "AP_NORTHEAST_1"
}
]
}
]
}
resource "mongodbatlas_project_ip_access_list" "app_vpc" {
project_id = var.project_id
cidr_block = "10.0.0.0/16"
comment = "app subnet"
}階層とリージョンがコードに書かれていれば、「誰がいつM30へ上げたか」がプルリクエストの履歴として残ります。手作業で上げ下げしていた頃に起きがちだった、検証で上げた階層を戻し忘れて請求が膨らむ事故も、差分として見えるようになります。IaCそのものの導入判断はデータベースとは？種類とRDBとNoSQLの選び方の範囲を超えるため、既存の運用体制と合わせて決めてください。
画面操作との併用｜手で変えた設定が差分に出たときの戻し方の判断
現実には障害対応で画面から設定を変えることがあり、その差分が次の terraform plan に現れます。ここで機械的に適用し直すと、対応中に入れた暫定設定が消えて再発します。運用としては、planの差分を見たら「コード側を実態へ寄せる」か「実態をコードへ戻す」かを毎回明示的に決める。決めた結果をコミットメッセージに残しておけば、後から履歴だけで経緯が追えます。
スナップショットの保持期間やアラート閾値のように運用中に頻繁に触る値は、あえてコード管理から外す判断もあり得ます。すべてを宣言に押し込むより、動かす頻度で線を引いたほうが摩擦は小さくなるでしょう。
独自章｜導入初日に決める5つの設定と、後から変えにくい設定の順序
変えにくい順に決める｜リージョンと接続経路を最初に固定する理由
後から変えやすい順に並べると、バックアップ保持期間、バージョン、階層、接続経路、リージョンの順です。したがって決める順序は逆になります。リージョンを動かすには実質的にデータ移送が要り、接続経路の変更は自社ネットワーク側の設計変更と関係部署の調整を伴う一方、階層は画面から上げ下げでき保持期間はただの設定値だからです。この非対称性を無視して「まず小さく作ってから考える」と進めると、動かしにくい部分ほど検証時の暫定値のまま本番になります。
決め切る5つの項目｜配置・階層・版・経路・保全の初期値の置き方
- 配置：アプリが動くクラウドとリージョンに揃える。転送費用と遅延の両方が効く
- 接続経路：単一VPCからならピアリング、複数アカウント構成やCIDR整理が難しいならプライベートエンドポイント
- 階層：実データが乗るならFlexから。専用ネットワークか復旧時点の細かい指定が要るならM10以上、本番設計ならM30以上
- バージョン：データ移送の予定があるうちは版を固定し、移送完了後に自動更新へ切り替える
- バックアップ保持：監査要件がなければ短く開始する。削除禁止の要件があるならコンプライアンスポリシーを先に有効化
もう一点、初期に決めると後が楽なものがあります。データベースユーザーをアプリ用・管理用・分析用で分けることです。Atlasはロールが細かく、後から分けるより最初から分ける方が接続文字列の差し替えは少なく済みます。前述の atlas dbusers create をスクリプトに落としておけば、環境を増やすたびに同じ分け方を再現できます。
独自章｜Atlasを選ぶ条件と、自前運用や他サービスへ寄せる場面
採用してよい条件｜文書指向のデータ型と運用要員の不足が重なる時
次の条件のうち二つ以上が当てはまるなら、Atlasを採用して差し支えありません。第一に、扱うデータが入れ子構造を持ち、正規化して複数テーブルへ割るより1ドキュメントに収める方が自然な形をしている。第二に、DBの運用に専任を割けず、パッチ適用や冗長化の維持を自分たちで持ちたくない。第三に、全文検索やベクトル検索を同じデータの上で回したい。第四に、配置するクラウドを将来変える可能性がある、あるいは複数クラウドに跨る要件がある。特に第三と第四は単一クラウド事業者のマネージドDBでは代替しにくく、逆にこの二つが不要ならAtlasである必然性は下がります。
見送るべき場面｜単一クラウドで閉じる構成や強い正規化が要る場合
データが強く正規化され、結合を伴う集計が業務の中心にあるなら、無理にドキュメント指向へ寄せる理由はありません。素直にリレーショナルデータベースを選んでください。AWSの中で閉じる構成が決まっており、MongoDB互換のAPIさえあれば足りるならAmazon DocumentDBが選択肢で、IAMやVPCの設計を既存資産と揃えられる利点が効きます。Azure中心でマルチモデルや細かな整合性レベルの指定が要るならAzure Cosmos DB、モバイルアプリからの直接接続やサーバーレス前提の構成ならCloud Firestoreが噛み合うでしょう。
どの階層でどのクラウドに置くか、既存システムからの移送をどう組むかを含めて相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で要件の整理から構築・移行まで承っています。
よくある質問
無料クラスタだけで本番運用できますか？
推奨できません。ストレージが0.5GBに制限される点よりも、Atlasのバックアップ対象外である点が本質的な理由です。加えて毎秒100操作・同時接続500・7日間で入出各10GBという上限があり、少し伸びただけで速度が絞られます。障害時に戻す手段を自前の mongodump に頼ることになり、運用を持たないという導入目的と噛み合いません。実データが入る段階でFlex以上へ上げてください。
Flexから専有クラスタへは止めずに移行できますか？
Flexから専有階層へのアップグレードはAtlas側の操作で実行できます。ただし切り替えに伴う短時間の接続断は見込んでおくべきで、アプリ側に再接続の実装があるかを事前に確かめてください。Flexで取得済みのスナップショットはM10以上への復元にも使えるため、復元経由で新クラスタを立ててから接続先を切り替える手順も選べます。
接続できないときは何から確認しますか？
第一にIPアクセスリスト、第二にデータベースユーザーの認証情報とロール、第三に接続文字列のホスト名とオプション、第四にTLSまわりの証明書検証、第五に踏み台やコンテナの送信元IPが想定どおりか。実務上は第一と第五で大半が解決します。CLIなら atlas accessLists list と atlas dbusers list の2コマンドで前2つを確かめられるので、画面を開く前にここを見てください。特にNATゲートウェイやコンテナ環境では、思っている送信元IPと実際の出口IPがずれがちです。
MongoDB本体をローカルに立てて開発し、本番だけAtlasにできますか？
できます。接続文字列を差し替えるだけでコードは共通に保てるため、DockerのMongoDBで開発して本番をAtlasに置く構成は一般的です。ただし差が出る箇所が二つあり、一つは全文検索とベクトル検索の索引（ローカルのMongoDB単体では同じようには動きません）、もう一つはアクセス制御と認証方式です。検索機能を使うなら、Atlas CLIの atlas deployments setup でローカルにAtlas相当の環境を立てるか、検証用の無料クラスタを開発者ごとに持つ形にしてください。
Atlas Data APIやHTTPSエンドポイントは今も使えますか？
使えません。Data APIとカスタムHTTPSエンドポイントは非推奨化を経て、公式の非推奨ページのとおり2025年9月30日に提供が終了しました。App Servicesの提供終了に伴う措置です。HTTP経由でMongoDBを触る構成が残っているなら、自前のAPI層を立てるか、ドライバから直接接続する構成へ移してください。
アプリ側のドライバやODMは何を使えばよいですか？
各言語の公式ドライバがそのまま使え、接続文字列を差し替えるだけで自前運用のMongoDBから移れます。Node.jsでスキーマ定義や型付けを効かせたい場合はODMを挟む構成が一般的で、Mongooseの使い方とv9の変更点に実装の勘所をまとめています。
関連記事
- MongoDBとは？ドキュメント指向データベースの構造・ドキュメント・使い方入門
- MongoDBのインデックス完全ガイド：種類・作成・ESR・効果確認
- Mongooseとは？Node.js用MongoDB ODMの使い方とv9の変更点
- Amazon DocumentDBとは？MongoDB互換マネージドDBの仕組み・料金・採用判断
- Azure Cosmos DBとは？マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断
- Cloud Firestoreとは？NoSQLドキュメントDBの仕組み・料金・実装判断
- データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説
- ベクトルデータベースのおすすめは？3タイプ比較とRAG用途の選び方【2026年版】
- VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点
- TerraformでAWSを構築する手順｜aws 6系の認証とS3バックエンド設計
