AWS - SNS

Amazon SNS is a fully managed publish/subscribe messaging service that enables applications, microservices, and users to communicate asynchronously — meaning messages are pushed to all interested subscribers instantly.

In short:

SNS = Publish once, deliver to many subscribers (fan-out)

It decouples services and allows parallel message delivery to multiple endpoints.

---

SNS Key Features

Feature	Description
Pub/Sub messaging	One publisher sends a message to many subscribers simultaneously.
Multiple protocols	Subscribers can be Email, SMS, HTTP/S endpoints, AWS Lambda, or SQS queues.
Fan-out pattern	A single event triggers multiple downstream processes.
High availability	Fully managed, scalable, and reliable (multi-AZ).
Security	IAM + topic policies + encryption with AWS KMS.

---

SNS vs. EventBridge

This is a common AWS interview and design question — let’s break it down clearly:

Feature	Amazon SNS	Amazon EventBridge
Type	Pub/Sub messaging service	Event bus for event-driven architecture
Message Model	Publisher → Topic → Subscribers	Event producer → Event bus → Rules → Targets
Routing Logic	All subscribers get the same message (fan-out)	Rules filter and route events based on content
Supported Targets	Lambda, SQS, HTTP/S, SMS, Email, Mobile	20+ AWS services + SaaS apps (Zendesk, Datadog, etc.)
Filtering	Basic (per-subscription filter policies)	Advanced content-based filtering using JSON pattern
Event Format	Custom message (you define the payload)	Standardized JSON “event envelope”
Delivery	Push-based to all subscribers	Routed to specific targets based on rule conditions
Best For	Alerts, notifications, fan-out processing	Complex event-driven integration across AWS and SaaS
Cost	Cheaper	Slightly higher (charged per event and rule)

In short:

• Use SNS when → you need simple notifications or fan-out (one-to-many).

• Use EventBridge when → you need intelligent routing, filtering, or event-driven workflows.

---

Example Architecture — SNS with Multiple Subscribers

Let’s design a multi-subscriber architecture using SNS:

Scenario: EC2 Monitoring & Alert System

When EC2 CPU utilization > 80%, CloudWatch sends an alert → SNS → multiple subscribers take different actions.

---

Flow:

1. CloudWatch Alarm detects EC2 CPU spike

2. Alarm publishes message to SNS topic → arn:aws:sns:us-east-1:123456789012:EC2-Alert-Topic

3. SNS fans out the message to multiple subscribers:

   • Email subscriber: Notifies sysadmin

   • Lambda function: Automatically scales up EC2 instance count

   • SQS queue: Stores message for audit/log processing

   • SMS subscriber: Sends urgent text alert to on-call engineer

---

Components

Component	Purpose
CloudWatch Alarm	Detects threshold breach and triggers SNS topic
SNS Topic: EC2-Alert-Topic	Central notification hub
Lambda Subscriber	Executes auto-remediation logic (e.g., scale up EC2)
SQS Queue	Stores events for downstream analytics/audit
Email Subscriber	Notifies support engineers
SMS Subscriber	Sends urgent mobile alerts

---

Message Example (JSON Payload)

{
  "AlarmName": "HighCPUUtilization",
  "InstanceId": "i-0abc12345def6789",
  "MetricName": "CPUUtilization",
  "Threshold": 80,
  "CurrentValue": 92.3,
  "Region": "us-east-1",
  "Time": "2025-10-21T14:10:00Z"
}

---

Architecture Diagram (described for PPT/draw.io)

          +----------------------+
          | CloudWatch Alarm     |
          |  (EC2 CPU > 80%)     |
          +----------+-----------+
                     |
                     v
             +---------------+
             |  SNS Topic     |
             | EC2-Alert-Topic|
             +-------+--------+
                     |
     -----------------------------------------
     |            |             |            |
     v            v             v            v
 +---------+  +---------+   +----------+  +----------+
 | Email   |  | Lambda  |   |   SQS    |  |   SMS    |
 | Notify  |  | AutoScale|   | Logging  |  | On-Call  |
 +---------+  +---------+   +----------+  +----------+

---

Cost & Reliability

