mirror of
https://github.com/nickpoida/og-aws.git
synced 2025-02-13 02:12:02 +00:00
Formatting and authors update.
This commit is contained in:
Joshua Levy
parent
dd1ddb3f7c
commit
1331a99c98
2 changed files with 20 additions and 13 deletions
|
|
@ -6,12 +6,12 @@ The following people (in alphabetical order) have contributed to or reviewed thi
|
|||
|
||||
|
||||
* [Alexander Atallah (alexanderatallah)](https://github.com/alexanderatallah)
|
||||
* [Ben Kehoe (benkehoe)](https://github.com/benkehoe)
|
||||
* [Ben Kehoe (benkehoe)](https://github.com/benkehoe) — [4+](https://github.com/open-guides/og-aws/commits?author=benkehoe)/[1+](https://github.com/open-guides/og-aws/issues?q=author%3Abenkehoe)
|
||||
* [Adam Mathias Bittlingmayer (bittlingmayer)](https://github.com/bittlingmayer)
|
||||
* [Donne Martin (donnemartin)](https://github.com/donnemartin)
|
||||
* [Max Grigorev (forwidur)](https://github.com/forwidur)
|
||||
* [Dmitry Golyshev (golyshev)](https://github.com/golyshev)
|
||||
* [Joshua Levy (jlevy)](https://github.com/jlevy) — [19+](https://github.com/open-guides/og-aws/commits?author=jlevy)/[34+](https://github.com/open-guides/og-aws/issues?q=author%3Ajlevy) — _project editor_
|
||||
* [Joshua Levy (jlevy)](https://github.com/jlevy) — [22+](https://github.com/open-guides/og-aws/commits?author=jlevy)/[37+](https://github.com/open-guides/og-aws/issues?q=author%3Ajlevy) — _project editor_
|
||||
* [KAZUYUKI TANIMURA (kazuyukitanimura)](https://github.com/kazuyukitanimura)
|
||||
* [Marcello Bastéa-Forte (marcello3d)](https://github.com/marcello3d)
|
||||
* Max Zanko
|
||||
|
|
@ -19,7 +19,7 @@ The following people (in alphabetical order) have contributed to or reviewed thi
|
|||
* [Ola Wiberg (olawiberg)](https://github.com/olawiberg)
|
||||
* Praveen Patnala
|
||||
* [Russell Power (rjpower)](https://github.com/rjpower)
|
||||
* [Thanos Baskous (ThanosBaskous)](https://github.com/ThanosBaskous) — [5+](https://github.com/open-guides/og-aws/commits?author=ThanosBaskous)/[3+](https://github.com/open-guides/og-aws/issues?q=author%3AThanosBaskous) — _project editor_
|
||||
* [Thanos Baskous (ThanosBaskous)](https://github.com/ThanosBaskous) — [7+](https://github.com/open-guides/og-aws/commits?author=ThanosBaskous)/[4+](https://github.com/open-guides/og-aws/issues?q=author%3AThanosBaskous) — _project editor_
|
||||
* [Stefan Zier (weirded)](https://github.com/weirded)
|
||||
|
||||
Additional authors are welcome; see the [contribution guidelines](CONTRIBUTING.md).
|
||||
|
|
|
|||
27
README.md
27
README.md
|
|
@ -216,7 +216,7 @@ Many services within AWS can at least be compared with Google Cloud offerings or
|
|||
| Monitoring | CloudWatch | Monitoring | Borgmon | | | Prometheus(?) |
|
||||
| Metric management | | | Borgmon, TSDB | | | Graphite, InfluxDB, OpenTSDB, Grafana, Riemann, Prometheus |
|
||||
| CDN | CloudFront | | | Azure CDN | | Apache Traffic Server |
|
||||
| Load balancer | ELB/ALB | Load Balancing | GFE | | | nginx, HAProxy, Apache Traffic Server |
|
||||
| Load balancer | ELB/ALB | Load Balancing | GFE | | | nginx, HAProxy, Apache Traffic Server |
|
||||
| DNS | Route53 | DNS | | | | bind |
|
||||
| Email | SES | | | | Sendgrid, Mandrill, Postmark | |
|
||||
| Git hosting | CodeCommit | | | | GitHub, BitBucket | GitLab |
|
||||
|
|
@ -688,18 +688,18 @@ EBS
|
|||
- ❗EBS volumes have a [**volume type**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) indicating the physical storage type. The types called “standard” (**st1** or **sc1**) actually old spinning-platter disks, which deliver only hundreds of IOPS — not what you want unless you’re really trying to cut costs. Modern SSD-based **gp2** or **io1** are typically the options you want.
|
||||
|
||||
Load Balancers
|
||||
----
|
||||
--------------
|
||||
|
||||
### Load Balancer Basics
|
||||
|
||||
- AWS has 2 load balancing products - “Elastic Load Balancers” (ELBs) (now also called “Classic Load Balancers”) and “Application Load Balancers” (ALBs).
|
||||
- ELBs have been around since 2009 while ALBs are a recent (2016) addition to AWS.
|
||||
- ELBs support TCP and HTTP load balancing while ALBs support HTTP load balancing only.
|
||||
- Both can optionally handle termination for a single SSL certificate.
|
||||
- Both can optionally perform active health checks of instances and remove them from the destination pool if they become unhealthy.
|
||||
- ELBs don't support complex / rule-based routing, while ALBs support a (currently small) set of rule-based routing features.
|
||||
- ELBs can only forward traffic to a single globally configured port on destination instances, while ALBs can forward to ports that are configured on a per-instance basis, better supporting routing to services on shared clusters with dynamic port assignment (like ECS or Mesos).
|
||||
- ELBs are supported in EC2 Classic as well as in VPCs while ALBs are supported in VPCs only.
|
||||
- AWS has 2 load balancing products - “Elastic Load Balancers” (ELBs) (now also called “Classic Load Balancers”) and “Application Load Balancers” (ALBs).
|
||||
- ELBs have been around since 2009 while ALBs are a recent (2016) addition to AWS.
|
||||
- ELBs support TCP and HTTP load balancing while ALBs support HTTP load balancing only.
|
||||
- Both can optionally handle termination for a single SSL certificate.
|
||||
- Both can optionally perform active health checks of instances and remove them from the destination pool if they become unhealthy.
|
||||
- ELBs don't support complex / rule-based routing, while ALBs support a (currently small) set of rule-based routing features.
|
||||
- ELBs can only forward traffic to a single globally configured port on destination instances, while ALBs can forward to ports that are configured on a per-instance basis, better supporting routing to services on shared clusters with dynamic port assignment (like ECS or Mesos).
|
||||
- ELBs are supported in EC2 Classic as well as in VPCs while ALBs are supported in VPCs only.
|
||||
|
||||
### Load Balancer Tips
|
||||
|
||||
|
|
@ -712,6 +712,7 @@ Load Balancers
|
|||
- **Using load balancers when deploying:** One common pattern is to swap instances in the load balancer after spinning up a new stack with your latest version, keep old stack running for one or two hours, and either flip back to old stack in case of problems or tear down it down.
|
||||
|
||||
### Load Balancer Gotchas and Limitations
|
||||
|
||||
- ❗ELBs and ALBs have **no fixed external IP** that all clients see. For most consumer apps this doesn’t matter, but enterprise customers of yours may want this. IPs will be different for each user, and will vary unpredictably for a single client over time (within the standard [EC2 IP ranges](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)). And similarly, never resolve an ELB name to an IP and put it as the value of an A record — it will work for a while, then break!
|
||||
- ❗Some web clients or reverse proxies cache DNS lookups for a long time, which is problematic for ELBs and ALBs, since they change their IPs. This means after a few minutes, hours, or days, your client will stop working, unless you disable DNS caching. Watch out for [Java’s settings](http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html) and be sure to [adjust them properly](http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html). Another example is nginx as a reverse proxy, which [resolves backends only at start-up](https://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/).
|
||||
- ❗It’s not unheard of for IPs to be recycled between customers without a long cool-off period. So as a client, if you cache an IP and are not using SSL (to verify the server), you might get not just errors, but responses from completely different services or companies!
|
||||
|
|
@ -719,25 +720,30 @@ Load Balancers
|
|||
- ❗ELBs and ALBs take time to scale up, it does not handle sudden spikes in traffic well. Therefore, if you anticipate a spike, you need to “pre-warm” the ELB by gradually sending an increasing amount of traffic.
|
||||
|
||||
### ELB Tips
|
||||
|
||||
- 📒 [Homepage](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/) ∙ [User guide](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/developer-resources/) ∙ [FAQ](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/faqs/) ∙ [Pricing](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/pricing/)
|
||||
- **Best practices:** [This article](http://aws.amazon.com/articles/1636185810492479) is a must-read if you use ELBs heavily, and has a lot more detail.
|
||||
|
||||
### ELB Gotchas and Limitations
|
||||
|
||||
- In general, ELBs are not as “smart” as some load balancers, and don’t have fancy features or fine-grained control a traditional hardware load balancer would offer. For most common cases involving sessionless apps or cookie-based sessions over HTTP, or SSL termination, they work well.
|
||||
- Complex rules for directing traffic are not supported. For example, you can’t direct traffic based on a regular expression in the URL, like [HAProxy](http://www.haproxy.org/) offers.
|
||||
- **Apex DNS names:** Once upon a time, you couldn’t assign an ELB to an apex DNS record (i.e. example.com instead of foo.example.com) because it needed to be an A record instead of a CNAME. This is now possible with a Route 53 alias record directly pointing to the load balancer.
|
||||
- 🔸ELBs use [HTTP keep-alives](https://en.wikipedia.org/wiki/HTTP_persistent_connection) on the internal side. This can cause an unexpected side effect: Requests from different clients, each in their own TCP connection on the external side, can end up on the same TCP connection on the internal side. Never assume that multiple requests on the same TCP connection are from the same client!
|
||||
|
||||
### ALB Basics
|
||||
|
||||
- 📒 [Homepage](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/) ∙ [User guide](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/developer-resources/) ∙ [FAQ](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/faqs/) ∙ [Pricing](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/pricing/)
|
||||
- **Websockets and HTTP/2** are [now supported](https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/).
|
||||
- Prior to the Application Load Balancer, you were advised to use TCP instead of HTTP as the protocol to make it work (as described [here](http://www.quora.com/When-will-Amazon-ELB-offer-SPDY-support)) and use [the obscure but useful Proxy Protocol](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html) ([more on this](https://chrislea.com/2014/03/20/using-proxy-protocol-nginx/)) to pass client IPs over a TCP load balancer.
|
||||
|
||||
### ALB Tips
|
||||
|
||||
- Use ALBs to route to services that are hosted on shared clusters with dynamic port assignment (like ECS or Mesos).
|
||||
- ALBs support HTTP path-based routing (send HTTP requests for “/api/*” -> {target-group-1}, “/blog/*” -> {target group 2}).
|
||||
|
||||
### ALB Gotchas and Limitations
|
||||
|
||||
- ALBs support HTTP routing but not port-based TCP routing.
|
||||
- ALBs do not (yet) support routing based on HTTP “Host” header or HTTP verb.
|
||||
- Instances in the ALB's target groups have to either have a single, fixed healthcheck port (“EC2 instance”-level healthcheck) or the healthcheck port for a target has to be the same as its application port (“Application instance”-level healthcheck) - you can't configure a per-target healthcheck port that is different than the application port.
|
||||
|
|
@ -821,6 +827,7 @@ DynamoDB
|
|||
- DynamoDB can be used [as a simple locking service](https://gist.github.com/ryandotsmith/c95fd21fab91b0823328).
|
||||
|
||||
### Gotchas and Limitations
|
||||
|
||||
- 🔸 DynamoDB doesn’t provide an easy way to bulk-load data (it is possible through [Data Pipeline](http://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-importexport-ddb-part1.html), and this has some [unfortunate consequences](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.AvoidExcessivePTIncreases). Since you need to use the regular service APIs to update existing or create new rows, it is common to temporarily turn up a destination table’s write throughput to speed import. But when the table’s write capacity is increased, DynamoDB may do an irreversible split of the partitions underlying the table, spreading the total table capacity evenly across the new generation of tables. Later, if the capacity is reduced, the capacity for each partition is also reduced but the total number of partitions is not, leaving less capacity for each partition. This leaves the table in a state where it much easier for hotspots to overwhelm individual partitions.
|
||||
- It is important to make sure that DynamoDB [resource limits](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-data-types) are compatible with your dataset and workload. For example, the maximum size value that can be added to a DynamoDB table is 400 KB (larger items can be stored in S3 and a URL stored in DynamoDB).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue