AWS Certification - Component Comparision

SCP vs IAM

https://tutorialsdojo.com/service-control-policies-scp-vs-iam-policies/#:~:text=SCPs%20are%20mainly%20used%20along,grant%20appropriate%20IAM%20Policy%20permissions 

Service Control Policies(SCP)	IAM Policies
SCPs are mainly used along with AWS Organizations organizational units (OUs).	IAM Policies operate at the Principal level. IAM Policies cannot be attached to OUs.
SCPs do not replace IAM Policies such that they do not provide actual permissions. To perform an action, you would still need to grant appropriate IAM Policy permissions.	There are two types of IAM policies: Identity-based policies – attached to an IAM user, group, or role. Resource-based policies – attached to an AWS resource such as an S3 bucket.
Even if a Principal is allowed to perform a certain action (granted through IAM Policies), an attached SCP will override that capability if it enforces a Deny on that action. SCP takes precedence over IAM Policies.	IAM Policies can grant/deny a Principal permissions to perform certain actions to certain resources. This can be used together with SCP to ensure stricter controls in AWS Organizations.
SCPs can be applied to the root of an organization or to individual accounts in an OU.	An IAM policy can be applied only to IAM users, groups, or roles, and it can never restrict the root identity of the AWS account.
When you apply an SCP to an OU or an individual AWS account, you choose to either enable (whitelist), or disable (blacklist) the specified AWS service. Access to any service that isn’t explicitly allowed by the SCPs associated with an account, its parent OUs, or the management account is denied to the AWS accounts or OUs associated with the SCP.	An IAM Policy can allow or deny actions. An explicit allow overrides an implicit deny. An explicit deny overrides an explicit allow.
Any account has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can’t use that permission, even if there is an attached IAM policy granting Administrator permissions to the user.
SCPs affect only principals that are managed by accounts that are part of the organization.

EC2 vs ECS vs Lambda

ECS vs EC2 vs Lambda

	EC2	ECS	Lambda
Type of Compute	Instance; Infrastructure as a Service (IaaS)	Container; Container as a Service (CaaS)	Function; Function as a Service (FaaS)
Defining Features	Extensive instance configuration	Container orchestration	Serverless function deployment
Use Cases	General computing; complete control over instance	Running Docker containers; running 15+ minute tasks	Smaller applications that run in less than 15 minutes
Availability	SLA: 99.99%	SLA: 99.99%	SLA: 99.95%
Scalability	Combines with Auto Scaling Group to scale out/in as defined in ASG policies	Automatic scaling based on desired count of tasks	AWS Lambda automatically scales on your behalf
Service Endpoint	IPv4, IPv6	Interface VPC endpoints	Interface VPC endpoints
Encryption	Supports encrypted EBS volume	EC2 Launch: Use encrypted EBS volumes; Fargate Launch: Images pulled from ECR use HTTPS and are encrypted at rest w/ S3	Uses HTTPS for encryption in transit; Uses AWS KMS for encryption at rest
Pricing	Varies by instance type, time run, and launch type (spot instances, RI, scheduled, etc.)	EC2 Launch: underlying resources; Fargate Launch: vCPU & memory used EKS: Per cluster & underlying resources	Number of requests and time it takes for code to execute

Direct Connect vs Site-to-Site VPN

Comparison: AWS Direct Connect vs. VPN | StormIT

	AWS Site-to-Site VPN	AWS Direct Connect
Network	Can reach 4Gbps or less Connect with shared and public networks, so the bandwidth and latency fluctuate	Starts from 50Mbps and expands to 100Gbps. Network is not fluctuating and provides a consistent experience.
Time to establish	It's relative easy to setup and faster to install than AWS Direct Connect.	Installation requires an experienced team, and setup is not as easy as AWS VPN.
Pricing	$0.05 per connection hour, $0.09 per GB of data transfer out (DTO)	$0.02 to $0.19 per GB of data transfer out (DTO). port hour fees varies based on port speed.
Security	Connectioin is encrypted via IPSec	Not encrypt your traffic in transit by default.

NACL vs SG

https://medium.com/awesome-cloud/aws-difference-between-security-groups-and-network-acls-adc632ea29ae

