The Four W's of an AWS Solution Architect

The first "W," What, focuses on understanding and defining the actual architecture solution you are designing. This stage is crucial as it involves making decisions on which services and components will be used, ensuring they align with the application’s specific requirements, and determining how those services will interact.

In the context of AWS, this typically involves identifying which of the following core elements will be used:

Services Selection

AWS offers a wide range of services, and the "What" phase primarily deals with choosing the right mix of these services to deliver a solution that meets the defined requirements.

• Compute Services: At the heart of most cloud solutions are compute services such as Amazon EC2 (Elastic Compute Cloud) or AWS Lambda for serverless computing. EC2 provides flexible, scalable virtual servers, while Lambda offers a fully-managed service for running code in response to events, without provisioning or managing servers.
• Storage Services: Depending on the application’s data needs, storage solutions could include Amazon S3 (Simple Storage Service) for object storage, Amazon EBS (Elastic Block Store) for block-level storage, or Amazon EFS (Elastic File System) for scalable file storage.
• Database Services: If the solution requires a database, AWS offers several choices, such as Amazon RDS (Relational Database Service) for traditional relational databases like MySQL and PostgreSQL, Amazon DynamoDB for NoSQL databases, or Amazon Redshift for data warehousing.
• Networking Services: For managing networks within the AWS cloud, services like Amazon VPC (Virtual Private Cloud) are used to create isolated networks, while Amazon CloudFront can provide content delivery network (CDN) services.
• Security Services: To ensure the system remains secure, services like AWS IAM (Identity and Access Management) are used to control access to AWS resources, while AWS WAF (Web Application Firewall) can help protect against common web exploits.

Application Components

The next part of the "What" phase is identifying and defining the components of the application architecture. This may include microservices, monolithic applications, event-driven architectures, or containerized applications. This will influence decisions such as:

• Amazon ECS (Elastic Container Service) or Amazon EKS (Elastic Kubernetes Service) for containerized workloads.
• Choosing between serverless architectures using AWS Lambda or traditional server-based architectures like EC2.

Scalability and Fault Tolerance

When defining "What" your solution is, it’s essential to ensure that it is designed for scalability and fault tolerance. AWS offers tools like Elastic Load Balancing (ELB), Auto Scaling, and Amazon Route 53 for high availability, making it easier to design solutions that can scale with traffic demands and automatically recover from failures.

Performance Requirements

One of the key decisions made during the "What" phase is whether to design the solution for performance over cost, or if the system can be optimized for lower costs while maintaining acceptable performance. AWS provides services like Amazon CloudWatch for monitoring and AWS X-Ray for tracing performance bottlenecks in applications.

The second "W" focuses on the Why. This phase is about justifying the architectural decisions made in the first phase and understanding the reasoning behind selecting specific AWS services and components. The Why answers the critical question of why this architecture was chosen and why it will fulfill both business and technical goals. Key considerations during this stage include:

Business Requirements

The primary consideration is how the chosen architecture aligns with the business goals. Does it provide the necessary features, performance, and scalability required by the business? For example, if your business application demands high availability, a multi-availability zone architecture might be necessary. Or if you're optimizing costs, services like AWS Spot Instances may be used to leverage unused EC2 capacity at a reduced cost.

Cost Efficiency

Another critical "Why" consideration is cost. AWS operates on a pay-as-you-go model, so understanding and justifying the costs is essential. The architect needs to make decisions on which services are more cost-effective based on the business's budget and usage patterns. Services like Amazon S3 and AWS Lambda are often selected for their lower operational costs, especially when compared to traditional infrastructure models.

Security and Compliance

Why are certain security protocols and best practices selected for the architecture? AWS provides several built-in tools such as AWS Shield (DDoS protection), AWS KMS (Key Management Service), and AWS Config (for auditing and compliance). Ensuring that the solution adheres to both organizational and regulatory requirements is a critical element of the Why phase. This includes selecting the right encryption methods, access controls, and compliance frameworks.

Reliability and Availability

AWS’s global network of data centers ensures high availability, but the choice of regions, availability zones, and replication strategies must be based on reliability needs. Choosing the right combination of services, such as Amazon S3 for data durability and Amazon RDS for database replication, reflects the "Why" of your solution: to deliver the highest reliability and minimize downtime.

Performance and Latency

