Technical Guide · Cloud Infrastructure
Private Endpoints and DNS in Google Cloud, AWS and Azure
A private endpoint provides a private network path to a cloud service. Google Cloud Private Service Connect, AWS interface endpoints/PrivateLink and Azure Private Endpoint differ in…
Technical review:
Architecture and operating model
A private endpoint provides a private network path to a cloud service. Google Cloud Private Service Connect, AWS interface endpoints/PrivateLink and Azure Private Endpoint differ in scope. Creating an endpoint does not prove correct DNS or disabled public access.
Trace resolution from the client through corporate resolver, conditional forwarder, cloud private zone and endpoint address. One FQDN may resolve privately internally and publicly externally. Private connectivity does not replace IAM authorization.
Verify API endpoint names/zone scope in Google Cloud, service/region and private DNS in AWS, and target subresource/zone links in Azure. VPN/dedicated connectivity alone is insufficient; test DNS forwarding paths and loops.
- 1Client DNS
- 2Conditional resolver
- 3Private zone/endpoint
- 4TLS and IAM
Design parameters
- Resolver scope
- Cloud VMs, corporate and VPN clients may use different resolvers; test each.
- Authorization
- Record endpoint policy, service IAM and resource ACL layers separately.
- Public access
- After endpoint deployment, verify unwanted public-path access is denied.
Worked example
Assume a data service has private address 10.20.0.8. If a cloud VM resolves it privately but corporate DNS returns a public address, fix forwarding/zone linkage first. Test TLS with the service FQDN; curling only its IP can break name validation.
Example commands: replace lab values and confirm permissions and software versions before use.
dig service.example.test
getent ahosts service.example.test
# Lab only: keep Host/SNI while forcing the approved private IP.
curl --resolve service.example.test:443:10.20.0.8 https://service.example.test/healthTroubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Endpoint approved, HTTP 403 | Wrong DNS path or service authorization. | Inspect resolved address, connection target and IAM decision separately. |
| Works in cloud, not on premises | Forwarder or private-zone scope. | Compare answers for the FQDN through each resolver. |
Acceptance checks
- Test DNS from three client paths.
- Preserve the TLS hostname.
- Verify endpoint subresource.
- Run an IAM negative test.
- Test public access separately.
- Document DNS failover.
Related concepts
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.
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.
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.
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.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
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.
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.