This page is a cut down version of the AWS "Architecting for the Cloud: AWS Best Practices" White Paper. It included links to all the relevant technologies mentioned in the document.
Click on the following links to see more relevant information:
The Abstract from the original white paper says:
"This whitepaper is intended for solutions architects and developers who are building solutions that will be deployed on Amazon Web Services (AWS). It provides architectural patterns and advice on how to design systems that are secure, reliable, high performing, and cost efficient. It includes a discussion on how to take advantage of attributes that are specific to the dynamic nature of cloud computing (elasticity, infrastructure automation, etc.). In addition, this whitepaper also covers general patterns, explaining how these are evolving and how they are applied in the context of cloud computing."
Introduction
Migrating applications to AWS, even without significant changes (an approach known as “lift and shift”), provides organizations the benefits of a secured and cost-efficient infrastructure. However, to make the most of the elasticity and agility possible with cloud computing, engineers will have to evolve their architectures to take advantage of the AWS capabilities.
The main differences bought by the AWS Cloud are:
- IT Assets Become Programmable Resources
- Global, Available, and Unlimited Capacity
- Higher Level Managed Services
- Security Built In
Scalability
Systems that are expected to grow over time need to be built on top of a scalable architecture. Such an architecture can support growth in users, traffic, or data size with no drop in performance.
Scaling Vertically
Scaling vertically takes place through an increase in the specifications of an individual resource (e.g., upgrading a server with a larger hard drive or a faster CPU).
Scaling Horizontally
- Stateless Applications
- Stateless Components
- Stateful Components
- Distributed Processing
Disposable Resources Instead of Fixed Servers
In a traditional infrastructure environment, you have to work with fixed resources due to the upfront cost and lead time of introducing new hardware. This would drive practices like manually logging in to servers to configure software or fix issues, hardcoding IP addresses, running tests or processing jobs sequentially etc.
- Instantiating Compute Resources
- Bootstrapping
- Golden Images
- Hybrid
Infrastructure as Code
Automation
In a traditional IT infrastructure, you would often have to manually react to a variety of events. When deploying on AWS there is a lot of opportunity for automation, so that you improve both your system’s stability and the efficiency of your organization:
- AWS Elastic Beanstalk
- Amazon EC2 Auto recovery
- Auto Scaling
- Amazon CloudWatch Alarms
- Amazon CloudWatch Events
- AWS OpsWorks Lifecycle events
- AWS Lambda Scheduled events
Loose Coupling
As application complexity increases, a desirable attribute of an IT system is that it can be broken into smaller, loosely coupled components. This means that IT systems should be designed in a way that reduces interdependencies—a change or a failure in one component should not cascade to other components.
- Well-Defined Interfaces
- Service Discovery
- Asynchronous Integration
- Graceful Failure
Services, Not Servers
Developing, managing, and operating applications—especially at scale—requires a wide variety of underlying technology components. With traditional IT infrastructure, companies would have to build and operate all those components.
- Managed Services
- Serverless Architectures
Databases
With traditional IT infrastructure, organizations were often limited to the database and storage technologies they could use. There could be constraints based on licensing costs and the ability to support diverse database engines. On AWS, these constraints are removed by managed database services that offer enterprise performance at open source cost. As a result, it is not uncommon for applications to run on top of a polyglot data layer choosing the right technology for each workload.
- Relational Databases
- NoSQL Databases
- Data Warehouse
- Search
Removing Single Points of Failure
Fault Isolation and Traditional Horizontal Scaling
A single request could bring all servers, including standby services down by cascading the fault. An option to protect against this is:
Optimise for Cost
Right Sizing
Choose the right :
- EC2 instance(s) size
- S3 Storage class - Either Standard or Infrequent Access. Also Glacier, which is not S3 based.
- Elastic Block Store (EBS), i.e. SSD (Solid State Drive) either General Purpose SSD (
gp2) OR Provisioned IOPS SSD (io1), HDD (Magnetic Hard Disk Drive) either Throughput Optimized HDD (st1) OR Cold HDD (sc1)
Continuous monitoring and tagging
Cost optimization is an iterative process. Your application and its usage will
evolve through time. In addition, AWS iterates frequently and regularly
releases new options.
AWS provides tools to help you identify those cost saving opportunities and
keep your resources right-sized. To make those tools’ outcomes easy to
interpret you should define and implement a tagging policy for your AWS
resources.
Elasticity
Take Advantage of a variety of EC2 purchasing options
- On Demand
- Reserved Capacity - Use Trusted Advisor or EC2 Useage Reports to identify which compute resources might be able to use these instances
- Spot Instances - Great for workloads that have tolerance to interruption
Caching
Application Data Caching
Amazon Elasticache - Either Memcached or Redis. See Performance at Scale with Amazon ElastiCache
Edge Caching - Using a Content Delivery Network (CDN) such as CloudFront with local edge locations around the world to deliver large popular objects to end users at scale
Security
For a detailed view on how you can achieve a high leve of security governance see:
- "Security at Scale: Governance in AWS (October 2015)”
- “AWS Security Best Practices (August 2016)”
whitepapers
AWS CloudFormation Templates can be imported as "products" into AWS Service Catalogue to provide corporate governance in conjunction with IAM.
Real-Time Auditing
Use:
- AWS Config
- Amazon Inspector
- AWS Trusted Advisor
Conclusion
For a lot more information see the Amazon Architecture Center