Skip to main content

Infrastructure & Security Overview

This article is intended to provide a high-level overview of the Lablogs platform infrastructure following our migration to a modern containerized architecture.

N
Written by Nicolas Ordoqui
Updated over 2 weeks ago

Cloud-Native Solution

Lablogs is a cloud-native web solution that requires no servers, installation, or infrastructure maintenance by your IT team. The platform has evolved from AWS Elastic Beanstalk to a more scalable and resilient containerized architecture using AWS ECS (Elastic Container Service).

We leverage AWS's comprehensive suite of managed services to achieve a secure, scalable, and highly available solution. Electronic Lab Logs does not own or maintain any on-premise servers to support our solution. By allowing AWS to provision and maintain all physical infrastructure and adopting container orchestration, we can achieve superior scalability, security, and operational efficiency, ultimately benefiting our customers.

Learn more: AWS Solutions Library

Container Architecture

The Lablogs application has been fully containerized using Docker, with the backend services deployed across AWS ECS. This approach provides us with greater flexibility, improved resource utilization, and simplified deployment processes. Our Docker images are built using Node.js 20 on Alpine Linux, ensuring a minimal attack surface while maintaining high performance.

Three primary services run within our ECS cluster. The web service handles all API requests from users and serves as the main entry point to our application. The back-v2 service manages specialized backend operations and provides additional processing capabilities. The worker service operates continuously, processing asynchronous tasks by polling SQS queues and executing scheduled jobs triggered by EventBridge rules.

AWS ECS Documentation: https://docs.aws.amazon.com/ecs/
AWS ECR Documentation: https://docs.aws.amazon.com/ecr/
AWS CloudFront Documentation: https://docs.aws.amazon.com/cloudfront/

High Availability and Redundancy

To meet SOC 2 compliance requirements and ensure business continuity, our infrastructure is deployed across multiple availability zones within the us-east-1 region in an active-active configuration. This multi-AZ deployment offers robust fault tolerance and high availability capabilities, with a Recovery Point Objective (RPO) of under 15 minutes and a Recovery Time Objective (RTO) of under one hour.

All ECS tasks and services are distributed across availability zones us-east-1a and us-east-1b to eliminate single points of failure. The Application Load Balancers automatically detect unhealthy containers and route traffic only to healthy instances across both zones, ensuring zero downtime during container updates or individual zone failures. Our ECS services utilize auto-scaling groups that respond to CPU and memory metrics, automatically adjusting capacity based on demand while maintaining balanced distribution across both availability zones.

The infrastructure employs AWS Auto Scaling for the EC2 instances that support our ECS cluster, configured to span both us-east-1a and us-east-1b availability zones. If one instance or entire availability zone becomes unavailable, traffic automatically routes to resources in the remaining zone without manual intervention, maintaining service availability and performance.

Databases Architecture

RDS Aurora MySQL Database

Our primary database runs on AWS RDS Aurora MySQL, a fully managed relational database service that provides up to five times better performance than standard MySQL. The production database cluster consists of one writer instance and multiple reader replicas distributed across different availability zones. This configuration ensures high availability and read scalability for our application.

All database instances have encryption at rest enabled using AWS KMS (Key Management Service), providing enterprise-grade security for sensitive data. The databases reside in isolated subnets within our VPC and are not publicly accessible, adding an additional layer of network security. Nightly automated backups are taken and stored across different availability zones, with point-in-time recovery available for up to 35 days.

For user authentication in non-SSO implementations, passwords are hashed using SHA256 encryption algorithm before being stored, ensuring they cannot be compromised even if unauthorized access were to occur. However, we now primarily utilize AWS Cognito for user pool management, which provides additional security features including multi-factor authentication and advanced security features.

DocumentDB for NoSQL Workloads

We utilize AWS DocumentDB, a MongoDB-compatible database service, for storing semi-structured data and documents that require flexible schemas. The DocumentDB cluster runs with three nodes for high availability, with encryption enabled both in transit and at rest. Like our RDS instances, DocumentDB resides in private subnets with no public access.

AWS DocumentDB Documentation: https://docs.aws.amazon.com/documentdb/

ElastiCache Redis for Caching

AWS ElastiCache Redis serves as our caching layer and session store, significantly improving application performance by reducing database load. The Redis cluster is configured with Multi-AZ support and automatic failover, ensuring cache availability even during zone failures. All data in transit is encrypted using TLS.

AWS ElastiCache Documentation: https://docs.aws.amazon.com/elasticache/

Event-Driven Processing

Lablogs implements an event-driven architecture using AWS EventBridge and SQS (Simple Queue Service) for asynchronous task processing. EventBridge rules trigger various scheduled operations, including daily notifications, instrument compliance checks, task scheduling, report generation, and weekly summaries. These events are published to SQS queues, where they are processed by our worker service running on ECS.

The worker service continuously polls the SQS queues, processing messages as they arrive. This decoupled architecture allows us to handle variable workloads efficiently and ensures that long-running tasks don't impact the responsiveness of our API services. Dead letter queues are configured to capture and retain messages that fail processing, allowing for debugging and manual intervention when necessary.

AWS EventBridge Documentation: https://docs.aws.amazon.com/eventbridge/
AWS SQS Documentation: https://docs.aws.amazon.com/sqs/

Document Storage

Lablogs utilizes AWS S3 to store all user-uploaded documents and attachments. Public access to these buckets is strictly disabled, with access controlled through our API layer using pre-signed URLs. A valid access token is required to upload, view, or remove any documents, ensuring that only authorized users can access their data.

