# Designing Solutions for New Workloads on AWS

> Chapter 15 of the Courseiva AWS-SAP-C02 curriculum — https://courseiva.com/learn/aws-sap-c02/designing-solutions-for-new-workloads

**Official objective:** 1.4 — Design new solutions that meet functional and non-functional requirements

## Introduction

If you design a new system on AWS without a structured approach, you will almost certainly build something that breaks under pressure, costs twice as much as it should, or cannot be fixed without a complete rebuild. Designing solutions for new workloads on AWS is the discipline of translating a business problem into a set of cloud services and configurations that meet explicit functional and non-functional requirements, before writing any code or provisioning any resource.

## The Custom Kitchen Architect Analogy

A professional kitchen architect is hired to design a brand-new restaurant kitchen from scratch. The restaurant has no existing equipment, no old plumbing, and no prior layout to work around. The architect starts by meeting the head chef to understand the menu: will they serve pizza from a wood-fired oven, delicate pastries from a proofing cabinet, or 200 covers of steak frites every night? Each menu item imposes functional requirements. The pizza oven needs a flue and a fireproof surround. The pastry station needs a refrigerated marble slab. The steak section needs a chargrill with an industrial extractor fan. The architect also captures non-functional requirements. The kitchen must operate safely, so there are fire suppression regulations. It must clean quickly between services, so surfaces are stainless steel with seamless corners. It must scale if the restaurant adds a second floor or starts catering events, so the architect specifies modular refrigeration units that can be expanded. Finally, the architect chooses every component: the exact brand of range cooker, the layout of the prep stations, the type of flooring, the position of sinks, and the capacity of the dishwasher. They produce a set of blueprints and a specification document before a single brick is laid. The restaurant owner then hands those blueprints to a contractor who builds the kitchen exactly as designed. No guesswork, no retrofitting, no tearing down walls six months later because the oven doesn't fit.

This is exactly what designing solutions for new workloads on AWS means. The IT professional is the kitchen architect. The workload is the restaurant menu. The functional requirements are the pizza and steak. The non-functional requirements are safety, cleanliness, and scalability. The AWS services are the range cookers and dishwashers. And the blueprints are the architecture diagram and infrastructure-as-code templates that get handed to the deployment pipeline.

## Core explanation

A workload is any collection of compute resources, storage, networking, and code that delivers a business outcome. Your e-commerce checkout page, your email notification service, your inventory management system are all workloads. When you design a new workload on AWS, you start with a blank sheet. There is no existing infrastructure to migrate. You have the freedom to choose the best services for the job, but that freedom also means you can make expensive mistakes if you skip the design process.

Functional requirements describe what a system must do. They are the features and behaviours the user or business needs. For example: 'The system must allow a customer to upload a profile photo'. 'The system must process a credit card payment within 2 seconds'. 'The system must send a confirmation email after booking'. These are binary pass/fail criteria. Either the system can do it or it cannot.

Non-functional requirements describe how a system must behave while it does those things. They are the quality attributes. Common categories include: availability (what percentage of time the system is operational), scalability (how well the system handles growth in users or data), performance (how fast responses are), security (how data is protected), cost (the operational budget), and maintainability (how easily developers can update the system). A common example: 'The system must be available 99.99% of the time'. That translates to roughly 53 minutes of downtime per year. To achieve that, you need a multi-Availability Zone (multi-AZ) deployment, which means running identical copies of your application in two or more physically separate data centres inside an AWS Region.

When you design a solution, you go through several phases. The first is requirement gathering. You interview stakeholders, read the business case, and write down every functional and non-functional requirement in a requirements document. You assign priority labels like 'must have', 'should have', and 'nice to have' using the MoSCoW method.

The second phase is architectural modelling. You decide on the overall pattern: will this be a monolithic application where all code runs in one process, or a microservices architecture where each business function runs as an independent service communicating over a network? You choose compute services. Amazon EC2 gives you virtual machines with full control over the operating system. AWS Lambda gives you serverless functions that run only when triggered, with no servers to manage. AWS Fargate runs containers without you managing the underlying hosts. You choose database services. Amazon RDS provides managed relational databases like PostgreSQL and MySQL. Amazon DynamoDB is a NoSQL key-value and document database designed for single-digit-millisecond latency at any scale. Amazon S3 stores objects like images, videos, and backups.

The third phase is sizing and scaling strategy. You estimate the expected load. How many users will access the system on day one? How many at peak after a marketing campaign? You decide whether to use vertical scaling (making a single server more powerful) or horizontal scaling (adding more servers and distributing traffic between them). AWS services like Auto Scaling can automatically increase or decrease the number of EC2 instances based on CPU utilisation or request count. Elastic Load Balancing (ELB) distributes incoming traffic across those instances.