Feature	SNS
Pricing	~$0.50 per million publishes
Retries	Yes, with exponential backoff for Lambda/HTTP
Durability	Messages stored redundantly across multiple AZs
Monitoring	Integrated with CloudWatch metrics and logs

---

When to Combine SNS + Event Bridge

In modern AWS event-driven setups, they’re often used together:

Example:
EventBridge captures all EC2 events → applies filtering rules → sends to SNS topic → SNS fans out to Lambda + SQS + email.

So you can use EventBridge for filtering/routing and SNS for multi-channel notification delivery. 

AWS - VPC Endpoints

Used to securely connect your VPC instance to external services(like S3) out side VPC without using internet Gateway.

A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by Private link without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
Instances in your VPC do not require public IP addresses to communicate with resources in the service.
Traffic between your VPC and the other service does not leave the Amazon network

1. Interface Endpoints (AWS Private Link)
An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service. The following services are supported:

1. Amazon CloudWatch Logs
2. Amazon EC2 API
3. Amazon Kinesis Data Streams
4. Amazon SNS
5. AWS KMS
6. AWS Service Catalog
7. AWS Systems Manager
8. Elastic Load Balancing API
9. Endpoint services hosted by other AWS accounts
10. Supported AWS Marketplace partner services

Connecting to other VPC without using internet Gateway, AWS private link with Interface End point.

2. Gateway Endpoints

A gateway endpoint is a gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service. The following AWS services are supported:
Basically supports storage services.

1. Amazon S3
2. DynamoDB

AWS - SQS

Amazon SQS is a fully managed message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. It acts as a buffer between components of a system that communicate asynchronously.

---

Why Use SQS?

Imagine you have a system with multiple services (e.g., a web app and a background worker). You don't want your web server to wait for long tasks (like image processing or email sending). With SQS:

• The web server sends a message to the queue.

• The worker processes messages from the queue asynchronously.

• If the worker fails, the message stays in the queue until it’s successfully processed (or moved to a dead-letter queue after repeated failures).

---

Core Concepts

Concept	Description
Queue	A buffer where messages are stored until they're processed.
Message	A unit of data sent between components (can include up to 256 KB of data).
Producer	The component that sends messages to the queue.
Consumer	The component that receives and processes messages.
Visibility Timeout	Time during which a message is invisible after being read (to avoid duplication).
Dead-Letter Queue	Stores messages that couldn't be processed successfully after retries.

---

Types of SQS Queues

1. Standard Queue

   • Default type

   • At-least-once delivery (possible duplicates)

   • Best-effort ordering

   • High throughput (nearly unlimited)

2. FIFO Queue (First-In-First-Out)

   • Exactly-once processing (no duplicates)

   • Preserved order

   • Lower throughput compared to Standard (up to 3000 messages/sec with batching)

---

Key Features

• Fully managed: No infrastructure to manage

• Scalable: Handles millions of messages per second

• Secure: Supports IAM policies, encryption (SSE)

• Durable: Messages stored redundantly across multiple AZs

• Long polling: Reduces empty responses by waiting up to 20 seconds for messages

---

Common Use Cases

• Decoupling microservices

• Buffering requests (throttling)

• Asynchronous task processing (email, video transcoding)

• Distributed workloads

• Order processing systems (FIFO)

---

Sample Workflow

1. Producer sends a message to the queue:

   aws sqs send-message --queue-url <QUEUE_URL> --message-body "ProcessOrder123"
   

2. Consumer polls and processes:

   aws sqs receive-message --queue-url <QUEUE_URL> --max-number-of-messages 1
   

3. Deletes message after processing:

   aws sqs delete-message --queue-url <QUEUE_URL> --receipt-handle <HANDLE>
   

---

Security and Access Control

• Use IAM policies to restrict who can send/receive/delete messages.

• Enable server-side encryption with SSE-SQS or SSE-KMS.

• Use VPC endpoints for private access.

---

Integrations

• AWS Lambda: Trigger Lambda functions from SQS messages (FIFO supported).

• Amazon SNS: SNS can fan-out messages to SQS queues.

• Step Functions: Use SQS for wait and queue-based orchestration.