Document versioning is enabled on all S3 buckets, with all revisions including delete actions retained for at least six months. This versioning strategy protects against accidental deletion or modification and supports compliance requirements for data retention. Cross-region replication is configured for critical buckets, ensuring data availability even in the event of a regional failure.

Security and Encryption

SSL/TLS and Network Security

All traffic to and from the Lablogs platform is encrypted using TLS 1.2 or higher. Our Application Load Balancers are configured to accept only HTTPS traffic on port 443, with valid SSL certificates managed through AWS Certificate Manager. The certificates cover all our domains, including *.lablogs.co and customer-specific subdomains.

The infrastructure utilizes a comprehensive VPC design with public, private, and isolated subnet tiers. Web-facing load balancers reside in public subnets, ECS tasks run in private subnets with NAT gateway access for external communications, and databases are placed in isolated subnets with no internet routing. Security groups implement least-privilege access controls, allowing only the minimum required connectivity between services.

Encryption at Rest

AWS KMS (Key Management Service) provides centralized key management for all encryption operations across our infrastructure. All data at rest is encrypted using AES-256 encryption, including database storage, S3 objects, and EBS volumes. KMS keys are rotated automatically according to AWS best practices, and all key usage is logged for audit purposes.

AWS KMS Documentation: https://docs.aws.amazon.com/kms/

Authentication and Authorization

User authentication is managed through AWS Cognito, which provides a secure, scalable user dactrectory with built-in security features. Cognito supports multi-factor authentication (MFA), advanced security features including adaptive authentication, and integration with enterprise identity providers through SAML 2.0.

API authorization is handled through Lambda authorizers integrated with API Gateway, providing flexible, custom authorization logic that can validate JWT tokens and enforce fine-grained access controls. This serverless approach to authorization ensures high availability and automatic scaling based on the volume of requests.

AWS Cognito Documentation: https://docs.aws.amazon.com/cognito/
AWS Lambda Documentation: https://docs.aws.amazon.com/lambda/


SSO Integration

Lablogs supports SAML-based identity federation with most enterprise Identity Providers. When SSO is implemented, your organization's IT department maintains complete control over user access to the system. Multi-factor authentication requirements, password policies, and user provisioning are all managed through your Identity Provider, ensuring that Lablogs integrates seamlessly with your existing security infrastructure.

For organizations interested in implementing SSO, our implementation team can guide you through the configuration process and ensure a smooth integration with your identity management system.

Frontend

The Lablogs frontend is built as a modern Angular application and deployed as a static site to AWS S3 buckets. These static assets are delivered globally through AWS CloudFront, Amazon's content delivery network.

CloudFront provides edge caching at over 400 points of presence worldwide, ensuring low latency for users regardless of their geographic location. The distributions are configured with custom cache behaviors, optimizing the delivery of different asset types. Static assets like images and CSS files are cached for extended periods, while dynamic content bypasses the cache entirely. Compression using both Gzip and Brotli is enabled to reduce bandwidth usage and improve load times.

Infrastructure as Code

Our entire infrastructure is defined and managed using Terraform, enabling version control, peer review, and automated deployment of infrastructure changes. This Infrastructure as Code approach ensures consistency across environments and allows for rapid disaster recovery by recreating the entire infrastructure from code if necessary.

GitHub Actions, combined with self-hosted runners on EC2 instances, handle our continuous integration and deployment pipelines. Docker images are automatically built, scanned for vulnerabilities, and pushed to AWS ECR (Elastic Container Registry) before being deployed to ECS. This automated pipeline ensures that all code changes go through proper testing and security scanning before reaching production.

Feature Management

AWS AppConfig provides dynamic feature flag management, allowing us to enable or disable features without requiring code deployments. Features can be toggled globally or for specific customers, providing granular control over feature rollouts. The current configuration includes frequency management features (frequency-v1 and frequency-v2) enabled for specific customer IDs, as well as global features such as blocker and schedule history, which are enabled for all users.

AWS AppConfig Documentation: https://docs.aws.amazon.com/appconfig/

Monitoring and Observability

All application logs from ECS tasks are centralized in AWS CloudWatch with a 14-day retention period. CloudWatch metrics track CPU utilization, memory usage, network traffic, and custom application metrics. Alarms are configured to alert the operations team when metrics exceed defined thresholds, enabling proactive issue resolution.

Metrics are exported to AWS Managed Grafana for advanced visualization and analysis. This provides our operations team with comprehensive dashboards showing system health, performance trends, and business metrics in real-time.

AWS CloudWatch Documentation: https://docs.aws.amazon.com/cloudwatch/
AWS Managed Grafana: https://docs.aws.amazon.com/grafana/

Compliance and Standards

Our infrastructure is designed to meet stringent compliance requirements, including SOC 2 Type II, with annual audits validating our security controls. The architecture implements enterprise-grade security features, including encryption at rest and in transit, comprehensive access controls, and detailed audit logging. These security foundations provide a robust framework that could support additional compliance requirements based on specific industry needs and appropriate agreements. Regular vulnerability scans and security assessments ensure that our infrastructure maintains the highest security standards.

AWS SOC Compliance: SOC Compliance - Amazon Web Services (AWS)
AWS Compliance Programs: Compliance Programs

Disaster Recovery

Comprehensive backup strategies protect against data loss at multiple levels. Database backups occur nightly with configurable retention periods. S3 versioning maintains all document revisions for extended periods. Critical data is replicated across regions to ensure availability even in catastrophic failure scenarios. Recovery procedures are documented in detailed runbooks and tested quarterly through disaster recovery drills.

AWS Backup Documentation: https://docs.aws.amazon.com/aws-backup/

Infrastructure Diagram


Did this answer your question?