The fourth phase is networking and security design. You design a Virtual Private Cloud (VPC) which is your isolated section of the AWS cloud. You define subnets to separate public-facing resources from private resources. You configure Security Groups which act as virtual firewalls for your instances. You set up Identity and Access Management (IAM) policies to control who can do what. You encrypt data at rest using services like AWS Key Management Service (KMS) and encrypt data in transit using TLS certificates.

The fifth phase is cost estimation. You use the AWS Pricing Calculator to estimate monthly costs for each service. You consider pricing models like On-Demand (pay per hour or second), Reserved Instances (pay upfront for a discount), and Savings Plans (commit to a consistent amount of compute usage for a lower rate). You also think about data transfer costs, storage costs, and request costs for serverless services.

The sixth phase is documentation and automation. You produce architecture diagrams using AWS Architecture Icons. You define your infrastructure in code using tools like AWS CloudFormation or Terraform. These templates describe every AWS resource and their configuration. When you run the template, AWS creates everything automatically. This is called infrastructure as code (IaC). It ensures the deployment is repeatable, testable, and version-controlled.

The seventh phase is validation. You build a proof of concept (PoC) or minimum viable product (MVP) to test that the design meets the requirements. You run load tests to verify performance and scalability. You test disaster recovery scenarios by simulating a failure in one Availability Zone to confirm the application continues running in another. You document any gaps or necessary changes.

The final phase is handover. You give the operational team the IaC templates, monitoring dashboards set up in Amazon CloudWatch, alerting rules, runbooks (step-by-step procedures for common tasks), and updated architecture diagrams. The team can then deploy the solution to production with confidence.

Designing solutions for new workloads replaces the old approach where a developer would just start writing code on a server, add features one by one, and only think about scalability or security after something broke. That approach, often called 'cowboy coding' or 'fire and forget', leads to fragile systems, high technical debt, and unexpected bills. By contrast, the structured design process produces robust, cost-effective, and maintainable systems from the start.

## Real-world context

A mid-sized retail company called 'FreshCart' decides to launch an online grocery delivery service. They have no existing cloud infrastructure. The business goal is to allow customers in three cities to order groceries online and receive them within two hours. The company hires a Solutions Architect to design the system on AWS.

The architect holds a kick-off meeting with the CEO, the head of logistics, the marketing lead, and a developer. They gather functional requirements:
- Customers must be able to browse products by category and search by name.
- Customers must add items to a cart and check out with credit card or digital wallet.
- The system must send an SMS to the customer when the order is out for delivery.
- Drivers must have a mobile app showing the route and order details.

Non-functional requirements are also captured:
- Availability: The website must be up 99.95% of the time.
- Scalability: The system should handle 10x the normal load during a promotional event.
- Performance: The checkout page must load in under 2 seconds.
- Security: Customer payment data must be encrypted.
- Cost: The total monthly bill must stay under $5,000 for the first six months.

The architect now works through the design phases.

For compute, they consider the website and the mobile app backend. They choose AWS Lambda for the backend API because the workload is unpredictable. During a flash sale, traffic spikes for an hour and then drops. Lambda scales instantly and charges only per request. They choose Amazon API Gateway to create a RESTful API that fronts the Lambda functions. For the database, they pick Amazon DynamoDB because it can handle millions of requests per second with consistent single-digit-millisecond latency. They design one table for product catalogue, one for customer profiles, and one for orders. For product images, they use Amazon S3 with a CloudFront content delivery network (CDN) to serve images quickly to users across the three cities.

For networking, they create a VPC with two public subnets for the API Gateway and two private subnets for the Lambda functions. They configure Security Groups to allow only HTTPS traffic from the internet to the API Gateway. For authentication, they use Amazon Cognito so customers can sign in with email or social media accounts.

For scalability, they enable DynamoDB auto-scaling and Lambda reserved concurrency to prevent a runaway function from exhausting service quotas. They set up an Auto Scaling group for any backend tasks that run on EC2, like generating nightly reports. For the SMS notifications, they use Amazon Simple Notification Service (SNS) which handles message delivery to phone carriers. For the driver app, they use AWS AppSync to provide a real-time GraphQL API that pushes location updates.

For cost estimation, the architect uses the AWS Pricing Calculator. The Lambda functions with 1 million requests per month cost about $15. DynamoDB with 25 GB of storage and provisioned capacity costs about $75. S3 with 100 GB of storage and CloudFront with 1 TB of data transfer costs about $100. SNS for 100,000 SMS messages costs about $70. The total comes to around $350 per month, well under the $5,000 budget.

