Nkreddy15/aws-medical-saas-cloud-architecture

# AWS 医疗 SaaS 云架构 这是一个关于将医疗 SaaS 平台从托管/本地部署基础设施迁移至 Amazon Web Services 的云架构案例研究。 ## 业务问题 这家虚构的医疗公司运营着一个支持医疗社交网络、远程咨询和 AI 辅助诊断的医疗 SaaS 平台。其现有的 Windows Server 和 SQL Server 环境无法： - 在需求高峰期将 Web 和应用服务器从两台扩展到四台； - 为美国、亚太地区和欧洲的用户提供低延迟的内容分发； - 提供托管数据库备份和自动故障转移； - 将开发环境与生产环境中的医疗工作负载进行隔离； - 为敏感的医疗数据提供足够的监控、审计、身份隔离和保护。 ## 提议方案 该设计在 `us-east-1` 中使用了独立的开发和生产 VPC，每个 VPC 跨越两个可用区。公有子网仅包含面向 Internet 的负载均衡器。Web 服务器、应用服务器和 SQL Server 数据库保持在私有子网中。 核心服务包括： - Amazon VPC 和 Internet Gateway - Amazon EC2 和 Auto Scaling - Elastic Load Balancing - 适用于 SQL Server 且具备 Multi-AZ 的 Amazon RDS - Amazon S3 - Amazon CloudFront - Amazon Cognito、AWS IAM 和 AWS STS - AWS Secrets Manager 和 AWS KMS - AWS CloudFormation - Amazon CloudWatch、AWS CloudTrail、VPC Flow Logs 和 Amazon SNS ## 架构 ``` flowchart TB Users[Patients, Doctors, Staff] --> CF[Amazon CloudFront] Users --> Cognito[Amazon Cognito] Cognito --> STS[AWS STS / Role Mapping] CF --> IGW[Internet Gateway] subgraph PROD["Production VPC — 10.1.0.0/16 — us-east-1"] direction TB subgraph PUB["Public subnets — AZ 1 and AZ 2"] ALB1[External Web Load Balancer] end subgraph WEB["Private web subnets — AZ 1 and AZ 2"] WebASG[EC2 Web Tier Auto Scaling\nWindows Server + IIS\nMin 2 / Max 4] end subgraph APP["Private application subnets — AZ 1 and AZ 2"] ALB2[Internal Application Load Balancer] AppASG[EC2 App Tier Auto Scaling\nWindows Server + IIS\nMin 2 / Max 4] end subgraph DB["Private database subnets — AZ 1 and AZ 2"] RDS1[(RDS SQL Server Primary)] RDS2[(Multi-AZ Standby)] end S3[(Amazon S3)] Secrets[AWS Secrets Manager] KMS[AWS KMS] ALB1 -->|HTTPS 443| WebASG WebASG -->|HTTPS 443| ALB2 ALB2 -->|HTTPS 443| AppASG AppASG -->|SQL Server 1433| RDS1 RDS1 -. synchronous standby / failover .-> RDS2 AppASG --> S3 AppASG --> Secrets Secrets --> KMS end IGW --> ALB1 IAM[AWS IAM] -. administrative access .-> PROD CFn[AWS CloudFormation] -. repeatable infrastructure design .-> PROD CloudTrail[AWS CloudTrail] --> LogBucket[(Encrypted S3 Log Bucket)] Flow[VPC Flow Logs] --> LogBucket CloudWatch[Amazon CloudWatch] --> SNS[Amazon SNS Alerts] CloudWatch -. metrics and logs .-> PROD ``` 与之匹配的开发 VPC 使用非重叠的 CIDR 范围（`10.0.0.0/16`），并镜像生产子网层级，但不共享生产资源。 ## 关键设计决策 ### 身份隔离 - AWS 管理员使用 IAM 角色、组、最小权限策略和 MFA。 - 患者、医生和员工通过 Amazon Cognito 进行身份验证。 - 当应用程序用户需要获得访问 AWS 资源的授权时，可以通过 AWS STS 签发临时凭证。 - Secrets Manager 可防止数据库凭证被硬编码。 ### 网络分段 - 外部流量通过 CloudFront 和面向 Internet 的负载均衡器进入。 - EC2 Web 和应用实例保持私有。 - 内部应用负载均衡器仅接受来自 Web 层的请求。 - RDS 仅接受来自应用层的 SQL Server 流量。 - 安全组是一种状态控制机制，用于限制哪一层可以向下一层发起通信。 ### 可扩展性与可用性 - Web 层：`t3.medium`，最少 2 台，最多 4 台实例。 - 应用层：`m5.xlarge`，最少 2 台，最多 4 台实例。 - 数据库层：在课程设计中使用 `db.m5.2xlarge` 的 RDS for SQL Server Standard Edition。 - Multi-AZ RDS 提供备用数据库和自动故障转移。 - CloudFront 改善了主区域之外用户的内容交付体验。 ### 监控与审计 - CloudTrail 记录账户和 API 活动。 - CloudWatch 监控资源并触发警报。 - VPC Flow Logs 捕获网络流量元数据。 - SNS 发送操作通知。 - 审计日志应进行加密并保留在 S3 中。 ## 我的文档贡献 这是一个两人团队项目。我已核实的展示职责涵盖： - 网络和安全服务； - 开发和生产 VPC 设计； - 跨两个可用区的子网隔离； - Web、应用和数据库层的规模规划； - 外部和内部负载均衡器； - 安全组通信规则； - EC2 Auto Scaling 和业务连续性设计； - CloudTrail、CloudWatch 和 VPC Flow Logs。 请参阅 [`docs/individual-contribution.md`](docs/individual-contribution.md)。 ## 仓库结构 ``` . ├── README.md ├── diagrams/ │ ├── architecture-overview.mmd │ ├── architecture-overview.svg │ └── architecture-overview.png ├── docs/ │ ├── architecture-decisions.md │ ├── design-requirements.md │ ├── individual-contribution.md │ ├── limitations-and-next-steps.md │ ├── monitoring-and-auditing.md │ ├── scalability-and-continuity.md │ └── security-and-identity.md └── original-deliverables/ └── README.md ``` ## 重要限制 - 这是一个架构设计，并非已部署生产环境的证明。 - 该项目提出了与 HIPAA 对齐的控制措施；仅凭架构文档无法确立符合 HIPAA 合规性。 - 虽然建议使用 CloudFormation 模板，但并未作为提交项目的一部分完成。 - CloudFront 改善了全球交付，但计算和数据库架构仍是单区域的。 - 生产环境的实施需要成本建模、威胁建模、备份测试、恢复测试、安全审查和合规性验证。 ## 团队 - Nikhil Kumar Reddy Chalamalla - Isaiah Lacet 课程：ITC 6480 — Amazon Web Services，东北大学

标签：AWS, DPI, SaaS, 云架构, 医疗信息化, 系统迁移