Recent Discussions
ServiceEndpointProxy activity on ADO Service Connection
I have an ADO Service Connection which I don't think is being used by any pipelines but I still see regular entries in the usage history like: Type: ServiceEndpointProxy Details: ServicePrincipalSignInAudience I've not been able to find any information about what causes this. What is causing this activity and will deleting the service connection adversely affect anything assuming this is the only thing using it?
Azure Admin Login
We have a client who has lost their access information to get into their Azure global admin. This is a non-profit institution that moved the ownership of their Azure account to another entity years ago now can't get in to the global admin for their entire Azure setup. Microsoft requires the global admin login to create a support ticket and in this case, how are they supposed to open up a case when they can't login. The customer is furious and now disputing the CC charges so we open an Azure support ticket 10 days ago for ourselves and since it's not a Critical issue, have gotten no response. This is untenable situation and there is no way to contact some one from MS without the login, how does this get resolved??
Building Production-Ready Pipelines in Azure DevOps: Beyond the Documentation Examples
Hi everyone, When moving from basic Azure DevOps tutorials to enterprise production environments, we all quickly realize that documentation examples don't always cover real-world complexities. Handling multi-stage dependencies, keeping Terraform state secure, and managing secrets across environments requires a highly strategic approach. To help DevOps engineers bridge this gap, I recently put together a deep-dive architecture breakdown detailing how to build a resilient, multi-stage YAML pipeline from scratch. Here is a quick look at the core enterprise architecture I focus on: - Multi-Stage Lifecycle: Safe progression flows through Build, Dev, QA, UAT, and Production stages. - Infrastructure Automation: Clean integration with Terraform, including state and secrets management using Azure Key Vault. - Security Gates: Implementation of SAST scanning, Workload Identity, and automated approval policies. - Team Alignment: Connecting Azure DevOps with project tools like Asana to streamline cross-platform tracking. I wanted to share this pattern here to get some community feedback on the YAML structure. Before I post the full configuration snippets, I would love to hear how your teams handle environment gates and approvals. What are the biggest bottlenecks you run into with multi-stage YAML pipelines? Let's discuss in the comments below! Best regards, Abdullah ShahidBuilding Production-Ready Pipelines in Azure DevOps: Beyond the Documentation Examples
Hi everyone, When moving from basic Azure DevOps tutorials to enterprise production environments, we all quickly realize that documentation examples don't always cover real-world complexities. Handling multi-stage dependencies, keeping Terraform state secure, and managing secrets across environments requires a highly strategic approach. To help DevOps engineers bridge this gap, I recently put together a deep-dive architecture breakdown detailing how to build a resilient, multi-stage YAML pipeline from scratch. Here is a quick look at the core enterprise architecture I focus on: - Multi-Stage Lifecycle: Safe progression flows through Build, Dev, QA, UAT, and Production stages. - Infrastructure Automation: Clean integration with Terraform, including state and secrets management using Azure Key Vault. - Security Gates: Implementation of SAST scanning, Workload Identity, and automated approval policies. - Team Alignment: Connecting Azure DevOps with project tools like Asana to streamline cross-platform tracking. I wanted to share this pattern here to get some community feedback on the YAML structure. Before I post the full configuration snippets, I would love to hear how your teams handle environment gates and approvals. What are the biggest bottlenecks you run into with multi-stage YAML pipelines? Let's discuss in the comments below! Best regards, Abdullah ShahidAgentic AIOps vs Traditional AIOps: What Actually Changes in Practice?
Artificial Intelligence for IT Operations (AIOps) has transformed how organizations monitor, manage, and optimize modern IT infrastructure. By combining machine learning, analytics, and automation, Traditional AIOps has helped IT teams reduce alert fatigue, identify anomalies faster, and improve operational efficiency. https://dellenny.com/agentic-aiops-vs-traditional-aiops-what-actually-changes-in-practice/How to Build Your First IT Support Agent Using Azure AI
Artificial Intelligence is transforming the way businesses provide IT support. Instead of waiting for a technician to answer every question, organizations are increasingly using AI-powered support agents that can troubleshoot common issues, answer employee questions, and automate repetitive tasks. Thanks to Microsoft Azure AI, building an intelligent IT support agent is no longer limited to data scientists or large enterprises. Even beginners can create a functional AI assistant with minimal coding. https://dellenny.com/how-to-build-your-first-it-support-agent-using-azure-ai/Dealing with Legacy Systems and Services in Cloud Computing
Every organization reaches a point where technology that once powered innovation begins to slow progress. Legacy systems, although reliable and familiar, often become barriers to growth, agility, and digital transformation. As businesses increasingly adopt cloud computing to improve scalability, reduce operational costs, and enhance security, one major challenge remains how to deal with legacy systems and services without disrupting business operations. https://dellenny.com/dealing-with-legacy-systems-and-services-in-cloud-computing/
Free Extension: Generate AI Development Prompts from Azure DevOps Work Items — Verity Framework
Hi Azure DevOps community, I wanted to share a free extension we just published to the Visual Studio Marketplace: the Verity Framework ADO Extension. **What it does** It adds a "Verity Prompt" tab to your work items. When you populate five custom fields on a User Story or Delivery Item, the extension generates a structured prompt ready to paste into Claude Code, Cursor, or GitHub Copilot Workspace. The five fields: - VF Intent — the problem and who experiences it - VF Value — the expected outcome - VF Appetite — time/resource ceiling (not an estimate) - VF Trust Criteria — Gate 2 hardening requirements - VF Failure Scope — Narrow / Moderate / Broad / Systemic **Why it matters** Most engineers using AI tools start from a blank context or a vague task description. The extension carries the team's planning judgment — including production risk level and hardening requirements — directly into the implementation context. It also includes field validation that flags vague Trust Criteria, incorrectly formatted Appetite values, and solution-framed Intent statements before generating the prompt. **Setup** About 20 minutes. You add five custom fields to your existing User Story work item type (no new work item type required). Full instructions are in the extension tab. **Install** Search "Verity Framework" on the Visual Studio Marketplace or visit idearoost.com/verity for the full framework context. Free. No subscription required. Happy to answer questions about the field definitions or the setup process. — Jacques Steward, IdeaRoostAzure Architecture Best Practices for Enterprise Applications
As businesses continue to modernize their IT infrastructure, Microsoft Azure has become one of the leading cloud platforms for building enterprise-grade applications. Organizations of all sizes rely on Azure to improve scalability, strengthen security, reduce operational costs, and accelerate digital transformation. However, simply moving an application to the cloud does not guarantee success. A well-designed Azure architecture is the foundation of a secure, reliable, and high-performing enterprise application. https://dellenny.com/azure-architecture-best-practices-for-enterprise-applications/Building Resilient Cloud Architectures with Azure’s Agentic Agents
Cloud computing has evolved far beyond simply moving workloads from on-premises servers to virtual machines. Organizations today expect their cloud environments to be intelligent, resilient, secure, and capable of adapting to changing business demands with minimal human intervention. As artificial intelligence continues to reshape enterprise technology, Microsoft Azure is introducing a new generation of AI-powered capabilities through Agentic AI. https://dellenny.com/building-resilient-cloud-architectures-with-azures-agentic-agents-migration-observability-and-optimization/Looking for a new home for our Learning Room (Azure Integration + AI)
Hi everyone, I’m Konstantinos, the host of the Learning Room Modern Development with Azure Integration and AI in the Microsoft Learn Skills Hub. I am a Tech enthusiast , geek , nigh crawler ,,,you know ! More about me https://passadis.github.io But enough. I’m reaching out because the Learn Expert program is being retired, and all Learning Rooms will close at the end of June. I currently host the room Modern Development with Azure Integration and AI, and I’m hoping to keep it alive by transferring it into an existing Tech Community space — if a community owner is open to it. 🔗 Learning Room: https://techcommunity.microsoft.com/group/a16aab22-66d5-4fc2-8539-b6a382916bda Focus: Practical Azure integration patterns, modern development approaches, and applied AI — with hands‑on guidance, discussions, and support for learners building real‑world solutions. If you are a community owner, moderator, or know who manages a relevant Azure space (Apps on Azure, Azure Architecture, Azure AI, Integration, Developer Tools, etc.), I’d really appreciate a quick introduction or guidance. A transfer is only possible with the destination owner’s approval, and the Tech Community team will handle the technical side — I just need confirmation from the right person. Thank you in advance to anyone who can help point me in the right direction. I’d love to keep supporting learners and contributing to the Azure community. KonstantinosFrom AWS to Azure: Practical Lessons and Best Practices from Real-World Migrations
Cloud-to-cloud migrations—especially from AWS to Azure—are often seen as straightforward “lift-and-shift” exercises. In reality, they involve careful planning across architecture, networking, identity, and deployment practices to ensure stability, scalability, and long-term maintainability. Based on my experience working on large-scale migration programs, here are some key best practices that can significantly improve the success of AWS-to-Azure transitions. 1. Start with Architecture, Not Migration One of the most common pitfalls is jumping directly into migration without defining the target architecture. Before moving workloads: Define landing zones and environment structure (Dev/UAT/Prod) Align networking, identity, and security models Map AWS services to Azure equivalents (e.g., EC2 → VM/VMSS, ALB → Application Gateway 2. Prioritize Infrastructure as Code (IaC) Manual changes during migration create long-term drift and instability. Best practices: Use IaC (Terraform/Bicep) for all infrastructure provisioning Capture any portal-level fixes back into code Maintain version-controlled deployments 3. Plan Capacity and Quotas Early Capacity-related issues are often discovered too late during migration. From experience: Validate VM sizes and availability in target regions Plan capacity reservations if needed Align quotas with expected workload scale 4. Design Networking and Private Access Upfront Networking is one of the most critical components in migration. Key considerations: Use private endpoints for PaaS services Design subnet segmentation and NSGs carefully Ensure DNS resolution works across environments. 5. Standardize Monitoring and Observability Migration is not complete until the system is observable. Enable diagnostics and logs across all resources Integrate with Log Analytics / monitoring tools Define alerts for critical failures 6. Manage Security and Access with RBAC Use Azure AD-based authentication Assign least-privilege roles Store secrets in Key Vault 7. Expect Iterations — Not One-Time Deployment Real-world migrations are iterative: Initial deployment Fixes and adjustments Re-deployments Stabilization 8. Strengthen Cross-Team Alignment Large migrations involve multiple teams: Infrastructure Application Database Platform From experience: Early alignment reduces rework Clear ownership improves execution Structured communication avoids last-minute confusion 9. Capture Learnings and Standardize Every migration teaches something: Capacity gaps Deployment challenges Configuration improvements Document: lessons learned reusable templates standard deployment patterns 10. Leverage Automation and AI for Efficiency As migrations scale, automation becomes critical. Use scripts and pipelines to reduce manual effort Automate repetitive validation steps Explore AI-driven approaches for log analysis and troubleshooting AWS to Azure migration is not just a technical shift—it’s an opportunity to modernize, standardize, and optimize your cloud platform. The key is to: design before deploying automate everything possible plan for scale and security and continuously improve based on real-world learnings[Architecture Pattern] Scaling Sync-over-Async Edge Gateways by Bypassing Service Bus Sessions
Hi everyone, I wanted to share an architectural pattern and an open-source implementation we recently built to solve a major scaling bottleneck at the edge: bridging legacy synchronous HTTP clients to long-running asynchronous AI workers. The Problem: Stateful Bottlenecks at the Edge When dealing with slow AI generation tasks (e.g., 45+ seconds), standard REST APIs will drop the connection resulting in 504 Gateway Timeouts. The standard integration pattern here is Sync-over-Async. The Gateway accepts the HTTP request, drops a message onto Azure Service Bus, waits for the worker to reply, and maps the reply back to the open HTTP connection. However, the default approach is to use Service Bus Sessions for request-reply correlation. At scale, this introduces severe limitations: 1. Stateful Gateways: The Gateway pod must request an exclusive lock on the session. It becomes tightly coupled to that specific request. 2. Horizontal Elasticity is Broken: If a reply arrives, it must go to the specific pod holding the lock. Other idle pods cannot assist. 3. Hard Limits: A traffic spike easily exhausts the namespace concurrent session limits (especially on the Standard tier). The Solution: Stateless Filtered Topics To achieve true horizontal scale, the API Gateway layer must be 100% stateless. We bypassed Sessions entirely by pushing the routing logic down to the broker using a Filtered Topic Pattern. How it works: 1. The Gateway injects a CorrelationId property (e.g., Instance-A-Req-1) into the outbound request. 2. Instead of locking a session, the Gateway spins up a lightweight, dynamic subscription on a shared Reply Topic with a SQL Filter: CorrelationId = 'Instance-A-Req-1'. 3. The AI worker processes the task and drops the reply onto the shared topic with the same property. 4. The Azure Service Bus broker evaluates the SQL filter and pushes the message directly to the correct Gateway pod. No session locks. No implicit instance affinity. Complete horizontal scalability. If a pod crashes, its temporary subscription simply drops—preventing locked poison messages. Open Source Implementation Implementing dynamic Service Bus Administration clients and receiver lifecycles is complex, so I abstracted this pattern into a Spring Boot starter for the community. It handles all the dynamic subscription and routing logic under the hood, allowing developers to execute highly scalable Sync-over-Async flows with a single line of code returning a CompletableFuture. GitHub Repository: https://github.com/ShivamSaluja/sentinel-servicebus-starter Full Technical Write-up: https://dev.to/shivamsaluja/sync-over-async-bypassing-azure-service-bus-session-limits-for-ai-workloads-269d I would love to hear from other architects in this hub. Have you run into similar session exhaustion limits when building Edge API Gateways? Have you adopted similar stateless broker-side routing, or do you rely on sticky sessions at your load balancers?Proyecto Escolar Tecnológico
Estamos haciendo un trabajo de investigación sobre las nuevas tecnologías aplicadas a la gestión empresarial ya que estamos desarrollando un proyecto de software para el sector de odontología y me gustaría preguntarle a los expertos: ¿Qué tecnologías se consideran "el estándar de oro" o esenciales para aplicar en 2026, y que ustedes ya han utilizado?.Detecting ACI IP Drift and Auto-Updating Private DNS (A + PTR) with Event Grid + Azure Functions
Solution Author Aditya_AzureNinja , Chiragsharma30 Solution Version v1.0 TL;DR Azure Container Instances (ACI) container groups can be recreated/updated over time and may receive new private IPs, which can cause DNS mismatches if forward and reverse records aren’t updated. This post shares an event-driven pattern that detects ACI IP drift and automatically reconciles Private DNS A (forward) and PTR (reverse) records using Event Grid + Azure Functions. Key requirement: Event delivery is at-least-once, so the solution must be idempotent. Problem statement In hub-and-spoke environments using per-spoke Private DNS zones for isolation, ACI workloads created/updated/deleted over time can receive new private IPs. We need to ensure: Forward lookup: aci-name.<spoke-zone> (A record) → current ACI private IP Reverse lookup: IP → aci-name.<spoke-zone> (PTR record) Two constraints drive this design: Azure Private DNS auto-registration is VM-only and does not create PTR records, so ACI needs explicit A/PTR record management. Reverse DNS is scoped to the VNet (reverse zone must be linked to the querying VNet, otherwise reverse lookup returns NXDOMAIN). Design principle: This solution was designed with the following non‑negotiable engineering goals: Event‑driven DNS updates must be triggered directly from resource lifecycle events, not polling or scheduled jobs. Container creation, restart, and deletion are the only reliable sources of truth for IP changes in ACI. Idempotent Azure Event Grid delivers events with at‑least‑once semantics. The system must safely process duplicate events without creating conflicting DNS records or failing on retries. Stateless The automation must not rely on in‑memory or persisted state to determine correctness. DNS itself is treated as the baseline state, allowing functions to scale, restart, and replay events without drift or dependency on prior executions. Clear failure modes DNS reconciliation failures must be explicit and observable. If DNS updates fail, the function invocation must fail loudly so the issue is visible, alertable, and actionable—never silently ignored. Components Event Grid subscriptions (filtered to ACI container group lifecycle events) Azure Function App (Python) with System Assigned Managed Identity Private DNS forward zone (A records) Private DNS reverse zone (PTR records) Supporting infra (typical): Storage account (function artifacts / operational needs) Application Insights + Log Analytics (observability) Event-driven flow ACI container group is created/updated/deleted. Event Grid emits a lifecycle event (delivery can be repeated). Function is triggered and reads the current ACI private IP. Function reconciles DNS: Upsert A record to current IP Upsert PTR record to FQDN Remove stale PTR(s) for hostname/IP as needed Function logs reconciliation outcome (updated vs no-op). Architecture overview (INFRA) This follows the“Event-driven registration” approach: Event Grid → Azure Function that reconciles DNS on ACI lifecycle events. RBAC at a glance (Managed Identity) Role Scope Purpose Storage Blob Data Owner Function App deployment storage account Access function artifacts and operational blobs (required because shared key access is disabled). Reader Each ACI workload resource group Read container group state and determine the current private IP. Private DNS Zone Contributor Private DNS forward zone(s) Create, update, and delete A records for ACI hostnames. Private DNS Zone Contributor Private DNS reverse zone(s) Create, update, and clean up PTR records for ACI IPs. Monitoring Metrics Publisher (optional) Data Collection Rule (DCR) Upload structured IP‑drift events to Log Analytics via the ingestion API. --- --- Architecture overview (APP) Event‑Driven DNS Reconciliation for Azure Container Instances 1. Event contract: what the function receives Azure Event Grid delivers events using a consistent envelope (Event Grid schema). Each event includes, at a minimum: topic subject id eventType eventTime data dataVersion metadataVersion In Azure Functions, the Event Grid trigger binding is the recommended way to receive these events directly. Why the subject field matters The subject field typically contains the ARM resource ID path of the affected resource. This solution relies on subject to: verify that the event is for an ACI container group (Microsoft.ContainerInstance/containerGroups) extract: subscription ID resource group name container group name Using subject avoids dependence on publisher‑specific payload fields and keeps parsing fast, deterministic, and resilient. 2. Subscription design: filter hard, process little The solution follows a strict runbook pattern: subscribe only to ARM lifecycle events filter aggressively so only ACI container groups are included trigger reconciliation only on meaningful state transitions Recommended Event Grid event types Microsoft.Resources.ResourceWriteSuccess (create / update / stop state changes) Microsoft.Resources.ResourceDeleteSuccess (container group deletion) Microsoft.Resources.ResourceActionSuccess (optional) (restart / start / stop actions, environment‑dependent) This keeps the Function App simple, predictable, and low‑noise. 3. Application design: two functions, one contract The application is intentionally split into authoritative mutation and read‑only validation. Component A — DNS Reconciler (authoritative writer) A thin Python v2 model wrapper: receives the Event Grid event validates this is an ACI container group event parses identifiers from the ARM subject resolves DNS configuration from a JSON mapping (environment variable) delegates DNS mutation to a deterministic worker script DNS changes are not implemented inline in Python. Instead, the function: constructs a controlled set of environment variables invokes a worker script (/bin/bash) via subprocess streams stdout/stderr into function logs treats non‑zero exit codes as hard failures This thin wrapper + deterministic worker pattern isolates DNS correctness logic while keeping the event handler stable and testable. Component B — IP Drift Tracker (stateless observer) The drift tracker is a read‑only, stateless validator designed for correctness monitoring. It: parses identifiers from the event subject exits early on delete events (nothing to validate) reads the live ACI private IP using the Azure SDK reads the current DNS A record baseline compares live vs DNS state and emits drift telemetry Core comparison logic No DNS record exists → emit first_seen DNS record matches live IP → emit no_change DNS record differs from live IP → emit drift_detected (old/new IP) Optionally, drift events can be shipped to Log Analytics using DCR‑based ingestion. 4. DNS Reconciler: execution flow Step 1 — Early filtering Reject any event whose subject does not contain: Microsoft.ContainerInstance/containerGroups. This avoids unnecessary processing and ensures strict contract enforcement. Step 2 — ARM subject parsing The function splits the subject path and extracts: resource group container group name This approach is fast, robust, and avoids publisher‑specific schema dependencies. Step 3 — Zone configuration resolution DNS configuration is resolved from a JSON map stored in an environment variable. If no matching configuration exists for the resource group: the function logs the condition exits without error Why this matters This keeps the solution multi‑environment without duplicating deployments. Only configuration changes — not code — are required. Step 4 — Delegation to worker logic The function constructs a deterministic runtime context and invokes the worker: forward zone name reverse zone name(s) container group name current private IP TTL and execution flags The worker performs reconciliation and exits with explicit success or failure. 5. What “reconciliation” actually means Reconciliation follows clear, idempotent semantics. Create / Update events Upsert A record if record exists and matches current IP → no‑op else → create or overwrite with new IP Upsert PTR record compute PTR name using IP octets and reverse zone alignment create or overwrite PTR to hostname.<forward-zone> Delete events delete the A record for the hostname scan PTR record sets: remove targets matching the hostname delete record set if empty All operations are safe to repeat. 6. Why IP drift tracking is separate DNS reconciliation enforces correctness at event time, but drift can still occur due to: manual DNS edits partial failures delete / recreate race conditions unexpected redeployments or restarts The drift tracker exists as a continuous correctness validator, not as a repair mechanism. This separation keeps responsibilities clear: Reconciler → fixes state Drift tracker → observes and reports state 7. Observability: correctness vs runtime health There is an important distinction: Runtime health container crashes image pull failures restarts platform events (visible in standard ACI / Container logs) DNS correctness A record != live IP missing PTR records stale reverse mappings The IP Drift Tracker provides this correctness layer, which complements — not replaces — runtime monitoring. 8. Engineering constraints that shape the design At‑least‑once delivery → idempotency Event Grid delivery must be treated as at‑least‑once. Every reconciliation action is safe to execute multiple times. Explicit failure behavior If the worker script returns a non‑zero exit code: the function invocation fails the failure is visible and alertable incorrect DNS does not silently persist
My First TechCommunity Post: Azure VPN Gateway BGP Timer Mismatches
This is my first post on the Microsoft TechCommunity. Today is my seven-year anniversary at Microsoft. In my current role as a Senior Cloud Solution Architect supporting Infrastructure in Cloud & AI Platforms, I want to start by sharing a real-world lesson learned from customer engagements rather than a purely theoretical walkthrough. This work and the update of the official documentation on Microsoft Learn is the culmination of nearly two years of support for a very large global SD-WAN deployment with hundreds of site-to-site VPN connections into Azure VPN Gateway. The topic is deceptively simple—BGP timers—but mismatched expectations can cause significant instability when connecting on‑premises environments to Azure. If you’ve ever seen seemingly random BGP session resets, intermittent route loss, or confusing failover behavior, there’s a good chance that a timer mismatch between Azure and your customer premises equipment (CPE) was a contributing factor. Customer Expectation: BGP Timer Negotiation Many enterprise routers and firewalls support aggressive BGP timers and expect them to be negotiated during session establishment. A common configuration I see in customer environments looks like: Keepalive: 10 seconds Hold time: 30 seconds This configuration is not inherently wrong. In fact, it is often used intentionally to speed up failure detection and convergence in conventional network environments. My past experience with short timers was in a national cellular network carrier between core switching routers in adjacent racks, but all other connections used the default timer values. The challenge appears when that expectation is carried into Azure VPN Gateway. Azure VPN Gateway Reality: Fixed BGP Timers Azure VPN Gateway supports BGP but uses fixed timers (60/180) and won’t negotiate down. The timers are documented: The BGP keepalive timer is 60 seconds, and the hold timer is 180 seconds. Azure VPN Gateways use fixed timer values and do not support configurable keepalive or hold timers. This behavior is consistent across supported VPN Gateway SKUs that offer BGP support. Unlike some on‑premises devices, Azure will not adapt its timers downward during session establishment. What Happens During a Timer Mismatch When a CPE is configured with a 30‑second hold timer, it expects to receive BGP keepalives well within that window. Azure, however, sends BGP keepalives every 60 seconds. From the CPE’s point of view: No keepalive is received within 30 seconds The BGP hold timer expires The session is declared dead and torn down Azure may not declare the peer down on the same timeline as the CPE. This mismatch leads to repeated session flaps. The Hidden Side Effect: BGP State and Stability Controls During these rapid teardown and re‑establishment cycles, many CPE platforms rebuild their BGP tables and may increment internal routing metadata. When this occurs repeatedly: Azure observes unexpected and rapid route updates The BGP finite state machine is forced to continually reset and re‑converge BGP session stability is compromised CPE equipment logging may trigger alerts and internal support tickets. The resulting behavior is often described by customers as “Azure randomly drops routes” or “BGP is unstable”, when the instability originates from mismatched BGP timer expectations between the CPE and Azure VPN Gateway. Why This Is More Noticeable on VPN (Not ExpressRoute) This issue is far more common with VPN Gateway than with ExpressRoute. ExpressRoute supports BFD and allows faster failure detection without relying solely on aggressive BGP timers. VPN Gateway does not support BFD, so customers sometimes compensate by lowering BGP timers on the CPE—unintentionally creating this mismatch. The VPN path is Internet/WAN-like where delay/loss/jitter is normal, so conservative timer choices are stability-focused. Updated Azure Documentation The good news is that the official Azure documentation has been updated to clearly state the fixed BGP timer values for VPN Gateway: Keepalive: 60 seconds Hold time: 180 seconds Timer negotiation: Azure uses fixed timers Azure VPN Gateway FAQ | Microsoft Learn This clarification helps set the right expectations and prevents customers from assuming Azure behaves like conventional CPE routers. Practical Guidance If you are connecting a CPE to Azure VPN Gateway using BGP: Do not configure BGP timers lower than Azure’s defaults Align CPE timers to 60 / 180 or higher Avoid using aggressive timers as a substitute for BFD For further resilience: Consider Active‑Active VPN Gateways for better resiliency Use 4 Tunnels commonly implemented in a bowtie configuration for even better resiliency and traffic stability Closing Thoughts This is a great example of how cloud networking often behaves correctly, but differently than conventional on‑premises networking environments. Understanding those differences—and documenting them clearly—can save hours of troubleshooting and frustration. If this post helps even one engineer avoid a late‑night or multi-month BGP debugging session, then it has done its job. I did use AI (M365 Copilot) to aid in formatting and to validate technical accuracy. Otherwise, these are my thoughts. Thanks for reading my first TechCommunity post.
Help wanted: Refresh articles in Azure Architecture Center (AAC)
I’m the Project Manager for architecture review boards (ARBs) in the Azure Architecture Center (AAC). We’re looking for subject matter experts to help us improve the freshness of the AAC, Cloud Adoption Framework (CAF), and Well-Architected Framework (WAF) repos. This opportunity is currently limited to Microsoft employees only. As an ARB member, your main focus is to review, update, and maintain content to meet quarterly freshness targets. Your involvement directly impacts the quality, relevance, and direction of Azure Patterns & Practices content across AAC, CAF, and WAF. The content in these repos reaches almost 900,000 unique readers per month, so your time investment has a big, global impact. The expected commitment is 4-6 hours per month, including attendance at weekly or bi-weekly sync meetings. Become an ARB member to gain: Increased visibility and credibility as a subject‑matter expert by contributing to Microsoft‑authored guidance used by customers and partners worldwide. Broader internal reach and networking without changing roles or teams. Attribution on Microsoft Learn articles that you own. Opportunity to take on expanded roles over time (for example, owning a set of articles, mentoring contributors, or helping shape ARB direction). We’re recruiting new members across several ARBs. Our highest needs are in the Web ARB, Containers ARB, and Data & Analytics ARB: The Web ARB focuses on modern web application architecture on Azure—App Service and PaaS web apps, APIs and API Management, ingress and networking (Application Gateway, Front Door, DNS), security and identity, and designing for reliability, scalability, and disaster recovery. The Containers ARB focuses on containerized and Kubernetes‑based architectures—AKS design and operations, networking and ingress, security and identity, scalability, and reliability for production container platforms. The Data & Analytics ARB focuses on data platform and analytics architectures—data ingestion and integration, analytics and reporting, streaming and real‑time scenarios, data security and governance, and designing scalable, reliable data solutions on Azure. We’re also looking for people to take ownership of other articles across AAC, CAF, and WAF. These articles span many areas, including application and solution architectures, containers and compute, networking and security, governance and observability, data and integration, and reliability and operational best practices. You don’t need to know everything—deep expertise in one or two areas and an interest in keeping Azure architecture guidance accurate and current is what matters most. Please reply to this post if you’re interested in becoming an ARB member, and I’ll follow up with next steps. If you prefer, you can email me at v-jodimartis@microsoft.com. Thanks! 🙂Help wanted: Refresh articles in Azure Architecture Center (AAC)
I’m the Project Manager for architecture review boards (ARBs) in the Azure Architecture Center (AAC). We’re looking for subject matter experts to help us improve the freshness of the AAC, Cloud Adoption Framework (CAF), and Well-Architected Framework (WAF) repos. This opportunity is currently limited to Microsoft employees only. As an ARB member, your main focus is to review, update, and maintain content to meet quarterly freshness targets. Your involvement directly impacts the quality, relevance, and direction of Azure Patterns & Practices content across AAC, CAF, and WAF. The content in these repos reaches almost 900,000 unique readers per month, so your time investment has a big, global impact. The expected commitment is 4-6 hours per month, including attendance at weekly or bi-weekly sync meetings. Become an ARB member to gain: Increased visibility and credibility as a subject‑matter expert by contributing to Microsoft‑authored guidance used by customers and partners worldwide. Broader internal reach and networking without changing roles or teams. Attribution on Microsoft Learn articles that you own. Opportunity to take on expanded roles over time (for example, owning a set of articles, mentoring contributors, or helping shape ARB direction). We’re recruiting new members across several ARBs. Our highest needs are in the Web ARB, Containers ARB, and Data & Analytics ARB: The Web ARB focuses on modern web application architecture on Azure—App Service and PaaS web apps, APIs and API Management, ingress and networking (Application Gateway, Front Door, DNS), security and identity, and designing for reliability, scalability, and disaster recovery. The Containers ARB focuses on containerized and Kubernetes‑based architectures—AKS design and operations, networking and ingress, security and identity, scalability, and reliability for production container platforms. The Data & Analytics ARB focuses on data platform and analytics architectures—data ingestion and integration, analytics and reporting, streaming and real‑time scenarios, data security and governance, and designing scalable, reliable data solutions on Azure. We’re also looking for people to take ownership of other articles across AAC, CAF, and WAF. These articles span many areas, including application and solution architectures, containers and compute, networking and security, governance and observability, data and integration, and reliability and operational best practices. You don’t need to know everything—deep expertise in one or two areas and an interest in keeping Azure architecture guidance accurate and current is what matters most. Please reply to this post if you’re interested in becoming an ARB member, and I’ll follow up with next steps. If you prefer, you can email me at v-jodimartis@microsoft.com. Thanks! 🙂Hi everyone!
Hi everyone! 👋 I’m new to this community and currently learning Azure Analytics. I’m really excited to be here and connect with people who have experience in this field. I believe the discussions and knowledge shared by members here are very valuable, and I’m looking forward to learning from all of you. If you have any advice, resources, or tips for someone starting with Azure Analytics, I’d really appreciate it. Happy to be part of this community! 😊
Recent Blogs
- Today, the Azure Arc team is pleased to announce that Extended Security Updates (ESUs) enabled by Azure Arc is now generally available for Windows Server 2016. By connecting your Windows Server 2016 ...Aug 06, 2026
- As enterprise AI systems evolve from standalone models into RAG applications, copilots, and autonomous agents, one question comes up often: Should we use Microsoft Foundry or PyRIT for Red Teaming?...Aug 06, 2026