NACL	Security Group
Multiple subnets can be bound with a single NACL, but one subnet can be bound with a single NACL only, at a time.	Security groups are associated with an instance of a service. It can be associated with one or more security groups which has been created by the user.
NACL can be understood as the firewall or protection for the subnet.	Security group can be understood as a firewall to protect EC2 instances.
These are stateless, meaning any change applied to an incoming rule isn’t automatically applied to an outgoing rule.	These are stateful, which means any changes which are applied to an incoming rule is automatically applied to a rule which is outgoing.
Network ACL supports allow and deny rules. By deny rules, you could explicitly deny a certain IP address to establish a connection example: Block IP address 123.201.57.39 from establishing a connection to an EC2 Instance.	Security group supports allow rules only (by default all rules are denied). e.g. You cannot deny a certain IP address from establishing a connection.
Network ACL rule only allow CIDR as destination.	Security group rule allow CIDR, IP, Security group as destination.

Private IP vs  Public IP vs Elastic IP

While Private IP addresses are used for internal communications within the VPC, Public and Elastic IPs allow establishing communication with the internet.

A Public IP address associated with an instance is not static and is lost when the instance is stopped, whereas an Elastic IP address is a static public address associated with your AWS account. This IP address is not lost when the instance with which it is associated is stopped and it remains allocated to your AWS account until you release it. The prime advantage of using Elastic IPs is that they can be moved or re-associated between instances and Elastic Network Adapters (ENAs).

In general, when allocating an Elastic IP address, make sure that it is allocated in the same region in which you are running the instance with which you want to associate the address, since Elastic IPs are regional.

In case you have a use case where you require global static IP addresses, use AWS’ Global Accelerator service. It provides two global static IP addresses when you create an accelerator.

IGW vs NGW

https://medium.com/awesome-cloud/aws-vpc-difference-between-internet-gateway-and-nat-gateway-c9177e710af6#:~:text=Internet%20Gateway%20(IGW)%20allows%20instances,IPs%20to%20access%20the%20internetAWS - Difference between NAT Gateway and Internet Gatewayhttps://medium.com/awesome-cloud/aws-vpc-difference-between-internet-gateway-and-nat-gateway-c9177e710af6#:~:text=Internet%20Gateway%20(IGW)%20allows%20instances,IPs%20to%20access%20the%20internet

IGW	NGW
allows instances with public IPs to access the internet.	allows instances with no public IPs to access the internet.
You can only have 1 IGW per VPC.	If you have created a Multi-AZ architecture, then you need to have 1 NAT Gateway in each Availability Zone since 1 NAT Gateway operates in 1 Availability Zone.
it does not cause availability risks or bandwidth constraints on your network traffic.	A NAT Gateway supports 5 Gbps of bandwidth and automatically scales up to 45 Gbps.
	A NAT Gateway is automatically assigned a public IP address.
Make sure that you have the route tables configured correctly. That is having a route from the subnet to the internet gateway.	NAT Gateway on its own does not know the route out to the internet in AWS. So, do remember to update your Route tables and create a route out to the internet i.e. route from the NAT Gateway to the Internet Gateway.

ELB vs ALB vs NLB

https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4

	ELB/CLB	ALB	NLB
