Cloud & DevOps Company in Edmonton

Estate size and OT segmentation are what set the number on an Alberta energy migration. A landing zone build and pilot workload migration on AWS or Azure is a twelve to twenty week engagement including Control Tower or Azure Landing Zone setup, network topology (Transit Gateway or vWAN), identity federation with Active Directory or Entra ID, logging, billing, and one production workload migrated. A multi-workload lift-shift-modernise of a mid-sized estate (50 to 200 VMs, plus databases) runs six to twelve months. Full hybrid cloud transformations spanning on-prem refresh, OT/IT segmentation, FinOps maturity, and Kubernetes platform engineering for a Tier 1 operator run as multi-year programs. Edmonton runs roughly 20 to 30 percent below Toronto and Calgary big-four consultancies for equivalent senior architecture, and we quote fixed-fee phases not open-ended day rates.

True. AWS ca-central-1 sits in Montreal, Azure Canada Central in Toronto, GCP northamerica-northeast2 in Toronto. Alberta workloads almost always end up running in Canadian east regions and replicating across Canada Central and northamerica-northeast1 for disaster recovery. For PIPEDA, Alberta PIPA, and Health Information Act scope, Canadian residency is satisfied because all three hyperscalers contractually keep data inside Canada. The exceptions that need explicit handling: provincial government workloads sometimes require Alberta-resident storage which means on-prem or colocation in Edmonton or Calgary with cloud-adjacent integration, federally-touching Protected B and above which require additional FedRAMP-equivalent or PBMM controls, and OT data where the conservative posture is to keep historians on-prem and only ship aggregated or sanitised telemetry to cloud.

Conservative by default. We treat the OT network as untrusted from the cloud side and untrusted from the corporate IT side both. Production patterns: a DMZ landing zone with one-way data diodes (Owl Cyber Defense or Waterfall) shipping PI System and SCADA telemetry into S3 or ADLS Gen2, ingestion pipelines on Lambda or Azure Functions writing into Timestream, InfluxDB, or Azure Data Explorer, and zero inbound paths from cloud back to OT. We align with IEC 62443 and ICS-CERT recommendations and document segmentation suitable for internal IT audit and external regulators. We will not run a project that requires inbound paths from cloud to a live SCADA network without an explicit risk acceptance from the customer's security and operations leadership.

Both options are on the table. We build and hand over the platform with documentation, runbooks, and a 60-day knowledge transfer for teams that already have or are hiring SREs. For mid-market operators that do not want to staff a platform team, we offer ongoing managed Kubernetes operations: 24x7 on-call for production incidents, monthly cluster upgrades, capacity and cost reviews, security patching, and quarterly architecture reviews. Pricing is fixed monthly with a clearly defined scope and incident SLA, not an open retainer. We prefer to operate clusters we built because we know the IaC and the failure modes. We will inherit a third-party-built cluster only after a paid stabilisation phase to bring it to a standard we can responsibly carry on-call.

Cost discipline starts at the landing zone, not at the invoice. We enforce tagging policy via Service Control Policies or Azure Policy from day one, build a FinOps dashboard in CloudHealth, Vantage, or a custom Looker model against the Cost and Usage Report, set per-account and per-tag budgets with alerting before overspend not after, and run monthly rightsizing reviews against actual CloudWatch or Azure Monitor metrics. The two cost levers that actually move the needle for Alberta clients: reserved instances and savings plans for steady-state workloads (typically 30 to 50 percent reduction on compute), and aggressive storage tiering for the petabyte-scale historian and seismic archives common in energy. We do not propose Spot instances for production workloads that affect field operations.

We have shipped against GoA cloud strategy patterns and AHS-adjacent integration work. The GoA standard leans Azure-first with Entra ID, Microsoft Sentinel, and Defender for Cloud, though AWS deployments are accepted with appropriate justification and security review. AHS work falls under the Health Information Act which requires data residency in Canada, custodian-level access controls, audit logging suitable for the Office of the Information and Privacy Commissioner of Alberta, and integration with Alberta Netcare or Connect Care via documented interface patterns. We can engage as a prime or as a subcontractor under existing vendors of record and bring SOC 2 Type II evidence, ISO 27001 alignment, and HIA-specific privacy artefacts to procurement review.

Yes. Several Alberta energy operators have standardised on GitLab self-hosted, often on-prem or in a private cloud account, for reasons that range from OT-adjacent isolation requirements to historical procurement decisions. We are fluent in GitLab CI, GitLab Runner sizing, and the integration patterns for pushing artefacts to AWS ECR or Azure Container Registry from a self-hosted runner. GitHub Actions remains our default for greenfield SaaS, and Azure DevOps still shows up in Government of Alberta and AHS contexts. We pick the platform that fits the customer rather than imposing our toolchain.

Tiered. Tier 1 (production field operations support, regulatory reporting, customer-facing platforms): cross-region active-passive with RPO under 15 minutes and RTO under one hour, tested quarterly with documented runbooks. Tier 2 (internal business systems, analytics, batch reporting): pilot-light or warm-standby in a secondary region with RPO under one hour and RTO under four hours, tested semi-annually. Tier 3 (development, sandbox): backup-restore only. We run real failover tests rather than tabletop exercises. The most expensive lesson in Alberta cloud history is the operator who paid for cross-region redundancy and discovered during a real outage that the runbook had drifted from reality. We refuse to deliver DR documentation that has not been executed under load at least once.