AWS Associate Developer Cert Cheat Sheet (DRAFT) by bdupvik5

*Region - Us-eas­t(Ohio) AZ: US-east-2 AZ are separate from other AZs to prevent disaster
*AWS consoles are region scoped except R53,IAM & S3)
*IAM (Identity & Access Mgt) - Root user never used,IAM policies are written in JSON,G­LOBAL
*IAM - give users least privileges as possible, has predefined managed policies
*IAM Federation - for big companies' users, uses SAML method (similar to AD)
*IAM - Don't use in code, one IAM user per person, one IAM role per app
*EC2 - Virtual machine, ssh -i EC2tut­ori­al.pem ec2-us­er@­3.2­0.2­22.124
*EC2 security groups - Network security in AWS (Inbou­nd/­Out­bound traffic), acts as firewall
*EC2 security groups - Can be attached to multiple instan­ces­,Locked down to region/VPC combo, If app times out then its a sec grp issue, if connection refused error then its a app error or some other issue,use separate one for ssh, all outbound traffic is allowed by default, all inbound are blocked by default. Security groups can have other security groups refere­nced.
*Public IP - unique across whole web, can be identified on internet
*Private IP - can be identified on company's network only
*Elastic IP - once the instance is stopped it loses its IP. So use ElasticIP as its fixed public IP.Att­ached to one instance at a time. It can be remapped to another instance. Max upto 5 elastic IPs. Poor arch decision.
*EC2 User data - set of things to run when the instance boots up. Runs only at startup. Runs with user's root user
*EC2 Launch Types - OnDemand, Reserved (1 to 3 yrs) for dbs, Conver­tible Reserved, Scheduled Reserv­ed(­every sunday football game), Spot Instan­ces(bid price, will lose if outbid, 2 min notifi­cation to shutdo­wn)­,De­dicated Instances (may share hardwa­re)­,De­dicates hosts (will not share hardwa­re,­BYO­Lic­ense)
*Ec2 pricing - per hr, region in , instance type,OS. Also pay for factors like data trnsfer, storage, load balancers, fixed IP public addresses
*AMI - Amazon Image,­Custom AMIs - no need for user data, packag­es/apps are already installed so faster deploy time. Built for specific region.
*EC2 charac­ter­istics - GPU,CP­U,R­AM,­I/O­,Ne­twork. M instances are balanced. R instances are heavy in RAM. T2/T3 are burstable instances which when need more CPU it will perform. You get burstable credits. T2 unlimited have unlimited burstable credits.

