Hi, these are the notes I took from the lectures.

I think this can be very useful to refresh your

memory before the exam. I wrote them very fast and there may be typos, this will not make sense
to read without watching the lectures, so read this after. Let me know if you find any mistakes.

PART 1: Classic Managed AWS

IAM

You need to select a region for all services besides IAM and S3

Root user is created with the account and should not be used.

IAM: User, Groups(teams, users) and Roles(machines). You apply permissions using policies in
JSON to users, groups and roles. A policy has resources events and actions.

IAM Federation is using SAML standard to use your IAM solution for example LDAP active
directory.

To log into EC2 instance use ec2-user@publlicIP  use -i and then pem file with the key, run chmod
0400 to give the right permissions to the pem file.

Use tag with key Name so you can add a name so it is show in the console.

Security groups are logical groups or firewall rules for the EC2 instances. Many to Many relation.
Locked down to region. By default all inbound traffic is not allowed and all outbound allowed.

You can reference other security groups to extend functionality.

A elastic IP is a public IP that you own and never changes, you can use it to mask failure or if you
need a constant IP but is is better to setup DNS names and use random IPs.

Use load balancer instead of setting IPs.

You get bill for elastic IPs.

Use EC2 user data field to execute programs during provisioning, so you can add your apps to
run at bootstrap like installing Apache. Is used to bootstrap the instance and only runs once.
Runs with root user. Click Advanced details and paste the script you want.

AMI are EC2 OS images, you have Amazon on linux based on Fedora, Red Hat, windows... you
can create your own images and then create all your instances with them. You need this if you
have proprietary software, extra security or federation is required to access your company LDAP.

Customs AMI are made for a specific region.

Instance names start with letters to give meaning: R -> RAM, G -> GPU, etc... M are the balanced
ones and T the burstable, you have burst credits you can get in advance and if you get a spike,
your CPU will burst and handle them until you run out. Credits are given as part of the instance
and once used you recover them over time, you will never pay unless you do T2 unlimited. There
is T2 unlimited which if you run out of credits then you will be charged.

Ec2 are billed per second.

ELB: spread load, expose DNS handle failure, SSL termination, cookie stickiness, HA zones and
separate public from private traffic.

AWS guarantees HA on the ELB and maintenance. 

3 ELB: classic which is not recommended and then you have the v2 version which are application
and network load balancers. You can setup private or public ELB. 

Application load balancers  ALB  are level 7 and they can handle multiple http apps even in the
same machine, you can use the url or hostnames to balance. It is great for microservices, it
support dynamic port mapping to run multiple containers on the same EC2 instance. The new
app balancer is much cheaper because it can handle multiple apps. 

You can bundle multiple ec2 instances into target groups that are the same app/route. So you
can scale and maintain cookie stickiness. 

You can enable stickiness at the app level transparent to the app.

ALB support HTTP/s and websockcets, classic load balancer does not support web sockets. 

The application servers doesn't see the IP of the client directly, it is in the X-Forwarded-For
header set by the ELB. This is because the ELB does connection termination including SSL then
redirects so the EC2 see the ELB ip, to get the client use the header.

Network load balancers CLB are level 4, lower level and are for TCP traffic. Really high
performance and low latency. 

CLB/ALB both have ssl termination and healthchecks.

ALB is great for docker because it can route based on port and path

All ELBs have static host names, but not IPs, do not use IPs.

ELBs can scale but not instantaneously. NLBs see directly see the client IP, ALB use forward
headers. 503 error means ELB is running out of capacity.

You can use auto scaling to automatically register new instances to the load balancer. Scale out
is adding instances and scale in removing. You need to define auto scaling groups ASG and the
balancer will use it to register new instances. 

ASG needs the same type of info as EC2 including AMI, EC2 user data, EBS volume, security
groups, etc. You also need to specify min, desired and max capacity. You also need to specify
the network and subnet settings, the load balancer info. and the scaling policies, that is when to
scale in or out. This can be done using Cloudwatch which is the monitoring service in AWS, they
do have alarms. so you can trigger scale in/out based on the triggers in the alarms. Some of the
alarms can be based on avg cpu usage, number of request in the ELB, network usage, etc. You
can also create custom metrics in cloud watch. Even you can scale based on a schedule. IAM
roles attached to an ASG will be assigned to the EC2 instances. ASG is free, you pay for the
instances. If you create ASG for you instances, with a min number if you terminate them, the AGS
will provision a new one to meet the min req. ASG will terminate unhealthy instances. 

Load balancers and ASG are under the menu in EC2. First you need to create a launch template
and then the ASG. The template is to create new EC2 instances, so the config is the same as for
creating an EC2 instance, this way you enforce that all of them are the same type. When creating
a ASG it is recommended that you go to advanced details and select load balancing so it works
with the ELB, just select the target group previously created for the ELB. You can reuse the health
check for ELB. You can attach and detach instances to the ASG, it is best practice that all ec2
instances are part of an ASG and ASG are part of target group for the ELB. So load balancers and
ASG work together.
EBS is elastic block storage which is a network drive that you can attach to instances while they
run, so you keep the data if the instance is terminated or if you want to store data and persist
data. You can attach the EBS volume and then attach it to a different volume so you keep the
same data between instances. EBSs are locked to availability zones. You cannot transfer it
between the data centers, you can move it by taking a snapshot and then copy the data to
another AZ.EBS they have a provision capacity(size and IOPS).  You can attach multiple volumes
to the same instance. you have EBS types such SSD, HDD and the price differs. GP2 are the avg
which are cheap and SSDs. You can increase EBS capacity at any time. You can take snapshots
to backup data or to transfer between AZ. You can schedule snapshots. You can create an EBS
encryption, all snapshots are encrypted. The data between EBS and the instance is transferred
encrypted. All volumes created from snapshots are encrypted. Data is encrypted at rest and in
flight, it has slow latency. Copying an unencrypted snapshots forces encryption automatically. 
Some EC2 instances do not have EBS, they use instance store, which means that the root volume
is attach to physical drive, not network like EBS, you get better performance but you lose the data
on termination and you cannot resize, also backups must be handled by the user. EBS backed are
recommended unless you really need the performance. Each EBS volume can be attach to just
one instance and one instance can have many volumes. EBS are locked to the AZ, you can
migrate by taking a snapshot and copying it. Snapshots use IO and impact performance, take
snapshots when the load is low. Although EBS volumes are persisted and you can attach/detach
them from instances, by default the EBS volume will be terminated with the instance, you need to
click the check box during creation to tell AWS not to terminate the volume. 