The architect documents the design in an architecture diagram and writes a CloudFormation template that defines every resource. They share the template with the developer, who uses it to deploy a test environment. The team runs load tests using AWS Distributed Load Testing, simulating 10,000 concurrent users. The checkout page still loads in 1.8 seconds. They simulate a single-AZ failure by disabling one subnet. DynamoDB continues serving because it is multi-AZ by default. Lambda functions re-run in the remaining subnets. Availability stays at 100% in the test.

After two weeks of validation, the team deploys to production. The website goes live at 8am on a Monday. Within the first hour, 500 orders are placed. The system handles it without breaking. The Operations team monitors CloudWatch dashboards for error rates and latency. The project is deemed a success.

## Exam focus

The SAP-C02 exam tests your ability to design solutions for new workloads across several question types. You will see multiple-choice questions where you must select the best combination of AWS services to meet a set of requirements. You will also see scenario-based questions that describe a business problem and ask you to choose the correct architecture.

Key concepts that appear frequently:
- Requirement analysis: The exam loves giving you a list of functional and non-functional requirements and expecting you to identify which ones are most critical. For example, they will say 'The system must process sensor data from 10,000 IoT devices in real time with sub-second latency and must be able to replay raw data for 90 days for compliance audits'. You must choose between a streaming pipeline with Amazon Kinesis Data Streams and Amazon Kinesis Data Firehose versus a batch solution with Amazon S3 and Amazon Athena. The correct answer is usually Kinesis Data Streams for real-time processing, lambda for transformation, and S3 for long-term storage.

- Trade-off analysis: Many questions force you to pick between two good options by comparing cost, complexity, and maintenance. They might ask whether to use Amazon RDS Multi-AZ or Amazon Aurora Global Database for cross-Region disaster recovery. Aurora Global Database has lower recovery time but higher cost. The trap is that candidates often pick the technically superior option without considering the cost requirement.

- Serverless vs. container vs. EC2: The exam tests your judgement on which compute service to use. Serverless (Lambda) is best for event-driven, short-running, variable workloads. Containers on ECS or EKS are best for consistent workloads with portability requirements. EC2 is best when you need full OS control, specific licensing, or very long-running processes. A common trap question describes a workload that needs GPU processing for machine learning and lists EC2 P3 instances as an option, but also offers SageMaker. SageMaker is almost always the better choice for machine learning because it manages the infrastructure and integrates with other AWS services.

- Database selection: The exam frequently presents a scenario with specific data access patterns. If the pattern requires complex joins and transactions, the answer is a relational database like Amazon RDS or Amazon Aurora. If the pattern is key-value lookups with high throughput, the answer is Amazon DynamoDB. If the data is analytical and read-heavy with columnar storage, the answer is Amazon Redshift. A common trap is suggesting a relational database for a high-throughput key-value workload.

- Networking design: Questions test your understanding of public vs. private subnets, NAT Gateways, VPC endpoints, and Security Groups. A typical question asks you to design a VPC so that an EC2 instance in a private subnet can download software updates. The correct answer is a NAT Gateway in a public subnet with a route table pointing the private subnet's traffic to the NAT Gateway. A trap is suggesting a VPC endpoint for S3, which is for accessing S3 from a private subnet without internet access, but the question asks about general internet access, not just S3.

- High availability and disaster recovery: You must know the difference between Multi-AZ (within one Region) and Multi-Region. The exam likes to ask about Recovery Point Objective (RPO) and Recovery Time Objective (RTO). RPO is how much data you can afford to lose measured in time. RTO is how quickly you must recover. For a new workload, you typically design for Multi-AZ from the start. A trap question might ask you to use Multi-Region replication for a workload that only requires 99.9% availability, which is achievable with Multi-AZ alone.

- Cost optimisation: The exam tests your knowledge of pricing models. Reserved Instances are for predictable, steady-state workloads. Spot Instances are for fault-tolerant, flexible workloads. Savings Plans provide flexibility across EC2, Lambda, and Fargate. A common trap is suggesting On-Demand for a predictable workload when Reserved Instances would save 40-60%.

- Infrastructure as code: You need to understand that AWS CloudFormation, AWS CDK, and Terraform are all IaC tools. The exam does not test command syntax, but it tests the concept that IaC ensures repeatable deployments, version control, and the ability to replicate environments. A question might ask 'A company wants to deploy identical production and staging environments with minimal manual effort.' The best answer is 'Use CloudFormation stacks deployed from a single template with different parameter files for each environment.'