Route 53 - Managed DNS.Re­directs URLs. Common are A : Url to IPV4 AAAA: URL to IPV6. CNAME: URL to URL and Alias: AWS resource. Use alias over CNAME for AWS resources.
RDS - Relational Database Service. Managed DB servic­e.use SQL as query language. Allows you to create dbs on the cloud that are managed by AWS. Oracle­,Po­stG­RE,­MSS­QL,­Maria etc and Aurora (AWS) are supported.
RDS advantages - Managed service, OS patching, Continous backups and Restore to point in time, Monitoring dashbo­ards, Read replicas, Multi AZ setup for disaster recove­ry,­Scaling (vertical & Horizo­ntal). BUT can't ssh into instances.
RDS Read replicas - Upto 5 replicas within same or cross AZ or cross region. Replic­ation is ASYNC so reads are eventually consis­tent. Replicas can be promoted to own DB. Apps must update the connection string to leverage read replicas.
RDS Multi AZ (Disaster recovery) - SYNC replic­ation. One DNS name - auto app failover to standby. Increase availa­bility. Failover in case of loss of AZ, loss of network, instance or storage failure. Not used for scaling. No manual interv­ention in apps.
RDS backups - Auto-e­nabled. Daily full snapshot of the db.Capture transa­ction logs in real time.A­bility to restore to any point in time. 7 days retention. Can be increased to 35.
DB Snapshots - Manually triggered by user. retention of backup as long as you want.
RDS Encryption - At rest with KMS. SSl certs to encrypt data in flight. To enforce SSL in postgre rds.force ssI in parameter groups. In MYSQL grant USAGE on '.' TO 'mysql'@' REQUIRE SSL.
RDS Security - Deployed in private subnets not in public. Security is enforced by security groups similar to EC2 instan­ces.Sec grps controls who can commun­icate with RDS. IAM controls who can manage RDS. Tradit­ional Username and password can be used to login to db. IAM users can now be used for MySQL/­Aurora.
RDS vs Aurora - Aurora is expensive but efficient. Aurora can have 15 replicas and replic­ation process is faster. Postgres and MySQL are supported as Aurora. Means drivers will work as if Aurora was a Postgre or MySQL db. Aurora is cloud optimi­zied.
Elasti­Cache - is for managing in-memory dbs Redis or Memcached as RDS is for Relational dbs.
Caches are in-memory dbs with high perfor­mance, low latency. Helps reduce load off read intensive workloads. makes app state less. Write scaling using sharding. Read scaling using replicas.
Elasti­cache Archit­ecture - Apps reads data from EC and if not present reads data from RDS and writes data to EC. Cache must have an invali­dation strategy to make sure only most current data is used in there.
Redis - in-memory key value store. Super low latency. Cache survives reboot by defaul­t.(­Per­sis­ten­ce).Su­pport for read replicas. Multi AZ with auto failover.
Memcached - Cache dpesnt survive reboots.
EC patterns - Lazy loading & Write through.
Laxy loading pros- load only when necessary. Cache isn't filled with unused data. Node failures are not fatal.
Lazy loading cons - Cache miss penalty results in 3 trips. Noticeable delay for that miss. Data can be updated in db but outdated in cache.
Write through pros - Data in cache is never stale. Write vs Read penalty (each write requires 2 calls).
Write through cons - Missing data unless it is added/­updated in db. Mitigation for this is to implement lazy loading as well. Cache becomes too big.
VPC - Within region you are able to create Virtual Private Cloud. Each VPC contains subnet­s(n­etw­orks). Each subnet must be mapped to AZ. Its common to have a privat­e/p­ublic subnet.(p­riv­ate­/public IP). Its common to have many subnets per AZ.
Public subnets contains LBs,Static websit­es,­Fil­es,­public auth layers.
Private subnets contains web app servers, dbs.
Private and public subnets can commun­icate if they are in the same VPC.

