AWS Builder Center

Builder Center

AWS Architecture Health Check: 10 Things to Review Before Production

AWS Architecture Health Check: 10 Things to Review Before Production

A practical guide to reviewing AWS workloads before production, covering security, reliability, scalability, monitoring, cost optimization, data protection, and disaster recovery.

AWS Architecture Health Check: 10 Things to Review Before Production

Deploying a workload on AWS is only the beginning. An application can work correctly in development and still have problems with security, reliability, scalability, monitoring, or cost when it moves into production.
A production-ready workload needs more than functioning code. It needs an architecture that can handle expected demand, recover from failures, protect data, provide visibility into its behavior, and operate efficiently.
The AWS Well-Architected Framework provides a structured way to evaluate these areas through six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. (AWS Documentation )
This article presents a practical 10-point health check that can be used when reviewing an AWS workload before production.

1. Review Identity and Access Management

Start with one of the most important questions:
Who can access this workload, and what are they allowed to do?
AWS Identity and Access Management (IAM) should follow the principle of least privilege. This means granting only the permissions required to perform a specific task, without unnecessary additional permissions. (AWS Documentation )
For example, if an application only needs to read objects from a particular S3 bucket, it should not automatically have permission to delete objects or access unrelated AWS resources.

Check the following:

  • Are permissions limited to what is actually required?
  • Are IAM roles being used for workloads where appropriate?
  • Are unused permissions removed?
  • Are access credentials handled securely?
  • Is MFA enabled for appropriate identities?
A useful way to think about permissions is:
1
2
3
4
5
6
7
Identity
↓
Required action
↓
Specific resource
↓
Required permission
Avoid giving broad permissions simply because they are convenient during development.

2. Protect the AWS Root User

The AWS account root user has extensive privileges and should not be used for everyday AWS operations.
AWS recommends protecting the root credentials, enabling MFA, avoiding root access keys, and using another identity for regular administrative activities. (AWS Documentation )
Before production, verify that:
  • The root credentials are securely protected.
  • MFA is enabled.
  • Root access keys are not being used.
  • Everyday administrative operations are performed through appropriate identities.
  • Access to account recovery mechanisms is controlled.
The root user should be treated as a highly privileged account rather than a normal administrative login.

3. Identify Single Points of Failure

Ask:
What happens if one component stops working?
Consider a simple architecture:
1
2
3
4
5
User
↓
Application Server
↓
Database
If the only application server fails, the entire application could become unavailable.
Depending on the workload's requirements, a more resilient architecture might distribute components across multiple resources or Availability Zones.
Reliability in the AWS Well-Architected Framework focuses on ensuring that workloads can perform their intended functions and recover from infrastructure or service disruptions. (AWS Documentation )

Review:

  • What happens if an instance fails?
  • What happens if a service becomes unavailable?
  • Are backups configured?
  • Can critical components recover from failure?
  • Are dependencies understood?
The objective is not to assume that failures will never happen.
It is to design the workload so that failures can be detected and handled.

4. Understand How the Workload Scales

A workload that performs well under normal traffic may behave very differently when demand increases.
Before production, understand the expected workload pattern:
1
2
3
4
5
6
7
Normal traffic
↓
Peak traffic
↓
Resource requirements
↓
Scaling strategy
Consider:
  • Can compute capacity scale when demand increases?
  • What happens during sudden traffic spikes?
  • Are application bottlenecks understood?
  • Can the database handle expected demand?
  • Are scaling limits known?
The AWS Well-Architected Framework emphasizes using cloud elasticity and monitoring to match resources to changing requirements. (AWS Documentation )
Scaling should be considered during architecture design, not only after performance problems appear.

5. Build Proper Monitoring and Observability

If something fails in production, how will you know?
Monitoring provides visibility into the behavior and health of a workload.
Amazon CloudWatch can be used to collect and monitor metrics, logs, and alarms across AWS resources and applications.
A simplified monitoring flow looks like this:
1
2
3
4
5
6
7
8
9
Application
↓
Metrics + Logs
↓
CloudWatch
↓
Alarms
↓
Investigation / Response
Depending on the workload, useful signals may include:
  • Request count
  • Error rate
  • Latency
  • CPU utilization
  • Database metrics
  • Application logs
  • Service-specific metrics
Monitoring should answer more than:
"Is the server running?"
It should help answer:
"Is the application behaving as expected?"

6. Review Your Logging Strategy

Logs are essential when investigating production problems, but simply generating large amounts of logs is not enough.
A useful logging strategy should help answer:
  • What happened?
  • When did it happen?
  • Which component was involved?
  • What request or operation caused it?
  • Was an error returned?
  • Can the event be correlated with related activity?
At the same time, avoid unnecessarily recording sensitive information.
Logs should not casually contain information such as:
1
2
3
4
Passwords
Secret keys
Access tokens
Private credentials
Good logging balances troubleshooting requirements with data protection.

7. Monitor and Optimize Costs

A technically successful workload can still be inefficient if resources are unnecessarily expensive.
Before production, understand what is running and how those resources contribute to your AWS bill.
Review:
  • Compute resources
  • Storage
  • Databases
  • Data transfer
  • Monitoring and logging
  • Development environments
  • Unused resources
