CCv2 Web and Network Architecture: Endpoints, CDN Integration, and VPN

The fastest way to burn a week on a CCv2 project is to design network architecture the platform does not permit. SAP Commerce Cloud gives you a fixed web tier (Apache, managed by SAP, running in Azure) and exposes a deliberately short list of knobs through the Cloud Portal. Everything else is off the table: no custom Apache modules, no Basic Auth at the web layer, no shell access to the proxies. This guide maps the knobs that exist, the patterns that work within them, and the traps teams hit when they assume on-premise freedoms.

The Web Layer: Seven Things You Control#

Every environment's web tier is configured through the Cloud Portal (or the Commerce Cloud APIs, which matter for automation and are covered at the end). The full list of configurable surfaces:

1. Endpoints. The unit of exposure. An endpoint binds a domain (virtual host) to a service (storefront, OCC API, Backoffice, Solr admin, JavaScript storefront) with its own security posture. You define which aspects answer on which hostnames here.
2. IP filter sets. Named allow/deny lists of CIDR ranges attached to endpoints, with a base rule of allow-all or deny-all. This is the primary access-control primitive at the web layer.
3. SSL/TLS certificates. Upload body, private key, and CA chain per domain; the portal supports adding, replacing, renewing, downloading, and deleting certificates as self-service. There is no CSR workflow in the platform, so generate keys and certificates in your own PKI or with your CA, then upload.
4. Trusted CA certificates (mutual TLS). Endpoints can require client certificates validated against a trusted CA you upload, with allowed-domain matching against the certificate subject CN. This is the modern answer to "how do I make sure only my CDN or my partner system can reach this endpoint" and it did not exist in the early CCv2 years, so older architecture documents still claim IP filtering is the only option. It is not.
5. Static files. A small ZIP (think verification files, security.txt, apple-app-site-association) served directly from the web layer without touching Tomcat.
6. Website redirects. Redirect and RedirectMatch directives only. Enough for domain consolidation and simple URL moves; not enough for complex rewrite logic, which belongs in the application or the CDN.
7. Maintenance pages. Custom 503 pages per endpoint for planned windows. Configure these before launch; a default cloud error page in the middle of a cutover is a trust incident.

Web caching for static paths (/medias/, /_ui/) can be enabled at this layer too, but if you run a CDN (you should), the CDN owns that job.

Endpoint Design That Survives Production#

The endpoint list is security architecture, not plumbing. A production-shaped layout:

Two rules from incident history. First, the deny-by-default base rule on anything that is not the storefront: Backoffice, hAC routes, Solr, and any admin path have no business answering the public internet, and automated scanners will find them within hours of DNS propagating. Second, review the filter sets at every go-live and after every partner change; stale CDN IP ranges are a classic self-inflicted outage when the provider rotates infrastructure.

CDN and WAF Integration: The Sandwich Pattern#

CCv2 does not bundle a general-purpose CDN or WAF for your custom domains; you bring your own (Cloudflare, Akamai, Fastly, CloudFront, Azure Front Door all appear in the wild). The integration pattern is a sandwich:

1. DNS points your public domain at the CDN.
2. The CDN's origin configuration points at the environment's default wildcard domain.
3. An IP filter set on the origin endpoint restricts access to the CDN's published egress ranges, so nobody bypasses the WAF by hitting the origin directly.
4. Where supported, add mutual TLS between CDN and origin via a trusted CA certificate on the endpoint, which closes the residual "attacker inside the CDN's IP space" gap that pure IP filtering leaves open.

One subtlety the documentation states plainly and teams still miss: the web layer filters on the source IP of the packet, not on X-Forwarded-For. Once traffic arrives via the CDN, the origin sees CDN addresses. Consequence: you cannot simultaneously route everyone through the CDN and allow a shortlist of internal users at the origin by their office IPs. The working pattern is an internal endpoint: a second domain that bypasses the CDN, points at the environment directly, and carries a strict IP filter set. During a launch or an incident you can lock the public endpoint down while the internal one keeps the door open for your team and your smoke tests.

DNS: CNAME First#

Point your domains at the environment with a CNAME to the environment's default wildcard domain (the *.model-t.cc.commerce.ondemand.com name visible in the portal). Use A records only when a DNS provider cannot CNAME at the apex, and treat any hardcoded IP as a liability to revisit, because the platform's addresses are not contractually stable. Standard cutover hygiene applies and is worth restating because it decides launch weekends: drop TTLs below five minutes well before the change, verify the old TTL has expired everywhere, and keep the previous target warm until traffic confirms the move (the go-live readiness guide covers the full checklist).

The Network Layer: VPN, NAT, and Private Endpoints#

Three self-service constructs cover private connectivity:

• Site-to-site VPN connects environments to your corporate or partner networks. Inbound to Commerce is HTTPS only (private endpoints); outbound from Commerce can use any TCP protocol, which is how you reach that legacy ERP listener or SFTP host that will never be internet-facing. There is no client-to-site VPN: individual users connect to your network first, then ride the site-to-site tunnel.
• NAT configuration rescues you when your private address space collides with the ranges the platform reserves. Check the documented reserved ranges during network design, not during tunnel setup, because remediation on your side means renumbering or NAT rules that someone must maintain.
• Private endpoints expose a service only over the VPN. For Backoffice access the trade-off against public-plus-IP-filter is straightforward: private endpoints keep traffic off the public internet entirely, at the cost of every Backoffice user needing to be on the corporate network; the public variant is operationally lighter but transits the internet and depends on filter hygiene.

Host alias management rounds out the layer for outbound name resolution quirks (fixed IPs for hosts your integrations must reach by name).

Automating It: The Same Knobs via API#

Everything above is clickable in the Cloud Portal, and most of it is scriptable through the Commerce Cloud management APIs, the same surface the first-deployment and continuous delivery guides use for builds and deployments. Treat endpoint definitions, filter sets, and certificate renewals as configuration you review in change management, not as portal folklore: export the current state into your runbook, and wire certificate expiry into your monitoring rather than your calendar. Certificate renewal is self-service and takes minutes; discovering an expired certificate from customer screenshots takes considerably longer.

What This Means for Solution Design#

• Anything requiring web-server customization beyond the seven knobs moves to another layer: the application (Spring Security for auth schemes), the CDN (rewrites, geo-routing, bot rules), or a side-by-side service.
• Latency-sensitive third-party components belong in the same Azure region as the subscription; the region is visible in your subscription details and the regions guide covers placement strategy.
• Design the endpoint and filter matrix as a deliverable during architecture, review it at go-live, and audit it quarterly. It is one page that encodes most of your internet-facing security posture.

The web and network layers are intentionally boring, and that is their value: SAP keeps them patched, scaled, and standardized, and your team spends its creativity in the layers where your business actually differs.