Skip to main content

​
Overview

The Poolside Reference Architecture for AWS describes the typical deployment of Poolside in an AWS environment. Components marked as optional may be included or excluded based on your specific requirements.

​
Architecture

Poolside AWS Reference Architecture

​
Reference architecture recommendations

This reference architecture significantly simplifies the Poolside deployment process in several ways:
  1. Accelerated Deployment. The pre-defined architecture eliminates the need for lengthy design phases, allowing teams to focus on validation rather than infrastructure decisions.
  2. Reduced Risk. By following a proven deployment pattern tested across multiple enterprise environments, teams can avoid common pitfalls and configuration issues.
  3. Enterprise Alignment. The architecture incorporates best practices for security, reliability, and scalability that align with typical enterprise requirements, making the transition from an evaluation environment to production more straightforward.
  4. Simplified Troubleshooting. When issues arise, having a standardized architecture makes it easier for both customer teams and Poolside support to diagnose and resolve problems quickly.
  5. Resource Optimization. The architecture is designed to minimize costs while maintaining necessary capabilities.
While certain components are marked as optional, adhering to the reference architecture as closely as possible provides significant benefits:
  • Consistent Support Experience. Poolside support teams are intimately familiar with the reference architecture, enabling faster and more effective assistance.
  • Well-Tested Integration Patterns. The interaction patterns between components have been extensively validated across numerous deployments.
  • Future Compatibility. Staying aligned with the reference architecture makes future upgrades and migrations simpler as the product evolves.
  • Documentation Relevance. All deployment guides, troubleshooting documentation, and best practices are written with this architecture in mind.

​
Architecture components

​
Core infrastructure

The architecture is built on three main tiers:
  • Public Subnet. Contains Application Load Balancers (ALBs) and NAT gateways to manage traffic
  • Control Plane Subnet. Hosts the EKS control plane endpoints and related networking components
  • Private Subnet. Contains EKS Compute Nodes where workloads execute, with separation between core components and interfaces

​
Key components

  1. Access Management.
    • AWS Identity and Access Management (IAM) with IRSA for workload-level AWS permissions
    • Administrators and Web Users have dedicated access paths
    • SSO integration for enterprise authentication
  2. Networking.
    • Deployment across multiple Availability Zones to support high availability, with a minimum of two and support for up to three
    • Network segmentation with public, control plane, and private subnets
    • NAT gateways for secure outbound connectivity
  3. Compute Resources.
    • EKS clusters providing Kubernetes orchestration
    • Separate compute nodes for web-assistant and interface workloads
    • PostgreSQL databases for persistent storage with backup capabilities
  4. Supporting Services.
    • S3 for object storage (models, code & docs, audit & telemetry data)
    • ECR for container registry
    • AWS Systems Manager Parameter Store

​
Deployment notes

  • Deployment scripts are available to create, update, and delete these deployments within your AWS account.
  • Components annotated as “Optional” indicate a deployment choice based on requirements.
  • NAT Gateway vs. Self-Managed options available depending on cost and management preferences.
  • Route53/DNS management can be integrated with enterprise DNS infrastructure.

​
Making architectural decisions

When considering modifications to the reference architecture:
  • Consult First. Reach out to your Poolside account team before making significant deviations.
  • Document Changes. Maintain clear documentation of any architectural differences for support purposes.
  • Consider Long-term Impact. Evaluate how changes might affect future scalability and maintenance.
  • Test Thoroughly. Any modifications should undergo additional testing to validate functionality.

​
Security considerations

  • The architecture maintains strict security boundaries with private subnets for compute resources.
  • SSO integration for consistent enterprise authentication.
  • Network traffic flows are controlled through dedicated gateways and security groups.
  • Data at rest is encrypted using AWS Key Management Service (KMS).
  • Data in transit is protected using TLS encryption.
  • Additional details on IAM roles, security groups, and encryption keys are available in the Amazon Web Services IAM guide
  • Additional details on Kubernetes security configuration are available in the Kubernetes security guide

​
Performance optimization

  • Multi-availability zone deployment ensures resilience.
  • EKS compute nodes are separated by workload type for optimized resource allocation.
  • PostgreSQL instances are properly sized according to workload requirements, and deployed close to compute resources for low-latency access.

​
Conclusion

The Poolside AWS Reference Architecture provides a proven foundation for successfully deploying Poolside in an enterprise environment while maintaining AWS best practices for security, performance, and operational excellence.