Since	2009	2016	2016
Layer	Layer 4/7 (HTTP/TCP/SSL traffic)	Layer 7 (HTTP/HTTPS traffic)	Layer 4 (TLS/TCP/UDP traffic)
Target	it can only forward to explicit EC2 instances or containers in ECS or EKS. it isn’t compatible with EKS containers running on Fargate.	Listeners receive requests and decide (based on a wide range of rules) to which target group they will forward the requests. A target group then routes the requests to instances, containers, or IP addresses. Target groups manage the targets in terms of deciding how to split up the traffic and by performing health checks on the targets. Both ALB and NLB can forward traffic to IP addresses, which allows them to have targets outside the AWS Cloud (for example: on-premises servers or instances hosted on another cloud provider).	Listeners receive requests and decide (based on a wide range of rules) to which target group they will forward the requests. A target group then routes the requests to instances, containers, or IP addresses. Target groups manage the targets in terms of deciding how to split up the traffic and by performing health checks on the targets. Both ALB and NLB can forward traffic to IP addresses, which allows them to have targets outside the AWS Cloud (for example: on-premises servers or instances hosted on another cloud provider).
WebSocket	No	Yes
Authentication	provide an SSL certificate (a self-signed certificate is fine, BTW). This provides end-to-end encryption, which is a usual requirement in many compliance programs. Optionally, ELB can be configured to verify the TLS certificate provided by the target for extra security	supports user authentication via a variety of methods, including OIDC, SAML, LDAP, Microsoft AD, and well-known social identity providers such as Facebook and Google. This can help you off-load the user authentication part of your application to the load balancer.
Usage	AWS discourages the use of ELB in favor of its newer load balancers. Admittedly, there are very few scenarios where the use of an ELB would be preferable; typically, these are cases where you simply don’t have a choice. For example, your workload might still run on EC2-Classic, or you need the load balancer to use your own sticky session cookies, in which cases ELB would be the only option available to you.	ALBs are typically used for web applications. If you have a microservices architecture, ALB can be used as an internal load balancer in front of EC2 instances or Docker containers that implement a given service. You can also use them in front of an application implementing a REST API, although AWS API Gateway would generally be a better choice here.	NLBs would be used for anything that ALBs don’t cover. A typical use case would be a near real-time data streaming service (video, stock quotes, etc.) Another typical case is that you would need to use an NLB if your application uses non-HTTP protocols.
Pricing	$0.025 per ELB-hour + $0.008 per GB of traffic	$0.0225 per ALB + $0.008 per LCU-hour	$0.0225 per NLB-hour + $0.006 per LCU-hour

SnowCone vs SnowBall vs SnowMobile

AWS Snow Family – terabyte migration and edge compute devices – Amazon Web Services

	SnowCone	SnowBall Edge Storage Optimized	SnowBall Edge Compute Optimized	SnowMobile
Usable HDD Storage	8 TB	80 TB	42 TB	100 PB
Usable SSD Storage	14 TB	1 TB	7.68 TB	No
Usable vCPUs	4 vCPUs	40 vCPUs	52 vCPUs	N/A
Usable Memory	4 GB	80 GB	208 GB	N/A
Device Size	9in x 6in x 3in	548 mm x 320 mm x 501 mm	548 mm x 320 mm x 501 mm	45 ft. shipping container
	227 mm x 148.6 mm x 82.65 mm
Device Weight	4.5 lbs. (2.1 kg)	49.7 lbs. (22.3 kg)	49.7 lbs. (22.3 kg)	N/A
Storage Clustering	No	Yes, 5-10 nodes	Yes, 5-10 nodes	N/A
256-bit Encryption	Yes	Yes	Yes	Yes
HIPAA Compliant	No	Yes, eligible	Yes, eligible	Yes, eligible

VPC Peering vs VPC Endpoint

When to use an AWS S3 VPC endpoint – Tom Gregory

What Are the Differences Between VPC Endpoints and VPC Peering Connections?_VPC Endpoint_FAQs_HUAWEI CLOUD

Category	VPC Peering Connection	VPC Endpoint
Security	All resources in a VPC, such as ECSs and load balancers, can be accessed.	Allows access to a specific service or application. Only the ECSs and load balancers in the VPC for which VPC endpoint services are created can be accessed.
CIDR block overlap	Not supported If two VPCs have overlapping subnets, the VPC peering connection will not work.	Supported If you use a VPC endpoint to connect two VPCs, you do not have to worry about overlapping subnets.
Communications mode	VPCs connected through a peering connection can communicate with each other.	Requests can only be initiated from a VPC endpoint to a VPC endpoint service, but not the other way around.
Route configuration	If a peering connection is established between two VPCs, add routes to the VPCs so that they can communicate with each other.	For two VPCs that are connected through a VPC endpoint, the route has been configured, and you do not need to configure it again.
Access using VPN/Direct Connect	Supported You can create a VPC Peering connection to connect your local data center to a cloud service using a VPN connection or a direct connection.	Supported You can create a VPC endpoint to connect your local data center to a cloud service using a VPN connection or a direct connection over an internal network.
Cross-region access	Not supported VPC Peering supports only communications between two VPCs in the same region.	Supported You can use Cloud Connect to enable communications between VPCs in different regions.

