[SEO Subhead]
This Guidance helps you send DICOM images directly to the cloud and store these images in Amazon Simple Storage Service (Amazon S3). This is accomplished by configuring a DICOM destination in your existing Picture Archiving and Communication System (PACS) or Vendor Neutral Archive (VNA) systems. The DICOM destination will be capable of receiving instances using DICOM Message Service Element (DIMSE). In this Guidance, image data is encrypted, and data storage is scalable to support variable workloads.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
Clients connect to the application through a Network Load Balancer (NLB) and send DIMSE C-STORE requests to the backend service.
Step 2
The NLB is deployed to a public subnet. Targets are one or more Amazon Elastic Container Service (Amazon ECS) on AWS Fargate task elastic network interfaces (ENIs) in a private subnet.
Step 3
An Amazon Virtual Private Cloud (Amazon VPC) security group allows fine-grained network access control to the application.
Step 4
Connections are passed to Amazon ECS on Fargate service tasks. Service task scaling is controlled through an AWS Auto Scaling rule, allowing the service to adjust its capacity according to demand. Container permissions are granted through the task AWS Identity Access and Management (IAM) role, avoiding the use of hard-coded credentials.
Step 5
Tasks access Amazon Simple Storage Service (Amazon S3) using reliable and private connectivity provided by a VPC gateway endpoint.
Step 6
Received DICOM images are stored in Amazon S3. Optionally, DICOM metadata can also be extracted and stored.
Step 7
Container definitions are stored in Amazon Elastic Container Registry (Amazon ECR) and are used by Amazon ECS on Fargate during deployment.
Step 8
Amazon CloudWatch collects container logs and metrics.
Step 9
The Guidance components access the internet using a VPC NAT gateway, avoiding the need to provision public IP addresses for all tasks.
Step 10
The Guidance is deployed as infrastructure-as-code using AWS Cloud Development Kit (AWS CDK).
Step 1
Clients connect to the application through a Network Load Balancer (NLB) and send DIMSE C-STORE requests to the backend service.
Step 2
The NLB is deployed to a public subnet. Targets are one or more Amazon Elastic Container Service (Amazon ECS) on AWS Fargate task elastic network interfaces (ENIs) in a private subnet.
Step 3
An Amazon Virtual Private Cloud (Amazon VPC) security group allows fine-grained network access control to the application.
Step 4
Connections are passed to Amazon ECS on Fargate service tasks. Service task scaling is controlled through an AWS Auto Scaling rule, allowing the service to adjust its capacity according to demand. Container permissions are granted through the task AWS Identity Access and Management (IAM) role, avoiding the use of hard-coded credentials.
Step 5
Tasks access Amazon Simple Storage Service (Amazon S3) using reliable and private connectivity provided by a VPC gateway endpoint.
Step 6
Received DICOM images are stored in Amazon S3. Optionally, DICOM metadata can also be extracted and stored.
Step 7
Container definitions are stored in Amazon Elastic Container Registry (Amazon ECR) and are used by Amazon ECS on Fargate during deployment.
Step 8
Amazon CloudWatch collects container logs and metrics.
Step 9
The Guidance components access the internet using a VPC NAT gateway, avoiding the need to provision public IP addresses for all tasks.
Step 10
The Guidance is deployed as infrastructure-as-code using AWS Cloud Development Kit (AWS CDK).
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
This Guidance is deployed using AWS CDK, which allows operators to reduce deployment risk and gives them better control over the deployment process. By using Amazon ECR to store versioned container images, operators can more easily test changes and revert failed deployments with minimal impact to end users or the availability of the system. CloudWatch collects metrics and logs to provide insight into the operation of the system, making it easier to troubleshoot issues.
-
SecurityRead the Security whitepaper
IAM roles and policies allow the system to contain no hard-coded credentials. AWS security groups and VPC endpoints are used to provide fine-grained access control. Further, this Guidance provides network segregation using public and private subnets. Data in transit is protected using TLS encryption. Data at rest is encrypted while stored on Amazon S3. Communication between tasks and Amazon S3 occurs over a VPC gateway endpoint and does not traverse the public internet.
-
ReliabilityRead the Reliability whitepaper
Elastic Load Balancing (ELB) routes requests to multiple Fargate tasks, running in different Availability Zones (AZs). Using managed services such as ELB and Fargate improves reliability by removing single points of failure. The Fargate scheduler replaces failed tasks, and auto scaling allows the system to respond to changes in load without impacting clients or end users. As more DICOM images are received and processed in parallel, auto scaling helps ensure necessary resources are available across multiple AZs.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
Fargate provides flexible task-sizing for both compute and memory capacity. This helps match resources to workload requirements to avoid overprovisioning. Amazon S3 provides performant object storage with virtually unlimited scalability, high availability, and multiple access tiers. Amazon S3 allows parallel access to objects without performance impact, and you can choose the most appropriate storage class based on data access for your workload.
-
Cost OptimizationRead the Cost Optimization whitepaper
Amazon S3 Intelligent-Tiering can reduce storage cost by automatically transitioning objects into a lower cost tier based on access patterns. Additionally, VPC endpoints allow connectivity between AWS services over private networking and can be used to reduce public data transfer and NAT gateway costs. This helps minimize data transfer outside of the VPC, reducing overall data transfer charges. Fargate allows for tracking and automated adjustment of provisioned compute based on current system load, and tasks can be appropriately sized to maximize cost efficiency.
-
SustainabilityRead the Sustainability whitepaper
Amazon S3 and Fargate are managed services (operated at scale by AWS), which reduces the amount of infrastructure needed to support your workloads. Additionally, Amazon S3 Lifecycle policies can be used to reduce storage resources by automating the deletion of unneeded data.
Implementation Resources
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.