3 Ways to manage the environments

AWS Elastic Beanstalk

AWS OpsWorks
AWS CloudFormation
Difference between Elastic BeanStalk & CloudFormation
Elastic Beanstalk is intended to make developers' lives easier. CloudFormation is
intended to make systems engineers' lives easier.

Elastic Beanstalk is a PaaS-like layer ontop of AWS's IaaS services which abstracts
away the underlying EC2 instances, Elastic Load Balancers, auto scaling groups,
etc. This makes it a lot easier for developers, who don't want to be dealing with all
the systems stuff, to get their application quickly deployed on AWS. It's very similar
to other PaaS products such as Heroku, EngineYard, Google App Engine, etc. With
Elastic Beanstalk, you don't need to understand how any of the underlying magic
works.

CloudFormation, on the other hand, doesn't automatically do anything. It's simply a

way to define all the resources needed for deployment in a huge JSON file. So a
CloudFormation template might actually create two ElasticBeanstalk environments
(production and staging), a couple of ElasticCache clusters, a DyanmoDB table, and
then the proper DNS in Route53. I then upload this template to AWS, walk away,
and 45 minutes later everything is ready and waiting. Since it's just a plain-text JSON
file, I can stick it in my source control which provides a great way to version my
application deployments. It also ensures that I have a repeatable, "known good"
configuration that I can quickly deploy in a different region.

AMI & Cloudformation

An AMI is an Amazon Machine Image. It contains the configuration to enable you to

boot up an EC2 instance with said configuration. For example, if you boot up an
Amazon Linux AMI, that AMI contains the Amazon Linux operating system pre-
installed so you don't have to do it yourself. You can also create multiple instances
from the same AMI.
Cloudformation is a templating language that allows you to describe how to build a
VPC and also allows you to create AWS services, such as ELB, RDS or EC2. A
cloudformation template can utilize an AMI as part of its build, but that's not the same
thing as saying an AMI is a subset of cloudformation.
To make my point clearer, a triangle is a subset of all shapes, because a triangle is a
specific type of shape, and a shape is less specific shape. An AMI can be used in a
cloudformation template, but it can also be used outside of a cloudformation
template on its own, one is not a more specific version of the other.

Golden Image and AMI

 A golden image is simply an image that you have customized to your liking with all
necessary software/data/configuration information ready to go and then saved as a
personal AMI from which you can launch instances.

ELB and Route 53

ELB duty is to distribute traffic to instances while making sure that the instances are
healthy to make sure your application is always available.
Route 53 has many functionality which are called polices and they are;
**simple, weighted, latency, failover and geolocation. **
Unlike ELB, with Route 53 weighted policy you can manually set the traffic
distribution for your applications like 20% traffic should be routed to instance A while
80% should be routed to instance B.
In the case of failover, both Route 53 and ELB do have similar functionality by
routing traffic to only health application or instances. But for Route 53, you use fail-
over for active passive fail-over.
Latency with Route 53 respond to DNS queries with the resources that provide the
best latency. This means that Route 53 chooses to respond to the DNS query based
on which data center gives your user the lowest latency.
Geolocation is when you want Amazon Route 53 to respond to DNS queries based
on the location of your users. But Geo-location do have a functionality of presenting
the user the ability to change the content like languages to suit the users.

 ELBs are intended to load balance across EC2 instances in a 'single' region.
Whereas DNS load-balancing (Route 53) is intended to help balance traffic 'across'
regions. Route53 policies like geolocation may help direct traffic to preferred regions,
then ELBs route between instances within one region.
Functionally, another difference is that DNS-based routing (e.g. Route 53) only
changes the address that your clients' requests resolve to. On the other hand, an
ELB actually reroutes traffic.
One analogy is: if you ask for the closest WalMart, you may get an address based on
your location, but you could choose to go to another Walmart if you know one. That's
Route 53; it just switches the address resolved based on some context. On the other
hand, a policeman redirecting traffic because of construction, is more like an ELB,
he/she is actually changing the traffic flow, not just suggesting.
There are additional considerations about whether DNS-based routing versus Load
Balancing is best for your use case, and why (or if) Route53 and ELB continue to co-
exist, but hopefully this helps at a high-level.
Both Route53 and ELB are used to distribute the network traffic. These AWS
services appear similar but there are minor differences between them. 