Route 53 is a managed DNS which is a collection of rules and records to help clients reach
servers using urls. the most common records are A: url to Piv4, AAAA URL to IPPv6, CNAME for
url to url and Alias utl to aws resource. Route 53 can work with public or private domains. It also
has load balancing using DNS not IP, called client side load balancing, health checks and routing
policies based on geolocation, failover, latency,etc. Use Alias instead of CNAME because it is
faster.

RDS is a relational database managed service, it is a managed relation database, it is a service

that manage an underlying RDBMS, not a DB itself like DynamoDB. You can use Postgres, Oracle,
MySQL, MariaDB, SQL Server and Aurora which is AWS proprietary. Because the DBs are
managed by RDS you get lots of things for free like patching, backups, monitoring, DR, scaling,
maintenance. replicas, etc. but you cannot access directly using ssh because they are AWS
managed. 

You can create up to 5 read replicas for RDS across any AZ or region. Replication is async so
there could be a small delay, eventual consistency. Replicas can be promoted as its own DB so it
can write. Applications must update the connection string to read from replicas, so it is not
totally transparent. 

Multi AZ is used for DR, it does sync replication between the master an stand by node which is
not live, it takes over just if the master fails. It uses DNS failover, so both DBs have the same dns
name, this is done transparent by AWS. So AZ replicas are read only live replicas for performance
and Multi AZ is standby for HA. RDS uses nightly backups by default with 7 days retention policy,
you can restore at any point in time. It also captures logs in real time. You can also do manual
snapshot and they will not be deleted. RDS uses encryption at rest using AWS KMS AS 256, you
can use SSL for in flight encryption. To enforce SSL it differs on the RDBMS. In Postgres
rds.force_ssl=1 to connect to an SSL DB you need to enter the SSL trust certificate that can be
downloaded from AWS. You should deploy RDS DBs in a private subnet. They also use security
groups like EC2 to enforce who can access. IAM policies are used to control who can manage
the DBs.  MySQL and Aurora can leverage IAM users instead of having a separate username and
password.

Aurora is not a full DB, is is based on MySQL and Postgres, so drivers are compatible it is cloud
optimized performs up to 5x better and can dynamically grow. Use Aurora if you don't care much
about portability. It can have up to 15 replicas and has instant failover but it is a bit more
expensive. Without Aurora you need to setup the replicas and failover. 

ElasticCache is a managed cache service using Redis or Memcached to improve read

performance or add state to stateless apps such as serverless. They use sharding, multiple
replicas, multi az failover, etc. AWS takes care of all maintenance: monitoring, patching, failover,
etc. Elastic Cache is used a lot with lamba or stateless micro services to use it for session
management or JWT token management. Redis is the most popular choice, it is in memory but
persistent into disk (async) so it survives restart. Great for user sessions, distributed states, it
has pub/sub queue. It has multi az failover. Memcached is 100% in memory, but Redis is more
popular. 

A VPC it is your own private cloud, you can create them inside a region. This isolates you from
the rest. Each VPC contains subnets, each subnets is inside an AZ. You usually have private
subnets to have the DBs and services and the public ones to have the public HTTP servers. It is
common to have several subnets inside each AZ. In public subnets you put: Load balancers, api
gateways, files and static content, and authentication. In private you have the servers and
databases. Public and private can talk to each other. Public have access to the outside, private
don't. You can use a VPN to access your VPC and see all the private network. VPC flow logs are
used to monitor the inbound and out bound traffic from your VPC. You can have several VPC in
your account, one per region. You can peer VPCs so they look like they are part of the same
network even if they are in different regions. 
S3 is the simple storage solution of AWS and the most famous service used for small and big
data files. Buckets are object containers that can be folders and files. Buckets must have global
unique names although their are defined at a region level. Names must be underscore and not an
ip. Objects have keys which is the full file.  Internally there are only objects inside buckets, but the
UI offers folders but these are just logical paths which are the keys. The max value of an object
is  5TB. More than 5GB you need to use multi part upload. You have meta  data and tags, there is
also a version ID because you get versioning, but you need  to enable it.

S3 is a global service that's why the bucket ID is unique, you do not have a region,however when
you create a bucket you need to select a region. This is because the bucket will have a unique
DNS name and these are global.

File versioning is enabled at the bucket level for all files. If you update a file a new version is
created automatically. You can enable versioning at any time, if there are files already their
version will be set to null and any changes from there will have a version.

4 encryption methods on s3: SSE-S3 uses keys managed by AWS, SSE-KMS uses AWS KMS
service to manage keys, SSE-C you provide your own keys for encrypt, Client side encryption you
manage. 

SSE-S3: mamaged by AWS, AES-256, encrypted servers side and must set header x-amz-server-
side-encryption:AES256 when you send file to S3, Amazon provides the key.

