AWS Architecture Best Practices

AWS Well-Architected platform helps cloud architects create a secured, powerful, resilient, and efficient infrastructure for their applications and workloads. Operational excellence, protection, reliability, performance quality and cost optimization are the five pillars which AWS is based. AWS Well-Architected platform provides a cohesive approach for customers and partners to assess architectures and implement scalable designs over time.
 

The AWS Well-Architected Framework started as a single white paper but has expanded to include domain-specific goals, hands-on labs, and the AWS Well-Architected Tool. Available for free in the AWS Management Console, the AWS WA tool provides a mechanism to regularly review your workloads, identify high-risk issues, and record your improvements.
AWS has an ecosystem of hundreds of Well-Architected Partner Program members. You can engage a partner in your area to help analyze and review your applications.

Differences Between Traditional and Cloud Computing Environments
In a traditional IT environment, a company must deliver capacity based on the best peak traffic estimate (for example, Black Friday). This implies that for a long time, a substantial part of the power can effectively be wasted.
This is the reason why Cloud Computing was created for your own use; you can use the extra strength garnered from others (in the case of AWS-Amazon). It is possible to start and stop servers, databases, storage, etc. in hours or even minutes, as needed.

Cloud computing with AWS has four main advantages:
It provide services when they are needed using the overall AWS infrastructure to physically deploy your applications closer to users (in a traditional model, you have to create your own data centers where the users are located); a host of managed services suggests that you can focus on building your product, and the low complexity is eliminated by being able to design AWS for a specific amount and you have the ability to track how much your organization spends on each service.

Design Principles
Scalability -  An IT architecture can be scaled in two ways:
Vertical scaling – which involves upgrading from one source. This shows that it can take up more RAM, a faster processor or more storage capacity. This is a valid approach, but to a limit, an infinite number of RAM cannot be added to a disk.
Horizontal scaling- scaling from a number of sources. It sounds easy on paper (just get more servers), but not all applications and architectures are designed with a horizontal approach in mind, which makes it tricky.

Stateless applications
In stateless applications, horizontal scaling is ideally suitable. A stateless application is an application that does not require knowledge of the previous request sent to that application and does not store any information about the session as such. If you are more familiar with functional programming, a stateless application is essentially a pure function that delivers the same output with the same input.

There are two key approaches involved in sharing the workload between different devices, which are easier said than done:
- Push Model-To disperse inbound traffic to many instances where your application is running, using an Elastic Load Balancer (ELB). You can also use Amazon Route 53 (a DNS service) to implement DNS touring, but this is not an elastic solution and has its limitations.
- Pull model: Store action items in a queue (Amazon SQS) and instruct authorities to retrieve their own action item.

Stateless Components
Most apps are not 100% stateless; they store some sort of status information (for example, they need to know if the user is logged in so they can select the content specific to that user). You can still make some of these architectures stateless by not storing anything which persists in the local file system longer than one request.
You can use HTTP cookies to store session information, but not only do cookies have to be sent with every request, they can also be forged on the client-side.
Saving a specific session ID in an HTTP cookie and storing more comprehensive user data on the server would be a better approach. A stateful architecture is generated by storing the data on the server, therefore, the main solution is to store this data in a database (a DynamoDB is a good choice).
Shift the data to a storage tier framework like Amazon S3 or Amazon EFS if you have to deal with massive files, which will help you avoid stateful components.

Stateful Components
There are apps specifically designed to run on a single machine (for example, real-time multiplayer games that require extremely low latency). If you're developing such an application, you don't want to distribute traffic horizontally to any instance.
A recommended approach for HTTP/HTTPS traffic is to use the Application Load Balancer 's persistent session feature to bind a user's session to a specific instance. This ensures that, as long as they keep playing, they are not moved to another physical machine. In other cases, you may want to implement client-side load balancing. This introduces additional complexity, but may sometimes be necessary.

Disposable items instead of fixed servers
You can purchase physical servers in a conventional hardware environment, install them in a data center, and place them there manually to update packages., etc.
With AWS, you ultimately treat servers and all other components as temporary resources, providing them only when needed.

To deliver different identical (or very similar) sources swiftly, you can use:
- Bootstrapping - a script that you configure when provisioning, for example, an EC2 instance. It runs as soon as you initiate the instance, and it is possible to specify configuration details that vary between different environments (e.g., staging and production).
- Gold Pictures - Some AWS resources (EC2, RDS, and Elastic Block Storage EBS) can be created from a gold picture, which creates a snapshot of a resource at a point in time. This approach is generally faster than booting an instance and allows you to quickly and reliably boot additional resources by essentially "cloning" an instance.
- It is possible to configure an instance and save its configuration to create an AMI (Amazon Machine Image) - you can then start as many instances as you like by using it. In AWS, multiple AMIs are open, so before you build your own AMIs, check if your case has been resolved.
- Containers are also an option - Docker (with Amazon ECS - Elastic Container Service) is supported, so also Kubernetes (with Amazon EKS).
- There is also a hybrid model in which some parts of the configuration are captured in a gold image, while others are dynamically configured via startup scripts. AWS Elastic Beanstalk follows this pattern - it allows you use AMIs to initiate a new service and perform bootstrap actions via .ebextensions files, as well as environmental variables.

Infrastructure as Code
Infrastructure can (and should) be stored as code and version control. AWS CloudFormation templates allow you to create, manage and update resources in an orderly and predictable manner. This simplifies the reuse of architectures, as well as the extension of existing architectures, which is very useful for large organizations.

Automate
Traditionally, someone has to manually respond to incidents to increase storage capacity, deploy additional servers, etc. With AWS, it is possible to automate these steps.

Examples:
Auto Recovery for Amazon EC2: You can build a CloudWatch alarm that tracks and recovers an EC2 instance automatically in case anything goes wrong. It is far better than manually restarting the machine.
Autoscale: You can scale the number of EC2 instances, DynamoDB capacity, ECS and EKS as needed based on the desired capacity. This way, you're not running more shifts than necessary (wasting money) or fewer shifts than necessary (which will not keep up with traffic if there's a rush). It is better to schedule the autoscaling group launch for a while, so you don't have to wait for AWS to "notice" more traffic.
Use alarms and events: For example, create a CloudWatch alarm that sends an SNS message when a certain metric exceeds a certain threshold. These messages then take up a lambda function, sends a message to the SQS queue, or sends a request to the HTTP or HTTPS endpoint so that you can respond to the event in context.