1. ELB distributes traffic among Multiple Availability Zone but not to multiple Regions.
Route53 can distribute traffic among multiple Regions. In short, ELBs are intended to
load balance across EC2 instances in a single region whereas DNS load-balancing
(Route53) is intended to help balance traffic across regions.

2. Both Route53 and ELB perform health check and route traffic to only healthy
resources. Route53 weighted routing has health checks and removes unhealthy
targets from its list. However, DNS is cached so unhealthy targets will still be in the
visitors cache for some time. On the other hand, ELB is not cached and will remove
unhealthy targets from the target group immediately. 

Use both Route53 and ELB: Route53 provides integration with ELB. You can use
both Route53 and ELB in your AWS infrastructure. If you have AWS resources in
multiple regions, you can use Route53 to balance the load among those regions.
Inside the region, you can use ELB to load balance among the instances running in
various Availability Zones.
Content Delivery & Domain Name System

CloudFront is a content delivery network (CDN) that allows you to store (cache)
contents at “edge locations” located all around the world. This allows customers to
access your content more quickly (and also provides additional security – especially
against DDos attacks)
EBS vs EFS vs S3

EFS is:

 Generally Available (out of preview), but may not yet be available in your

region
 Network filesystem (that means it may have bigger latency but it can be
shared across several instances; even between regions)
 It is expensive compared to EBS (~10x more) but it gives extra features.
 It's a highly available service.
 It's a managed service
 You can attach the EFS storage to an EC2 Instance
 Can be accessed by multiple EC2 instances simultaneously
 Since 2016.dec.20 it's possible to attach your EFS storage directly to on-
premise servers via Direct Connect. ()

EBS is:

 A block storage (so you need to format it). This means you are able to choose
which type of file system you want.
 As it's a block storage, you can use Raid 1 (or 0 or 10) with multiple block
storages
 It is really fast
 It is relatively cheap
 With the new announcements from Amazon, you can store up to 16TB data
per storage on SSD-s.
 You can snapshot an EBS (while it's still running) for backup reasons
 But it only exists in a particular region. Although you can migrate it to another
region, you cannot just access it across regions (only if you share it via the EC2;
but that means you have a file server)
 You need an EC2 instance to attach it to
 New feature (2017.Feb.15): You can now increase volume size, adjust
performance, or change the volume type while the volume is in use. You can
continue to use your application while the change takes effect.

S3 is:

 An object store (not a file system).

 You can store files and "folders" but can't have locks, permissions etc like you
would with a traditional file system
 This means, by default you can't just mount S3 and use it as your webserver
 But it's perfect for storing your images and videos for your website
 Great for short term archiving (e.g. a few weeks). It's good for long term
archiving too, but Glacier is more cost efficient.
 Great for storing logs
 You can access the data from every region (extra costs may apply)
 Highly Available, Redundant. Basically data loss is not possible
(99.999999999% durability, 99.9 uptime SLA)
 Much cheaper than EBS.
 You can serve the content directly to the internet, you can even have a full
(static) website working direct from S3, without an EC2 instance

Glacier is:

 Long term archive storage

 Extremely cheap to store
 Potentially very expensive to retrieve
 Takes up to 4 hours to "read back" your data (so only store items you know
you won't need to retrieve for a long time)

In short

 S3 is a storage facility accessible any where

 EBS is a device you can mount onto EC2
 EFS is a file system you can mount onto several EC2 instances at the same
time

https://developer.ibm.com/recipes/tutorials/a-step-by-step-guide-choosing-aws-
storage-options-ebs-efs-and-s3/

API Gateway vs Application Load Balancer

Elastic Beanstalk vs Elastic Container Service (EC2 Container Service)
EB vs ECS really comes down to control. Do you want to control your scaling and
capacity or do you want to have that more abstracted and instead focus primarily on
your app. ECS will give you control, as you have to specify the size and number of
nodes in the cluster and whether or not auto-scaling should be used. With EB, you
simply provide a Dockerfile and EB takes care of scaling your provisioning of number
and size of nodes, you basically can forget about the infrastructure with the EB route.

With ECS you'll have to build the infrastructure first before you can start deploying
the the Dockerfile so it really comes down to 1) your familiarity with infrastructure and
2) level of effort that you want to spend on the infrastructure vs the app.

Security Groups and Network ACLs

Security group is the firewall of EC2 Instances whereas Network ACL is the firewall of
the Subnet.