SSE-KMS: uses KMS service so you have more control on the expiry and audit trail you also need
to pass the header. You manage the lifecycle.

SSE-C: server side encryption using your keys that you manage, AWS doesn't store it, so you need
to pass the public key in the upload request using headers, because of this you must use HTTPS.

Client side encryption: you encrypt and decrypt AWS doesn't do anything.

AWS exposes https for encrypted data and http for non encrypted. Encryption in flight is called
SSL/TLS.

Two types of S3 security user based (IAM policies, based on API calls), Resource Based: bucked
policies which is the most used and are wide rules you set in the console. Object ACL finer grain
and Bucket ACL. Bucket policies are json files with resources, actions and effect(allow/deny) and
principal (account or user). you can grant public access, force objects to be encrypted on upload
and grant access to other AWS accounts. S3 supports VPC end points for instances without
public access so instances in the private network can access the file. You can have S3 access
logs and store them in other buckets. API calls can be logged in cloud trail. MFA can be used for
extra security. You can create signed urls which are available for a limited time only. There is a
policy generator that you can use to generate JSON policy
documents: https://awspolicygen.s3.amazonaws.com/policygen.html 

You can setup websites in S3 using s3-website prefix, make bucket public.

If you request data from another bucket you need to enable cors. Is common to have images in
another bucket but you don't want public access but thru website bucket so enable cors to set
origin.
S3 uses eventual consistency you can put and read and get an object immediately but if you do a
get first and got 404 you may get it right after you put it, same as update or delete.

For the best S3 performance you want the highest partition distribution. Historically it was
recommended to have random characters in front of the key name like "g65d_my_folder/" so the
data is partition properly. Never use dates as keys since the partition will be very similar. Since
July 2018 you don't need random characters and the performance is much better  > 3500TBS but
this is not in the exam.

More than 5GB you need multipart uploaded to maximize bandwith and decrease time on retries.
CloudFront is used to cache S3 objects. If you are in a different region and need to do a big file
upload use S3 transfer acceleration which uses edge location to upload temporally to a local end
point improving performance. If you use KMS encryption you may see a small performance
decrease because KMS has bandwidth limits.

CLI: You install the CLI using python, then use aws command. First create access keys in IAM
and use aws configure to enter credentials. Then start using aws, for example aws s3 ls.
You can use the cli inside an EC2 instance but this is a bad practice, do not use your credentials
anywhere. To use the cli in the EC2 use IAM roles which can be attached to EC2 instances, roles
come with a policy authorizing what the ec2 can do. You can assign a cli role to ec2 instance to
use cli. aws cli is already installed in aws linux amis but do not use aws configure to set the keys,
you can set the region if you want. You need to create a role and attached to the ec2 service,
once you have the role click on the instance and select attach role.
You can create your own policies and assign them to roles, you can also create inline policies
specific for just one role, but this is not recommended.  Policies have versions to track changes.

There is a AWS policy simulator to test your policies. Many commands have the --dry-run option
to test calls without being charged, this is perfect to test for permissions.

The STS command line tools is used to decode errors: aws sts decode-authorization-message.
You need DecodeAuthorizationMessage permission in the role to run the command.
EC2 instance metadata is a powerful tool so instance learn about themselves and what
permissions they need without using an IAM role for that purpose. The metadata is the info
about the instance and can be retrieved at http://169.254.169.254/latest/meta-data which is a
private IP. This metadata is heavily used for automation and to run scripts.

AWS has a SDK to access its services. Java, Python, Node.js, C++, etc. AWS cli is based on the
python sdk. The SDK is used to deal with DynamoDB and other services. To use the SDK use the
default credential provider chain in the user directory aws/credentials. You can also use ENV
variables not recommended but useful for docker images. Never use credentials in the code. For
API calls from the SDK AWS implements exponential backoff so if you make a request and it fails
the SDK will automatically retry but each times it waits the double to not overloaded. 

If you have multiple AWS accounts you can use profiles using aws configure -- profile, so you can
use the CLI with multiple accounts. 
Elastic Beanstalk is a developer centric simple view to manage your apps which leverages on the
existing components like elb, rds, AGS, etc which are easier to manage, it is a CI tool. Beanstalk
manages your instances like os, configuration, etc and also runs the deployment strategy defined
by you. It is key for ci. It has 3 components: your app, the app version and the environment (test,
qa, prod). You can promote a build through the environments or rollback. It is free to use. Many
platforms are supported including docker. Each app can have many envs, each env many
versions. You can choose web server or worker type (batch). Beanstalk can create a DB but it is
better to externalize it since if you delete beanstalk you lose the DB.

Deployment Modes:  

- Single Instance: great for dev, DNS name is Elastic IP

- HA with load balancer: ELB with the DNS name and many instances. Multi AZs. Auto scaling
group. 

4 kind of deployments for HA:

- All at once: very fast and simple but small downtime. No additional cost

- Rolling: You update some of instances call bucket and once is healthy move to the next. You are
under capacity during the update but no additional cost. It can be a long deployment.

-Rolling with additional batches: like the other but spins new instances to maintain same
capacity during the update and then once completed the old ones get deleted. Long deployment
and extra cost. You have a new extra bucket, so it cost extra.

- Inmutable: Spins new instances in a new ASG and when done it switch the ASG. zero downtime
and brand new instances, high cost because you replicate cluster and it takes long but you get a
quick rollback, you just switch to the old ASG.

- Blue/Green: create a brand new environment, test it independently. Then use Route 53 to start
directing traffic in bits until you are happy.

You can use EB extensions files to configure the deployment. The directory must in the root of
the src code and must be called .ebextensions and the config must be in yaml or json. the
extension must be .config like logging.config. You can use these files to modify default setting or
to add resources like RDS or DynamoDb. 

