1. Start With an Application Inventory (Even If It’s Incomplete)
Why: You can’t segment what you don’t understand.
Gather DNS names, IPs, ports, protocols from:
- Firewalls
- Proxy logs
- CMDB / ServiceNow
- Internal DNS zones
- Load balancers
Tip: Even a partial inventory gives you a better starting point than jumping to wildcards.
2. Avoid Wildcards in Large Environments
Why: Wildcards like *.corp.internal result in:
- Thousands of discovered apps
- Every App Connector seeing all apps
- Hitting the 6,000 app limit quickly
Best Practice:
- Use wildcards only:
- In small environments
- Or for known, constrained subdomains like
*.hr.corp.internal
Instead, define:
*.apps.finance.corp.internal*.vpn.corp.internalhrportal.corp.internal
3. Design With Segmentation and Policy in Mind
Segment based on:
- Access control needs (who should access what)
- App type (Web, RDP, SQL, SSH)
- Compliance domains (PCI, HIPAA, etc.)
- Hosting location (AWS, Azure, on-prem)
Examples:
- WEB – Finance Apps
- SQL – Internal Reporting
- SSH – Jump Servers (DevOps)
4. 🔗 Use Multiple Segment Groups & Connector Groups Strategically
Why: This allows ZPA to assign apps only to relevant App Connectors.
Design Rule:
- One Segment Group = Apps with similar policy/connectivity
- One Connector Group = Set of connectors that serve those apps (e.g., AWS/DR)
This reduces the number of apps each connector sees.
5. Use ZPA App Discovery — But Don’t Deploy Everything
- Use Application Discovery to collect unknown apps without assigning to wildcards
- Review discovered apps and manually group them
- Only assign segments after validation
6. Limit Application Segment Scope
Keep each Application Segment focused and small:
- Only a few domains or IPs per segment
- Avoid mixing protocols (don’t combine RDP and SSH into one segment)
7. Set Guardrails With Tags & Naming Conventions
Use consistent:
- Prefixes for application types
- Suffixes for environments (
-Prod,-Dev) - Tags for automation (
env:prod,type:web)
8. Test In Lower Environments First
- Build the structure in staging first
- Validate app routing, connector load, and user access
- Use connector load metrics and app connector insights
9. Monitor App Connector Load
Use:
- ZPA Analytics > Connector Load
- Alerts for when connectors hit high memory or CPU
- Check number of apps per connector regularly
10. Review and Refactor Periodically
- Decommission unused apps from segments
- Split overly broad segments
- Reallocate apps based on usage patterns
Common Mistakes to Avoid
| Mistake | Why It’s a Problem |
|---|---|
Using *.corp.internal in production |
Explodes app count, overloads connectors |
| Mapping all segments to all connectors | No load distribution benefit |
| Mixing unrelated apps in one segment | Makes policy hard to apply and audit |
| No naming convention | Leads to confusion and management debt |
Summary: What to Do Before Rollout
| Step | Task |
|---|---|
| 1 | Build an initial app inventory |
| 2 | Define access requirements by app group/type |
| 3 | Create clean naming conventions |
| 4 | Use specific domains instead of wildcards |
| 5 | Break apps into granular Application Segments |
| 6 | Use appropriate Segment Groups & Connector Groups |
| 7 | Test in dev/staging before full rollout |