AWS Cloud Best Practices Flashcards
When operating services on AWS, there are several common categories of operating models.
What are they?
- Applications that are migrated, maintain existing traditional operating models, leverage the ability to manage infrastructure as Code through APIs enabling robust and repeatable build processes, improving reliability
- Solutions are that refactored leverage higher levels of automation of the operation processes as the supporting services, ei AWS Auto Scaling and self-healing architectures
- Solutions that are rearchitected and designed for cloud operations are typically fully automated through DevOps processes for delivery pipeline and management
How does Scalability work in regards to AWS?
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
It should provide that scale in a linear manner where adding extra resources results in at least a proportional increase in ability to serve additional load.
Growth should introduce economies of scale, and cost should follow the same dimension that generates business value out of that system.
While cloud computing provides virtually unlimited on-demand capacity, your design needs to be able to take advantage of the resources seamlessly
What is scaling vertically and how does it work?
Scaling vertically takes place through an increase in the specifications of an individual resource, such as upgrading a server with a larger hard drive or faster CPI.
With Amazon EC2, you can stop an instance and resize it to an instance type that has more RAM, CPU, I/O or networking capabilities.
This way of scaling can eventually reach a limit and it is not always a cost efficient or high available approach
However, it is very easy to implement and can be sufficient for many use cases especially in the short term
What is scaling horizontally and how does it work?
Scaling horizontally takes place through an increase in the number of resources, such as adding more hard drives to a storage array or adding more servers to support an application.
This is a great way to build internet-scale applications that leverage the elasticity of cloud computing .
Not all architectures are designed to distribute their workload to multiple resources,
What are stateless applications and how do they work in AWS environments?
When users or services interact with an application they will often perform a series of interactions that form a session,
A session is unique data for users that persists between request while they use the application
A stateless application is an application that does not need knowledge of previous interactions and does not store session information.
For example, an application that, given the same input, provides the same response to any user, is a stateless application
Stateless applications can scale horizontally because any of the available compute resources ( such as EC2 instances and AWS Lambda functions) can service any request.
Without stored sessions data, you can simply add more compute resources as needed.
When that capacity is no longer required, you can safely terminate those individual resources, after running tasks have been drained..
Those resources do not need to be aware of the presence of their peers- all that is required is a way to distribute the workload to them
There are two models to follow what distributing load to multiple nodes.
What are they and how to they work?
Push Model- With push model, you can use Elastic Load Balancing (ELB) to distribute a workload.
ELB routes incoming application request across multiple EC2 instances.
When routing traffic, a Network Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model to handle millions of requests per second.
With the adoption of container based services, you can also use an Application Load Balancer
An Application Load Balancer provides Layer 7 of the OSI model and supports content-based routing of requests based on application traffic.
Alternatively, you can use Amazon Route 53 to implement a DNS round robin fashion
While easy to implement, this approach does not always work well with the elasticity of the cloud computing.
This is because even if you can set low time to live (TTL) values for your DNS records, caching DNS resolves are outside the control of Amazon Route 53 and might not always respect your settings
What is a pull model and how does it work?
Pull model works well with asynchronous, event-driven workloads.
In a pull model, task that need to be performed or data that needs to be processed can be stored as messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming data solution such as Amazon Kinesis, Multiple compute resources can then pull and consume those messages, processing them in a distributed fashion
What are stateless components?
In practice, most applications maintain some kind of state information.
For exmaple, web applications need to track whether a user is signed in so that personalized content can be presented based on previous actions.
An automated multi-step process also needs to track previous activity to decide what is its next action should be.
You can still make a portion of these architectures stateless by not storing anything that needs to persist for more than a single request in the local file system
For example, web applications can use HTTP cookies to store session information (such as shopping cart items) in the web client cache.
The browser passes that information back to the server at each subsequent so that the application does not need to store it.
However, this approach has two drawbacks.
First, the content of the HTTP cookies can be tampered with on the client side, so you should always treat it as untrusted data that must be validated.
Second, HTTP cookies are transmitted with every request, which means that you should keep their size to a minimum to avoid unnecessary latency
COnsider only storing a unique session identifier in an HTTP cookie and storing more detailed user session information on the server side.
Most programming platforms provide a native session management mechanism that works this way
However, user session information is often stored on the local file system by default and results in a stateful architecture
A common solution to this problem is to store this information in a database.
Amazon DynamoDB is a great choice because of its scalability, high availability and durability characteristics.
For many platforms, there are open source drop-in replacement libraries that allow you to store native sessions in Amazon DynamoDB
Other scenarios required storage of larger files (such as user uploads and interim results of batch processes)
By placing those files in a shared storage layer such as Amazon Simple Storage Service (Amazon S3) or Amazon Elastic File System (Amazon EFS), you can avoid the introduction of stateful components
Finally, a complex multi-step workflow is another example where you must track the current state of each execution.
You can use AWS Step Functions to centrally store execution history and make these workloads stateless
What are Stateful Components?
Inevitably, there will be layers of your architecture that you wont turn into stateless components.
By definition, databases are stateful.
In addition, many legacy applications were designed to run on a single server by relying on local compute resources.
Other use cases might require client devices to maintain a connection to a specific server for prolonged periods.
For example, real-time multiplayer gaming must offer multiple players a consistent view of the game world with very low latency.
This is much simpler to achieve in a non-distributed implementation where participants are connected to the same server
What is implement session affinity?
For HTTP and HTTPS traffic, you can use the sticky sessions feature of an Application Load Balancer to bind a users session to a specific instance.
With this feature, an Application Load Balancer will try to use the same server for that user for the duration of the session
Another option- if you control the code that runs on the client - is use to client-side load balancing.
This adds extra complexity, but can be useful in scenarios where a load balancer does not meet your requirements.
For example, you might be using a protocol thats not supported by ELB or you might need full control over how users are assigned to servers
In this model, the clients need a way of discovering valid server endpoints to directly connect.
You can use DNS for that, or you can build a simple discovery API to provide that information to the software running on the client.
In the absence of a load balancer, the health checking mechanism also needs to be implemented on the client side.
You should design for your client logic so that when server unavailability is detected, devices reconnect to another server with little disruption for the application
What is distributed processing?
Use cases that involve the processing of very large amounts of data - anything that can’t be handled by a single compute resource in a timely manner- require a distributed processing approach.
By dividing a task and its data into many small fragments of work, you can execute them in parallel across a set of compute resources
What is distributed processing implemented?
Offline batch jobs can be horizontally scaled by using distributed data processing engines such as AWS Batch, AWS Glue, and Apache Hadoop.
On AWS, you can use Amazon EMR to run Hadoop workloads on top of a fleet of EC2 instances without the operational complexity.
For real-time processing of streaming data, Amazon Kinesis partitions data in multiple shards that can be consumed by multiple Amazon EC2 or AWS Lambda resources to achieve scalability
Why is having disporable resources instead of fixed servers beneficial?
In a traditionally infrastructure environment, you have to work with fixed resources because of the upfront cost and lead time of introducing new hardware.
This drives practices such as manually logging in to servers to configure software or fix issues, hardcoding IP addresses, and running test or processing jobs sequentially
When designing for AWS, you can take advantage of the dynamically provisioned nature of cloud computing.
You can think of servers and other components as temporary resources.
You can launch as many as you need, and use them only for as long as you need them
Another issues with fixed, long-running is configuration drift.
Changes and software patches applied through time can result in untested and heterogeneous configurations across different environments
You can solve this problem with an immutable infrastructure pattern
With this approach, a server - once launched - is never updated
Instead, when there is a problem or need for an update, the problem server is replaced with a new server that has the latest configuration.
This enables resources to always be in a consistent (and tested) state, and makes rollbacks easier to perform
This is more easily supported with stateless architectures
Instantiating Compute Resources
Whether you are deploying a new environment for testing or increasing capacity of an existing system to cope with extra load, you do not want to manually set up new resources with their configuration and code.
It is important that you make this an automated and repeatable process that avoids long lead times and is not prone to human error
What are some ways we can achieve instantiating computing resources?
Bootstrapping, what is it?
When you launch an AWS resource such as an EC2 instance or Amazon Relational Database Service (Amazon RDS) DB instance, you start with default configuration.
You can then execute automated bootstrapping actions, which are scripts that install software or copy data to bring resource to a particular state.
You can parameterize configuration details that vary between different environments (such as production or test) so that you can reuse the same scripts without modifications
You can set up new EC2 instances with user data scripts and cloud-init directives
You can use simple scripts and configuration management tools such as CHef or Puppet.
In addition, with customer scripts and the AWS APIs, or with AWS CloudFormation support for AWS Lambda-back customer resource, you can write provisioning logic that acts on almost any AWS resource
What are Golden Images?
A golden image is a pre-configure template for your users.
A Golden Image may also be referred to as a clone mage, master image or base image
If you have ever built a standard image for your user-base, you understand the need for consistency and ease of development
Certain AWS resource types, such as EC2 instances, Amazon RDS DB instances and Amazon Elastic Block Store (Amazon EBS) volumes, can be launched from a golden image, which is a snapshot of a particular state of that response.
When compared to the bootstrapping approach, a golden image results in faster start times and remove dependencies to configuration services or third-party repositories.
This is important in auto-scaled environments where you want to be able to quickly and reliability launch additional resources such as a response to demand changes
You can customize an EC2 instance and then save its configuration by creating an Amazon Machine Image (AMI)
You can launch as many instances from theAMI as you need, and they will all include those cusomizations
Each time you want to change your configuration you must create a new golden image, so you must have a versioning convention to manage your golden images over time.
We recommend that you use a script to create the bootstrap for the EC2 instances that you use to create your AMIs,.
Alternatively, ylu if have an existing on-premises virtualized environment, you can use VM import/export from AWS to convert a variety of virtualization formats to an AMI.
You can also find and use prebaked, shared AMIs provided either by AWS or third parties in AWS Marketplace
While golden images are most commonly used when you launch an EC2 instance, they can also be applied to resources such as Amazon RDS DB instances or Amazon EBS volumes.
For example, when you launch a new test environment, you might want to prepopulate its database by instantiating it from a specific Amazon RDS snapshot, instead of importing the data from a lengthy SQL script