There is also a EB cli specify for Elastic Bean and you can eb create, status, etc.to manage
environments and versions. Very helpful for CI/CD. Eb relies on CloudFormation which is a
service. Usually you resolve dependencies when you install like npm install, but when you have
many instances, and you need to do npm install in all of them, it is better to do npm install in one
machine and then create the zip file with the dependencies inside.

AWS CI equivalents: Github->CodeCommit, Jenkins->CodeBuild. To deploy you can use

BeanStalk or CodeDeploy. AWS CodePipeline is used to orchestrate all the tools CodeCommit,
CodeBuild, BeanStalk etc. 
CodeCommit is a private GIT with no size limit and fully managed and secure. You can integrate
it with Jenkins. Security: SSH keys, HTTPS (generate credentials), it supports MFA. It uses IAM
policies for authorization. Repositories are encrypted at rest using KMS. In transit uses HTTPS.
For cross account access do not use ssh keys or aws credentials, use IAM role and then use
AWS STS to access. Both github and code commit integrate with
CodeBuild. CodeBuild integrates with IAM roles with github you have other users. Github
Enterprise is hosted in your servers. CodeCommit UI it is worse. CodeCommit can integrate with
AWS SNS for notifications or AWS Lambda or CloudWatch event rules. Alerts for deleting,
pushes, you can run AWS lambda functions to respond to events. CloudWatch rules are uses for
pull request or when a comment is added. CloudWatch rules uses SNS under the hood.

CodePipeline: CD with visual workflow. Source: Github/CodeCommit, build, load test, deploy
(AWS CodeDeploy, BeanStalk). It is made of stages each stage can have sequential or parallel
actions. Stages: Build/Test/Deploy/LoadTest... You can define manual approval step. 
CodePipeline works with Artifacts. Each stage can create several artifacts which are passed and
stored on S3 and passed to the next stage. Each stage changes will generate a CloudWatch
event which can trigger sns notifications. CloudTrail can be used to audit AWS API call. You
attach roles to pipelines and must have the right permissions to perform the actions.

CodeBuild: build and test like Jenkins. It is fully managed by AWS which handles provisioning
and scaling. You pay for the usage only. It uses Docker under the hood and you can create your
own images. It is secure, integration with KMS/IAM/VPC... it uses cloud train for audit. 
Takes code from CodeCommit/github. Build instructions are defined in the code in the
buildspec.yml file. Outputs log are output to S3 and cloudwatch logs. There are also metrics to
monitor and get statistics. You can use cloud watch events and AWS lambda for alerts and
notifications that can use SNS. You can reproduce CodeBuild locally to troubleshoot errors.
Pipelines can be defined with CodePipeline or CodeBuild itself. CodeBuild support Java, Ruby,
Python,Go, Node, .Net, etc.... You can use Docker to use any other platform. You have Source
code with the buildspec.yml. CodeBuild will create a image with the code and run it on a
container. There is an optional S3 bucket for cache. Artifacts are stored in S3. Logs are saved in
S3 and CloudWatch. buildspec.yml must be in the root o the code. You can define env Variables,
you can use secrets using SSM parameter store. You define phases: install(dependencies), pre
build, build and post build. Artifacts are generates and stored in S3, cache is also based on S3.
You can run CodeBuild locally using CodeBuild Agent.
CodeDeploy: deploy app into many EC2 instances which are not managed by Elastic Beanstalk.
Similar to Ansible, Chef, Puppet... Each ec2 machine must run the CodeDeploy agent. The agent
is continuously pooling AWS codeDepploy for work to do. CodeDeploy sends appspec.yml which
has the instructions with the source code, then the app is pulled form GitHub or S3, EC2 will run
the deployment based on the yaml instructions and the agent in the EC2 instance will report
success/error. EC2 instances are grouped by deployment group (dev,test,qa...). CodeDeploy can
be chained into CodePipeline and use artifacts from there or other tools like auto scaling groups.
CodeDeploy is more complex than BeanStalk but more flexible and supports blue green
deployments but only on cloud, It supports lambda. It doesn't provision EC2 instances so they
need to be ready. Deployment configuration: deployment rules for success or failures for
example the minimum number of healthy instances.  Compute platform: Ec2 or lambda.
Deployment type: in place or blue/green.  IAM instance profile needed to give EC2 the
permissions to pull from S3/Github. Application Revision: application code + appspec.yml.
Service role: Role for CodeDeploy to perform operations. Target revision: target deployment app
version.

AppSpec file: File section: how to source and copy from S3/Github. Hooks: set of instructions to
deploy a new version. The order is StopApplication, DownloadBundle, BeforeInstall, AfterInstall,
ApllicationStart, ValidateService(it is healthy)
Configs for Code Deploy: one at a time, half at a time, all  at once (quick but downtime), custom.

Failures: instances stay in failed state, new deployments will first be deployed to failed instances.
To rollback redeploy old deployments or enable automated rollback.

Deployment Targets: Set of EC2 instances with tags, directly to ASG, mix ASG/tags or
customization scripts using ENV variables. BeanStalk uses CodeDeploy under the hood. 

For blue/green deployment there are BeforeAllowTraffic and AfterAllowTraffic hooks to test it is
healthy. 

CodeBuild-> buidspec.yml   CodeDeploy-> appspec.yml

AWS OpsWorks is a configuration management service based on Chef that allows managing and
deploying complex application stacks on AWS. 

Cloud Formation: Infrastructure as Code. Traditional CI/CD is hard to reproduce in another region

