Architecture and operating model
A landing zone is the identity, hierarchy, networking, logging, policy and cost-governance foundation created before application workloads. Google Cloud organization/folder/project, AWS Organizations OU/account and Azure tenant/management group/subscription address similar governance concerns but are not equivalent objects.
Instead of copying one universal template into three clouds, define shared control outcomes: production separation, central logs, emergency access, egress, key management, budget alerts and policy exceptions. Translate each outcome into the native platform model. Common naming and labels improve reporting without hiding platform differences.
A centralized network account is not automatically correct. Consider application change rate, data residency, regional dependencies and common failure domains. Organization roots or management accounts should not host routine workloads; use separate security/logging scopes and controlled break-glass access.
- 1Enterprise identity and hierarchy
- 2Policy and network foundation
- 3Account/project/subscription vending
- 4Workload acceptance
Design parameters
- Hierarchy
- Model business unit, environment and data class together with policy-inheritance behavior.
- Identity
- Separate federated human access from short-lived workload identities.
- Network
- Evaluate hub-spoke, shared VPC/VNet and transit options for latency, charges and failure domains.
- Policy
- Separate preventive and detective controls; give exceptions owners, expiry and approval records.
Worked example
Create prod, nonprod and sandbox boundaries across all three platforms. A shared matrix requires blocking public object storage, central audit logs and monthly budget alerts, while implementations use Google Cloud Organization Policy, AWS Control Tower/Organizations and Azure Policy.
For ten teams and three clouds, pilot one application before creating 30 accounts. Measure account lead time, policy conflicts, log latency, private DNS and emergency access, then turn the result into an account factory.
Example commands: replace lab values and confirm permissions and software versions before use.
# Track control outcomes independently of platform object names.
control_id,scope,mode,owner,exception_expiry
LOG-001,all,audit,security,
NET-003,production,enforce,network,
COST-002,all,alert,finops,Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| New account misses policy | It may be under the wrong OU/folder/management group or bootstrap is incomplete. | Check hierarchy path, policy inheritance and provisioning record together. |
| Central logs are incomplete | Sink, trail or diagnostic settings may omit regions or services. | Generate a pilot event and trace one event ID through source, transport and destination. |
| Private service name fails | Central DNS connection or split-horizon association may be missing. | Compare client resolver path, zone association and forwarder logs. |
Acceptance checks
- Validate automated baseline on each new cloud scope.
- Show that management roots host no routine workloads.
- Test central audit delivery to a protected destination.
- Exercise public-access policy with a controlled violation.
- Rehearse break-glass with alerting and expiry.
- Produce budget, label and orphan-resource reports across platforms.
Related concepts
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
IT/OT security zones
A zone groups assets with similar operational and security requirements; communications between zones should traverse controlled conduits. An accessible OT device is not necessarily safe to scan or update. Control latency, safety, vendor support and maintenance windows influence decisions. Observe actual PLC and SCADA flows rather than copying IT policies unchanged. Define identity, duration, approval and logging requirements for remote support, and coordinate active tests and cutovers with production owners.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behaviour. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Cost boundaries
Cost includes more than purchase price or a monthly resource bill. Licensing scope, storage, egress, backup, support, operating effort and disruption impact are separate items. Compare equal service levels, capacity and time periods; a cheaper option may exclude an obligation. Compare forecast and actual spending by resource or business unit. Assess underuse risk for commitments and uncontrolled growth for flexible models. Verify pricing and licensing conditions against official documents at decision time.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.