You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
An anti-pattern is a common approach that seems reasonable at first but leads to poor outcomes. Recognising anti-patterns is just as important as knowing best practices. This lesson covers the most common architectural mistakes teams make on Azure, mapped to the Well-Architected Framework pillars, along with the recommended alternatives.
The problem: Deploying critical components as a single instance with no redundancy. A single VM, a single database without failover, or a single-region deployment means any failure takes down the entire workload.
Why teams do this: It is simpler and cheaper to deploy a single instance. Redundancy adds complexity and cost.
The fix: Use Availability Zones for production workloads. Deploy zone-redundant services (Azure SQL, Storage with ZRS). For business-critical workloads, implement multi-region deployment with Traffic Manager or Front Door.
The problem: Treating all errors as permanent failures. In distributed systems, many failures are transient — temporary network blips, service throttling, brief DNS resolution issues. Without retry logic, the application fails on errors that would resolve themselves within seconds.
Why teams do this: Retry logic is not part of the core feature. It feels like an edge case.
The fix: Implement retries with exponential backoff for all calls to external services (databases, APIs, storage). Use the built-in retry policies in Azure SDKs. Add circuit breakers to prevent cascading failures.
The problem: Having no tested plan for recovering from a regional outage or data loss. Backups may exist, but they have never been restored. Failover has never been tested.
Why teams do this: Disaster recovery feels unlikely and testing is disruptive.
The fix: Define RTO and RPO targets. Configure Azure Backup and Azure Site Recovery. Test your recovery process regularly. An untested backup is not a backup — it is a hope.
The problem: Storing connection strings, API keys, and passwords in source code, configuration files, or environment variables. Secrets in code end up in version control, logs, and error messages.
Why teams do this: It is the fastest way to get something working in development.
The fix: Store all secrets in Azure Key Vault. Use managed identities to access Key Vault from your application. Never commit secrets to source control. Use tools like git-secrets or GitHub secret scanning to prevent accidental commits.
The problem: Granting Owner or Contributor roles at the subscription level when Reader or a custom role at the resource group level would suffice. Giving applications more permissions than they need.
Why teams do this: Broad permissions are easier to set up and avoid access-denied errors during development.
The fix: Follow the principle of least privilege. Assign the most restrictive role that meets the requirement, at the narrowest scope. Review access regularly. Use Privileged Identity Management (PIM) for just-in-time elevation of administrative access.
The problem: Deploying everything in a single subnet with no NSG rules. PaaS services accessible from the public internet when they only need to be accessed from within the VNet.
Why teams do this: Network configuration is complex and slows down development.
The fix: Segment your network into subnets by workload tier. Apply NSGs to restrict traffic between subnets. Use Private Endpoints for PaaS services. Use Azure Firewall for centralised traffic control.
The problem: Migrating on-premises VMs to Azure with the same specifications. On-premises servers are often over-provisioned because hardware procurement has long lead times. Moving that same over-provisioning to the cloud means paying for resources you do not need.
Why teams do this: It is the fastest way to migrate, and teams fear performance issues if they reduce capacity.
The fix: Analyse workload utilisation before migrating. Right-size VMs based on actual CPU, memory, and disk usage. Use Azure Migrate assessment tools to recommend appropriate Azure VM sizes. Re-assess after migration using Azure Advisor.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.