EB uses all base AWS components like EC2,AS­G,I­AM,­LB,­VPC,RDS etc. Dashboard to view all these.
EB is free but pay for underlying instances.
Instance config/OS is handled by EB and Deployment is handled by EB but can be config­ured.
3 arch models - Single instance (Dev) ,ASG + LB (prod/­pre­-prod) , ASG (non-web prod apps)
EB has Enviro­nments & Applic­ati­ons.Every deployment gets an applic­ation version. You can deploy applic­ation versions to Enviro­nments and can promote applic­ation version to next enviro­nment.
Rollback feature to get to prev app version.
EB supports many platforms and Single­/Multi docker contai­ners.
Deployment Options - All at once,R­olling, Rolling with additional batches, Immutable
All at once - Fastest Deploy­ment, Downtime, Great for quick iterations in dev, No additional cost
Rolling - Applic­ation is running below capacity, can set bucket sizes, will run both apps simult­ane­ously, No additional cost, Will take long time to deploy
Rolling with additional batches - App runs at capaci­ty,­Add­itional cost,will run both apps simult­ane­ous­ly,­Longer deployment
Immutable - Zero downtime, New code is deployed to new instance on temp ASG,High cost double capaci­ty,­Longest deploy­ment, Quick rollback feature (just terminate new ASG), great for prod.
Blue/Green Deployment - Not a direct feature of EB.Zero Downti­me.C­reate stage enviro­nment and release new code there. Route 53 can direct little traffic to new version to test it.
EB Extensions - A zip file containing our code must be deployed to EB. All parameters set in UI can be configured using files. Requir­ements are that it should be in the .ebext­esions/ directory in the root of source code. It should be in YAML/JSON format. .Config extens­ions. Ability to modify def settings and add resources like RDS,Dy­nam­odb­,El­ast­iCache etc. .ebext­esnions will get deleted if enviro­nment gets deleted.
EB CLI - command eb create, eb status, eb deploy.
Under the hood EB relies on CloudF­orm­ation.
EB Deployment Mechanism - You have to describe depend­encies e.g. req.txt fpr python or packag­e.json for node.js. Pacakage code as zip. EC2 will resolve depencies which can be slow. To optmize this package depend­encies with code to improve deployment perfor­mance and speed.
EB with https - SSL certs can be loaded to LB through EB console or LB config. Can be done by code through .ebext­ens­ion­s/s­ecu­rel­ist­ene­r-a­lb.c­onfig. It can be provis­ioned through ACM or CLI. Must configure security group rule to allow incoming port 443 (https port).
EB redirect from http to https - Configre instances to do redirect. Configure ALB to redirect with a rule. Make sure health checks are not redire­cted.
EB lIfecycle Policy - can store at most 1000 app versio­ns.To remove old versions use lifecycle policy based on no of versions or days to retain version. Versions currently used wont be deleted. Option not to delete the source bundle in S3 to prevent loss of data.
Webserver vs worker enviro­nment - If your app performs long tasks then decouple the apps to two tiers. One tier is web app tier where work is requested and then using SQS queue it to second tier where the long task is procesed. Periodic Tasks can be defined in cron.yaml file.
EB with RDS - EBS can provision a RDS but this RDS is specific to enviro­nment. So its better to decouple and create RDS alone and then provide it to EB with connection string.
To migrate RDS coupled in EB to standalone RDS -
Take RDS snapshot
Enable deletion protection in RDS.
Create new enviro­nment without RDS and point to existing old RDS.
Perform blue/green deplyment and swap old/new enviro­nment.
Terminate old enviro­nment.
Delete cloud formation stack.

CloudWatch
Metrics - Collect &track key metrics. EC2 detailed monitoring - default metrics every 5 mins. for extra cost you can have detailed monitoring at every 1 min. AWS free tier allows upto 10 detailed monitoing metrics. Dimension is an attribute of a metric.(i­nstance id, enviro­nment etc). Upto 10 dimensions per metric. Custom metrics : use api call PutMet­ric­Data. Use expone­ntial back-off in case of throttling errors.
Logs - Collect, monitor, store and analyze log files. Apps can send logs using SDK. Logs can go to S3 for archival or to Elasti­cSe­arc­hCl­uster for further analytics. Log storage archit­ecture - Log groups (name rep applic­ation), Log streams (instances within app/log files/­con­tai­ners). Log expiration policies. Need IAM policies to write to logs. Encryption of logs using KMS at group level.
Events - Send notifi­cations when certain events happen in AWS. Event pattern - event rules to react to a service doing something. e.g. code pipeline state change. Schedule cron jobs. Triggers to Lambda functi­ons­,SQ­S/S­NS/­Kinesis msgs. Creates JSON doc to give info about change.
Alarms - React in realtime to metric­s/e­vents . Alarm states are OK,INS­UFF­ICI­ENT­_DA­TA,­ALARM. can trigger notifi­cations for any metric.

X-ray - Troubl­esh­ooting app perfor­mance and errors. Distri­buted tracing of micro-­ser­vices.
Visual analysis of apps.
Advantages :
Troubl­esh­ooting perfor­mance issues
Understand depend­encies in micros­ervice archit­ecture.

CloudTrail - Internal monitoring of API calls. Audit changes to AWS resources by your users.