or different AWS account. Infrastructure as code is turning infrastructure into code. Automate
infrastructure. Cloud Formation is a declarative way to provision infrastructure. We just tell them
what we need (Load balancer, security groups, instances, etc) and cloud formation goes and
does it for you. No resources are manually created, everything is automated and the declarative
code can be in git. Changes in infrastructure are code reviewed. No additional costs just what
you provision, you can estimate the cost with templates. You can have your whole environment
provision and deleted, companies they do provision the dev envs at 8 and destroy them at 5pm to
save costs. Separation of concerns: there are different stacks: vpc, network, and app stacks.
There are lots of cloud formation templates with stacks you can reuse. You upload the templates
in S3 and cloud formation will read it. Stacks are identified by names and if you delete the stack
you delete everything (not good idea to provision your DBs there). There is a cloud formation
designer but you can use yaml file with templates for automation using AWS cli. Building blocks:
Resources, parameters, mappings, outputs, conditionals and metadata. You can have template
helpers with functions. 

Resources are mandatory and there are over 200.  They can reference each other and they
represent AWS components. AWS::aws-product-name::data-type-name. Everything you click in
the UI manually is translated into the yaml format this way it can be automated. You cannot
create things dynamically in Cloud Formation, it needs to be declared in the template.. There are
few AWS services not supported but you can use AWS Lambda custom resources to use them.
Parameters are used to pass inputs to the template, very useful to reuse templates. So they are
like custom fields. Use Fn::Ref function to reference parameters like vpcId: !Ref MyVPC. !Ref can
be used to reference other parameters or even reference resources. Pseudo parameters are
custom parameters provider by AWS like AWS::AccountId.

Mappings are hardcoded values in the template, great to define env specific values. If you know
the values in advance by deriving then from other values like region you can set up safety
templates than using parameters. Use !FindInMap function to get values based on keys. Outputs
are optional and can be used as inputs to other templates. You need to export them and the you
can use them in other templates, console or cli. Each team can own a template like the network
team can have the network template and export the vpc id as output for devs to refer. You
cannot delete a stack if its outputs are used by other stacks. Use Export: block to export the
value using a name, then use !ImportValue using the export name. Conditions: have conditions
using equals and other operators. CreateProdResources: !Equals [ !Ref EnvType, prod] ->if prod.
So you define conditions and then use Condition: to use it. Intrinsic Functions: !Ref-> reference
parameters.  !GetAtt get attributes from resources, like Ref but ref only returns the ID of the
resource but getAtt you can get anything. ImportValue-> previously exported. !Join -> join values
to create resources. !Sub -> substitute values in Strings. By default is something fails the whole
stack gets deleted. There is an options to disable this. If you update and it fails it goes back to
previous state. You can check the log to see the messages.

CloudWatch: Metrics, logs , events, alarms. Can send notifications using SNS.

AWS X-Ray: Similar to Istio, has distribute tracing, performance monitor, troubleshooting.

CloudTrail: Internal monitoring and audit changes of resources. 

Cloudwatch has metrics for all services. Metrics belong to namespaces. Dimension is an

attribute of a metric, we can have up to 10 per metric. Metrics have a timestamp. We can build
dashboard. EC2 comes monitor with metrics every 5 min, if you want faster enable detailed
monitor and pay for it. Memory usage is not pushed by default, you need a custom metrics. By
default custom metrics are push every one minute. You can enable high resolution to go up to
1s. To send a metric you need to use the API call PutMetricData which uses the exponential back
off strategy to handle error throttling. 

Alarms can be attached to auto scaling, ec2 actions, sns notifications... States: OK,
INSUFFICIENT_DATA and ALARM. Period: time to evaluate the metric that triggers the alarm,
enable high resolution for faster.

Clodwatch logs: log aggregate. apps can send logs using the sdk, agents can run agents to send
logs to cloudwatch, most of the services send by default. The logs can best archived in S3 or
send to elastic search. You can use filters in cloudwatch. Logs are grouped in group and each
app is a stream. You can tail using sdk and also define expiration policies. You need to have
proper permission in aim to stream logs. logs are encrypted at a group level using kms.
Cloudwatch Events can be schedule: as cron jobs, event pattern rules in cloudwatch. You can
call lambda functions, send sns notifications, etc. They use json format.

AWS X-Ray. Distributed tracing, logging and monitoring. Troubleshoot performance, understand
dependencies, review requests, bottlenecks, etc. It is compatible with many services. Each trace
has several segments, one for each call. You can add annotations to the traces.  You can trace
every requests or aggregate them. There is IAM access control and KMS encryption at rest. Your
code must use X-ray sdk. You need a small code modification not like Istio. The code snippet will
capture: AWS calls, http calls, database calls, sqs calls, etc. You need to also install x-ray
daemon or enable the AWS integration for x-ray. AWS lambda and other services already run the
daemon. You need IAM write rights to send data to x-ray. Make sure that Lambda has the proper
role. For EC2 besides the role you need the daemon.

AWS cloud trail provides governance, compliance and audit for your account. It is enabled by
default. You get a history in the console from any change in the console, sdk, cli or AWS service.
You can put logs from cloud trail into cloud watch. If a resource gets deleted you can find the
event in cloud trail and see what happened. Everything you do in AWS is tracked here, great for
audits.
AWS has Amazon ES which is the elastic search and Kibana offerings that can be used to analize
cloud watch logs. Athena big data analysis tool can also query logs.
AWS config is a fully managed service that provides resource inventory, config history, config
change notifications and more. 

Messaging
SQS for queue model, SNS for pub subscribe and Kinesis for stream processing, these are ways
to decouple service calls  using async calls, this extra queue layer is great for back pressure, if
you get  a spike in traffic the queue will hold messages so the receivers will not go down. 

