ZeroTrustKerberosLink Deployment Architecture Comparison¶
This guide provides a comprehensive comparison of different deployment architectures for ZeroTrustKerberosLink, helping you select the optimal configuration for your enterprise environment.
Table of Contents¶
- Overview
- Deployment Architecture Comparison
- Single-Node Architecture
- High-Availability Architectures
- Multi-Region Architectures
- Scaling Considerations
- Industry-Specific Recommendations
Overview¶
ZeroTrustKerberosLink can be deployed in various architectures to meet different enterprise requirements for availability, performance, compliance, and geographic distribution. This guide helps you understand the tradeoffs between different deployment models.
Deployment Architecture Comparison¶
| Feature | Single-Node | Active-Passive HA | Active-Active HA | Multi-Region |
|---|---|---|---|---|
| Availability | 99.5% | 99.9% | 99.99% | 99.999% |
| Failover | None | Manual or automatic | Automatic | Automatic with geo-routing |
| Performance | Good | Good | Better | Best |
| Complexity | Low | Medium | High | Very High |
| Cost | $ | $$ | $$$ | $$$$ |
| Scaling | Vertical only | Vertical primary | Horizontal and vertical | Global horizontal |
| Maintenance Downtime | Required | Minimal | None | None |
| Data Consistency | N/A | Strong | Eventually consistent | Eventually consistent |
| Disaster Recovery | Manual backup/restore | Automatic failover | Automatic failover | Multi-region resilience |
| Recommended For | Development, small deployments | Medium enterprises | Large enterprises | Global enterprises |
Single-Node Architecture¶
Overview¶
A single-node deployment is the simplest architecture, with all ZeroTrustKerberosLink components running on a single server.
Diagram¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Enterprise Environment │
│ │
│ ┌──────────────┐ ┌───────────────┐ │
│ │ │ │ │ │
│ │ Kerberos │◄──────►│ ZTK Server │ │
│ │ KDC │ │ (Single) │ │
│ │ │ │ │ │
│ └──────────────┘ └───────┬───────┘ │
│ │ │
└──────────────────────────────────┼──────────────────────────────┘
│
│ Secure VPN/Direct Connect
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ │
│ AWS Cloud │
│ │
│ ┌──────────────┐ ┌───────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ IAM Roles │◄──────►│ AWS STS │◄────►│ AWS KMS │ │
│ │ │ │ │ │ │ │
│ └──────────────┘ └───────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Pros¶
- Simple to deploy and manage
- Lower cost
- Minimal configuration required
- Suitable for development and testing
Cons¶
- No high availability
- Single point of failure
- Limited scalability
- Maintenance requires downtime
Recommended For¶
- Development and test environments
- Small organizations with limited AWS usage
- Proof of concept deployments
- Environments with non-critical AWS access requirements
High-Availability Architectures¶
Active-Passive HA¶
Overview¶
An active-passive architecture consists of a primary node that handles all requests and a standby node that takes over if the primary fails.
Diagram¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Enterprise Environment │
│ │
│ ┌──────────────┐ ┌───────────────┐ │
│ │ │ │ │ │
│ │ Kerberos │◄──────►│ ZTK Primary │ │
│ │ KDC │ │ Node │ │
│ │ │ │ │ │
│ └──────────────┘ └───────┬───────┘ │
│ │ │
│ │ │
│ ┌───────▼───────┐ │
│ │ │ │
│ │ ZTK Standby │ │
│ │ Node │ │
│ │ │ │
│ └───────┬───────┘ │
│ │ │
└──────────────────────────────────┼──────────────────────────────┘
│
│ Secure VPN/Direct Connect
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ │
│ AWS Cloud │
│ │
│ ┌──────────────┐ ┌───────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ IAM Roles │◄──────►│ AWS STS │◄────►│ AWS KMS │ │
│ │ │ │ │ │ │ │
│ └──────────────┘ └───────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Pros¶
- Improved availability (99.9%)
- Automatic failover capability
- Strong data consistency
- Relatively simple to configure
Cons¶
- Standby resources are idle during normal operation
- Brief service interruption during failover
- Limited horizontal scalability
- Requires load balancer or DNS failover mechanism
Recommended For¶
- Medium-sized enterprises
- Organizations with moderate AWS usage
- Environments with standard availability requirements
- Budget-conscious organizations requiring HA
Active-Active HA¶
Overview¶
An active-active architecture consists of multiple nodes that all actively handle requests simultaneously, providing both high availability and load distribution.
Diagram¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Enterprise Environment │
│ │
│ ┌──────────────┐ ┌───────────────┐ │
│ │ │ │ │ │
│ │ Kerberos │◄──────►│ ZTK Node 1 │◄─┐ │
│ │ KDC │ │ │ │ │
│ │ │ └───────────────┘ │ │
│ └──────────────┘ │ │
│ │ │
│ ┌───────────────┐ │ │
│ │ │ │ │
│ │ ZTK Node 2 │◄─┼───────────┐ │
│ │ │ │ │ │
│ └───────────────┘ │ │ │
│ │ │ │
│ ┌───────────────┐ │ │ │
│ │ │ │ │ │
│ │ ZTK Node 3 │◄─┘ │ │
│ │ │ │ │
│ └───────┬───────┘ │ │
│ │ │ │
│ ┌──────────────┐ │ │ │
│ │ │ │ │ │
│ │ Load │◄───────────────┴──────────────────────┘ │
│ │ Balancer │ │
│ │ │ │
│ └──────┬───────┘ │
│ │ │
└─────────┼───────────────────────────────────────────────────────┘
│
│ Secure VPN/Direct Connect
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ │
│ AWS Cloud │
│ │
│ ┌──────────────┐ ┌───────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ IAM Roles │◄──────►│ AWS STS │◄────►│ AWS KMS │ │
│ │ │ │ │ │ │ │
│ └──────────────┘ └───────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Pros¶
- High availability (99.99%)
- Horizontal scalability
- Load distribution
- No downtime during maintenance
- Better performance under load
Cons¶
- More complex configuration
- Requires load balancer
- Data synchronization challenges
- Higher cost
Recommended For¶
- Large enterprises
- Organizations with high AWS usage
- Mission-critical applications
- Environments requiring high throughput
Multi-Region Architectures¶
Overview¶
A multi-region architecture deploys ZeroTrustKerberosLink across multiple AWS regions or geographic locations for global resilience and performance.
Diagram¶
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Enterprise Environment │
│ │
│ ┌──────────────┐ ┌───────────────┐ │
│ │ │ │ │ │
│ │ Kerberos │◄──────►│ ZTK Region 1 │◄─┐ │
│ │ KDC │ │ Cluster │ │ │
│ │ │ └───────────────┘ │ │
│ └──────────────┘ │ │
│ │ │
│ ┌───────────────┐ │ │
│ │ │ │ │
│ │ ZTK Region 2 │◄─┼───────────┐ │
│ │ Cluster │ │ │ │
│ └───────────────┘ │ │ │
│ │ │ │
│ ┌──────────────┐ │ │ │
│ │ │ │ │ │
│ │ Global Load │◄──────────────────────────┘ │ │
│ │ Balancer │ │ │
│ │ │◄──────────────────────────────────────┘ │
│ └──────┬───────┘ │
│ │ │
└─────────┼───────────────────────────────────────────────────────┘
│
│ Secure VPN/Direct Connect
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ │
│ AWS Global Cloud │
│ │
│ ┌──────────────────────────┐ ┌──────────────────────────┐ │
│ │ │ │ │ │
│ │ AWS Region 1 │ │ AWS Region 2 │ │
│ │ │ │ │ │
│ │ ┌─────────┐ ┌────────┐ │ │ ┌─────────┐ ┌────────┐ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │IAM Roles│ │AWS STS │ │ │ │IAM Roles│ │AWS STS │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ └─────────┘ └────────┘ │ │ └─────────┘ └────────┘ │ │
│ │ │ │ │ │
│ └──────────────────────────┘ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Pros¶
- Highest availability (99.999%)
- Geographic redundancy
- Disaster recovery built-in
- Reduced latency for global users
- Regional compliance capabilities
Cons¶
- Highest complexity
- Most expensive option
- Data synchronization challenges across regions
- Requires global load balancing
Recommended For¶
- Global enterprises
- Organizations with strict disaster recovery requirements
- Multi-national companies
- Applications requiring global low-latency access
Scaling Considerations¶
Vertical Scaling¶
Increasing resources (CPU, memory) on existing nodes:
- When to use: When request volume increases but not enough to justify additional nodes
- Advantages: Simpler to implement, no additional configuration needed
- Limitations: Hardware limits, potential downtime during scaling
Horizontal Scaling¶
Adding more nodes to the deployment:
- When to use: When authentication request volume exceeds capacity of optimally-sized nodes
- Advantages: Linear scaling, no theoretical upper limit, no downtime
- Limitations: Requires load balancer, more complex configuration, data synchronization challenges
Scaling Recommendations by User Count¶
| Number of Users | Number of AWS Accounts | Recommended Architecture | Minimum Nodes | Node Specifications |
|---|---|---|---|---|
| <500 | <10 | Single-Node | 1 | 2 vCPU, 4GB RAM |
| 500-2,000 | 10-50 | Active-Passive HA | 2 | 4 vCPU, 8GB RAM |
| 2,000-10,000 | 50-200 | Active-Active HA | 3 | 8 vCPU, 16GB RAM |
| 10,000-50,000 | 200-1,000 | Active-Active HA | 5+ | 16 vCPU, 32GB RAM |
| >50,000 | >1,000 | Multi-Region | 8+ (4+ per region) | 16+ vCPU, 32+ GB RAM |
Industry-Specific Recommendations¶
Financial Services¶
- Recommended Architecture: Active-Active HA or Multi-Region
- Key Considerations:
- PCI-DSS compliance requires high availability
- Transaction volume can be bursty, requiring scalability
- Consider active-active in multiple availability zones
- Implement comprehensive audit logging
- Enable FIPS-compliant encryption
Healthcare¶
- Recommended Architecture: Active-Passive HA or Active-Active HA
- Key Considerations:
- HIPAA compliance requires business continuity
- PHI access tracking requires comprehensive logging
- Consider geographic redundancy for large hospital networks
- Implement emergency access procedures
- Enable extended log retention (6+ years)
Government¶
- Recommended Architecture: Active-Active HA or Multi-Region
- Key Considerations:
- FedRAMP compliance requires high availability
- Consider AWS GovCloud deployment
- Implement PIV/CAC integration
- Enable FIPS-compliant encryption
- Consider air-gapped or isolated deployments for classified environments
Retail/E-commerce¶
- Recommended Architecture: Active-Active HA
- Key Considerations:
- Seasonal traffic patterns require scalability
- Global presence may require multi-region
- Focus on performance during peak shopping periods
- Consider cost optimization during off-peak times
Technology/SaaS¶
- Recommended Architecture: Multi-Region
- Key Considerations:
- Global customer base requires low latency
- Continuous deployment requires zero-downtime architecture
- Consider containerized deployment for flexibility
- Implement CI/CD pipeline integration