*This section is equivalent to ELB/Cl­oud­For­mation in running docker apps
*ECR - Elastic container registry to store private docker images
*To manage containers we have 3 choices. They are below
*ECS - Amazons own
*Fargate - Amazon's serverless
*EKS - Amazon's own Kubernetes (open source)
*ECS clusters - grp of EC2 instances. Instance run Ecs agent (Docker container) which registers to cluster. When a cluster is created it creates instances with Docker in it. We must configure the file /etc/e­cs/­ecs.config with the cluster name to register instance with the cluster.
*ECS tasks - containers running to create apps.
*ECS task defini­tions - Json form tells ECS how to run docker container (Env var,CP­U,ports etc). Task Role is important as it gives permis­sions.
*ECS service -app defini­tions running on ECS cluster. tells how many tasks to run and how to run it. Can link to LB (Dynamic Port Mapping)
*ECS--­>Cl­ust­ers­-->Task Def(Co­ntainer def)/S­erv­ice­-->­Tasks
ECR - aws ecr get-login --no include email --region us-east-1a -- login command to authen­ticate docker to push images to your registry
docker build
docker tag
docker push 3867.dkr.e­cr.u­s-­eas­t-1.am­azo­naw­s.c­om/­dem­o:l­atest
docker pull "­ima­gen­ame­/ta­g" (Push and pull must be preceded by aws ecr login to get docker login creden­tials).
Fargate - Server­less. No need to add instan­ces.Just create task definition and increase number of tasks running.
ECS + Xray - 1. ECS cluster X-ray daemon 2. ECS cluster X-ray container as sidecar 3. Fargate cluster X-ray container as sidecar . Portma­ppings - Port -2000 Protocol - UDP
Enviro­nment variable - AWS-X-­ray­_Da­emo­n_A­ddress : x-ray_­dae­mon­_ad­dress :2000
Links : X-ray
ECS + EB (Beans­talk) - You can run EB in Single­/Multi Docker container mode.It will create ECS cluster ,EC2 instances, task defini­tions and execution, LB. Requires a config file Docker­run.aw­s.json at the root of source code. EB has an option for containers under platform to make this posible. So this is configured when you create EB.
For EC2 instances to run multiple containers you must NOT specify host port. Enable LB dynamic port mapping featur­e.S­ecurity grp should provide LB with access. Sec grps should only work at instance level and not at task level. Task def has IAM roles.
ECS integr­ations - Can integrate with X-ray. X-ray must run as 2nd container. ECS integrates with cloudwatch logs. You need to set up logging at task def level. Each container will have separate log stream.
CLI command to create ECS service - aws ecs create­-se­rvice