- Security: Questions often require you to design least-privilege IAM policies. A trap is giving a role full access to all S3 buckets when the workload only needs to write logs to one specific bucket. The correct answer is a policy with a resource ARN scoped to that bucket.

## Step by step

1. **Gather and document requirements** — Meet stakeholders to capture all functional features and non-functional quality attributes. Write them in a document with priority labels. Without this step, you will build the wrong thing or miss critical constraints like budget or latency.
2. **Choose compute and storage services** — Select the appropriate AWS services for running code and storing data. For compute, decide between EC2, Lambda, or ECS/Fargate based on workload characteristics. For storage, choose between RDS, DynamoDB, S3, or Redshift based on data structure and access patterns. This step directly determines scalability, cost, and maintenance effort.
3. **Design networking and security** — Create a VPC with public and private subnets. Define Security Groups, NACLs, and IAM policies. Set up encryption at rest and in transit. This step ensures the system is secure and isolated. A mistake here, like exposing a database to the internet, can cause a data breach.
4. **Plan scaling and high availability** — Configure Auto Scaling groups, multi-AZ deployments, and load balancers. Define scaling policies based on CloudWatch metrics. This step ensures the system can handle traffic spikes and survive infrastructure failures without manual intervention.
5. **Estimate costs and optimise** — Use the AWS Pricing Calculator to project monthly costs. Compare On-Demand, Reserved Instances, and Savings Plans. Identify cost-saving opportunities like S3 lifecycle policies or Spot Instances for non-critical tasks. This step prevents billing surprises.
6. **Document and automate deployment** — Write infrastructure as code templates in CloudFormation or CDK. Create architecture diagrams with AWS icons. Produce runbooks for operations. This step ensures the design can be deployed reliably and passed to the operations team.
7. **Validate with a proof of concept** — Deploy a test environment from your IaC templates. Run load tests, failure simulations, and security scans. Compare actual performance against requirements. This step catches design flaws before production, saving money and reputation.

## Comparisons

### Functional Requirements vs Non-Functional Requirements

**Functional Requirements:**
- Describe what the system does.
- Are binary: the feature either exists or not.
- Examples: 'user can upload a photo', 'system sends email receipt'.

**Non-Functional Requirements:**
- Describe how the system behaves.
- Are measured on a scale: latency, uptime, cost.
- Examples: 'upload must complete in 2 seconds', 'system must be 99.95% available'.

### EC2 (Virtual Machines) vs Lambda (Serverless Functions)

**EC2 (Virtual Machines):**
- You manage the OS and runtime environment.
- Billed per hour or second even when idle.
- Best for long-running, predictable workloads.

**Lambda (Serverless Functions):**
- AWS manages the OS and runtime entirely.
- Billed per millisecond only when code executes.
- Best for event-driven, short-running, variable workloads.

### Amazon RDS (Relational Database) vs Amazon DynamoDB (NoSQL Database)

**Amazon RDS (Relational Database):**
- Supports SQL, complex joins, and transactions.
- Vertically scaled by increasing instance size.
- Best for structured data with predictable access patterns.

**Amazon DynamoDB (NoSQL Database):**
- Key-value and document store, no joins.
- Horizontally scaled automatically with no downtime.
- Best for high-throughput, low-latency, key-value lookups.

### Reserved Instances vs On-Demand Instances

**Reserved Instances:**
- Require a 1-year or 3-year commitment.
- Offer significant discounts (up to 72%).
- Best for steady-state, predictable workloads.

**On-Demand Instances:**
- No commitment, pay per hour or second.
- More expensive per unit of compute.
- Best for short-term, experimental, or variable workloads.

## Diagram

_The step-by-step workflow for designing a new workload on AWS, from requirement gathering through to production deployment._

```mermaid
flowchart TD
    A[New Workload Requirements] --> B[Gather Functional & Non-Functional Requirements]
    B --> C[Choose Compute: EC2, Lambda, ECS]
    B --> D[Choose Database: RDS, DynamoDB, S3]
    C --> E[Design VPC Networking & Security]
    D --> E
    E --> F[Configure Scaling & High Availability]
    F --> G[Estimate Costs & Optimise]
    G --> H[Write Infrastructure as Code]
    H --> I[Deploy Proof of Concept]
    I --> J[Validate & Hand Over]
    J --> K[Production Deployment]
```

## Common misconceptions

