Amazon AWS Limits

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#USER_PIOPS

Architecting for the Cloud: AWS Best Practices

Migrating applications to AWS, even without significant changes (an approach known as “lift and shift”).
Architect in a such a way to exploit the elasticity of cloud.

The Cloud Computing Difference:
1. IT Assets Become Programmable Resources
2. Global, Available, and Unlimited Capacity
3. Higher Level Managed Services : EC2, storage, database, analytics, application, and deployment services
4. Security Built In : The AWS cloud provides governance capabilities that enable continuous monitoring of configuration changes to your IT resources. Since AWS assets are programmable resources, your security policy can be formalized and embedded with the design of your infrastructure.
6. Design Principles
7. Scalability : Architecture can support growth in users, traffic, or data size with no drop in performance.
While cloud computing provides virtually unlimited on-demand capacity, your design needs to be able to take advantage of those resources seamlessly.
A. Scaling Vertically : On Amazon EC2, this can easily be achieved by stopping an instance and resizing it to an instance type that has more RAM, CPU, IO, or networking capabilities.
B. Scaling Horizontally: Increase in the number of resources.Not all architectures are designed to distribute their workload to multiple resources.
Stateless Applications: A stateless application is an application that needs no knowledge of previous interactions and stores no session.
How to distribute load to multiple nodes:
Push Model:
Elastic Load Balancer (ELB) routing requests to EC2.
Aletnerate approach DNS round robin (e.g., with Amazon Route 53): Round robin fashion. While easy to implement, this approach does not always work well with the elasticity of cloud computing. This is because even if you can set low time to live (TTL) values for your DNS records, caching DNS resolvers are outside the control of Amazon Route 53 and might not always respect your settings.
Pull Model:
Data that need to be processed could be stored as messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming data solution like Amazon Kinesis.

Stateless Components:Use HTTP cookies to store information about a session at the client’s browser (e.g., items in the shopping cart).
Two drawbacks
1.Content of the HTTP cookies can be tampered with
2. Second, HTTP cookies are transmitted with every request ( Keep their size to minimum)

A common solution to this problem is to store user session information in a database. Amazon DynamoDB is a great choice due to its scalability, high availability, and durability characteristics.
Amazon S3 for large file storage.
Amazon Simple Workflow Service (Amazon SWF) can be utilized to centrally store execution history and make these workloads stateless.

Stateful Components:
Databases are stateful
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 of time. e.g. Consistent view of the
game in real time multiplayer game. Session affinity.

How to implement session affinity:
For HTTP/S traffic, session affinity can be achieved through the “sticky sessions” feature of ELB4. Elastic Load Balancing will attempt to use the same server for that user for the duration of the session.
DNS
Clinet API to discover information (server)


Distributed Processing:
By dividing a task and its data into many small fragments of work, you can execute each of them in any of a larger set of available compute resources.
How to implement distributed processing.
Offline batch jobs can be horizontally scaled by using a distributed data processing engine like Apache Hadoop. On AWS, you can use the Amazon Elastic MapReduce (Amazon EMR) service 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 then be consumed by multiple Amazon EC2 or AWS Lambda resources to achieve scalability.

Disposable Resources Instead of Fixed Servers:
Fixed resources:
Manual efforts and Cost
Configuration drift - Changes and software patches applied through time can result in untested and heterogeneous configurations across different environments.


Instantiating Compute Resources:
There are a few approaches on how to achieve an automated and repeatable process.
Bootstrapping -
Start with a default configuration. You can then execute automated bootstrapping actions.
Parameterize configuration details that vary between different environments (e.g., production, test, etc.)
Bootstrapping in practice
You can use user data scripts and cloud-init6 directives or AWS OpsWorks lifecycle events7 to automatically set up new EC2 instances.
You can use simple scripts, configuration management tools like Chef or Puppet.
AWS OpsWorks natively supports Chef recipes or Bash/PowerShell scripts.
In addition, through custom scripts and the AWS APIs, or
through the use of AWS CloudFormation support for AWS Lambda-backed custom resources, it is possible to write provisioning logic that acts on almost any AWS resource.

Golden Images
Amazon EC2 instances, Amazon RDS DB instances, Amazon Elastic Block Store (Amazon EBS) volumes, etc., can be launched from a golden image: a snapshot of a particular state of that resource.
Compared to bootstrapping faster.
Create AMI.
Versioning of AMI's.

Containers:
Docker - Docker Image, which is a standardized unit for software development, containing everything the software needs to run: code, runtime, system tools, system libraries, etc. AWS Elastic Beanstalk and the Amazon EC2 Container Service (Amazon ECS) support Docker and enable you to deploy and manage multiple Docker containers across a cluster of Amazon EC2 instances.