• EC2, ECS, EKS: Poll SQS from worker nodes.

AWS - Simple Queue Service (SQS)

Amazon SQS is a web service API with highly scalable, reliable hosted queue of messages, those can be produced and consumed by multiple sources(components/micro services) of your application architecture.
Amazon Simple Queue Service (Amazon SQS) is a scalable message queuing system that stores messages as they travel between various components of your application architecture. Amazon SQS enables web service applications to quickly and reliably queue messages that are generated by one component and consumed by another component. A queue is a temporary repository for messages that are awaiting processing.

Standard Queue:
May deliver a message more than one, order of messages not maintained.
Useful when high volume processing important not order   

FIFO Queue:
Delivers a message once in correct order.
Useful when order is important

S.No.	Limit	Description
1	Message attributes	A message can contain up to 10 metadata attributes.
2	Message batch	A single message batch request can include a maximum of 10 messages.
3	Message content	A message can include only XML, JSON, and unformatted text. The following Unicode characters are allowed: #x9 | #xA | #xD | #x20 to #xD7FF | #xE000 to#xFFFD | #x10000 to #x10FFFF Any characters not included in this list are rejected
4	Message retention	By default, a message is retained for 4 days. The minimum is 60 seconds (1 minute). The maximum is 1,209,600 seconds (14 days).
5	Message throughput	Standard queues support nearly unlimited transaction per second Without batching, FIFO queues support 300 messages per second With batching, FIFO supports 3000 messages per second
6	Message size	The minimum message size is 1 byte (1 character). The maximum is 262,144 bytes (256 KB). To send messages larger than 256 KB, you can use the Amazon SQS Extended Client Library for Java. This library allows you to send an Amazon SQS message that contains a reference to a message payload in Amazon S3. The maximum payload size is 2 GB.
8	Message visibility timeout	The default visibility timeout for a message is 30 seconds. The maximum is 12 hours.
9	Policy information	The maximum limit is 8,192 bytes, 20 statements, 50 principals, or 10 conditions.

Benefits

1. Reduces Infrastructure
2. Multiple Producers and consumers
3. Each Queue can be configured Separately
4. Access Control
5. Variable Message Size
6. Customized Delay Setting

Facts

1. Message delivers once but might be multiple times, no guarantee

AWS - AWS Services Definitions

GraphQL: Query and manipulation language for APIs

Comprehend: Used for natural language processing, Personal Identifiable Information (PII) detection and redaction, Custom Classification and Entity detection, and topic modeling, enabling a broad range of applications that can analyze raw text, and with some APIs, document formats like PDF and Word.(text analysis)

Lex: Amazon Lex is an AWS service for building conversational interfaces for applications using voice and text. With Amazon Lex, the same conversational engine that powers Amazon Alexa is now available to any developer, enabling you to build sophisticated, natural language chatbots into your new and existing applications.

Polly: Used to convert text to audio

AppSync: An application can fetch required data from multiple sources (like lambda, dynamodb, aurora, http end points or other services) with single network call, Appsync resolver diverts the call to correct data source. 

S3 File Gateway: File gateway using S3. (File Gateway can use S3, FSX, TAP or volume storage to store data) 

Neptune: Graph database, store entities with relations

Timestream data

S3 select: Used to query required data from a single object like csv

Athena: Querying data from S3

Redshift Spectrum: Can Query data from Redshift and S3 as well

VPC Endpoint service vs VPC Gateway Endpoint service: Gateway endpoint service is for only S3 and DynamoDB

AWS Trusted Advisor: Provide guidance to provision aws resources following AWS best practices

AWS Personal health dashboard: Provides alerts and guidance for events that might effect your environment. 

AWS Data Pipeline: AWS Data Pipeline is a cloud-based data workflow service that helps you process and move data between different AWS services and on-premise data sources.

Formula to get no. of Ip addresses by mask:

a = 32 - mask

b = 2 pow a

c = b - 5

Ans: c

Ex. Mask is 24 

32-24 = 8

2 pow 8 = 256

256 - 5 = 251