SQS: 3 types of queues. Standard: fully managed, oldest offering, scales from 1 to 10.000
messages per second and holds them for 4 days by default and 14 max. Low latency < 10ms,
horizontal scaling using consumers. It may be duplicate messages and out of order. Max size
message is 256kb. Delay queue: can delay messages up to 15min, default is 0. DelaySeconds
parameter. It has a body and then key value properties called meta data. In SQS consumers poll
the data and can receive up to 10 message at a time. Consumers must process the messages
within the visibility timeout period, the delete the message with the ID and a delete handle
function. If there are multiple consumers each one will get the message one by one and the
consumer needs to process it within the visibility timeout during this time other consumers will
not see it. After the time out they will. the default timeout is 30 sec and the max 12 hours. If the
operation is idempotent set it low for performance and if one message takes too long it will get
process more than one. If not, you can still use the ChangeMessageVisibility API which allows
you to request more time. Dead Letter Queue: 3rd type, failed messages go back to the queue in
the standard queue, if the problem is the message a loop will be created, you can set a redrive 
policy to stop the loop and then use the dead letter queue to send error messages.  To avoid
many api calls you can enable long poling up to 20 seconds where consumer will wait if there are
no messages. Set WaitInSeconds to set the value. They charge per api call so long poling is
cheaper. FIFO queue is newer queue not available in all regions, less throughput < 300 but exactly
one warranty and order. You can set consumer groups based on content and have automatic de
duplication based on the body hash.

For large messages use SQS extended client that leverages on S3, body is encrypted but not
metadata, so do not put sensitive data. No VPC end point for SQS, you need internet connectivity.
PurgeQueue to delete all messages in queue. There is a batch API you can use to decrease cost.
SNS: pub subscribe. a producer sends a singe message to a topic and many subscribers
consume the topic, subscribers can be SQS, http end points, lambda, email, sms, push
notifications. It integrates with many services: Cloudwatch, cloud formation, s3, etc. You need
mobile sdk to send push notifications. A common pattern is the SNS + SQS fan out where you
put a message once in SNS and this is sent to many SQS queues. This is the overcome the
problem that SNS doesnt hold the messages and SQS does. 

Kinesis is a managed alternative to Kafka, although recently they released KMS managed kafka
since it is better than kinesis. Compatible with Spark. It is HA using 3 AZs.It has several APIs like
Kafka: streams, analytics (ksql) and firehorse(connect). Retention from 1 to 7 days. You can
replay data. You need to define shards(partitions) in advanced and you are billed per shard. You
can batch calls. Hot partition problem is when you use a key that is not evenly distributed so
most of the messages go to the same partition. You can use SDKs or cli.
ProvisionThroughputExceeded is thrown is you sent too many messages, just retry, add more
shard or make sure you dont have a hot partition. Besides the SDK you can use the client library
KCL which uses DynamoDB to track the offsets. Data Base64 encoded. You can use Kinesis
inside your VPC. Data Analytics: real time sql, can create new streams, you pay for the data you
consume, it has auto scaling. Firehorse is for ETL, a bit more latency, many data formats but you
pay for conversion. You pay for data. SQS and Kinesis consumer pull data and SNS they get
push. Kinesis only one consumer per shard. You must provision your throughput in advance for
Kinesis not in SQS.

PART 2: SERVERLESS

It is anything that doesn't require managed infrastructure. Started with Lambda and Faas but
now it has authentication and storage like DynamoDB. The idea is that you don't deploy services
but code as functions, or in DB, you do not manage a database just store data. EC2 you need to
provision in advance, they are continuously running, you need to bootstrap them and do other
management. You are limited by RAM and CPU. 

Lambda are virtual functions that run when called and they automatically scale without
intervention, they are short lived and you pay per usage. It integrates with many services and it is
the glue between them based on events. Supports many languages and it is integrated with
cloud watch for monitoring. You need to define the RAM in advance but it is easy to get and it is
based on the code not load. It is very cheap. Functions have roles to define what can they do in
the AWS infrastructure. 

Configuration: timeout is the max execution time, by default is just 3 seconds. Max 300. You
send ENV variables, set RAM, you can deploy in your VPC. Lambda functions can have up to
1000 parallel executions. You can set reserve concurrency to lower the value, once the max is
passed throttling takes place. Throttle error is 429. You can run the functions async and they will
retry 2  times after that they go to the DLQ queue which can be SNS or SQS. You need to add SNS
and SQS permissions to the role to write to the queue. Lambda is integrated with X-ray. You can
write to tmp folder up to half GB. If you upload a function it must be a zip file up to 50mb and
uncompress 250mb. Functions have versions. $LATEST is the last one which is mutable, then
you publish a immutable version. a version is the code and configuration. Aliases are pointers to
lambda versions this way you can have your dev,test, prod environment and point them to
different function versions. You can do blue green and canary deployments with lambda and
assign certain percent of traffic to different versions. So users interact with the same arn and
you can rewire the aliases. Do heavy work like connect to DBs outside the handler otherwise you
will re initialize the connections. Use env variables, do not hard code urls. Encrypt passwords
with KMS. Break down big functions. do not use recursions and VPC is slower so try to avoid.
Lambda invocation type: RequestResponse sync or Event async. Increased RAM will also
allocate more CPU and network bandwidth.

The code package is stored in s3 and on first invocation the code is pull and a set of containers
are created using cloud formation, this enables hot invocations.

It is common to write lambda functions for ci/CD that do integration test simulating event
sources using the invoke api, or functions that update the aliases, this is done thanks to events
trigger by code pipeline that can call lambda.
AWS CodeStar is a unified UI for creating serverless apps using best practices. It comes with a
pre build pipeline for serverless apps.It comes with member management, issue tracking and
operations.

