Determining the appropriate placement of resources to meet business requirements

Task Statement 3.4: Determine high-performing and/or scalable network architectures.

In AWS, “resources” can be:

“Placement” refers to where you put these resources so they perform well, are secure, and can scale as the business needs grow.

It’s like designing a digital office: you want your servers, databases, and applications in the right “rooms” so they can work efficiently together.

When deciding where to place resources in AWS, consider:

Resources should be placed to minimize downtime.
Use Multiple Availability Zones (AZs) within a region:
- Example: For EC2 web servers, deploy them in at least 2 AZs behind an Application Load Balancer (ALB).
- If one AZ fails, traffic goes to the other AZ.

Resources should be close to the users or other services they interact with.
Example:
- Place a database (RDS) in the same AZ as your EC2 application servers to reduce latency.
- Use Edge services like CloudFront to cache content closer to users globally.

Some workloads require private placement: not directly exposed to the internet.
Example:
- Place databases in private subnets with no direct internet access.
- Only allow access via application servers in public subnets.

Resource placement affects data transfer costs.
Example:
- Placing EC2 instances in one AZ and S3 in another may increase cross-AZ data transfer costs.
- Keep high-traffic components in the same AZ to save money.

Think about growth in traffic or workload.
Example:
- Launch EC2 Auto Scaling groups in multiple AZs to handle spikes automatically.
- Place read replicas of RDS in different AZs or regions to scale reads.

Here’s how AWS resources are typically placed:

Public-facing apps: Put in public subnets, behind ALB/NLB.
Back-end apps: Put in private subnets with security groups controlling access.
Use Auto Scaling groups for scaling across AZs.

RDS:
- Place in private subnets.
- Use Multi-AZ deployment for high availability.
- Use read replicas for scaling read-heavy workloads.
DynamoDB:
- Fully managed, globally replicated option available (Global Tables) to place data near users.

S3 buckets:
- Accessible globally via region selection.
- Enable S3 Cross-Region Replication for disaster recovery.
EBS volumes:
- Must be in same AZ as the EC2 instance they are attached to.
EFS:
- Can be mounted across multiple AZs for shared access.

VPC Subnets:
- Public subnet → Internet-facing resources (ALB, NAT gateway).
- Private subnet → Internal apps, databases, backend services.
Route 53 / Global Accelerator:
- Place resources in regions closest to users for lower latency.
- Can failover to other regions for high availability.

CloudFront caches content at edge locations, reducing load on origin resources and improving global performance.
AWS Global Accelerator directs traffic to the optimal endpoint based on health and geography.

Identify resource type: Compute, Database, Storage, or Networking.
Determine workload requirements:
- High availability needed? → Multi-AZ
- High performance needed? → Same AZ or region placement
- Global access? → Edge caching or replication
Security requirements:
- Internet-facing? → Public subnet
- Private? → Private subnet, VPN, or Direct Connect
Scalability considerations:
- Auto Scaling for EC2/ECS
- Read replicas for databases
- Caching for heavy read workloads
Cost impact:
- Cross-AZ and cross-region traffic
- Storage and backup strategies

Remember the subnet rule:
- Public subnet = route to Internet Gateway
- Private subnet = no direct Internet access (use NAT for outbound)
EC2 + EBS must be in same AZ.
Multi-AZ RDS = high availability; Read replicas = scaling reads.
Edge placement = CloudFront, Global Accelerator.
Always balance performance, cost, and security.

✅ Summary

Placing AWS resources correctly is about:

Proper resource placement ensures your network is high-performing, scalable, and secure—exactly what the SAA-C03 exam wants you to know.