Cloud Data Infrastructure for Canadian Public Sector

Canada’s federal government has made cloud adoption a strategic priority, and Treasury Board Secretariat’s GC Cloud Adoption Strategy makes AWS a listed strategic cloud provider. Yet for many departments and Crown corporations, the move from on-premises data centres to cloud-based analytics infrastructure remains slow — held back by uncertainty about which data classifications can go to cloud, how to meet Protected B requirements on AWS, and how to demonstrate to Shared Services Canada that the architecture is compliant with GC Security Controls.

This post is a technical guide for IT managers, data architects, and CIOs in the Canadian public sector who are ready to move forward. We cover the data classification framework that governs what can go to cloud, the AWS services and configurations that satisfy Protected B requirements, and the practical architectures for transactional systems, analytical platforms, and open data initiatives.

Protected B Classification and the AWS Canada (Central) Region

The Government of Canada classifies information in four categories: Unclassified, Protected A, Protected B, and Classified (which remains off-cloud). Protected B is the most sensitive level routinely considered for cloud deployment. It covers information that, if disclosed, could cause serious injury to an individual or organisation — this includes personal tax records, health benefit information, immigration files, and law enforcement records.

TBS has confirmed that Protected B workloads can run on AWS in the ca-central-1 region (Montreal) when appropriate security controls are in place. The key controls that distinguish a Protected B-compliant AWS deployment from a standard commercial deployment are:

Data residency. All data must remain in Canada. This means ca-central-1 only — no cross-region replication to US regions, no use of global AWS services that do not offer Canadian data residency, and explicit S3 bucket policies that deny PutObject requests from outside ca-central-1.

Encryption. Protected B data must be encrypted at rest using FIPS 140-2 validated cryptographic modules. AWS KMS in ca-central-1 uses FIPS 140-2 validated HSMs, satisfying this requirement when customer-managed keys (CMKs) are used. AWS GovCloud is not required for Canadian public sector workloads — ca-central-1 with FIPS-validated KMS is the correct approach.

Access control. All access to Protected B data must be authenticated using government-managed identities. AWS IAM Identity Center (formerly SSO) integrates with GCKey or departmental Active Directory Federation Services (ADFS) implementations, allowing government employees to access AWS analytics tools using their existing credentials without separate AWS account credentials.

Logging and monitoring. CloudTrail must be enabled in all regions and all services, with logs delivered to an immutable S3 bucket with Object Lock enabled. AWS Config must record all resource configuration changes. GuardDuty must be enabled for threat detection. These controls map directly to GC Security Controls profile requirements.

Aurora for Transactional Systems

Many federal departments operate legacy transactional systems on Oracle or SQL Server databases that are end-of-life, expensive to maintain, and running on hardware approaching end-of-support. Migrating these to Amazon Aurora (PostgreSQL-compatible or MySQL-compatible) in ca-central-1 is both a cost reduction and a reliability improvement.

Amazon Database Migration Service (DMS) handles the migration with minimal downtime using continuous replication: the legacy database continues to serve transactions during migration, DMS replicates all changes to Aurora in near real time, and the cutover is a connection string change rather than a maintenance window. For a federal department running a grants management system on Oracle 11g, this approach achieves migration with a cutover window of under 30 minutes.

Aurora’s automatic storage scaling, multi-AZ high availability with automatic failover in under 30 seconds, and automated backup to S3 with point-in-time recovery address the resilience requirements that GC Cloud guidance sets for transactional systems. Aurora Serverless v2 is appropriate for systems with highly variable load — a grants submission portal that sees heavy traffic at fiscal year-end and low traffic otherwise can scale compute from 0.5 to 128 ACUs without manual intervention.

For analytical reporting against transactional data, Aurora zero-ETL integration with Amazon Redshift eliminates the need for a separate ETL pipeline. Changes in Aurora are replicated to Redshift in near real time, giving analysts access to current transactional data for reporting without placing query load on the operational database.

Analytical Platform for Policy and Program Analytics

Policy analysts and program evaluators in federal departments need to answer questions that span multiple datasets: What is the demographic profile of recipients of a particular benefit program? Which regions have underutilised program uptake relative to eligible population? How has program participation changed following a policy change?

These questions require joining data from multiple departmental systems — benefits administration, population registry, geographic reference data — in an analytical environment that is isolated from operational systems. The AWS analytical platform for this use case uses a standard data lake architecture: S3 as the storage layer, Glue for ETL, Redshift for analytical queries, and QuickSight for dashboarding.

The Protected B wrinkle is data linkage privacy. Joining datasets from different departments to answer cross-program questions raises Privacy Act obligations — the data must be used only for purposes consistent with its original collection, and data sharing agreements between departments must be in place before the join is performed. The data platform enforces this through Lake Formation: cross-department joins are only possible when the IAM role requesting the query has been explicitly granted access to both source tables, and these grants are configured only after the data sharing agreement is executed.

Statistical disclosure control — ensuring that query results cannot be used to re-identify individuals in small cells — is implemented as a post-processing step on Redshift query output. A Lambda function intercepts Redshift query results and suppresses cell values below a minimum count threshold (typically n<5) before delivering results to QuickSight.

For detailed data governance patterns applicable to this architecture, see Data Governance Framework.

Open Data Initiatives and Public-Facing APIs

The Government of Canada’s Open Government initiative commits to publishing datasets that do not contain personal information as open data on the open.canada.ca portal. Many departments are also building public-facing APIs that expose program data to provincial governments, municipalities, and accredited researchers.

The AWS architecture for open data publication is a distinct pattern from internal analytics — the data is non-sensitive, the users are external, and the performance requirement is for API response latency rather than complex analytical queries.

Open datasets are published to a dedicated S3 bucket configured for public read access, with CloudFront distribution providing global edge caching for CSV and GeoJSON file downloads. This approach serves large file downloads (Statistics Canada-style tabular datasets can be hundreds of megabytes) at high throughput without per-request compute cost.

For API access, Amazon API Gateway fronts Lambda functions that query DynamoDB or Aurora for structured data lookups. Lambda authorisers authenticate API callers using GC API authentication standards. Usage plans and throttling in API Gateway prevent any single consumer from overwhelming the platform.

AWS Glue crawlers maintain the Glue Data Catalog as the authoritative metadata registry, with catalog entries linking to both the S3 open data files and the API endpoints — giving the Open Government team a single source of truth for dataset inventory management.

Conclusion

The Canadian public sector has both the mandate and the tools to modernise its data infrastructure on AWS. The ca-central-1 region, configured with FIPS-validated KMS, CloudTrail, GuardDuty, and Lake Formation access controls, satisfies Protected B requirements. Aurora handles the transactional workloads that legacy Oracle and SQL Server databases currently carry. Redshift and QuickSight deliver the analytical capabilities that policy and program teams need.

The barrier is not technical — it is the knowledge gap between what GC Cloud guidance permits and what IT teams have implemented before. Infra IT Consulting bridges that gap. Contact us to discuss your department’s cloud data infrastructure requirements, whether you’re starting a new modernisation initiative or completing a partially deployed platform that needs security control validation.

For related reading on migrating legacy on-premises data infrastructure to AWS, see On-Premises to AWS Migration.