LB - Spread Load, Single point of access (DNS) to the app, Handle failures of instances, Health checks , SSl (Https) , stickiness (cache), high availa­bility across zones, separate public­/pr­ivate traffic
ELB - takes care of upgrades, mainte­nance & high availa­bility
ELB Types - ALB(ht­tp/­htt­ps/­web­soc­ket­s),NLB (TCP/IP) , Internal (private) and External (public) ELBs
Health Check - They make LBs know if it can forward data to instances. Response 200 - OK.
ALB - awesome for micro services and for containers (apps run on same machine). Has port mapping feature to redirect to dynamic port. Stickiness is enabled by ALB and not app. App servers don't see the client ip directly but see only ALB ip. The client IP is stored in X-Forw­ard­ed-For.
LB Target Groups - Instances where LB should direct its traffic.
NLB - TCP traffic. Less latency. Support for static /Elastic IP. Used for extreme perfor­mance. Default should be ALB. Both ALB & NLB has static host name. Always use host name and don't resolve underlying IP.
LBs can scale but not instan­tan­eously,
4xx errors are client induced.
5xx errors are app induced.
LB error 503 means at capacity.
If LBs cant connect to your apps then check security groups.
ASG - Scale out or Scale in instances based on increa­sed­/de­creased load. Ensure we have minimu­m/max number of instances running. Automa­tically register new instances to a LB.
ASG Launch config­uration - AMI + Ins type, user data, security grp, EBS volume, SSH key pair
Other ASG attributes - Min/ma­x/i­nitial capacity, Scaling policies, LB info, Networ­k/s­ubnet info.
ASG alarms - Based on cloud watch alarms we can write ASG scaling policies
ASG new rules - New scaling rules based on CPU usage, avg network in/out. Easy to set up and makes more sense.
ASG metric - Integr­ation with cloud watch metrics to get custom metric from EC2 instance to alarm an ASG scaling policy. PUTMetric API.
EBS - Elastic Block Store. Network drive not physical drive. Store instance data here so that you don't lose it when instances are termin­ated. Can be detached from instance and attached to another. Can be attached to only one instance at a time.L­ocked to AZ. Provis­ioned capacity (GB and IOPS) which can be increased over time.
EBS 4 Types - GP2 (SDD General purpose. Balanced) , IOI - Mission critical low latency high perfor­mance ,STI (HDD frequently accessed) and SCI (HDD less frequency accessed).
You can resize EBS volumes but need to repart­ition it.
EBS snapshot - backups. Snapshots backups only actual data. So if 100 GB EBS has only 5GB of data then only that 5 GB is snapsh­otted. Snapshots can be used for disaster recovery.
EBS encryption - Rest & inflight. Snapshots are also encrypted. All volumes created from snapshot is also encrypted. We don't have to do encryp­tio­n/d­ecr­yption.
Instance Store - Instances without EBS volumes. Better I/O.
Migrating EBS across AZ means snapshot and then recreate in another AZ.
EBS backups use high I/O so don't run them when your applic­ation is handling lot of traffic.
Root EBS volumes (one that comes with instance) get deleted once instances are deleted. This can be disabled.

S3 - Simple Service Storage
S3 buckets - direct­ories which stores files. Defined at region level.
S3 objects - are files. They have Key which is the path of the file. Max 5TB. More than 5GB then it should be multi-part upload.
S3 Versioning - Enabled at bucket level. Any file that is not versioned prior to enabling versioning will have version "­nul­l".
S3 Encryption - SSE-S3­,SS­E-K­MS,­SSE­-C,­Client Side Encryption
SSE-S3 - encrypt using keys handled by S3 & AWS, Server­-side enc,AE­S-256, Set Header "­x-a­mz-­ser­ver­-si­de-­enc­ryp­tio­n" : "­AES­256­"
SSE-KMS - encrypt using keys handled by KMS , server­-side , KMS gives user control + audit trail , Set Header "­x-a­mz-­ser­ver­-si­de-­enc­ryp­tio­n" : "aws : KMS"
SSE-C - server­-side enc by keys managed by customer outside of AWS. S3 does not store enc keys. HTTPS must be used and data key must be provided in every Https header.
Client -side - used SDK such as S3 encryption client library. Encr and Decr happens at clients place.
Encryption in transit is also called SSl/TLS.
S3 security - user-based - IAM policies resour­ce-­based - Bucket Policies, Object ACL, Bucket ACL
S3 Bucket Policies - used for providing access, force encryp­tion, cross-­account access. Written in JSON it can have Resources (buckets & object­s),­Actions (set of API to allow/­deny), Principal (user/­account the policy applies to)
S3 access logs can be stored in another bucket.
Can be integrated with Cloud trail for API calls. Supports VPC endpoints.
S3 websites - allows static websites. Url is <bu­cke­t-n­ame­>.s­3-w­ebs­ite­-<AWS region­>.a­maz­ona­ws.com . If you get 403 error then check bucket policies for public read.
S3 CORS - If you request data from another S3 bucket you need to enable Cross Origin Resource Sharing. This allows to limit the number of websites that can request your files in S3 (and limit costs).Access­-Co­ntr­ol-­All­ow-­Origin : <do­mai­n>
S3 Consis­tency Model - Read after write consis­tency for PUTS (you can read imm after write) , Eventually consistent for PUTS and DELETES
S3 can send notifi­cations on changes to SQS,SNS & Lambda. S3 has cross-­region replic­ation feature.
S3 perfor­mance - upto 3500 RPS for PUTS & 5500 RPS for GETS. Faster upload of >100MB use multi-­part. Must use multi part if >5GB. Use cloudfront to cache S3 reads. S3 transfer accele­rat­ion­(uses edge location) - just need to change the endpoint u write to. If using KMS encryption then AWS limits applies.
S3 & Glacier Select - Glacier is for long term archiv­al.Its another 'tier' within S3.If you retrieve from glacier you might need only a subset. Otherwise costs might be high. So SQL select queries can be used. No subqueries or joins are supported. Works in CSV,JSON or parquet format.

