AWS Well-Architected Basics: Reliability, Cost and Security

The AWS Well-Architected Framework provides a structured way to evaluate cloud workloads and make informed design decisions. It does not prescribe one architecture for every application; instead, it uses design principles and review questions to identify risks and possible improvements.

This guide focuses on three areas that commonly affect one another: reliability, cost optimization and security. The objective is to understand what each decision improves, what it costs and which new risks it may introduce.

What is the AWS Well-Architected Framework?

The AWS Well-Architected Framework is a set of architectural principles, questions and recommended practices for designing and operating workloads on AWS. Teams use it to review an existing system, identify high-risk decisions and plan improvements based on business requirements.

The framework contains six pillars:

AWS also provides the AWS Well-Architected Tool. It records workload information, presents review questions and creates milestones that capture the workload's state at a point in time.

A review is not a pass-or-fail certification. It is a risk discussion supported by evidence such as architecture diagrams, recovery tests, monitoring data, access policies and cost reports.

Why do reliability, cost and security create trade-offs?

Reliability, cost and security often depend on additional resources, controls or operational work. For example, a second application instance improves availability but adds compute cost, while extensive log retention improves investigation capability but increases storage and analysis charges.

A trade-off does not mean removing essential security or recovery controls to save money. It means selecting controls that match the workload's business impact, data sensitivity, recovery objectives and usage pattern.

Before selecting an architecture, define requirements rather than starting with AWS services. Important requirements include expected traffic, acceptable downtime, recovery time objective (RTO), recovery point objective (RPO), compliance obligations and budget boundaries.

How should reliability be designed?

Reliable AWS workloads anticipate component failure, replace unhealthy capacity automatically and recover data through tested procedures. Multi-AZ deployment is useful, but it must be combined with health checks, scaling, backups, monitoring and operational testing.

Define RTO and RPO first

RTO is the maximum acceptable time required to restore a service. RPO is the maximum acceptable amount of data loss measured in time.

For example, an application might have an RTO of one hour and an RPO of 15 minutes. These values influence backup frequency, replication, automation and whether a second Region is justified.

Diagram in words: a reliable web application

Imagine the architecture from left to right:

1. Users resolve the application name through Amazon Route 53.
2. An Application Load Balancer has enabled subnets in two Availability Zones.
3. An Auto Scaling group runs EC2 application instances in private subnets across those AZs.
4. The load balancer sends traffic only to healthy targets.
5. Amazon RDS uses a Multi-AZ deployment for database availability.
6. Automated backups support point-in-time recovery within the configured retention period.
7. Amazon CloudWatch alarms notify operators about unhealthy targets, errors and resource pressure.

An RDS Multi-AZ standby is primarily for availability and failover; it should not be treated as a normal read-scaling instance. Read replicas serve a different purpose.

Reliability controls to validate

• Remove hard-coded dependency on one instance or IP address.
• Use Auto Scaling health checks and suitable minimum capacity.
• Store application state outside replaceable EC2 instances.
• Test backup restoration instead of checking only whether backups exist.
• Use infrastructure as code to rebuild resources consistently.
• Set timeouts, retries and backoff without creating retry storms.
• Monitor dependencies such as databases, queues and external APIs.

Students who want guided practice with these architecture decisions can review the AWS Solutions Architect course.

How can cost be reduced without weakening reliability?

Cost optimization should remove waste before removing resilience. Start with idle resources, oversized capacity, unnecessary data transfer and unsuitable pricing models; then confirm that each change still meets performance and recovery requirements.

Consider an application with two EC2 instances running continuously. Reducing it to one instance may cut compute usage, but it also creates a single point of failure. A better approach may be two smaller instances across two AZs with target-tracking scaling, provided load testing confirms sufficient capacity.

Practical cost controls

Use Cost Explorer to inspect service-level spending. The following example retrieves daily unblended cost grouped by AWS service:

aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-08 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

The end date is exclusive. Review the returned Groups for services with unexpected changes, and then investigate resources, traffic or retention settings behind the increase.

Do not right-size from average CPU alone. An EC2 instance may have low CPU but require memory, disk throughput or network capacity that is not visible in the basic CPU metric.

How should security influence architecture decisions?

Security should be built into identity, network, data and monitoring layers rather than added after deployment. The correct level of control depends on risk, but foundational practices such as least privilege, encryption, patching and audit logging should not be discarded only to reduce cost.

AWS uses a shared responsibility model. AWS secures the underlying cloud infrastructure, while customers remain responsible for areas such as IAM permissions, guest operating systems, application code, data classification and many network configurations.

Diagram in words: layered security

Read this design from the internet towards the database:

1. Route 53 directs users to an Application Load Balancer using HTTPS.
2. AWS Certificate Manager supplies the TLS certificate.
3. AWS WAF can inspect HTTP requests when the application's risk justifies it.
4. The load balancer security group permits inbound HTTPS from approved sources or the internet, depending on the service.
5. The application security group permits traffic only from the load balancer security group.
6. The database security group permits the database port only from the application security group.
7. EC2 instances use an IAM role instead of stored access keys.
8. Secrets Manager stores database credentials, while AWS KMS protects supported encrypted data.
9. CloudTrail, CloudWatch and relevant service logs provide audit and operational evidence.

