Architecture and operating model
Google Cloud Private Service Connect, AWS PrivateLink and Azure Private Link let a consumer use a private endpoint to reach a managed or producer service. Each can provide service-oriented access instead of broad network peering, but endpoint types, producer publication, regional behavior and DNS operations are not identical.
A private IP does not automatically authorize traffic. Consumer identity, endpoint or service acceptance, security-group/firewall policy, service authentication and data permissions remain separate layers. Disable a public endpoint only after private routing and DNS have been validated under change control.
Cost is more than an hourly endpoint charge. Include processed data, zone or region transfer, load balancers, DNS resolvers, logs and producer-side charges. Because prices and quotas can change, use a measurable formula and validate current values on official pricing pages rather than embedding a universal price claim.
- 1Classify service and data
- 2Create endpoint and producer acceptance
- 3Resolve private DNS and route
- 4Validate identity, flow logs and cost
Design parameters
- Region and zone
- Client, endpoint and service placement affect latency, availability and data-transfer cost.
- DNS model
- Private zones, split-horizon rules and on-prem resolver forwarding must return the intended private address for the same FQDN.
- Authorization
- Manage endpoint creation and service data access as separate policies and audit streams.
- Cost units
- Calculate endpoint-hours, bidirectional processed GiB, regional/zonal transfer, load balancing, DNS and logs together.
Technical equivalents across platforms
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Design area | Google Cloud | AWS | Azure |
|---|---|---|---|
| Consumer endpoint | Private Service Connect endpoint/backend | Interface VPC endpoint | Private Endpoint |
| Producer publication | Service attachment / published service | Endpoint service | Private Link Service |
| Name resolution | Private DNS zone and PSC DNS design | Private DNS or Route 53 private zone | Private DNS zone and links |
| Cost control | Validate PSC endpoint, processing and regional transfer | Validate endpoint-hour, processing and transfer | Validate endpoint-hour, processed data and transfer |
Worked example
For 12 endpoints running 720 hours per month and 18 TiB of bidirectional traffic, begin with 12 × current endpoint-hour price × 720 plus 18,432 GiB × the applicable processing tier. Add cross-region access, load balancers and central DNS as separate lines, then validate with the provider calculator for the selected region.
If an on-prem client resolves the private FQDN to a public IP, the route can still reach the wrong destination. Validate the client → corporate resolver → cloud inbound resolver → private zone chain, including A/AAAA result, flow logs and TLS server name.
Example commands: replace lab values and confirm permissions and software versions before use.
# Verify the client's effective DNS path
dig +short service.internal.example A
dig service.internal.example A +trace
# Test TCP reachability and TLS name separately
nc -vz service.internal.example 443
openssl s_client -connect service.internal.example:443 -servername service.internal.example </dev/nullTroubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| DNS returns a public address | Private-zone association or on-prem forwarding may be missing. | Query through the client’s resolver and inspect authoritative zone and VPC/VNet links. |
| Endpoint is ready but connection times out | Producer acceptance, security policy, route or service port may be missing. | Check endpoint state, flow logs and the listening port from both ends. |
| Unexpected data-transfer charge | Clients may reach the endpoint across a region/zone or through a load balancer/NAT path. | Export billing labels, flow logs and source/destination region mapping. |
Acceptance checks
- Verify support for the selected region and endpoint type.
- Record public and private DNS answers from different networks.
- Test endpoint acceptance and data-level IAM separately.
- Attempt connections from allowed and denied clients.
- Correlate the attempt across flow logs and service audit logs.
- Compare actual GiB and endpoint-hours with monthly billing lines.
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.
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
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.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior 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.
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.