Hybrid:

Some part in Golden Image, some part in bootstrapping

The line between bootstrapping and golden image:

Items that do not change often or that introduce external dependencies will typically be part of your golden image.

For example, web server software

Items that change often or differ between your various environments can be set up dynamically through bootstrapping actions. 

For example, if you are deploying new versions of your application frequently

Database hostname configuration (different between the test and production environments)

User data or tags.

AWS Elastic Beanstalk follows the hybrid model.
 It provides preconfigured run time environments (each initiated from its own AMI10)
 but allows you to run bootstrap actions (through configuration files called .ebextensions11) and configure environmental variables to parameterize the environment differences.

Infrastructure as Code:
Apply techniques, practices, and tools from software development to make your whole infrastructure reusable, maintainable, extensible, and testable.

• Create and manage - AWS resources, and 
• provision and update them in an orderly and predictable fashion.
• Describe the AWS resources, and any associated dependencies or run time parameters, required to run your application. 
• Version control repository, allowing architectures to be reused and production environments to be reliably cloned for testing.

Automation:

AWS Elastic Beanstalk : Developers can simply upload their application code and the service automatically handles all the details

Amazon EC2 Auto recovery: Recovered instance is identical to the original instance, including the instance ID, private IP addresses, Elastic IP addresses, and all instance metadata ( Only certain EC2 Type). During instance recovery memory data is lost.

Auto Scaling:

Amazon CloudWatch Alarms: Sends an Amazon Simple Notification Service (Amazon SNS) message -  

SNS Message automatically trigger AWS Lambda function, 

enqueue message to SQS  or 

POST request to an HTTP/S endpoint.

Amazon CloudWatch Events:

AWS OpsWorks Lifecycle events:

AWS OpsWorks supports continuous configuration through lifecycle events that automatically update your instances’ configuration to adapt to environment changes. These events can be used to trigger Chef recipes on each instance to perform specific configuration tasks. For example, when a new instance is successfully added to a Database server layer, the configure event could trigger a Chef recipe that updates the Application server layer configuration to point to the new database instance.

AWS Lambda Scheduled events:

AWS Security In your VPC

Amazon VPC provides three features that you can use to increase and monitor the security for your VPC:
• Security groups — Act as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level
• Network access control lists (ACLs) — Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level
• Flow logs — Capture information about the IP traffic going to and from network interfaces in your VPC

You can monitor the accepted and rejected IP traffic going to and from your instances by creating a flow log for a VPC, subnet, or individual network interface. Flow log data is published to CloudWatch Logs, and can help you diagnose overly restrictive or overly permissive security group and network ACL rules.

Amazon security groups and network ACLs don't filter traffic to or from link-local addresses
(169.254.0.0/16) or AWS-reserved addresses (the first four IP addresses and the last one in each
subnet). Similarly, flow logs do not capture IP traffic to or from these addresses.
These addresses support the services:
  Domain Name Services (DNS),
  Dynamic Host Configuration Protocol (DHCP),
  Amazon EC2 instance metadata,
, Key Management Server (KMS—license management for Windows instances), and
  routing in the subnet.
You can implement additional firewall solutions in your instances to block network communication with link-local addresses.

Comparison of Security Groups and Network ACLs:

64#
Security Groups for Your VPC:
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign the instance to up to five security groups. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a different set of security groups. If you don't specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC.

For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.
You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.

65#
Security Group Basics
The following are the basic characteristics of security groups for your VPC:
• You can create up to 500 security groups per VPC.You can add up to 50 rules to each security group, and associate up to 5 security groups per network interface.
• You can specify allow rules, but not deny rules.
• You can specify separate rules for inbound and outbound traffic.
• By default, no inbound traffic is allowed until you add inbound rules to the security group.
• By default, an outbound rule allows all outbound traffic.You can remove the rule and add outbound rules that allow specific outbound traffic only.
• Security groups are stateful — responses to allowed inbound traffic are allowed to flow outbound
regardless of outbound rules, and vice versa. For more information, see Connection Tracking in the
Amazon EC2 User Guide for Linux Instances.
• Instances associated with a security group can't talk to each other unless you add rules allowing it
(exception: the default security group has these rules by default).
• Security groups are associated with network interfaces. After you launch an instance, you can change  the security groups associated with the instance, which changes the security groups associated with the primary network interface (eth0).You can also change the security groups associated with any other network interface. For more information about network interfaces, see Elastic Network Interfaces (ENI).

Default Security Group for Your VPC
The following table describes the default rules for a default security group.

You can change the rules for the default security group. You can't delete a default security group.