Cloud & DevOps in Canada

About Cloud & DevOps

We run our own production infrastructure, including an EV charging platform with chargers live across multiple cities and a managed cloud hosting product, so cloud and DevOps is not theory for us. We help teams get off fragile manual deployments and onto infrastructure that is automated, observable, and cheap to run. That covers first-time cloud setup, migrating an existing app to AWS, Azure, or GCP, containerizing with Docker, and wiring up CI/CD so shipping is a push, not an ordeal.

What the engagement includes

• Cloud setup on AWS, Azure, and GCP
• Cloud migration from on-premise or other providers
• Docker containerization
• Kubernetes cluster setup and management
• CI/CD pipeline setup (GitHub Actions, GitLab CI)
• Infrastructure as code (Terraform)
• Serverless architecture (Lambda, Cloud Functions)
• Monitoring, logging, and alerting

Where the workload runs in Canada, and who is allowed to reach it

On a cloud and DevOps engagement the residency question is not the one it is on a build, because here the access is the deliverable. Where the data sits is the short half of it: AWS runs Canadian regions in Montreal and Calgary, Azure in Toronto and Quebec City, Google Cloud in Montreal and Toronto, and pinning to one of them is a line in the Terraform rather than a project. The longer half is that residency wording written for a public body or a regulated buyer often reaches access and not only storage, and an engineer of ours holding a console session on your production account from Noida is access wherever the bytes are resting. Nothing in PIPEDA sets that rule; it comes from your buyer's own statute and the contract they hand you, and those do not all point the same way. British Columbia dropped its blanket requirement that personal information held by a public body be stored and accessed only in Canada in 2021, other limits on disclosure outside the province stayed behind it, and some jurisdictions never dropped theirs at all, so the clause in front of you is the thing to read and that reading is your counsel's job rather than ours. What we do about it is structural and does not wait on the answer. Access runs through your identity provider with named accounts, no shared root, no long lived keys parked in a chat thread, elevation granted for a window and taken back rather than left standing. Changes reach production through the pipeline rather than through a person at a console, which is what makes the access question answerable at all. Where the clause is strict, the arrangement that usually works is that your own team holds the only standing production credentials and the break glass account while we work in the lower environments and through reviewed pipeline changes. That boundary belongs in the scope document, because drawing it later means re-cutting permissions on a system already carrying traffic.

Pinning to Canada has consequences that are cheaper to price than to discover. The Canadian regions are not the flagship ones: managed services and instance families land in the large US regions first and reach Canada later, and some never arrive, so anything the architecture leans on gets checked against that region's own service list while it is still a drawing, not against documentation written around a US default. Redundancy has fewer moves too, because if nothing may leave the country then your disaster recovery target is the other Canadian region, and most of the material you would copy from works against you: cross region snapshot copies, log archives, backup vaults and registry replicas point at a US region in a lot of published templates, and quietly undo the promise the region choice was made to keep. The machines that build your code are the same problem, since hosted CI runners generally give you no way to choose the country they execute in, and a runner clones your repository and holds your deployment credentials for the length of every build. Where the clause is strict that means self hosted runners in your own Canadian region, which is a standing bill and one more thing to patch rather than a checkbox. Then there is the currency. The providers publish list prices in US dollars, and whether your account settles in those or in a converted local price list, the figure finance sees can move when the rate moves and usage has not, which is worth confirming with the provider before anyone treats it as fixed. A one or three year commitment bought for the discount is a currency position as much as a capacity one. The biggest US regions also tend to price lower than the Canadian ones, so the same architecture usually costs a little more here than a vendor's example implies. None of that argues against staying in Canada. It argues for the monthly figure being on the table when the residency decision is made rather than on the first invoice.

Two Canadian duties land in the logging and the on call design rather than in the application code. PIPEDA requires an organisation to report a breach of security safeguards to the Privacy Commissioner and notify the people affected where the breach creates a real risk of significant harm, and separately to keep a record of every breach of security safeguards, including the ones judged harmless, for two years. Both assume you can reconstruct what was reached and by whom, which is a retention decision rather than a policy one. Retention defaults run from a few weeks on one service to forever on another, and none was chosen with a two year record in mind. Data plane audit logging, the layer that records reads and writes against the objects rather than changes to the infrastructure around them, is commonly off until somebody turns it on and charged separately once they do. Nobody else on the project settles either of those, so retention gets set against the two year record and the audit trail on the stores that actually hold personal information gets turned on at the start rather than after the first question about it. If you touch Quebec, Law 25 adds a register of confidentiality incidents and its own notification route to the Commission d'accès à l'information, which changes the runbook more than the stack: the person who decides whether to notify is on your side of the world, the duty is to act promptly rather than within a stated number of hours, and it does not wait for a business day, so the escalation path names them and reaches them directly instead of stopping at whoever can restore the service. Worth agreeing early, too, that a status page and an incident notice are customer facing communications, because your French obligations are an awkward thing to work out while an incident is running. Whether an incident crosses either threshold is a call for your counsel or privacy officer, and the reason to build the logging this way is so they have something to make it from.

How we work with Canadian clients

Two things shape Canadian projects more than anything technical. The first is language: if you serve Quebec, French is a legal requirement rather than a nice addition, and the rules tightened considerably under Bill 96. The French version has to be available on equal terms with the English one, which is a design constraint from the first wireframe rather than a translation task at the end.

The second is anti-spam law. CASL is stricter than most teams expect, and the penalties are real. Consent has to be express or clearly implied, records of it have to be kept, and every commercial message needs a working unsubscribe and accurate sender identification. We build those into the product rather than leaving them to whoever configures the mailing tool later, because that is where the exposure usually sits.

Indicative pricing in CAD

Converted from our published Indian rates and rounded. Exchange rates move, so the figure on your quote is calculated on the day it is issued.

Questions Canadian clients ask

Cloud & DevOps: common questions

Other markets we work in