System Manager: A collection of capabilities to help you manage your applications and infrastructure running in the AWS Cloud. A management service that helps you automatically collect software inventory, apply OS patches, create system images, and configure Windows and Linux operating systems. These capabilities help you define and track system configurations, prevent drift, and maintain software compliance of your EC2 and on-premises configurations.

Security Hub: The Security Hub provides a single place in the AWS environment to aggregate, organize, and prioritize security alerts and discoveries from multiple AWS security services. This may be Amazon GuardDuty, Amazon Inspector, Amazon Macie, IAM, Access Analyzer, AWS Firewall Manager. A cloud security posture service that automates security checks and brings security alerts into a central location. 

• Inspector: (For EC2 mostly) An automated vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure.
• Macie: (Care your sensitive data) A fully managed data security and data privacy service that uses machine learning and pattern matching to discover and protect your sensitive data in S3.
• Detective: Amazon Detective makes it easy to analyze, investigate, and quickly identify the root cause of security findings or suspicious activities
• Guard Duty: A threat detection service that continuously monitors your AWS accounts and workloads for malicious activity

AWS Keyspace: Service that manages Casendra DB so developer don't have headach to manages hundreds of casandra nodes

Cloud trail Lake: Modernize, fully managed solution for capturing, storing, accessing and analyzing user and API related activities.
It enables you to create a event data store from different resources like events of your applications under aws or on premises. 
Then you can query event data store.

EMR: Big data processing 

AWS Transcribe: Used to convert audio/video to text. Polly does just opposite work.

AWS Translate: Used for text translations to supported languages

AWS Kendra: Used to build search capabilities (like search engine)

AWS Health Dashboard & event bridge:

---------------------------------------------------------------------------------------------------------------------

Here are some widely used AWS resources and services, along with their descriptions and usage:

Compute Services

1. EC2 (Elastic Compute Cloud): Virtual machines for computing and processing.

2. Lambda: Serverless computing for event-driven applications.

3. Elastic Beanstalk: Managed platform for deploying web applications.

Storage Services

1. S3 (Simple Storage Service): Object storage for files and data.

2. EBS (Elastic Block Store): Block-level storage for EC2 instances.

3. EFS (Elastic File System): File-level storage for EC2 instances.

Database Services

1. RDS (Relational Database Service): Managed relational databases (e.g., MySQL, PostgreSQL).

2. DynamoDB: NoSQL key-value and document database.

3. DocumentDB: Document-oriented database compatible with MongoDB.

Security, Identity, and Compliance

1. IAM (Identity and Access Management): User authentication and access control.

2. Cognito: User identity and access management for web apps.

3. Inspector: Security assessment and compliance monitoring.

Networking and Content Delivery

1. VPC (Virtual Private Cloud): Virtual networking for AWS resources.

2. Route 53: Domain name system (DNS) and routing.

3. CloudFront: Content delivery network (CDN) for distributing content.

Analytics and Machine Learning

1. Redshift: Data warehousing and analytics.

2. QuickSight: Fast, cloud-powered business intelligence.

3. SageMaker: Machine learning platform for building and deploying models.

Application Integration and Deployment

1. SQS (Simple Queue Service): Message queue for decoupling applications.

2. SNS (Simple Notification Service): Pub-sub messaging for event-driven apps.

3. CodePipeline: Continuous integration and continuous delivery (CI/CD) pipeline.

Management and Governance

1. CloudWatch: Monitoring and logging for AWS resources.

2. CloudFormation: Infrastructure as code for resource provisioning.

3. Trusted Advisor: Best practices and optimization recommendations.

--------------------------------------------------------------------------------------------------------------------------

Here are some additional widely used AWS resources and services:

Compute Services

1. ECS (Elastic Container Service): Container orchestration for Docker containers.

2. EKS (Elastic Kubernetes Service): Managed Kubernetes service for containerized applications.

3. Batch: Batch processing for large-scale workloads.

Storage Services

1. Glacier: Long-term archival storage for infrequently accessed data.

2. Storage Gateway: Hybrid storage for on-premises and cloud storage.

3. FSx: Fully managed file storage for Windows and Linux workloads.

Database Services

1. Aurora: MySQL and PostgreSQL-compatible relational database.

2. Neptune: Graph database for relationships and networks.