Round-robin vs Least Outstanding Requests

https://medium.com/dazn-tech/aws-application-load-balancer-algorithms-765be2eca158

VPC Peering vs Transit VPC vs Transit Gateway

https://jayendrapatil.com/aws-transit-vpc 

Transit Gateway can be used instead of Transit VPC. AWS Transit Gateway offers the same advantages as transit VPC, but it is a managed service that scales elastically in a highly available product.

AWS Budgets vs Cost Explorer

Set Custom Cost and Usage Budgets – AWS Budgets – Amazon Web Services

AWS Cost Explorer - Amazon Web Services

AWS Budgets Vs. AWS Cost Explorer: The Ultimate Comparison Guide

Dimension	AWS Budgets	AWS Cost Explorer
Main use case	Governance controls	Cost analysis
Ease of use	Simple user interface Guided setup for reports and alerts	Chart interface, with filter options Multiple built-in charts that can be adapted
Useful features	Regular report delivery Granular filters Alerts Automated responses	Data visualization Granular filters Cost-saving recommendations Sharing reports Hourly granularity
Customization	Filtering Email recipients Automated responses	Filtering and grouping

Public VIF vs Private VIF vs Transit VIF

What is AWS Direct Connect? - AWS Direct Connect

• Private virtual interface: A private virtual interface should be used to access an Amazon VPC using private IP addresses.

• Public virtual interface: A public virtual interface can access all AWS public services using public IP addresses.

• Transit virtual interface: A transit virtual interface should be used to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways. You can use transit virtual interfaces with any AWS Direct Connect dedicated or hosted connection.

S3 Pre-signed URLs vs CloudFront Signed URLs vs Origin Access Identity (OAI)

https://tutorialsdojo.com/s3-pre-signed-urls-vs-cloudfront-signed-urls-vs-origin-access-identity-oai/

S3 Pre-signed URLs	CloudFront Signed URLs	Origin Access Identity (OAI)
All S3 buckets and objects by default are private. Only the object owner has permission to access these objects. Pre-signed URLs use the owner’s security credentials to grant others time-limited permission to download or upload objects. When creating a pre-signed URL, you (as the owner) need to provide the following: Your security credentials An S3 bucket name An object key Specify the HTTP method (GET to download the object or PUT to upload an object) Expiration date and time of the URL.	You can control user access to your private content in two ways Restrict access to files in CloudFront edge caches Restrict access to files in your Amazon S3 bucket (unless you’ve configured it as a website endpoint) You can configure CloudFront to require that users access your files using either signed URLs or signed cookies. You then develop your application either to create and distribute signed URLs to authenticated users or to send Set-Cookie headers that set signed cookies on the viewers for authenticated users. When you create signed URLs or signed cookies to control access to your files, you can specify the following restrictions: An expiration date and time for the URL (Optional) The date and time the URL becomes valid (Optional) The IP address or range of addresses of the computers that can be used to access your content You can use signed URLs or signed cookies for any CloudFront distribution, regardless of whether the origin is an Amazon S3 bucket or an HTTP server.	You can configure an S3 bucket as the origin of a CloudFront distribution. OAI prevents users from viewing your S3 files by simply using the direct URL for the file. Instead, they would need to access it through a CloudFront URL. To require that users access your content through CloudFront URLs, you perform the following tasks: Create a special CloudFront user called an origin access identity. Give the origin access identity permission to read the files in your bucket. Remove permission for anyone else to use Amazon S3 URLs to read the files (through bucket policies or ACLs). You cannot set OAI if your S3 bucket is configured as a website endpoint.

Backup Restore vs Pilot Light vs Warm Standby vs Multi-Site

AWS Disaster Recovery: Pilot Light, Warm Standby, Multi-site | CBT Nuggets

https://tutorialsdojo.com/backup-and-restore-vs-pilot-light-vs-warm-standby-vs-multi-site/

