AWS Migration of Node.js Medical SaaS

Cliente Freelancer · Remoto · Remoto · freelance · mid · 1500–3000 USD

Publicada el 2026-07-17

Descripción de la oferta

Title: AWS Migration — Node.js/Next.js Medical SaaS to ECS Fargate (5 services, RDS, SQS, DICOM over NLB TCP) Budget: Fixed price, milestone-based. Description: We run a teleradiology SaaS platform (Node.js/Express API + Next.js web + PostgreSQL 16) currently deployed on a dedicated VPS with Docker. It works, but we need to move it to AWS to scale from 1 pilot clinic to 75 clinics over the next 12–18 months. This is a focused migration, not a redesign — the application code stays as-is except for the changes needed to run stateless on AWS. Target architecture — 5 containerized services on ECS Fargate: 1. WEB — Next.js app (radiologist/clinic portal), behind ALB. 2. API — Express API: auth (JWT/RBAC multi-tenant), studies, reports, pipeline triggers. Behind ALB. 3. DICOM-adapter — receives C-STORE on TCP 11112 from clinic PACS, stores images in Google Cloud Healthcare (which stays as the DICOM store in Phase 1), registers the study in RDS, enqueues a job in SQS. Behind NLB. 4. Dmwl-server — DICOM modality worklist, C-FIND on TCP 11113. Behind NLB. 5. Worker — pulls jobs from SQS and orchestrates external AI providers (screening, medical vision, report drafting), stores the draft report in RDS and the PDF in S3. We do NOT host AI models — the worker calls external APIs. Scales independently by queue depth. Study flow (so you understand what you're migrating): clinic PACS → C-STORE → NLB → dicom-adapter → GCP Healthcare + RDS + SQS → worker → external AI APIs → draft report in RDS, PDF in S3 → radiologist reviews and approves in web. Scope: AWS foundation with Terraform: VPC (public/private subnets), IAM task roles per service, ECR, Secrets Manager, CloudWatch. Two environments: dev and prod. The 5 services above containerized and running on ECS Fargate, fully stateless (no service stores anything important on its local disk — all state lives in RDS, SQS, or S3). Database migration: PostgreSQL 16 from VPS to RDS PostgreSQL (Multi-AZ in prod), private subnet, no public exposure, automated backups and one verified restore test. Replace the current in-memory job queue with SQS + DLQ. Workers must be idempotent: a retried job must never produce a duplicate report or duplicate billing event (idempotency key per study/job). Move generated PDFs/artifacts from local filesystem to S3 with KMS encryption and presigned URLs. DICOM connectivity through a Network Load Balancer (TCP 11112 / 11113). Must pass C-ECHO / C-FIND / C-STORE tests from an external PACS before cutover. Hard requirement — if you don't know why DICOM DIMSE can't go through an ALB or API Gateway, please don't bid. HTTPS via ALB + ACM, DNS on Route 53. CI/CD with GitHub Actions (OIDC, no permanent access keys): build → push to ECR → deploy to ECS with rollback to previous task definition. One pipeline per service. Basic observability: CloudWatch logs per service, health-check alarms, SQS queue-depth alarm, AWS budget alerts. Cutover plan with rollback window, and a short runbook (deploy, rollback, restore, scale workers). Acceptance test: we will kill any single container in dev during operation. No study may be lost, no report duplicated, and the service must self-recover. If the architecture can't pass this, it's not done. Important context: The platform handles medical data (PHI). You will work with anonymized/test data during the migration; production data migration happens in a supervised cutover window. NDA required. All credentials shared through a secure channel only. What we provide: read-only repo access, existing Dockerfiles and docker-compose, environment variable inventory, current NGINX config, database schema and size, and a technical owner available for questions. Milestones and payment: M1 (20%): Terraform foundation + dev environment live, the 5 services running on ECS dev. M2 (30%): RDS migration validated + SQS queue working end-to-end with idempotency + artifacts in S3. M3 (30%): DICOM tests passed through NLB from external source + CI/CD + alarms + acceptance test passed in dev. M4 (20%): Production cutover completed, 1-week stability window, runbook delivered. To apply, answer these 3 questions (bids without answers will be ignored): Why does DICOM DIMSE traffic require an NLB instead of an ALB? Describe a migration you've done from a single server to ECS Fargate: what broke, and how did you handle the stateful parts (DB, queue, files)? How would you guarantee worker idempotency so a retried job never duplicates a report?

Skills

Fuente original: freelancer

Análisis JobHunter