The choice of regions and AWS services may also be influenced by the requirement for low latency. If your application serves users in specific geographic areas, choosing the closest AWS region, using Amazon CloudFront for content delivery, or designing for edge computing with AWS Greengrass may be the best approach to meet performance expectations.

The third "W" is about understanding When different components of the solution will be deployed, scaled, or updated. Timing is essential in cloud architecture because solutions may need to adapt dynamically based on traffic patterns, application load, or other triggers.

Deployment Lifecycle

The "When" phase includes defining the deployment pipeline. Using AWS CodePipeline and AWS CodeBuild, a solution can be deployed continuously with minimal downtime, ensuring that updates happen seamlessly. The architect must also decide whether the solution will use rolling updates, blue-green deployment strategies, or canary releases, depending on how critical uptime is.

Scaling

One of the essential aspects of cloud architecture is scaling. In the "When" phase, decisions are made about when to scale services based on traffic and load. For example, using AWS Auto Scaling, EC2 instances can be automatically added or removed as the load fluctuates. Amazon DynamoDB also offers automatic scaling of throughput capacity, ensuring that database performance is not affected during periods of high demand.

Cost Optimization Timing

To minimize costs, architects will decide when to apply various cost-saving strategies. For example, AWS allows for the use of Reserved Instances for services like EC2 or RDS, which can provide significant savings for long-term workloads. Conversely, AWS Lambda can be used for event-driven, short-lived processes, reducing the need for long-term instance management.

Security Updates

The "When" aspect also encompasses when to implement security patches, software updates, or hardware changes. AWS provides tools like AWS Systems Manager to automate patch management across instances, which is crucial for maintaining the security and integrity of cloud resources.

Disaster Recovery and Failover

For mission-critical applications, disaster recovery planning becomes an important aspect of the "When" phase. The architect must decide when to implement failover mechanisms and how quickly services should be restored in case of an outage. AWS offers Route 53 for DNS failover and AWS Elastic Load Balancer for automatic rerouting of traffic in case of instance failures.

The final "W" is the Where: defining the geographical location and architecture placement. This encompasses the choices made about which AWS regions and availability zones to deploy the solution in, as well as where certain services should reside to achieve the desired performance, compliance, and cost objectives.

AWS Regions and Availability Zones

AWS operates in a global network of regions, each consisting of multiple availability zones (AZs). The choice of where to deploy your application depends on factors like:

• Data Sovereignty: Certain countries require data to reside within their borders. AWS provides regions in specific countries to meet these compliance needs.
• Latency: To ensure low latency, services may need to be deployed closer to end-users. For example, if your application is mainly serving users in Europe, deploying in the EU (Ireland) region may provide the best performance.
• High Availability: To ensure fault tolerance, architects often choose to deploy in multiple availability zones or regions. For example, deploying your application across two AZs within the same region ensures that even if one zone experiences an outage, the other will continue serving requests.

Edge Locations and Content Delivery

In addition to AWS regions, architects must consider edge locations for content delivery. Amazon CloudFront can distribute static and dynamic content to users globally with low latency by caching it at edge locations close to viewers. When logic has to run near users, Lambda@Edge and CloudFront Functions execute code at those edge locations, and AWS Global Accelerator routes traffic over the AWS global network to the nearest healthy endpoint.

Hybrid and Specialised Locations

Not every workload can live entirely in a public AWS region. AWS Outposts brings AWS infrastructure and services into your own data centre for workloads that must stay on premises, AWS Local Zones place compute and storage close to large population and industry centres, and AWS Wavelength runs services inside 5G networks for applications that need single-digit-millisecond latency. Choosing among them is part of the "Where": it follows from data residency rules, latency targets and the systems the solution has to sit next to.

The Four W's are not separate checklists; each answer shapes the others. What you build determines the services you depend on, Why you build it that way justifies every trade-off between cost, security, reliability and performance, When things happen defines how the system deploys, scales, patches and recovers, and Where it runs decides latency, resilience and compliance.

Working through all four before the first resource is provisioned, and revisiting them as requirements change, gives you an architecture that meets today's business goals and can grow with them. The AWS Well-Architected Framework is a useful companion: its pillars (operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability) map naturally onto the questions the Four W's ask.

If you are planning a new AWS workload or reviewing an existing one, our team can help you work through the Four W's for your environment.