Best Practices

Best Practices for Building Solutions on AWS

Design Trade-offs

Tip

Core Principle: As you design a solution, think carefully about trade-offs so you can select an optimal approach.

Key Trade-off Examples

• Trade consistency, durability, and space for time and latency to deliver higher performance
• For new features, prioritize speed to market over cost
• Base design decisions on empirical data

Trade-offs can increase cost and complexity, so design decisions should be based on empirical data. This might include load testing for measurable performance benefits or benchmarking for cost-optimal workloads over time.

Core Best Practices

1. Implementing Scalability

Objective: Ensure that your architecture can handle changes in demand.

Proactive Scaling

Key Concepts

• Scale infrastructure quickly and proactively on AWS Cloud
• Implement scalability at every layer of infrastructure
• Improve design to anticipate need for more capacity before it’s too late

Implementation Example

• Use Amazon CloudWatch to detect when total load reaches specified threshold (e.g., “above 60% CPU utilization for longer than 5 minutes”)
• Amazon EC2 Auto Scaling immediately launches new instances when alarms are invoked
• Design system to be elastic - scale down when demand drops to avoid paying for unused instances

Anti-pattern: Reactive manual scaling where users are prevented from accessing applications while administrators manually launch instances.

2. Automating Your Environment

Objective: Automate the provisioning, termination, and configuration of resources.

AWS offers built-in monitoring and automation tools at virtually every infrastructure layer. Without automation, you must manually detect and respond to failures.

Benefits of Automation

• CloudWatch and Amazon EC2 Auto Scaling detect unhealthy resources
• Automate launch of replacement resources
• Receive notifications when resource allocations change
• Log changes to change management solutions for tracking

3. Using Infrastructure as Code (IaC)

Objective: Provision your computing infrastructure using code instead of manual processes.

Rapid Deployment

Using a single template, identical environments can be deployed, removing repetitive manual steps and checklists

Reduce Errors

Manual configuration is error-prone. IaC reduces errors and streamlines error checking with quick rollback capabilities

Consistent Changes

Make changes to template and push to all stacks, enabling consistent deployment across environments

4. Treating Resources as Disposable

Objective: Take advantage of the dynamically provisioned nature of cloud computing.

Think about infrastructure as software instead of hardware:

• Automate deployment of new resources with identical configurations
• Stop resources that are not in use
• Test updates on new resources, then replace old resources with updated ones

This approach enables quick response to capacity changes, application upgrades, and underlying software management.

5. Using Loosely Coupled Components

Objective: Design architectures with independent components.

Traditional infrastructures have chains of tightly integrated servers where one component failure can be fatal and impedes scaling.

Solutions for Decoupling

• Load balancers: Route requests between layers (e.g., Elastic Load Balancing)
• Message queues: Handle communication between applications

With loose coupling, managed solutions act as intermediaries that automatically handle both failures and scaling of components.

6. Designing Services, Not Servers

Objective: Use the breadth of AWS services. Don’t limit your infrastructure to servers.

Note

Amazon EC2 offers tremendous flexibility but shouldn’t always be the first or only solution for every need.

Consider Alternatives

• Containers or serverless solutions when appropriate
• Message queues for application communication
• Amazon S3 for static web assets storage
• Managed AWS services for user authentication and state storage

Examples of managed solutions: AWS Lambda, Amazon SQS, Amazon DynamoDB, ELB, Amazon SES, Amazon Cognito

7. Choosing the Right Database Solution

Objective: Match technology to the workload, not the other way around.

Key Considerations

• Read and write needs
• Total storage requirements
• Typical object size and nature of access
• Durability and latency requirements
• Maximum concurrent users to support
• Nature of queries
• Required strength of integrity controls

AWS recommends choosing data stores based on application environment needs rather than hardware or license constraints.

8. Avoiding Single Points of Failure

Objective: Assume everything fails. Then, design backward.

Where possible, eliminate single points of failure from architecture. This doesn’t mean duplicating every component - you can use:

• Automated solutions that launch components when needed
• Managed services where AWS automatically replaces malfunctioning hardware

Implementation Example

Create secondary (standby) database server and replicate data. If main database goes offline, secondary server picks up the load, and application servers automatically send requests to secondary database.

9. Optimizing for Cost

Objective: Take advantage of AWS flexibility to increase cost efficiency.

Variable vs Fixed Expense

Key Questions

• Are my resources the right size and type for the job?
• Which metrics should I monitor?
• How do I turn off resources not in use?
• How often will I need this resource?
• Can I replace servers with managed services?

Trade fixed expenses (servers running 24/7) for variable expense (pay only for services you need for as long as you use them).

10. Using Caching

Objective: Minimize redundant data retrieval operations, improving performance and cost.

Caching temporarily stores data in intermediary location between requester and permanent storage to make future requests faster and reduce network throughput.

Implementation Example

• Use Amazon CloudFront in front of Amazon S3
• Initial request checks CloudFront; if not found, retrieves from S3
• CloudFront stores copy at edge location close to user
• Subsequent requests served from closer edge location with lower latency and cost

11. Securing Your Entire Infrastructure

Objective: Build security into every layer of your infrastructure.

Security involves ensuring individual environments and components are secured from each other, not just getting through outer boundary.

Security Implementation

• Use managed services and log access of resources
• Isolate parts of infrastructure (e.g., Amazon EC2 security groups)
• Encrypt data in transit and at rest
• Enforce granular access control using principle of least privilege
• Use multi-factor authentication (MFA)
• Automate deployments to keep security consistent

These best practices work together to create robust, scalable, and cost-effective cloud architectures that can adapt to changing business needs while maintaining security and reliability.