3. Quantum Ledger Database (QLDB): Ledger database for financial and supply chain applications.

Security, Identity, and Compliance

1. GuardDuty: Threat detection and monitoring for AWS accounts.

2. Macie: Data privacy and data protection for S3 and DynamoDB.

3. Certificate Manager: SSL/TLS certificate management for secure connections.

Networking and Content Delivery

1. Direct Connect: Dedicated network connection to AWS for hybrid environments.

2. API Gateway: RESTful API management for microservices and serverless applications.

3. App Mesh: Service mesh for microservices and containerized applications.

Analytics and Machine Learning

1. Lake Formation: Data warehousing and analytics for data lakes.

2. Comprehend: Natural language processing (NLP) for text analysis.

3. Rekognition: Deep learning-based image and video analysis.

Application Integration and Deployment

1. Step Functions: Visual workflow management for serverless applications.

2. AppRunner: Containerized application deployment and management.

3. Cloud Development Kit (CDK): Infrastructure as code for AWS resources using programming languages.

Management and Governance

1. CloudTrail: Auditing and logging for AWS API calls.

2. Config: Resource configuration and compliance monitoring.

3. Organizations: Centralized management for multiple AWS accounts.

AWS - Dynamo DB Eventual Vs Strong Consistency

 1. Eventually Consistent Reads (Default)

🔹 Definition:

When you perform a read immediately after a write, you may not get the latest data right away — but it will become consistent after a short delay (typically a fraction of a second).

🔹 Characteristics:

• Low latency

• Higher throughput (uses fewer read capacity units)

• Suitable for most applications where data staleness of a few milliseconds is acceptable.

🔹 Use Case Example:

You’re displaying a product catalog on an e-commerce site where slight delay in updated inventory count is okay.

---

2. Strongly Consistent Reads

🔹 Definition:

When you request a strongly consistent read, DynamoDB returns the most up-to-date value — including all successful writes before the read.

🔹 Characteristics:

• Higher latency than eventually consistent reads

• Lower throughput (uses more read capacity units)

• Guaranteed to return the latest data from a single region

🔹 Use Case Example:

Banking app displaying account balance immediately after a transaction.

🔐 Note: Strongly consistent reads are only supported in the same AWS region. Cross-region replication introduces eventual consistency.

---

Additional Concepts Related to Consistency:

🔸 Transactions:

• DynamoDB supports ACID transactions, which ensure serializable isolation — the highest consistency level.

• You can group multiple reads/writes to succeed or fail as a unit.

🔸 DynamoDB Global Tables:

• Allow multi-region, active-active replication.

• Eventually consistent by design across regions.

• Great for high availability and low-latency access globally, but writes in one region may not be immediately visible in another.

---

Summary Table:

Feature	Eventually Consistent	Strongly Consistent
Read Latency	Lower	Higher
Read Capacity Usage	0.5 units per KB	1 unit per KB
Data Freshness Guarantee	No	Yes (within region)
Availability	Higher	Slightly Lower
Use Case	Read-most apps, low risk of staleness	Critical reads needing up-to-date data

AWS - CloudTrail Vs Cloudwatch

AWS CloudTrail vs CloudWatch is a common area of confusion, especially since both are logging and monitoring tools, but they serve very different purposes.

Here’s a clear, side-by-side breakdown from an AWS architecture and security perspective:

---

AWS CloudTrail vs CloudWatch

Feature	CloudTrail	CloudWatch
Purpose	Audit and log API activity across AWS services	Monitor performance, logs, and metrics of applications and AWS resources
Primary Use Case	Security auditing, compliance, forensics, user activity tracking	System performance, operational health, alerting, log analytics
What it Captures	API calls (who did what, when, where, from where)	Logs, metrics, and events from AWS resources and apps
Scope	Account-level activity across all regions	Resource-level metrics and logs
Data Source	AWS service control plane (e.g., IAM, EC2, S3 APIs)	Resource metrics, custom metrics, application logs
Event Format	Structured JSON audit logs	Metrics (numbers), logs (unstructured/semi-structured), dashboards
Delivery Target	S3 (by default), CloudWatch Logs (optionally), CloudTrail Lake	CloudWatch Console, Logs, Alarms, Dashboards
Real-time Alerts?	Not directly (can trigger via CloudWatch)	Yes — native alerting with CloudWatch Alarms
Retention	Depends on S3 bucket policy or CloudTrail Lake	Configurable (default 14 days for metrics)
Cost	Free for basic management events; charges for data events, Insights, Lake	Charges for metrics, logs, dashboards, alarms

