As a cloud solutions architect, I often get asked about the best way to design a secure and compliant cloud architecture, especially when dealing with sensitive data like health records. In this blog post, I'll walk you through a recent project where I designed a solution for a health management company in Australia. We'll look at the architecture, the compliance frameworks we had to consider, and how we designed a traffic management system to handle a large user base.
The Core Architecture: Security and Resilience First
Our first step was to design a core architecture that was both secure and resilient. The client needed to run Confluence and Jira for their internal teams, and the data had to be stored securely in Australia. Here's a breakdown of the architecture we came up with:
Azure Virtual Machine Scale Sets: We used Azure Virtual Machine Scale Sets to run the Confluence and Jira applications on Windows VMs. This allows us to automatically scale the number of VMs up or down based on demand, ensuring that the applications are always available and responsive.
Azure Database for PostgreSQL: For the database, we chose Azure Database for PostgreSQL. It's a fully managed, enterprise-ready database service that's both reliable and secure. To ensure business continuity, we designed the database to failover to a secondary region in Australia East. This means that if there's an outage in the primary region (Australia Southeast), the database will automatically switch over to the secondary region, with minimal downtime.
Navigating the Compliance Maze
Because we were dealing with sensitive health data, we had to comply with a number of Australian and international regulations. Here's a quick overview of the key compliance frameworks we had to consider:
IRAP (Information Security Registered Assessors Program): This is an Australian government initiative that provides a framework for assessing the security of cloud services. By using Azure services that are IRAP assessed, we can be confident that our solution meets the Australian government's security requirements.
PSPF (Protective Security Policy Framework): The PSPF provides a set of mandatory requirements for Australian government agencies to protect their people, information, and assets. While our client is not a government agency, we used the PSPF as a best-practice guide for our security controls.
GDPR (General Data Protection Regulation): Even though our client is based in Australia, they may have users who are based in the European Union (although unlikely). To ensure that we were protecting the data of these users, we had to comply with the GDPR. This meant implementing strict data protection controls, such as data encryption and access control.
APRA (Australian Prudential Regulation Authority): APRA is the prudential regulator of the Australian financial services industry. While our client is not a financial services company, we used APRA's prudential standards as a guide for our risk management and data governance practices.
Managing Traffic for a Distributed User Base
With the core architecture in place, our next challenge was to design a traffic management system that could handle 5,000 users spread across all major Australian cities. The key requirement was to provide a low-latency experience for all users, with a particular focus on the 80% of users who are based in Melbourne and Sydney.
Here's how we designed the traffic management system:
Azure Front Door/Application Gateway: We used Azure Front Door as the single entry point for all user traffic. Front Door is a global, scalable, and secure entry point for your web applications. It provides a range of features, including SSL offloading, web application firewall (WAF), and content delivery network (CDN) capabilities.
Azure Traffic Manager: We used Azure Traffic Manager to intelligently route traffic to the appropriate backend resources. Traffic Manager uses a variety of routing methods, including performance, weighted, and geographic, to ensure that users are always routed to the closest and most responsive resources. Note: Traffic Manager is not strictly necessary and it does add a level of complexity a simplified architecture would only include Front Door plus load balancers for each region.
Azure Load Balancers: We used two Azure Load Balancers to distribute traffic across our VM Scale Sets. The first load balancer is dedicated to serving the Melbourne and Sydney regions, where we have a high concentration of users. The second load balancer serves the other cities.
Azure Private Link: To ensure that all traffic between our Azure services is secure and private, we used Azure Private Link. Private Link provides private connectivity from a virtual network to Azure platform as a service (PaaS), customer-owned, or Microsoft partner services.
Conclusion
By combining a secure and resilient core architecture with an intelligent traffic management system, we were able to design a solution that meets the needs of our health management client. The solution is not only secure and compliant, but it also provides a high-performance and low-latency experience for all users.
Roberto