A simple cost review can follow this process:
1
2
3
4
5
6
7
8
9
What am I running?
↓
How much is it being used?
↓
What does it cost?
↓
Is the resource still required?
↓
Can it be optimized?
AWS Budgets can be used to create cost or usage budgets and configure alerts based on actual or forecasted usage. (AWS Documentation )
Cost optimization should be treated as a continuous process rather than a final step before deployment.

8. Protect Data at Every Stage

Data protection should be considered throughout the data lifecycle.
Think about both data at rest and data in transit.

Data at rest

Consider data stored in:
  • Amazon S3
  • Databases
  • Backups
  • Persistent storage

Data in transit

Consider communication between:
1
2
3
4
5
User
↓
Application
↓
Database
Use appropriate encryption and access controls based on the workload and the sensitivity of the data.
Also review:
  • Who can access the data?
  • How long should it be retained?
  • Are backups protected?
  • Are unnecessary public access paths removed?
  • Are encryption and key-management requirements understood?
Security should be designed into the architecture rather than added after deployment.

9. Test Your Recovery Strategy

Having a backup does not automatically mean that you have a recovery strategy.
Ask:
If a critical resource or data is lost today, can the workload actually be restored?
A basic recovery process looks like:
1
2
3
4
5
6
7
8
9
10
11
Failure
↓
Detection
↓
Recovery Procedure
↓
Restore
↓
Validation
↓
Return to Service
Two important concepts are:

Recovery Time Objective (RTO)

How quickly should the workload be restored?

Recovery Point Objective (RPO)

How much data loss is acceptable?
For example:
1
2
RTO = 1 hour
RPO = 15 minutes
These values are not universal. They should be defined according to the requirements and impact of the specific workload.
Most importantly, recovery procedures should be tested, rather than existing only as documentation.

10. Review the Architecture as a Whole

The final step is to stop looking at individual AWS services and review the entire workload.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Users
│
▼
┌─────────────┐
│ Application │
└──────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Compute Database Storage
│ │ │
└─────────────┼─────────────┘
▼
Monitoring
│
▼
Alerts
Now evaluate the workload across the six Well-Architected pillars:
PillarKey question
Operational ExcellenceCan the workload be operated and improved effectively?
SecurityAre identities, systems, and data appropriately protected?
ReliabilityCan the workload recover from failures?
Performance EfficiencyAre resources being used efficiently?
Cost OptimizationAre resources providing appropriate value for their cost?
SustainabilityCan unnecessary resource consumption be reduced?
These six pillars form the foundation of the AWS Well-Architected Framework. (AWS Documentation )

A Practical Production Checklist

Before moving a workload into production, review the following:
AreaQuestion
🔐 IAMDoes every identity have only the permissions it needs?
🛡️ Root UserIs root access protected and avoided for everyday operations?
🌐 NetworkingAre unnecessary public access paths removed?
🔄 ReliabilityWhat happens when a component fails?
📈 ScalabilityCan the workload handle changing demand?
📊 MonitoringAre important metrics and logs being monitored?
🚨 AlertingWill the team know when something goes wrong?
💰 CostAre costs being monitored and unexpected spending detected?
🔒 Data ProtectionIs sensitive data appropriately protected?
💾 RecoveryCan the workload actually be restored after a failure?
This checklist is not a substitute for a full architecture review, but it provides a useful starting point for identifying common areas that deserve attention.

Don't Treat Architecture Review as a One-Time Activity

One of the biggest mistakes is reviewing an architecture only before the initial deployment.
Cloud workloads change continuously.
Teams may:
  • Add new AWS services
  • Change IAM permissions
  • Increase traffic
  • Introduce new databases
  • Store more data
  • Modify networking
  • Change deployment processes
  • Add new application features
Each change can introduce new architectural risks or create opportunities for improvement.
The AWS Well-Architected approach is intended to help teams continuously evaluate and improve their workloads rather than treating architecture review as a one-time exercise. (AWS Documentation )

Use the AWS Well-Architected Tool

AWS provides the AWS Well-Architected Tool to help review workloads against the Well-Architected Framework.
A Well-Architected Framework Review involves three broad phases:
1
2
3
4
5
Prepare
↓
Review
↓
Improve
During the review, you answer questions across the framework's pillars. The results can then be used to identify risks and create an improvement plan. (AWS Documentation )
The important part is what happens after the review: findings should be converted into concrete actions.
For example:
1
2
3
4
5
6
7
8
9
10
11
Finding
↓
Understand the impact
↓
Identify possible solutions
↓
Prioritize
↓
Implement
↓
Review again
This creates a continuous improvement cycle for the workload.

Final Thoughts

A workload being successfully deployed does not necessarily mean it is production-ready.
Before putting an AWS workload into production, ask:
Is it secure?
Can it recover from failure?
Can it handle changing demand?
Can we monitor it?
Can we control its costs?
Can we protect and recover its data?
These questions encourage a shift from simply building an application to engineering a reliable cloud workload.
The goal is not to use the maximum number of AWS services. It is to choose an architecture that matches the workload's requirements, understand the trade-offs involved, and continuously improve the system as those requirements change.
A strong AWS architecture is not defined by how many services it uses.
It is defined by how well it meets its requirements.

Official AWS References

# architecture# iam
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article