---

When to Use Each

Use Case	Use CloudTrail	Use CloudWatch
Track who accessed or modified a resource	✅ Yes	❌ No
Set an alarm when CPU > 80%	❌ No	✅ Yes
Detect a user disabling MFA or deleting logs	✅ Yes	❌ No
View S3 read/write object access	✅ Yes (with Data Events)	❌ Not by default
Get alerted when Lambda errors spike	❌ Not natively	✅ Yes
Log your application output (stdout, errors)	❌ No	✅ Yes (CloudWatch Logs)

---

Analogy

• CloudTrail is like a security camera recording who did what in your AWS account.

• CloudWatch is like a dashboard and alarm system monitoring how things are performing, and notifying you when something goes wrong.

---

How They Work Together

They’re often used together for full observability and security:

• CloudTrail can send logs to CloudWatch Logs, where you can:

  • Create metric filters

  • Trigger CloudWatch Alarms

  • Integrate with SNS or Lambda for automated responses

Example: You can detect and alert when someone disables CloudTrail logging using a CloudWatch Alarm on a specific API call (StopLogging).

---

Example Use in Real-World Scenario:

Goal: Detect when an IAM user deletes a security group

1. CloudTrail logs the API call: DeleteSecurityGroup

2. This event is sent to CloudWatch Logs via a Trail

3. A Metric Filter in CloudWatch detects this pattern

4. A CloudWatch Alarm triggers an SNS notification or Lambda function

AWS - CloudTrail

AWS CloudTrail is a logging and auditing service that automatically records every API call (management, data, and event-level) made in your AWS account.

Think of it as your "flight recorder" for AWS — it captures the who, what, when, where, and from where for every action taken, whether via:

• AWS Console

• CLI

• SDKs

• AWS services on your behalf

---

Why Use CloudTrail?

1. Security Auditing
   Detect unauthorized or unusual activity (e.g., a user creating new IAM roles or disabling logging).

2. Compliance
   Helps meet regulatory requirements (e.g., PCI-DSS, HIPAA, SOC).

3. Operational Troubleshooting
   Trace changes or errors back to specific users or services.

4. Forensics & Incident Response
   Investigate breaches or misconfigurations historically.

---

Key Concepts

Concept	Description
Event	A record of an API call or action taken
Trail	A configuration that delivers events to an S3 bucket
Management Events	Actions like creating resources, changing permissions (default: enabled)
Data Events	High-volume events like S3 object-level access or Lambda executions (optional, paid)
Insight Events	Detect and alert on unusual API call patterns (e.g., spikes in activity)

---

Where are the logs stored?

CloudTrail delivers logs to:

• Amazon S3 bucket (mandatory)

• CloudWatch Logs (optional, for real-time monitoring)

• CloudTrail Lake (optional, for querying with SQL directly in AWS)

---

Cost

• Management events: First copy per region is free

• Data events & Insights: Charged per event

• CloudTrail Lake: Charged for ingestion and querying

---

Best Practices

1. Enable CloudTrail in all regions (Global trail)

2. Use an S3 bucket with versioning and access logging

3. Enable encryption (SSE or KMS)

4. Send logs to CloudWatch Logs for alerts

5. Enable Insight events to detect anomalies

6. Enable multi-account trails with AWS Organizations

---

Example Event Log (JSON)

{
  "eventTime": "2025-10-05T12:00:00Z",
  "eventSource": "ec2.amazonaws.com",
  "eventName": "StartInstances",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "dev-ops-user"
  },
  "sourceIPAddress": "192.0.2.0",
  "requestParameters": {
    "instancesSet": {
      "items": ["i-1234567890abcdef0"]
    }
  }
}

AWS - Resource Sharing

