Common Architecture Anti-Patterns

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. In cloud architecture, anti-patterns lead to workloads that are fragile, expensive, insecure, or difficult to operate. Understanding these anti-patterns — and knowing how to avoid them — is a critical skill for any cloud architect.

---

1. Single Availability Zone Deployment

The Anti-Pattern

Deploying all resources in a single Availability Zone (AZ). If that AZ experiences an outage, the entire workload goes down.

Why It Happens

• Teams want to keep things simple during initial development
• Cross-AZ data transfer costs are seen as unnecessary
• Developers are not aware of AZ-level failures

The Fix

Deploy across at least two Availability Zones. Use Elastic Load Balancing to distribute traffic and Auto Scaling to maintain capacity in each AZ. For databases, use Multi-AZ deployments in RDS or Aurora.

Component	Single-AZ (Anti-Pattern)	Multi-AZ (Best Practice)
Web servers	2 instances in one AZ	2+ instances across 2+ AZs
Database	Single RDS instance	RDS Multi-AZ or Aurora
Load balancer	No load balancer	ALB spanning multiple AZs

---

2. Hardcoded Credentials and Secrets

The Anti-Pattern

Embedding access keys, database passwords, or API tokens directly in application code or configuration files that are committed to version control.

Why It Happens

• Speed of development — hardcoding is the quickest path to a working prototype
• Lack of awareness of secrets management tools
• Legacy practices carried over from on-premises development

The Fix

Use AWS Secrets Manager or AWS Systems Manager Parameter Store to manage secrets. Grant your application access through IAM roles, which provide temporary credentials automatically.

# Anti-pattern: hardcoded credentials
db_password = "SuperSecret123!"

# Best practice: retrieve from Secrets Manager
import boto3
import json

client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/database/password')
db_password = json.loads(response['SecretString'])['password']

---

3. No Monitoring or Alerting

The Anti-Pattern

Deploying a workload without setting up metrics, logs, alarms, or dashboards. The team only discovers problems when users report them.

Why It Happens

• Monitoring is treated as a "nice to have" rather than a launch requirement
• Teams plan to add monitoring "later" but never do
• Lack of clarity on which metrics matter

The Fix

Define monitoring as part of your operational readiness criteria. At a minimum:

• Enable CloudWatch metrics for all services
• Set alarms for error rates, latency, CPU utilisation, and queue depth
• Centralise logs in CloudWatch Logs or OpenSearch
• Create dashboards for key operational and business metrics
• Use X-Ray for distributed tracing in microservices architectures

---

4. Over-Provisioned Resources

The Anti-Pattern

Running large instance types "just in case" — paying for capacity that is never used. A common example is running an r5.4xlarge instance when an r5.large would suffice.

Why It Happens

• Fear of performance issues
• No baseline measurements to guide sizing decisions
• Instances provisioned during a load spike and never downsized

The Fix

Start small and scale up based on data. Use AWS Compute Optimiser to get right-sizing recommendations. Monitor CPU, memory, and network utilisation with CloudWatch. Implement Auto Scaling to match capacity to demand dynamically.

---

5. Monolithic Deployments

The Anti-Pattern

Deploying the entire application as a single, tightly coupled unit. A change to any component requires redeploying the whole system, increasing risk and slowing down release cycles.

Why It Happens

• The application started as a monolith and was never decomposed
• Perceived complexity of microservices architecture
• Tight coupling in the codebase makes separation difficult

The Fix