You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -47,10 +48,18 @@ security settings and governance for your {+service+} enterprise estate:
47
48
organization(s). The MongoDB account team must enable the paying organization when you establish the |service| subscription. A paying organization lets you set up :atlas:`cross-organization billing <billing/#std-label-cross-org-billing>` to share a
48
49
billing subscription across multiple organizations.
49
50
51
+
A paying organization is common for large enterprises with many
52
+
{+BU+}\s or departments that operate independently but where the
53
+
contract or bill is owned by a central authority.
54
+
50
55
* - Organization
51
-
- Invoicing aggregates and generates at the organization level.
52
-
Line items go to cluster level and below. An organization often
53
-
maps to a {+BU+} or application.
56
+
- An organization can contain many projects under it and provides
57
+
a container to apply shared integration and security settings.
58
+
An organization often maps to a {+BU+} or department within a
59
+
company. The built-in {+service+} Cost Explorer aggregates cloud
60
+
spend at the organization level and breaks out line items at the
61
+
{+cluster+} level below it. You can customize further
62
+
by leveraging the billing API.
54
63
55
64
* - Project
56
65
- Security configuration for the data plane (including database
@@ -106,20 +115,33 @@ projects and {+clusters+}:
106
115
end users.
107
116
108
117
For your dev and test environments, you can develop {+service+}
109
-
{+clusters+} locally with the {+atlas-cli+}. To learn more, see
118
+
{+clusters+} locally with the {+atlas-cli+}. This can enable developers
119
+
to work locally from their machine and cut down on costs for
120
+
development and test environments. To learn more, see
110
121
:atlascli:`Create a Local {+service+} Deployment
111
122
<atlas-cli-deploy-local>`.
112
123
113
124
Org and Project Hierarchies
114
125
````````````````````````````
115
126
127
+
Generally, we recommend a paying organization that is managed
128
+
centrally, and one organization for each {+BU+} or department that is
129
+
linked to the paying org. Then, create a project with one {+cluster+}
130
+
each for your lower (dev/test) and upper environments. To learn more,
131
+
see the following information for :ref:`<project-hierarchy-1>`.
132
+
133
+
If you will easily hit the 250 project limit per organization, we
134
+
recommend creating one organization per environment, such as one each
135
+
for lower and upper environments, or one each for dev, test, staging,
136
+
and prod. This has an added benefit of additional isolation.
Consider the following hierarchy for an example enterprise.
122
-
This hierarchy, which creates fewer |service| organizations, might be useful if you have common teams and permissions across the {+BU+}, and less than the raiseable limit of 250 projects per organization.
143
+
Consider the following hierarchy, which creates fewer |service| organizations, if you have common teams and permissions across the
144
+
{+BU+} and less than the raiseable limit of 250 projects per organization.
Consider the following hierarchy for a different enterprise.
135
-
This hierarchy creates a relatively large number of |service|
136
-
organizations: one per application or scrum team. This hierarchy might
137
-
be useful if each of your teams is fairly independent, they don't share people or permissions within a {+BU+}, or they want to buy credits themselves through the cloud provider marketplace. There is
138
-
no paying organization in this hierarchy.
156
+
Consider the following hierarchy if your organization is highly
157
+
decentralized without a centralized function to serve as the contract
158
+
and billing owner. In this hierarchy, each {+BU+},
159
+
department, or team has their own {+service+} organization. This
160
+
hierarchy is useful if each of your teams is fairly independent, they
161
+
don't share people or permissions within the company, or they want to
162
+
buy credits themselves through the cloud provider marketplace or
163
+
directly with their own contract. There is no paying organization in
0 commit comments