Dynamo DB: NoSQL, no direct supports for joins or aggregations like join, no relational data but
distributed horizontal scaling which is great for lambda. By default Dynamo is highly available
using 3 AZs. Highly scalabable and serverless, you do not manage it. Millions of request per
seconds, fast and consistent performance, integrated with IAM. You can do event driven
programing using Dynamo Streams. Very low cost and auto scaling.
DynamoDB is made of tables each one with a primary key, each table has infinite number of
items (rows), each item has attributes similar to columns but they can be nested and can be
added over time, you can have list and maps as attributes. Primary key two options: partition key
only, this is a hash like Kinesis, must be evenly distributed. The second option is having a
combination of a primary key and sort key, the combination must be unique, data is grouped by
partition key and sorted by sort key. You start by creating tables, no need to create or manage a
DB. 

Tables capacity must be calculated and provision in advance. there is read capacity units RCU
and write WCU. You can set up auto scaling and you also have burst credit for peak demand.
When the credits expire you get the ProvisionThroughputException, in this case do exponential
back off. 1 WCU = 1 write per second for item up to 1KB, if more than 1KB, one extra WCU per
KB. In DynamoDB you can select between strong consistency read and eventual. By default is
strong to get items but you can change it using ConsisentRead parameter. RCU = 1 strong read
per second or 2 eventual per second for 4KB size. WCU and RCU are spread over partitions. If
you exceed throuput you get the ProvisionThroughputException which may be caused by a hot
partition, large items or hot keys. Solutions: use an evenly distributed key, back off, or use
DynamoDB accelerator for read which is a cache. PutItem create or fully replace item.
UpdateItem partial update of attributes. Conditional writes allow to write or read info only if a
condition is true, this is good for concurrency since you can only replace a value if the original
value is what you expected. There is also DeleteItem and DeleteTable. It is much efficient and
cheaper to use batch: BatchWlriteItem up to 25 items for put or delete item. 16MB max batch,
only one API call so less latency and AWS run the batch in parallel. Part of the batch can fail and
is up to the client to retry. GetItem: read by key, uses eventual read by default. use
ProjectionExpression to retrieve only some of the attributes. BatchGetItem: up to 100 items in
parallel. Query returns values based on the key and sort key. You can define a filter as well but
this is executed on the client. Up to 1MB of data returned and you can specify a limit. It is very
efficient. Scan goes through the whole table and then fllters data which is not efficient,
consumes a lot of RCU. You can use parallel scan for efficiency but lots of RCU. You can use
Projection and Filter Expression. Scan is needed to see the whole table query needs equals in
primary key so it will return just one item or group of items in case it is a primary + sort key. You
can have up to 5 alternative local secondary indexes which are extra sort keys that must be
defined when creating the table. There are also global secondary indexes to speed up queries on
non keys attributes, the index is a new table that you can query and project values. GSI can be
modified after table creation. So local secondary is to speed up queries of attributes inside a
table that you are querying using the defined primary key and global indexes is to query primary
keys that are not defined PKs, so you create new tables. DynamoDB is optimistic locking, you
have conditional updates and deletes underr the hood using version numbers. 

DAX is DynamoDB accelerator, super performance read cache. When enabled writes go through
DAX. It is multi AZ, up to 10 nodes and default TTL is 5 min. DynamoDB streams are a change
log like kafka, every update, create and delete go to the stream. Lambda functions can subscribe
to DynamoDB streams to react in real time to events. You can use the streams to replicate data
across regions, the retention policy is 24h. DynamoDB supports VPC so you can access without
internet and it is fully managed by IAM. You can have global tables across regions using streams
as replication. There is a tool called DMS to import data from Mongo and other DBs. You can run
it locally.

API Gateway is AWS api management tool to expose rest end points. Lambda + API gateway is
serverless. It handles versioning of an API to support different versions for clients, authorization
and authentication, different environments, swagger ad open api, key management and client
throttling. It can also parse transform and validate request, it has a cache and also generates
SDK and API specs. You need to make a deployment in the gateway for changes to take effect,
you deploy to stages: dev, test, prod. You can have many stages and you have full history for
rollback, each stage has env variables to set properties for each environment. This way you can
change http end points and lambda functions (using context parameters). A common pattern is
to use env variables to point to lambda aliases. API management support canary deployments.
Mapping templates are used to modify in and out requests. You can parse the body, parameters,
change content, add headers, map json to xml, etc. It uses VLT language.

Swagger is now a standard called Open API which AWS API gateway support. It can be written in
yaml or json. You can export or import directly from AWS. Swagger can generate SDK for mobile
apps. API gateway can use cache, default 5 min max 1h, clients with the right role can bypass
cache using header: Cache-Controle:max-age=0.

For monitoring enable cloud watch at stage level. You have the request and response and many
metrics, It also integrates with x ray. 