CICD - automating deployment with additional safety using CodeCo­mmi­t,C­ode­Bui­ld,­Cod­ePi­pel­ine­,Co­deD­eploy
CodeCommit - storing code. Version Contro­l.C­oll­oborate with other develo­pers. Code is backed up. Fully viewable and auditable. Provides private reposi­tories. No size limit on reposi­tories. Secure (encry­pti­on,­ACL­).I­nte­grated with Jenkin­s/C­ode­Build and other CI tools.
CodeBuild - building and testing code
CodePi­peline - automating pipeline from code to EB
CodeDeploy - deploying code to EC2 fleets.
CI - Find bugs early and fix, Deliver faster as the code is tested­,Deploy often
CD - Ensure that sw can be delivered reliably, Ensures deploy­ments happen often and quick
Code Commit security - Authen­tic­ation using SSH,HTTPS using AWS cli or https cred,MFA can be enable­d.IAM to reposi­tor­ies.EN­cry­ption at rest using KMS and in flight through https/ssh.
Code commit notifi­cations - SNS,cloud watch events or lambda. To automa­tically trigger a code analysis when code is commited and to check if there are no secrets there use AWS SNS/Lambda integ in code commit.
Code Pipeline - Visual workflow, source - S3/GIT­/Code commit. Made of stages. Each stage can have seq or parallel actions. Manual approval can be define at any stage.
CodePi­peline Artifacts - Each stage in pipeline can produce artifacts which are stored in S3.
Pipeline troubl­esh­ooting - Stage changes happen in CloudWatch events. Events can create SNS notifi­cat­ions. If stage fails it stops and info can be seen in console. CloudTrail can be used to audit API calls. If pipeline cant perform actions make sure IAM service role has enough permis­sions. (IAM policies).
Code Build - Continous scalin­g,Fully managed, Leverages docker. Secure as it integrates KMS for secure build artifa­cts,IAM for build permis­sions, VPC for nw security, CloudTrail for API calls logging.
Code build - Source code from code commit­/S3­/gi­thu­b/C­ode­pip­eline. Build inst can be defined in code (build­spe­c.y­aml). Output logs to S3 & Cloudwatch logs. Cloudwatch events to trigger notifi­cations if build fails. Cloudwatch alarms to notify if threshold failures. Can reproduce locally to troubl­eshoot using code build agent.
Buildspec - builds­pec.yaml must be at the root of the code. Enviro­nment variables - Secure secrets using SSM parameter store. Phases - Install (depen­den­cies), Prebuild, Build ,postbuild (output). Cache depend­encies to S3 to help speed up build.
CodeDeploy - Each EC2 instance must run CodeDeploy agent. Agent contin­ously polls CD for work. CD send appsec.yaml. App is pulled from github or S3. EC2 will run deployment instru­ctions.
Code Deploy components - Applic­ation (must have unique name), platform (EC2/o­n-p­rem­,La­nbd­a),dep group (group of ec2 inst)
App Sec - File section (how to copy from git/S3) , Hooks (Appli­cat­ion­Sto­p,D­own­loa­dBu­ndl­e,B­efo­reI­nst­all­,Af­ter­Ins­tal­l,A­ppl­ica­tio­nst­art­,Va­lidate service)
Deployment Config - Configs : one a time(1 inst a time), Half at time,all at once, Custom
Deploy targets - set of EC2 instances with tags, ASG,Mix of ASG/Tags, Custom­ization in scripts using DEPLOY­MEN­T_G­ROU­P_NAME env variable.
Codestar - Integrates solution that regroups Github, CodeCo­mmit, Codebuild, Codepi­peline, Codede­ploy, CloudF­orm­ation & Cloudw­atch.
Codestar helps create projects for Lambda­,EC­2,B­ean­stalk.

