Hardening Azure Container Registry: Soft Delete & Retention Policies
Hi everyone, We are planning to enable soft delete on our Azure Container Registries (ACR), set to the maximum retention of 90 days. In addition, we want to introduce a retention policy for images and artifacts within the repositories, so that old or orphaned images with potential security vulnerabilities can no longer find their way into circulation. Ideally, we would also like to validate the whole setup safely via a dry run before applying it to production registries. Before we roll this out, I would like to share our approach and get feedback from the community. Goals Protect against accidental deletion (restore window of up to 90 days) Automatically clean up stale, untagged or orphaned images and artifacts Reduce the attack surface caused by outdated images with known CVEs Keep storage costs and registry sprawl under control Test every cleanup rule risk-free before enforcing it Step 1: Enable soft delete (90 days) az acr config soft-delete update \ --registry <registryName> \ --status enabled \ --days 90 Deleted manifests and tags can be listed and restored within the retention window: az acr manifest list-deleted --registry <registryName> --name <repo> az acr manifest restore --registry <registryName> --name <repo>:<tag> Step 2: Retention policy for untagged manifests az acr config retention update \ --registry <registryName> \ --status enabled \ --days 30 \ --type UntaggedManifests Step 3: Scheduled purge for old tagged images (dry run first) The built-in retention policy only covers untagged manifests. For old tagged images, acr purge via an ACR Task is the right tool, and it supports --dry-run: az acr run --registry <registryName> \ --cmd "acr purge --filter '<repo>:.*' --ago 60d --keep 5 --untagged --dry-run" \ /dev/null Review the output, and only when you are happy, remove --dry-run and schedule the command as a recurring ACR Task (az acr task create --schedule "0 2 * * Sun"). Best practices we are considering Test with dry run first: run acr purge --dry-run against non-production registries and review the list of affected images before enforcing anything. Always use --keep: retain the last N tags per repository so rollbacks stay possible. Protect important tags: use --filter patterns to exclude release/production tags, or lock critical images with az acr repository update --write-enabled false. Combine with vulnerability scanning: use Microsoft Defender for Containers to identify vulnerable images and drive purge criteria, rather than relying on age alone. Align retention with your deployment cadence: make sure no running workload (AKS, Container Apps, App Service) still references an image that would be purged. Use consistent tagging: avoid reusing latest; use immutable, versioned tags (e.g. semantic version plus commit SHA). Roll out via IaC: manage the settings through Bicep or Terraform and Azure Policy so every new registry gets the same baseline. Monitor and audit: send ACR diagnostic logs to Log Analytics and alert on unexpected delete operations. Mind the cost: soft-deleted data still counts toward storage until the retention window expires. Open questions for the community Are you running soft delete with 90 days in production? Any pitfalls? How do you combine retention policies with acr purge in practice? Do you use vulnerability findings (e.g. from Defender) as a trigger for image cleanup? Are there known limitations (SKU, geo-replication, preview status) we should consider? Looking forward to your experiences and feedback!
Azure VM resize: PowerShell lists Dv5 sizes, but Azure Portal only offers Dv4
Hello, We recently migrated two production Azure virtual machines away from the retiring Bv1 family. Initially, the VMs were running as: Standard_B2ms Standard_B4ms Our goal was to move them to a newer supported VM family. Environment Region: France Central Managed OS disks (one Standard SSD, one Standard HDD/Standard LRS) SCSI disk controller Windows Server virtual machines What we observed After stopping and deallocating the VM, we queried the available resize targets using PowerShell: Get-AzVMSize ` -ResourceGroupName "<ResourceGroup>" ` -VMName "<VMName>" For one VM, PowerShell returned, among others: Standard_D2ads_v5 Standard_D2ds_v5 Standard_D2d_v5 Standard_D2as_v4 Standard_D2ds_v4 For the other VM, it returned: Standard_D4ads_v5 Standard_D4ds_v5 Standard_D4d_v5 Standard_D4as_v4 However, when opening VM → Size in the Azure Portal, the v5 sizes were not available. Only the following sizes appeared: Standard_D2as_v4 Standard_D4as_v4 As a precaution, we resized both VMs using the sizes proposed by the Azure Portal: Standard_B2ms → Standard_D2as_v4 Standard_B4ms → Standard_D4as_v4 The migration completed successfully and both VMs are running correctly. Question Can someone explain why there is a difference between: the sizes returned by Get-AzVMSize, and the sizes displayed by the Azure Portal? More specifically: Does Get-AzVMSize return VM sizes that are not actually valid resize targets? Does the Azure Portal apply additional compatibility or capacity checks that PowerShell does not? Is this related to: regional capacity, VM generation, disk controller, managed disk type, host cluster, or another compatibility requirement? Would you recommend staying on Das_v4, or should we plan another migration to Dads_v5 if possible? I am trying to understand the reason behind the different behavior rather than forcing the resize through PowerShell. Thank you in advance for your insights.Unexpected $22,000 Azure Marketplace Charge With No Meaningful Warning or Support Escalation
I am hoping someone from Microsoft, Azure Support, or the community can help point me in the right direction because we have reached a point where we genuinely do not know what else to do. Our company participates in an Azure Sponsorship program and has historically operated primarily using sponsorship credits. Recently, we deployed Claude models through Azure AI Foundry under the understanding that our Azure usage was generally being covered through our sponsorship. We later discovered that Claude is considered an Azure Marketplace charge and is therefore excluded from Azure Sponsorship credits. We understand that distinction now. The problem is everything that happened around it. In approximately three days, our company accumulated roughly $22,000 CAD in direct charges. At no point during the deployment process did we receive what I would consider a clear or meaningful warning that: Claude usage would not be covered by our Azure Sponsorship credits. The deployment would result in direct Marketplace charges. We were beginning to accumulate significant charges outside of our sponsorship. Our spending had suddenly increased dramatically beyond our normal usage pattern. We also had a budget configured, but it did not provide us with a meaningful warning before these charges accumulated. We discovered the approximately $22,000 charge almost by accident while reviewing another area of the Azure portal. Had we not happened to look at that page, I do not know how much higher the charges could have become. The Support Experience Has Been Even More Frustrating Since discovering the issue, I have been trying to work through Microsoft's support channels. Microsoft documentation indicates that billing support is available, but actually reaching someone with the ability to review this situation has been extremely difficult. We have repeatedly been directed to create support requests, but the process either prevents us from creating the appropriate ticket or directs us to other support channels. We have also received automated guidance recommending that we use certain cost-management and monitoring capabilities, despite some of those capabilities being unavailable or limited under the legacy sponsorship subscription we are operating under. In another support case, Microsoft simply closed the ticket without asking us and without resolving the issue. That has been one of the most concerning parts of this experience. We are trying to actively resolve a significant financial issue, and instead of getting an escalation path, tickets are being redirected, answered with generic information, or closed. What We Are Looking For At this point, I am simply trying to reach someone at Microsoft who has the authority to actually review this situation. I would greatly appreciate guidance on any of the following: How to escalate an Azure Marketplace billing dispute beyond Azure Sponsorship support. How to reach an Azure billing or Marketplace escalation team that can review exceptional circumstances. Whether there is a formal billing dispute or invoice review process for this type of situation. How to escalate a support case when an existing case has been closed without resolution. Whether someone from Microsoft can review the circumstances surrounding these charges rather than only confirming that Marketplace charges are excluded from sponsorship credits. We have been Microsoft and Azure customers in good faith, and we attempted to put spending controls in place. We are not trying to avoid legitimate usage costs. We are asking Microsoft to review a situation where approximately $22,000 CAD accumulated in roughly three days without a meaningful warning or intervention, followed by a support experience where we have struggled to reach anyone with the authority to help. If anyone from Microsoft or the Azure community can help identify the correct escalation path, I would sincerely appreciate it.
Azure support team not responding to support request
I am posting here because I have not received a response to my support request despite my plan stating that I should hear back within 8 hours. It has now gone a day beyond that limit, and I am still waiting for assistance with this urgent matter. This issue is critical for my operations, and the delay is unacceptable. The ticket/reference number for my original support request was 2410100040000309. And I have created a brand new service request with ID 2412160040010160. I need this addressed immediately.
Is there no way to get better support for Azure - esp for SEV A tickets
We have had a sev A ticket open for over 5 days, and are incurring thousands in losses every day, and despite assurances from the Azure Support that it is being solved in hours and then having confirmations that it is solved, the issue is still not solved. I have asked numerous times to get our teams in touch with actual microsoft employees, not front end contractors, who is more like level 1 support, and just running messages between customer and back end team, and really are powerless to handle any suport issues themselves, and they are on complete mercy of "other teams" yet as a customer, apparantly we cant even get on a call with these other teams, and the poor front end contractors are getting the brunt of our pain. Absolutely are in the dark, as to what is actually happening in the back end, other than "trust me bro" we are working on it. No eta, no explanation.. hard to fathom how this can go on like thisCloud-Native vs. Hybrid for the 2026 Workplace
When to choose Cloud-Native vs. Hybrid for the 2026 Workplace? Hi everyone, I am starting a discussion on the foundational phase of one project. As a Computer Engineer, I believe the most critical decision we face in 2026 is determining exactly when to step to a Full Cloud model versus maintaining a Hybrid Infrastructure. In my view, the decision is not about cost, it is about resiliency, high availability and more avalability. I would like to exchange views with other engineers on these area: latency, edge requirements, integration and aglility. In your experience, what are the Tipps that makes you choose one over the other for a 2026 environment? I'm looking for technical architectural insights, not sales approaches.🚀 Azure Application Gateway: Smart Load Balancing & Security
Ensuring high availability and efficient load balancing is crucial for web applications. Azure offers several traffic management solutions, including Application Gateway, Front Door, Load Balancer, and Traffic Manager. Today, let's focus on why Application Gateway stands out as a powerful tool for managing web traffic. 🚀 Why we should use Azure Application Gateway? 🔹 Layer 7 Load Balancing: Unlike Layer 3 or 4 solutions, Application Gateway makes intelligent routing decisions based on HTTP request properties. For example, requests to /images/ can be directed to dedicated image servers, while /videos/ traffic is routed to specialized video servers. 🔹 SSL/TLS Termination (Offloading): Reduces processing load on backend servers by decrypting traffic at the gateway before forwarding it unencrypted. Note: This might conflict with compliance requirements, so verify your app’s security needs !! 🔹 Autoscaling: Dynamically scales up or down based on traffic patterns, ensuring cost-effective resource utilization. 🔹 Zone Redundancy: Operates across multiple Availability Zones, enhancing fault tolerance without needing separate gateways in each zone. 🔹 Web Application Firewall (WAF): Provides centralized security against common exploits like SQL injection and cross-site scripting (XSS). Built on OWASP 3.1 (WAF_v2), it can function in Detection Mode (alerting admins) or Prevention Mode (blocking threats proactively). 🔹 URL-Based Routing: Enables smart traffic distribution by directing different types of content to the most appropriate backend pools. Example: http://contoso.com/video/* → VideoServerPool 🔹 Multiple-Site Hosting: Hosts multiple web applications on a single gateway, routing requests based on hostname or domain. Example: http://contoso.com → ContosoServerPool 🔹 Redirection & Rewrite Capabilities: ✔ Redirect HTTP → HTTPS to enforce encrypted traffic. ✔ Rewrite HTTP headers & URLs to enhance security (e.g., add HSTS or remove sensitive response headers). 🔹 Cookie-Based Session Affinity: Ensures users maintain session continuity by always connecting to the same backend server. Useful when session state is stored locally. ⚙️ How to Deploy & Configure Azure Application Gateway ⚙️ ✅ Dedicated Subnet: Create a subnet (e.g., myAGSubnet) within a Virtual Network. ✅ Frontend IP: Define whether to use a public or private IP or both (If you configured multiple listeners) to receive client requests. ✅ Backend Pool: Assign backend servers via NICs, Virtual Machine Scale Sets, public/internal IPs, or FQDNs. ✅ HTTP/HTTPS Listener: Specify which port (e.g., 80, 443) will handle incoming requests. ✅ Routing Rules: Set up domain-based (host-based routing) or path-based routing logic. 🔹 Host-Based Routing means routing traffic based on the hostname in the HTTP request header 🔹 Path-based Routing allows you to direct traffic to different backend pools based on the URL path in the request. ✅ Health Probes: Ensure backend servers are online using TCP or HTTP-based monitoring.🔥The Power of Azure’s Security Arsenal 🔥
◆ Using a Public IP without securing your Azure applications and resources exposes you to security threats. Today, we’ll explore the most powerful security solutions from Azure’s arsenal. ◆ Azure provides a multi-layered approach (more than one layer of protection) to secure your resources when using a Public IP. Organizations can now transform this open gateway into a fortified checkpoint. Here’s how these tools work together to mitigate risks: 🚀 Azure DDoS Protection 🚀 ■ Protects your resources and services from being overwhelmed by malicious traffic. This excellent service is available for Network & IP Protection SKUs. ■ Uses Machine Learning to distinguish between normal traffic patterns and malicious flooding attempts (such as SYN floods or UDP amplification attacks) before they impact your applications and services ensuring availability. 🚀 Azure Web Application Firewall (WAF) 🚀 ■ Adds application-layer protection, intercepting HTTP/HTTPS traffic for inspection. ■ Blocks suspicious attacks like SQL injection or XSS by applying OWASP core rule sets, which define how attacks occur and how to defend against them, with continuous updates. ■ Enhances security for customer-facing services, ensuring trust and protection for your website and users. 🚀 Network Security Groups (NSGs) 🚀 ■ Acts as a virtual firewall at the subnet or network interface level, filtering traffic based on predefined rules. ■ Can allow only trusted HTTPS (port 443) connections while blocking unsolicited RDP or SSH attempts. ■ Implements the critical security principle of reducing attack surface, ensuring only authorized traffic reaches your target resources. 🚀 Azure Private Link 🚀 ■ In some scenarios, avoiding Public IPs altogether is the best security approach. This powerful service allows secure access to Azure SQL Database or Storage via Private Endpoints inside your virtual network. ■ Helps organizations minimize external exposure while maintaining secure, private connections to necessary services. 🚀 Azure Bastion 🚀 ■ Provides secure access to Azure VMs without Public IPs, using RDP/SSH over encrypted TLS 1.2 traffic. ■ Uses a browser-based HTML5 web client to establish RDP/SSH sessions over TLS on port 443, fully compatible with any firewall. ■ Connects to VMs via Private IPs while enforcing NSG rules to allow access only through Azure Bastion. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! 🚀🚀 Mastering Azure Management with Global Admin Elevation 🌐
◆ Microsoft Entra ID and Azure resources are secured independently from one another. ◆ Microsoft Entra role assignments do not grant access to Azure resources. ◆ Azure role assignments do not grant access to Microsoft Entra ID. ◆ As a Global Administrator in Microsoft Entra ID, you can assign yourself access to all Azure subscriptions and management groups in your tenant. ◆ Use this capability if you don't have access to Azure subscription resources, such as virtual machines or storage accounts, and you want to use your Global Administrator privilege to gain access to those resources. ◆ When you elevate your access, you are assigned the User Access Administrator role in Azure at root scope (/). This allows you to view all resources and assign access in any subscription or management group in the tenant. ◆ User Access Administrator role assignments can be removed using Azure PowerShell, Azure CLI, or the REST API. 🚀 Why would you need to elevate your access? If you are a Global Administrator, there might be times when you want to do the following actions: ■ Regain access to an Azure subscription or management group when a user has lost access ■ Grant another user or yourself access to an Azure subscription or management group ■ See all Azure subscriptions or management groups in an organization ■ Allow an automation app (such as an invoicing or auditing app) to access all Azure subscriptions or management groups # Perform steps at root scope # Follow these steps to elevate access for a Global Administrator using the Azure portal. (1) Sign in to the Azure portal as a Global Administrator. Note : If you are using Microsoft Entra Privileged Identity Management, activate your Global Administrator role assignment !! (2) Browse to Microsoft Entra ID > Manage > Properties. (3) Under Access management for Azure resources, set the toggle to Yes. (4) Select Save to save your setting. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! 🚀Applying DevOps Principles on Lean Infrastructure. Lessons From Scaling to 102K Users.
Hi Azure Community, I'm a Microsoft Certified DevOps Engineer, and I want to share an unusual journey. I have been applying DevOps principles on traditional VPS infrastructure to scale to 102,000 users with 99.2% uptime. Why am I posting this in an Azure community? Because I'm planning migration to Azure in 2026, and I want to understand: What mistakes am I already making that will bite me during migration? THE CURRENT SETUP Platform: Social commerce (West Africa) Users: 102,000 active Monthly events: 2 million Uptime: 99.2% Infrastructure: Single VPS Stack: PHP/Laravel, MySQL, Redis Yes - one VPS. No cloud. No Kubernetes. No microservices. WHY I HAVEN'T USED AZURE YET Honest answer: Budget constraints in emerging market startup ecosystem. At our current scale, fully managed Azure services would significantly increase monthly burn before product-market expansion. The funding we raised needs to last through growth milestones. The trade: I manually optimize what Azure would auto-scale. I debug what Application Insights would catch. I do by hand what Azure Functions would automate. DEVOPS PRACTICES THAT KEPT US RUNNING Even on single-server infrastructure, core DevOps principles still apply: CI/CD Pipeline (GitHub Actions) • 3-5 deployments weekly • Zero-downtime deploys • Automated rollback on health check failures • Feature flags for gradual rollouts Monitoring & Observability • Custom monitoring (would love Application Insights) • Real-time alerting • Performance tracking and slow query detection • Resource usage monitoring Automation • Automated backups • Automated database optimization • Automated image compression • Automated security updates Infrastructure as Code • Configs in Git • Deployment scripts • Environment variables • Documented procedures Testing & Quality • Automated test suite • Pre-deployment health checks • Staging environment • Post-deployment verification KEY OPTIMIZATIONS Async Job Processing • Upload endpoint: 8 seconds → 340ms • 4x capacity increase Database Optimization • Feed loading: 6.4 seconds → 280ms • Strategic caching • Batch processing Image Compression • 3-8MB → 180KB (94% reduction) • Critical for mobile users Caching Strategy • Redis for hot data • Query result caching • Smart invalidation Progressive Enhancement • Server-rendered pages • 2-3 second loads on 4G WHAT I'M WORRIED ABOUT FOR AZURE MIGRATION This is where I need your help: Architecture Decisions • App Service vs Functions + managed services? • MySQL vs Azure SQL? • When does cost/benefit flip for managed services? Cost Management • How do startups manage Azure costs during growth? • Reserved instances vs pay-as-you-go? • Which Azure services are worth the premium? Migration Strategy • Lift-and-shift first, or re-architect immediately? • Zero-downtime migration with 102K active users? • Validation approach before full cutover? Monitoring & DevOps • Application Insights - worth it from day one? • Azure DevOps vs GitHub Actions for Azure deployments? • Operational burden reduction with managed services? Development Workflow • Local development against Azure services? • Cost-effective staging environments? • Testing Azure features without constant bills? MY PLANNED MIGRATION PATH Phase 1: Hybrid (Q1 2026) • Azure CDN for static assets • Azure Blob Storage for images • Application Insights trial • Keep compute on VPS Phase 2: Compute Migration (Q2 2026) • App Service for API • Azure Database for MySQL • Azure Cache for Redis • VPS for background jobs Phase 3: Full Azure (Q3 2026) • Azure Functions for processing • Full managed services • Retire VPS QUESTIONS FOR THIS COMMUNITY Question 1: Am I making migration harder by waiting? Should I have started with Azure at higher cost to avoid technical debt? Question 2: What will break when I migrate? What works on VPS but fails in cloud? What assumptions won't hold? Question 3: How do I validate before cutting over? Parallel infrastructure? Gradual traffic shift? Safe patterns? Question 4: Cost optimization from day one? What to optimize immediately vs later? Common cost mistakes? Question 5: DevOps practices that transfer? What stays the same? What needs rethinking for cloud-native? THE BIGGER QUESTION Have you migrated from self-hosted to Azure? What surprised you? I know my setup isn't best practice by Azure standards. But it's working, and I've learned optimization, monitoring, and DevOps fundamentals in practice. Will those lessons transfer? Or am I building habits that cloud will expose as problematic? Looking forward to insights from folks who've made similar migrations. --- About the Author: Microsoft Certified DevOps Engineer and Azure Developer. CTO at social commerce platform scaling in West Africa. Preparing for phased Azure migration in 2026. P.S. I got the Azure certifications to prepare for this migration. Now I need real-world wisdom from people who've actually done it!