If you want to support calls from other rest services you need to enable CORS, in the console you
can generate the OPTIONS call with the desired response. In API gateway you can define plans
for different clients each one will have an API key, quota per stage and throttling settings. You
define user plans first and then associate keys with them to reuse settings. For security create a
IAM policy and assign it to a role, the gateway will apply permissions based on the a service
called Sig v4 which attached credentials to requests headers. Lambda authorizers previously
know as custom authorizers are used fro OAuth, SAML and any other 3rd party to validate
credentials, it uses a cache. A lambda function is executed which return the policy for the given
credentials. There is also cognito users pools for oauth. So, IAM is for users and apps within
AWS, it handles authentication and authorization. Custom authorizer is for 3rd party tokens, very
flexible and does auth plus authorization but you pay for lambda function call. Cognito is great
for authentication using oauth google, facebook, etc. it does only authentication and you have to
implement authorization.
Cognito is the authentication module for AWS. It has the Cognito User Pools (CUP) which is a
serverless DB of user identities that can be simple(username and password) or federated using
Oauh  like Facebook or Google; or SAML. It is based on JWT and integrated with API gateway
which uses the JWT. There are also Federated Identity pools which are used to get temp access
to AWS resources using identity providers. So you can login with facebook, get a token the
request the federated pool for temp access to a S3 bucket if granted the client get this policy for
a time period. This is for direct access while the user pool is for permanent using api gateway.
Cognito Sync is deprecated for AppSync, it is used to store config, state and preferences of
applications, it has cross device sync (android or IOs) and offline mode. It relies on federated
pool.
SAM is the serverless application model. It is a complete framework for development and
deployment of serverless apps. It uses SAM Yaml file that is used to generate complex cloud
formation deployments. Only two commands to deploy to Prod and you can use CodeDeploy.
With SAM you can run lambda, API gateway and DynamoDB locally. The SAM template is a yaml
file that starts with Transform: AWS::Serverles. It has 3 core sections AWS::Serverless:Function
for lambda, AWS::Serverless::api for API gateway and AWS::Serverless:::simple table for dynamo.
To deploy you can use SAM package and deploy  or aws cloudformation package and deploy for
cli.

KMS is AWS key management service which manages all the keys for data encryption. It is fully
integrated with IAM. KMS is integrated with many services for encryption. You can also use the
SDK and cli to encrypt and decrypt data. KMS manages your private key, it can rotate it for extra
security, you do not need to worry about managing the key, you cannot even retrieve your own
private key used for encryption, you can only ask KMS to encrypt data. The user master key is
called CMK. So, you never store your secrets in plaintext, you ask KMS to encrypt them and then
store them in env variables. It can only encrypt 4k data per call. For bigger use envelope
encryption. 

To give access to KMS to a user make sure the key policy allows the user and that the IAM role
allow the KMS API calls. KMS give us full key and policy management and cloud trail for audit. 

Three types of CMK, the default master which is free, you can create your own in KMS for 1$ a
month or create your own and import it for 1$ month. There is also a charge per call to KMS.
KMS is under IAM in the console under encryption keys. The key policy describes who can use
the key and what they can do like update or delete. Encryption SDK is provided to do envelope
encryption for data bigger than 4KB. This is different fro S3 encryption SDK. The API call to
encrypt is GenerateDataKeyAPI.
AWS parameter store SSM is used to store secrets and configuration. It uses KMS and it is
serverless so you don't have to do anything and you have a secure vault. There is a SDK and free,
there is also version tracking to recover. The configuration management uses IAM, It integrates
with cloud watch events  for notifications and cloudformation for deployments with secrets. So
SSM is an easier alternative when you want to store parameters than using KMS directly. It uses
a tree structure so you can define by app, then environment, etc. In the console is under EC2 or
systems management. The parameters are based on paths so you can search by path:
myapp/dev/dbpasswd. 
Cross account access: define a role in IAM for another account, define which accounts can
access,  use AWS STS (secure token service) to get a token so the external account can assume
the role using AssumeRole API, the access is between 15 min and 1h.

Cloud Front is an AWS CDN to add cache in the current 168 edge locations across regions,
designed for S3 because a bucket can be created only in one region but also works for EC2. Can
protect against DDos attacks and it has SSL termination but also can talk to your services using
ssl. It support RTMP for video.
Step functions are used to create a state machine using a JSON file to orchestrate several
lambda functions calls. There is also a designer. It integrates with EC2, ECS, api gateway.... You
can have also human approval. It is used for workflows. 
SWF is similar to step functions but for EC2, not serverless, it is the simple workflow service. The
manual intervention is better and supports parent and child processes, other than that AWS
recommends step functions.

ECS is the container orchestration solution for AWS. There is also has EKS which is kubernetes
whereas ECS is amazon specific Docker orchestration. The Core service runs containers on your
user defined EC2 instances, simple: just runs Docker on linux EC2. Fargate is another solution to
run tasks(pods) on containers on AWS managed instances, so it is serverless. EKS is Kubernetes
managed by AWS, more portable. ECR is the docker registry managed by Amazon. ECS + ECR is
great alternative to microservices if you don't use lambda. Lambda is more popular for green
field and ECS to bring on prem services. Also ECS is popular for CI and batch. You create an ECS
cluster on EC2 instances and define services which are replicated and call tasks(pods) which are
running containers. Each EC2 can have multiple services and tasks, each container has
integration with IAM for security. The new  ALB load balancer has integration with ECS for port
mapping so you can replicate containers and assign dynamic ports so they can run on the same
instance. This allows max utilization of cpu and ram and easier rolling updates. You need to run
ECS agent with its config file on each EC2 instance. On EC2 Linux the agent is already installed
but you still need to modify the ecs.config file. Main properties: ECS_CLUSTER,
ECS_ENGINE_AUTH_DATA to authenticate to external repositories,
ECS_AVAILABLE_LOGGING_DRIVERS to use cloud watch for logs,
ECS_ENABLE_TASK_IAM_ROLE to enable role and policy check when running containers, very
important, set it to true. ECR is the image repo fully integrated with IAM and secure. Code Build
can build and push images to ECR.

SES is the simple email server. Integrated with IAM for security and with many services like S3
and Lambda. You can use SMTP or the SDK.
Redshift is the big data service for big queries, analytics and OLAP which is slow big data
queries. This is the data warehouse and data lake solution. Neptune is the graph DB in AWS.
DMS is the AWS sqoop equivalent, used to migrate data between RDS, DynamoDB and specially
Redshift. There are other migration tools.