- **Misconception:** You should always choose the newest or most complex AWS service for a new workload because it is more advanced. **Reality:** You should choose the simplest service that meets the requirements. Overcomplicating a design increases cost, maintenance burden, and the risk of misconfiguration. (Beginners often think that using the latest service demonstrates skill, but the exam rewards pragmatic, cost-effective solutions.)
- **Misconception:** Non-functional requirements like scalability and availability can be added later after the system is built. **Reality:** Non-functional requirements must be designed into the architecture from the start. Retrofitting high availability or auto-scaling after the system is live often requires a full re-architecture. (This misconception stems from on-premises thinking where you could upgrade hardware later. In the cloud, architectural choices like using DynamoDB vs. RDS determine scalability from day one.)
- **Misconception:** If you use AWS Lambda, you do not need to think about scaling at all because it scales automatically without limits. **Reality:** Lambda scales automatically, but there are service quotas like 1,000 concurrent executions per Region by default. You must request increases for high-throughput workloads. Also, downstream resources like databases can be overwhelmed if Lambda scales without limits. (Marketing materials emphasise Lambda's auto-scaling, but the exam tests real-world constraints that new designers miss.)
- **Misconception:** Designing a new workload means you can ignore existing AWS accounts and organisational policies because you are starting fresh. **Reality:** New workloads must still comply with existing organisational guardrails like Service Control Policies (SCPs), tagging standards, and security baselines defined in AWS Organizations. You cannot bypass these just because it is a new project. (Beginners think 'new' means total freedom, but in enterprise contexts, governance applies to everything.)

## Key takeaways

- Functional requirements define what the system does; non-functional requirements define how well it does it.
- Always capture non-functional requirements like availability, scalability, performance, and cost before choosing any AWS service.
- Simple architectures are nearly always better than complex ones because they are easier to maintain, cheaper, and less error-prone.
- Infrastructure as code with CloudFormation or Terraform ensures your design is repeatable and version-controlled.
- Serverless services like Lambda and DynamoDB scale automatically but have service quotas and downstream limits you must account for.
- Multi-AZ deployment is the minimum standard for production workloads on AWS to achieve high availability.
- Cost estimation must be part of the design phase, not an afterthought, to avoid budget overruns.

## FAQ

**What is the difference between functional and non-functional requirements in AWS design?**

Functional requirements describe specific features the system must perform, like 'process a payment'. Non-functional requirements describe quality attributes, like 'the payment must be processed in under 1 second' or 'the system must be available 99.99% of the time'.

**Do I need to design for scalability even if the workload is new and has no users?**

Yes. Design for scalability from the start because it is much harder to add later. Many services like DynamoDB and Lambda can be configured with auto-scaling at no extra cost, so there is no reason to avoid it.

**How do I decide between EC2, Lambda, and ECS for a new workload?**

Use EC2 when you need full OS control, specific software installs, or long-running processes. Use Lambda for event-driven, short-running, variable workloads. Use ECS/Fargate for containerised applications that need portability and consistent resource usage.

**What is infrastructure as code and why is it important for new workloads?**

Infrastructure as code is a practice where you define AWS resources in text files (like CloudFormation templates). It is important because it makes deployments repeatable, version-controllable, and auditable, reducing human error.

**What should I do first when designing a new workload on AWS?**

Start by gathering and documenting all functional and non-functional requirements from stakeholders. Without clear requirements, you cannot make correct decisions about compute, storage, networking, or cost.

**How do I estimate costs for a new workload before building it?**

Use the AWS Pricing Calculator. You select each service you plan to use, enter expected usage quantities (GB of storage, number of requests, data transfer), and the tool estimates monthly costs.

## Check your understanding

1. **What is the primary difference between a functional requirement and a non-functional requirement when designing a new AWS workload?**

   Answer: A functional requirement describes what the system must do (e.g., process a payment), while a non-functional requirement describes how the system must behave (e.g., process the payment in under 1 second).

2. **A startup wants to build a real-time chat application that handles unpredictable traffic spikes. Which compute service is most cost-effective and scalable for processing chat messages?**

   Answer: AWS Lambda, because it scales automatically per request and charges only when message processing occurs, making it ideal for variable, event-driven workloads.

3. **A company needs a database with strong consistency and support for complex joins to store financial transactions. Which database service should they choose?**

   Answer: Amazon RDS or Amazon Aurora, because they are relational databases that support SQL, joins, and ACID transactions.

4. **What does 'Multi-AZ deployment' achieve for a new workload on AWS?**

   Answer: It provides high availability by running identical copies of the workload in two or more physically separate data centres (Availability Zones) so that if one fails, the other continues serving traffic.

5. **Why should infrastructure as code be part of the design for a new workload?**

   Answer: It ensures that deployments are repeatable, version-controlled, and auditable, reducing human error and making it easy to replicate environments for testing or disaster recovery.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sap-c02/designing-solutions-for-new-workloads