CloudF­orm­ation - Infra as code.
Benefits
Infra as code - No manual creation of resour­ces.Code is version contro­lled. Changes to infra are reviewed in code.
Cost - you can see how much all resources in stack costs. You can estimate costs of your resources using template. Savings strategy : You can automate deletion of template at 5pm and creation at 8PM.
Produc­tivity
Separation of concern - VPC stack,­Network Stack, App stacks
Reusable - use templates on web
How CF works - Templates have to be uploaded in S3.To update a template re-upload a new version. Stacks are identified by name. Deleting stack deletes all artifacts.
Deploying CF - Manually : Edit templates in CF designer, Using console to input parame­ters.
Automated : Editing templates in YAML File, AWS CLI to deploy templates
CF Building blocks - Templates Components : Resour­ces­,Pa­ram­ete­rs,­Map­pin­gs,­Out­put­s,C­ond­iti­ona­ls,­Met­adata.
Resources - AWS resources declared in template. Resource type identifier AWS:: aws-pr­odu­ct-­nam­e::­dat­a-t­ype­-name e.g. AWS::E­C2:­:in­stance
Parameters -dynamic inputs. If CF resource config is going to change then use parame­ters. To reference a parameter use Fn::Ref function. In YAML it is !Ref.
Pseudo Parameters - AWS provides these params by default. Some are AWS::A­cco­untId , AWS::R­egion , AWS::S­tac­kName
Mappings - static variables, used to differ­entiate enviro­nme­nts­(de­v,prod) or Regions (us-ea­st-­1,e­u-c­ent­ral-1). To reference mappings use Fn::Fi­ndInMap. In YAML it is !FindI­nMa­p[M­apname, Toplev­elkey, second­lev­elkey].
Outputs - References to what has been created. Can export to other stack and used for cross stack reference using Fn::Im­por­tValue. Cant delete the stack until the underlying cross-ref stack is also deleted.
Conditions - list of condition to perform resource creation
CF intrinsic functions - Ref , Fn::Ge­tAtt, Fn::Fi­ndI­nMap, Fn::Im­por­tValue, Fn::Join, Fn::Sub (subst­itu­te)­,Co­ndition functions
YAML & JSON are used to create templates.
CF Rollbacks - When stack creation fails - default it will roll back (gets deleted). Optional is to stop rollback and troubl­eshoot what happened. When stack update fails - The stack will rollback to previous known working state. You can see the logs what happened.

CloudFront - Works with Content Delivery network. Improves read perfor­man­ce.C­ached at edge.P­revents network attacks. Provides encryp­tion.
Simple Email Service (SES) - integrates with SNS,La­mbda,S3
Step Functions - Server less workflow to orches­trate Lambda functi­ons­,JSON state machine, max execution of 1 yr, integrate with EC2/EC­S/API gateway
Simple Workflow Service - not server less, Human approval possible, if you need external interv­ention or child processes then go with this otherwise Step functions.
Other Dbs - RDS, Dynamo, Inmemo­ry(­mem­cac­hed­/Re­dis­),N­ept­une­(gr­aph­),O­LAP­(Re­dsh­ift­),DMS
ACM - Certif­icate manager. Loads SSL certif­icates to LBs,API gatewa­y,Cloud front distri­butions