Chris Hailes
Microsoft MVP | Cloud Technology Strategist | Azure Networking, Security & Platform Architecture
Sydney, Australia
Actions
Chris Hailes is a Cloud Technology Strategist at cubesys and a Microsoft MVP based in Sydney, Australia. With more than 20 years in senior technology roles, he specialises in Azure networking, security, and platform architecture.
His work focuses on the decisions that determine how cloud environments behave in practice: connectivity, identity, governance, automation, and operational resilience. He brings a pragmatic view of architectural trade-offs, helping teams distinguish what looks secure on a diagram from what can be demonstrated in a running environment.
Through his technical and strategy blogs, Brewed in the Cloud, Chris explores Azure architecture and the emerging challenges of AI-enabled systems, including agent authority, data boundaries, and accountability. His sessions aim to give engineers and architects practical decision frameworks—not just another catalogue of features.
Away from cloud architecture, he appreciates good coffee and craft beer.
Links
Area of Expertise
Topics
Azure Network Decisions That Are Expensive to Reverse
An Azure network can meet today’s requirements and still make tomorrow’s changes unnecessarily difficult. Address-space allocations, connectivity topology, and the placement of shared services can become costly constraints as workloads, teams, and security requirements grow.
This session examines those three architectural decisions through an evolving Azure environment. We’ll explore how IP planning affects expansion and integration, where hub-and-spoke and Virtual WAN fit different requirements, and how shared DNS, inspection, and connectivity services introduce dependencies across workloads.
Rather than presenting one topology as the correct answer, we’ll compare the consequences of different choices: what they simplify, what they constrain, and which changes they make harder. We’ll also distinguish genuine architectural flexibility from complexity added for requirements that may never arrive.
Attendees will leave able to:
- Assess an Azure network design for address-space, topology, and shared-service constraints.
- Identify decisions that need explicit growth assumptions and review triggers.
- Plan incremental network changes while accounting for workload dependencies.
Audience: Azure engineers, cloud architects, and platform teams.
Level: Intermediate.
Duration: 45 minutes; expandable to 60 minutes with deeper scenario discussion.
Prerequisites: Familiarity with VNets, subnets, peering, and routing.
Format: Slides, architectural diagrams, and worked scenarios.
Designing Azure Egress: NAT, Inspection, and Routing Trade-offs
Outbound connectivity is an architectural decision—not simply a route to the internet. Azure workloads may need predictable source addresses, traffic inspection, access to platform services, or tightly controlled destinations. Those requirements do not all call for the same design.
This session compares explicit outbound-connectivity patterns using Azure NAT Gateway, Azure Firewall, and secured Virtual WAN hubs. We’ll distinguish address translation from traffic inspection, examine when centralised egress is justified, and explain how routing determines which controls traffic actually encounters.
We’ll also clarify the scope of Azure’s default outbound-access changes: why new and existing environments can behave differently, and how to assess workloads before changing their connectivity. Worked scenarios will expose common mistakes, including assuming a NAT gateway filters destinations or that a deployed firewall necessarily inspects every outbound path.
Attendees will leave able to:
- Choose an egress pattern based on connectivity, inspection, cost, and operational requirements.
- Trace the intended outbound path and identify where translation and filtering occur.
- Plan a transition to explicit outbound connectivity without overlooking essential dependencies.
Audience: Azure engineers, networking professionals, and cloud security architects.
Level: Intermediate.
Duration: 45 minutes.
Prerequisites: Familiarity with Azure VNets, route tables, and basic NAT concepts.
Format: Slides, traffic-path diagrams, and worked scenarios.
Secure Azure Platforms by Default: Guardrails Developers Can Use
A secure Azure platform needs more than security products and a policy document. Teams need a usable deployment path that establishes sensible defaults, makes exceptions explicit, and provides evidence that controls remain effective.
This session follows a workload from onboarding into an Azure platform through deployment and ongoing operation. We’ll examine how workload identities, network boundaries, Azure Policy, and infrastructure-as-code work together—and where each mechanism stops providing assurance.
We’ll distinguish controls that prevent a configuration from being deployed from those that detect a problem afterwards. We’ll also explore how to manage exceptions without turning temporary access or policy exemptions into permanent platform weaknesses, and where Defender for Cloud contributes posture information rather than replacing preventive controls.
The focus is a practical platform baseline that reduces unnecessary delivery friction while preserving clear security boundaries.
Attendees will leave able to:
- Separate preventive guardrails, detective controls, and operational evidence.
- Define a repeatable workload-onboarding path with explicit identity and connectivity requirements.
- Structure exceptions with ownership, review criteria, and removal conditions.
Audience: Platform engineers, cloud architects, and security-minded Azure engineers.
Level: Intermediate.
Duration: 45 minutes; expandable to 60 minutes with exception-management discussion.
Prerequisites: Basic familiarity with Azure RBAC, Azure Policy, and infrastructure-as-code.
Format: Slides, platform diagrams, and a worked workload-onboarding scenario.
Private Isn’t Enough: Testing Azure Security Boundaries
Private endpoints reduce exposure through specific network paths. They do not, by themselves, establish who can access data, which alternative paths remain available, or whether workloads can send information elsewhere.
This session examines three gaps that can survive in a private Azure architecture: DNS and endpoint configuration that do not match the intended access path, outbound connectivity that permits unintended destinations, and identities whose effective permissions exceed the workload’s needs.
For each gap, we’ll trace a workload-to-service interaction, identify the control responsible for enforcing the boundary, and define the evidence needed to test it. We’ll distinguish private endpoint connectivity from public-access restrictions, network reachability from authorization, and a successful configuration change from a verified operational result.
The goal is not to dismiss private endpoints. It is to show how to combine them with identity, DNS, and egress controls—and validate the resulting architecture.
Attendees will leave able to:
- Identify residual access paths in an apparently private environment.
- Review network reachability and identity authorization as separate conditions.
- Define positive and negative tests that verify intended access while preserving legitimate workload dependencies.
Audience: Azure networking professionals, security engineers, and cloud architects.
Level: Intermediate to advanced.
Duration: 45 minutes.
Prerequisites: Familiarity with private endpoints, DNS, Azure RBAC, and outbound connectivity.
Format: Slides, access-path diagrams, and worked security scenarios.
Where Does Your AI Data Go? Inference, Retention, Retrieval, and Access
“Is our data used to train the model?” is an important question—but it is not a complete AI security assessment. Even when training is excluded, sensitive information may still pass through conversation history, retrieved documents, application logs, connected tools, and service-specific retention mechanisms.
This session follows a request through a cloud-hosted AI application to examine where data travels, which identities can access it, and what may remain after the response is returned. We’ll distinguish model training from inference, service retention from application logging, and conversation history from persistent agent memory.
Using worked examples, we’ll compare a direct model interaction with a retrieval-augmented application and an agent that invokes tools. We’ll examine how each introduces different access and data-handling requirements, and why private networking alone cannot establish that every document, response, or downstream action is authorised.
Rather than treating all AI services as having the same behaviour, we’ll identify which questions require provider documentation, configuration evidence, contractual assurance, or application-level testing.
Attendees will leave able to:
- Map the data paths and access boundaries of an AI application.
- Distinguish training, inference, retention, logging, and memory when assessing sensitive-data use.
- Identify the evidence needed to evaluate retrieval permissions, connected tools, and service-specific data handling.
Audience: Cloud architects, security professionals, platform engineers, and data owners.
Level: Intermediate.
Duration: 45 minutes; expandable to 60 minutes with deeper scenario discussion.
Prerequisites: Basic understanding of cloud identity and application architecture; no machine-learning knowledge required.
Format: Slides, data-flow diagrams, and worked examples.
Scope: Azure-centred examples, with principles applicable to other cloud and SaaS AI services. Provider-specific claims will be checked against current documentation before delivery.
Let the AI Ask the Questions: Turning Operational Knowledge into Draft Runbooks
Operational knowledge often lives with the people doing the work rather than in the documentation. Asking an AI system to “write a runbook” can produce a polished document while leaving critical assumptions, exceptions, and recovery steps unexplored.
This session examines an interview-led approach in which an AI assistant asks structured questions about one bounded operational procedure. We’ll explore how it can help surface prerequisites, decision points, expected outcomes, failure conditions, and escalation paths before assembling a draft runbook.
The focus is on assisting knowledge capture—not claiming that an agent can independently discover how an organisation operates. We’ll distinguish information supplied by a subject-matter expert from assumptions introduced by the model, and examine how unresolved questions should remain visible rather than being filled with plausible instructions.
We’ll also cover the human review needed before a draft becomes an approved procedure, including sensitive-information handling, ownership, versioning, and validation by someone other than its author.
Attendees will leave able to:
- Structure an AI-assisted interview around a bounded operational procedure.
- Identify unsupported assumptions and missing decision or recovery steps.
- Define a review and validation process before publishing an AI-assisted runbook.
Audience: Operations engineers, platform teams, architects, and technical process owners.
Level: Introductory to intermediate.
Duration: 45 minutes.
Prerequisites: Familiarity with operational procedures; no coding or machine-learning knowledge required.
Format: Slides and a worked interview-to-draft example.
Scope: Knowledge capture and reviewed documentation—not autonomous workflow observation, procedure execution, or continuous documentation maintenance.
AI on Call: Investigating an Azure Incident with Azure SRE Agent
An alert tells you something is wrong. It does not tell you which evidence to trust, whether a recent change caused the problem, or whether the proposed fix will restore service.
This session follows an incident in an isolated Azure application using Azure SRE Agent. We’ll examine how the agent gathers operational context, develops a diagnosis, and proposes a mitigation—and how an engineer evaluates those recommendations before allowing a change.
Through a worked demonstration, we’ll distinguish symptoms from causes, inspect the evidence supporting the agent’s conclusions, and explore how Azure permissions and approval controls shape its ability to act. After a mitigation, we’ll verify application behaviour independently rather than treating the agent’s “resolved” message as proof of recovery.
We’ll also examine the preparation behind the demonstration: telemetry, resource access, response instructions, and any supplied runbooks. The aim is an honest assessment of AI-assisted operations, including where deterministic automation remains the better choice.
Attendees will leave able to:
- Assess whether an agent’s diagnosis is supported by operational evidence.
- Distinguish resource permissions from action-approval controls.
- Verify recovery and recognise when a mitigation has not removed the underlying cause.
Audience: Azure engineers, platform engineers, SREs, cloud architects, and technical operations teams.
Level: Intermediate.
Duration: 45 minutes; expandable to 60 minutes with deeper investigation and discussion.
Prerequisites: Familiarity with Azure resources, monitoring, and RBAC. No machine-learning knowledge required.
Format: Architectural explanation and a live demonstration, with a recorded fallback.
Session status: In development. The final demonstration and product-specific claims will be validated before submission or delivery.
Azure Cloud Commanders User group Sessionize Event
global-azure-anz-2026 Sessionize Event
Azure Back to School 2025 Sessionize Event
Chris Hailes
Microsoft MVP | Cloud Technology Strategist | Azure Networking, Security & Platform Architecture
Sydney, Australia
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top