Backup and Restore	Pilot Light	Warm StandBy	Multi-Site
This DR plan provides the slowest system restoration after a DR event. You take frequent snapshots of your data such as those in Amazon EBS Volumes and Amazon RDS databases, and you store them in a durable and secure storage location such as Amazon S3. There are many ways for you to move data in and out of S3 Transfer over the network via S3 Transfer Acceleration Transfer over a dedicated network line using AWS Direct Connect Transfer using transport hardware such as AWS Snowball Edge and Snowmobile With S3 Glacier, you get to reduce a large portion of your costs compared to using S3 Standard, since Glacier is meant for long term archival storage which is perfect for backups. AWS Storage Gateway enables snapshots of your on-premises data volumes to be transparently copied into S3 for backup. Storage-cached volumes allow you to store your primary data in S3, but keep your frequently accessed data local for low-latency access. Gateway-VTL of AWS Storage Gateway serves as a replacement for traditional magnetic tape backup. You can quickly create local volumes or Amazon EBS volumes from snapshots in S3. You can create AMIs out of your EC2 instances which preserve the following: A template for the root volume for the instance (for example, an operating system, an application server, and applications) Launch permissions that control which AWS accounts can use the AMI to launch instances A block device mapping that specifies the volumes to attach to the instance when it’s launched Backup and restore is used in combination with other DR plans since it is crucial to always have a working backup of your system.	The pilot light method gives you a quicker recovery time than the backup-and-restore method because the core pieces of the system are already running and are continually kept up to date, but is not as fast as Warm Standby. You can maintain a pilot light by configuring and running the most critical core elements of your system in AWS. When the time comes for recovery, you can rapidly provision a full-scale production environment around the critical core. Pilot light is an example of active/passive failover configuration. Infrastructure elements for the pilot light itself typically include your database servers, which would be configured for data mirroring replication. Restoring the rest of the system includes utilizing EBS snapshots and EC2 AMIs that you should be regularly generating. Pilot light tends to be more costly than backup and restore since you leave a few core AWS resources running all the time. From a networking point of view, you have two main options for provisioning web servers: Use Elastic IP addresses, which can be pre-allocated and pre-identified, and associate them with your instances. Use Elastic Load Balancing (ELB) to distribute traffic to multiple instances. You would then update your DNS records to point at your EC2 instance or point to your load balancer using a CNAME. Consider redundancy especially at your data layer (enable multi-AZ, cluster sharding, etc). If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.	This DR plan is faster in system restoration than performing Pilot Light after a DR event, but is not as fast as having a Multi-site System. Warm standby describes a DR scenario in which a scaled-down version of a fully functional environment is always running in the cloud. Since it is not only your core elements that are running all the time, warm standby is usually more costly than pilot light. Warm standby is another example of active/passive failover configuration. Servers can be left running in a minimum number of EC2 instances on the smallest sizes possible. Once failover occurs, quickly resize them and add scaling capabilities. It is best to place these instances behind a load balancer as well. For the data layer, the practice is similar to pilot light where a standby resource is present and changing data is constantly being replicated to the other. In the case of failure of the production system, the standby environment will be scaled up for production load , and DNS records will be changed to route all traffic to AWS. If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.	This DR plan is the fastest in system restoration during a DR event. Multi-site is a one-to-one copy of your infrastructure that is located and running in another region or AZ, known as an active-active configuration. Because of this, multi-site is the most expensive among all DR plans. Multi-site gives you the best RTO and RPO as no downtime is expected and little to no data loss should be experienced. In addition to recovery point options, there are various replication methods, such as synchronous and asynchronous methods. You can use a DNS service that supports weighted routing, such as Amazon Route 53, to route production traffic to different sites that deliver the same application or service. During failover, you can quickly increase compute capacity by using AWS Auto Scaling or by resizing your instances to a larger size. Multiple services in AWS such as RDS offer a multi-AZ feature which allows you to provision resources in a different location for a more fault-tolerant setup. If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.

Kinesis Data Stream vs Kinesis Data Firehose

AWS Kinesis Data Streams vs Kinesis Data Firehose