This design reduces direct exposure, but every control must be tested. A restrictive security group that blocks the health-check port can make all load balancer targets unhealthy.

For broader defensive monitoring and incident-response skills, see the Cybersecurity and SOC course.

Security controls that also affect cost

Security services and logs consume resources, so their configuration needs clear retention and response policies. For example, retaining every verbose application log indefinitely is rarely useful. A better design separates audit, security, access and debug logs, then assigns retention according to legal and operational requirements.

Use Amazon S3 lifecycle policies where appropriate, encrypt retained data and restrict deletion rights. Sending alerts without defining ownership also creates cost without improving response.

What does a balanced architecture look like?

A balanced architecture satisfies explicit business requirements with the simplest design that manages known failure and security risks. It avoids both under-engineering, such as one unbacked-up server, and unnecessary complexity, such as a multi-Region active-active design for a low-impact internal tool.

Consider a small production booking application currently running on one public EC2 instance with a database installed locally.

Initial risks

• The instance is a single point of failure.
• Application and database failures affect the same server.
• Direct internet exposure increases attack surface.
• Manual recovery makes RTO uncertain.
• Vertical scaling may produce unused capacity.

Reasonable improvement plan

1. Place an Application Load Balancer in public subnets across two AZs.
2. Run replaceable application instances through an Auto Scaling group in private subnets.
3. Move relational data to Amazon RDS and enable automated backups.
4. Select Multi-AZ only if the required availability justifies its additional cost.
5. Use IAM roles, Secrets Manager and narrowly scoped security groups.
6. Add alarms for target health, application errors, database capacity and billing signals.
7. Test instance replacement and database restoration.
8. Review utilisation after collecting representative workload data.

Automation improves consistency, but it must be controlled with code review, deployment checks and rollback procedures. The AWS DevOps course covers the operational side of repeatable cloud delivery.

How can the AWS Well-Architected Tool be checked from the CLI?

The AWS CLI can list workloads and retrieve pillar answers from the Well-Architected Tool. This is useful for reporting and review automation, but it does not replace discussions with application, security, finance and operations teams.

List workloads in a Region:

aws wellarchitected list-workloads --region ap-south-1

Retrieve reliability answers for a workload:

aws wellarchitected list-answers \
  --workload-id WORKLOAD_ID \
  --lens-alias wellarchitected \
  --pillar-id reliability \
  --region ap-south-1

The output includes questions, selected choices and risk information. If no workloads appear, confirm the Region, IAM permissions and AWS account being used.

How do you troubleshoot a Well-Architected workload?

Troubleshooting should move from the user-visible symptom to health checks, dependencies, recent changes and logs. Avoid changing several components at once because that makes the actual cause difficult to confirm.

Scenario 1: the load balancer returns HTTP 503

An Application Load Balancer commonly returns 503 when it has no healthy registered targets.

aws elbv2 describe-target-health \
  --target-group-arn TARGET_GROUP_ARN

Check the TargetHealth.State and Reason fields. If targets are unhealthy, verify:

1. The application listens on the target group's configured port.
2. The health-check path returns an accepted status code.
3. The instance security group allows traffic from the load balancer security group.
4. Network ACLs permit the request and response traffic.
5. The application starts successfully after instance replacement.

Scenario 2: Multi-AZ is expected but not enabled

aws rds describe-db-instances \
  --db-instance-identifier booking-db \
  --query 'DBInstances[0].{Status:DBInstanceStatus,MultiAZ:MultiAZ,AZ:AvailabilityZone}'

If MultiAZ is false, compare the actual configuration with the approved architecture. Do not enable it without checking cost, maintenance impact and the workload's availability requirement.

Scenario 3: a security group changed unexpectedly

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
  --max-results 20

Review the event identity, time and request parameters. Then remove unauthorised access, investigate the principal involved and correct the deployment process or IAM permissions that allowed the change.

For a deeper explanation of alarms, logs and dashboards, read AWS CloudWatch metrics, logs, alarms and dashboards.

Short summary

The AWS Well-Architected Framework helps teams evaluate architecture through six connected pillars. For reliability, cost and security, the best decision is based on measurable requirements rather than automatically choosing the cheapest or most complex design.

Define RTO, RPO, security obligations and budget boundaries. Build for replacement and recovery, remove verified waste, enforce least privilege, retain useful evidence and test the procedures on which the architecture depends.

*Reviewed by Network Rhinos AWS and cloud trainers.*

To practise Well-Architected reviews, Multi-AZ designs, IAM, monitoring and cost-aware AWS architecture, enquire about upcoming batch details for the AWS Solutions Architect course.

Related reading: Docker Compose vs Kubernetes: When to Use Which