Infrastructure & Architecture

ConnectHL7 is built cloud-native on Amazon Web Services (AWS). We run no on-premise servers. This lets us inherit the security, scale, and resilience of a leading cloud provider while focusing our own efforts on securing everything we build on top of it.

This page describes our architecture and operational controls at a level appropriate for security review.

---

Architecture diagram

The diagrams below (visible at the end of this page) illustrate the platform architecture, AWS deployment topology, and inter-service communication paths at a level appropriate for public security review. Enterprise customers may request a more detailed architecture overview, including internal network segmentation, during a vendor security review under NDA.

---

Cloud-native AWS architecture

Our platform is composed of managed, well-understood AWS services:

• Application layer: Python and FastAPI services, running in containers (Docker) and serverless functions (AWS Lambda).
• Ingress: Amazon API Gateway provides a controlled, authenticated entry point for API traffic.
• Data layer: PostgreSQL for relational data and Redis for caching, both encrypted at rest.
• Messaging: Amazon SQS decouples and buffers healthcare message processing, improving resilience under load.

Because these are managed services, security patching and hardening of the underlying platform benefit from AWS's operational maturity, while we control configuration, access, and data protection.

---

High availability

The platform is designed to remain available through common failure modes:

• Workloads run across multiple AWS Availability Zones, so the failure of a single data center does not take the service down.
• We use managed, redundant AWS services (such as multi-AZ databases and regionally redundant queuing) that tolerate individual component failures.
• Buffering through message queues helps the platform absorb spikes and degrade gracefully rather than fail outright.

For how we handle larger-scale disruptions, see Business Continuity & Disaster Recovery.

---

Monitoring

We continuously monitor our environment for threats and anomalies using native AWS security services:

• Amazon GuardDuty for continuous threat detection.
• AWS Security Hub for a consolidated view of security posture and findings.
• Amazon Inspector for continuous vulnerability assessment of our workloads and container images.
• AWS Config for tracking resource configuration and detecting drift from our secure baseline.

Security findings are monitored and triaged, and material issues are handled through our internal incident response process.

---

Logging

We maintain centralized, tamper-resistant logging:

• AWS CloudTrail records API and administrative activity across our AWS environment.
• Amazon CloudWatch centralizes application and infrastructure logs and metrics and drives operational alerting.
• Logs are retained to support investigation, monitoring, and auditability.

---

Authentication

• Multi-factor authentication (MFA) is mandatory for all team member access to our AWS environment, source control, and business systems.
• Human access to AWS is centrally managed through single sign-on with federated, time-scoped credentials rather than long-lived static keys.
• API access by customers and integrations is authenticated using managed credentials issued through controlled processes.

---

Authorization

• Access follows role-based access control (RBAC) and least-privilege principles: people and systems receive only the permissions their role requires.
• Production access is tightly restricted to a small number of authorized personnel and is separated from development access.
• Access is reviewed on a recurring basis, and removed promptly when no longer needed.

---

Secure software development

Security is built into how we ship software:

• All code changes go through peer review and are merged only after approval.
• Our automated CI/CD pipeline (GitHub Actions) runs security checks on every change, including static analysis, dependency vulnerability scanning, and secret scanning.
• Deployments run through automated pipelines using short-lived credentials — no manual handling of production keys.
• Known high-severity vulnerabilities are remediated on defined timelines.
• Our practices are informed by the OWASP secure development guidance.

---

Backup strategy

Customer data is protected by automated, encrypted backups with point-in-time recovery for our primary datastores, retained according to defined schedules and regularly tested. This is summarized here and described further in Business Continuity & Disaster Recovery.

---

Operational resilience

Several deliberate architectural choices make the platform more resilient and more secure:

• Infrastructure as Code: Our entire environment is defined as code, so it is consistent, reviewable, version-controlled, and reproducible — including in another region if ever required.
• Immutable, automated deployments reduce configuration drift and the risk of manual error.
• Continuous monitoring and alerting mean we detect and respond to issues quickly.
• Managed, redundant services reduce single points of failure.

---

Related: Security Overview · Encryption & Data Protection · Business Continuity & Disaster Recovery · Compliance Roadmap

Last updated: 1 July 2026