In AWS, Resource Sharing means making AWS resources owned by one account available for use in other AWS accounts.

This is typically done via AWS Resource Access Manager (RAM).

Instead of duplicating infrastructure in every account, you share centrally and let other accounts or AWS Organizations members use those resources.

(Not all AWS resources are shareable; only supported ones via RAM.)

---

How Resource Sharing Works (via AWS RAM)

1. Owner account (Resource owner)

   • Creates the resource (e.g., VPC subnets, Transit Gateway, License configuration).

   • Shares it via AWS RAM.

2. Shared accounts (Principals)

   • Can be:

     • Another AWS account

     • An AWS Organization / OU

     • Specific IAM roles or users (in some cases)

3. Accepting the share

   • The other account accepts the resource share invitation (unless sharing is inside an Organization with auto-accept enabled).

4. Using the resource

   • Shared account can use the resource, but usually cannot manage/delete it (ownership stays with the resource owner).

---

Example Resources You Can Share

• VPC Subnets (for centralized networking).

• Transit Gateway (hub-and-spoke networking).

• Route 53 Resolver rules.

• AWS License Manager configurations.

• Dedicated Hosts.

• Aurora DB clusters (via Aurora global).

• Outposts resources.

(Not all AWS resources are shareable; only supported ones via RAM.)

---

Real-World Example

Imagine a company with 3 AWS accounts:

• Networking account → hosts central VPC, Transit Gateway, Route 53 rules.

• App account → runs EC2 & ECS.

• DB account → runs RDS clusters.

Instead of duplicating networking in every account:

• The Networking account shares the Transit Gateway and VPC subnets using AWS RAM.

• The App account attaches its workloads to the shared VPC and TGW.

• The DB account uses shared Route 53 rules to resolve internal DNS.

This way → centralized control + cost savings + easier management.

---

Benefits of Resource Sharing

• Centralized management (one networking/account manages core infra).

• Cost optimization (no duplicate TGWs, subnets, rules).

• Security & compliance (principals can use but not modify resources).

• Scalability (works across AWS Organizations).

AWS - WAF

AWS Web Application Firewall (WAF) is a managed security service that protects your web applications and APIs from common Layer 7 (HTTP/S) threats and exploits.

It lets you define rules that filter, allow, or block requests based on conditions like:

• IP addresses

• HTTP headers

• Query strings

• URI paths

• Request size

• SQL injection attempts

• Cross-site scripting (XSS)

---

Where AWS WAF Can Be Deployed

You can associate WAF with:

• Amazon CloudFront (global CDN layer)

• Application Load Balancer (ALB)

• API Gateway

• AWS AppSync

• AWS Verified Access

---

Key Features

1. Rule-based filtering

   • Managed rule groups (by AWS & AWS Marketplace vendors).

   • Custom rules (e.g., block specific IPs, allow only certain countries).

2. Protection against OWASP Top 10

   • SQLi, XSS, bad bots, etc.

3. Rate-based rules

   • Throttle traffic (e.g., block IPs sending > 1000 requests in 5 minutes).

4. Bot Control

   • Detects & blocks automated bots and scrapers.

5. Visibility & Monitoring

   • Integration with Amazon CloudWatch & AWS Kinesis Firehose for logging.

---

Example Use Cases

• Protect an e-commerce site against SQL injection.

• Block traffic from specific countries (GeoMatch).

• Rate-limit APIs to prevent DDoS-style floods.

• Allow only corporate IP ranges to access admin endpoints.

---

Example Rule (JSON snippet)

This rule blocks requests with script in the query string (to stop simple XSS):

{
  "Name": "BlockXSS",
  "Priority": 1,
  "Action": { "Block": {} },
  "Statement": {
    "ByteMatchStatement": {
      "SearchString": "script",
      "FieldToMatch": { "QueryString": {} },
      "TextTransformations": [
        { "Priority": 0, "Type": "URL_DECODE" }
      ],
      "PositionalConstraint": "CONTAINS"
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockXSS"
  }
}

---

AWS WAF vs AWS Shield

• AWS WAF → Protects against application layer attacks (Layer 7).

• AWS Shield → Protects against DDoS (Layer 3/4).