AWS Services Overview - Interview Questions with Diagrams

Q1: CloudWatch vs CloudTrail

graph TB
    subgraph CloudTrail[CloudTrail - Who Did What?]
        CT[CloudTrail] --> Audit[Audit & Compliance]
        Audit --> Q1[Who made S3 public?]
        Audit --> Q2[Who shut down EC2?]
        Audit --> Q3[Which IP logged in?]
        
        CT --> Store[Centralized Storage]
        Store --> S3Logs[Store in S3]
        Store --> CrossRegion[Across Regions]
    end
    
    subgraph CloudWatch[CloudWatch - What's Happening?]
        CW[CloudWatch] --> Monitor[Monitoring & Alerts]
        Monitor --> Logs[Application Logs]
        Monitor --> Metrics[Resource Metrics]
        Monitor --> Alarms[Alarms & Events]
        
        Metrics --> CPU[CPU Utilization]
        Metrics --> Network[Network In Out]
    end
    
    style CloudTrail fill:#FF9900
    style CloudWatch fill:#2196F3

Key Differences:

• CloudTrail: Answers "Who did what?" for compliance, governance, and auditing
• Logs all API calls, user actions, and administrative activities
• Centralizes logs across regions and accounts in S3 buckets
• Essential for security investigations and compliance requirements
• CloudWatch: Answers "What's happening?" with resource performance
• Collects logs from applications, Lambda functions, and system services
• Monitors metrics like CPU, memory, disk, network for EC2 and other services
• Creates alarms to trigger actions based on metric thresholds

Q2: Storage Comparison - EBS vs EFS vs S3

graph TB
    Storage[AWS Storage] --> Block[Block Storage]
    Storage --> Object[Object Storage]
    
    Block --> EBS[EBS<br/>Elastic Block Store]
    Block --> EFS[EFS<br/>Elastic File System]
    Object --> S3[S3<br/>Simple Storage]
    
    EBS --> E1[EC2 Server Disk]
    EBS --> E2[High IOPS]
    EBS --> E3[Single AZ]
    EBS --> E4[One EC2 at Time]
    
    EFS --> F1[Multiple EC2]
    EFS --> F2[Cross-AZ]
    EFS --> F3[NFS Protocol]
    EFS --> F4[Auto Scaling]
    
    S3 --> S1[Write Once Read Many]
    S3 --> S2[Object Storage]
    S3 --> S3[Cross-AZ]
    S3 --> S4[Unlimited Scale]
    
    style EBS fill:#FF9900
    style EFS fill:#4CAF50
    style S3 fill:#2196F3

Storage Selection Guide:

• EBS: Block storage attached to single EC2 instance in one AZ
• Best for databases, operating systems requiring high IOPS performance
• Must provision size in advance, can resize but requires downtime
• EFS: Network file system mountable by multiple EC2 instances simultaneously
• Spans multiple AZs for high availability, can mount on-premise via VPN
• Auto-scales capacity, pay only for storage used, no pre-provisioning
• S3: Object storage for write-once-read-many scenarios
• Best for static files, backups, archives, data lakes, content distribution
• Unlimited scalability, cross-AZ replication, not suitable for databases or OS

Q3: SNS vs SQS Messaging

graph TB
    subgraph SNS[SNS - Publish Subscribe]
        Publisher[Publisher] --> Topic[SNS Topic]
        Topic --> Sub1[SQS]
        Topic --> Sub2[Lambda]
        Topic --> Sub3[Email]
        Topic --> Sub4[SMS]
        
        Note1[Push Model<br/>Immediate]
    end
    
    subgraph SQS[SQS - Queue Service]
        Sender[Sender] --> Queue1[Queue 1]
        Sender --> Queue2[Queue 2]
        
        Queue1 --> Consumer1[Consumer 1<br/>Polls]
        Queue2 --> Consumer2[Consumer 2<br/>Polls]
        
        Note2[Pull Model<br/>Polling]
    end
    
    style SNS fill:#FF9900
    style SQS fill:#2196F3

Messaging Patterns:

• SNS (Simple Notification Service): Publish/subscribe pattern for fan-out
• One publisher sends message to topic, multiple subscribers receive simultaneously
• Push model—messages delivered immediately to all subscribers
• Supports SQS, Lambda, Email, SMS, HTTP endpoints as subscribers
• SQS (Simple Queue Service): Point-to-point message queue
• Consumers must actively poll queue to retrieve messages (pull model)
• Each message processed by single consumer, then deleted from queue
• Need multiple queues if multiple consumers require same message
• SQS provides message persistence, SNS provides immediate broadcast

Q4: SNS Fan-Out Pattern

sequenceDiagram
    participant S3
    participant SNS as SNS Topic
    participant SQS1 as SQS Queue 1
    participant Lambda
    participant Email
    
    S3->>SNS: Publish Event<br/>New File Uploaded
    
    Note over SNS: Fan-out to all
    
    SNS->>SQS1: Deliver to Queue
    SNS->>Lambda: Trigger Function
    SNS->>Email: Send Notification
    
    Note over SQS1,Email: All receive simultaneously

Fan-Out Benefits:

• Single event triggers multiple independent processing workflows
• S3 upload event can simultaneously trigger queue processing, Lambda execution, and email notification
• Each subscriber processes message independently without affecting others
• Decouples publishers from subscribers for better scalability
• If one subscriber fails, others continue processing
• Common pattern for event-driven architectures and microservices
• Reduces complexity compared to point-to-point integrations

Q5: SQS Processing Pattern

sequenceDiagram
    participant Producer
    participant SQS as SQS Queue
    participant C1 as Consumer 1
    participant C2 as Consumer 2
    
    Producer->>SQS: Send Message 1
    Producer->>SQS: Send Message 2
    Producer->>SQS: Send Message 3
    
    Note over SQS: Messages wait
    
    C1->>SQS: Poll for Messages
    SQS-->>C1: Return Message 1
    C1->>C1: Process Message 1
    C1->>SQS: Delete Message 1
    
    C2->>SQS: Poll for Messages
    SQS-->>C2: Return Message 2
    C2->>C2: Process Message 2
    C2->>SQS: Delete Message 2

SQS Characteristics:

• Messages persist in queue until explicitly deleted by consumer
• Visibility timeout prevents other consumers from processing same message
• Supports message retention up to 14 days
• Dead letter queue for messages that fail processing multiple times
• Standard queue: at-least-once delivery, best-effort ordering
• FIFO queue: exactly-once delivery, strict ordering (lower throughput)
• Decouples producers from consumers for asynchronous processing
• Auto-scales to handle any message volume

Q6: Amazon SES Email Service

graph TB
    SES[Amazon SES] --> Send[Send Email]
    SES --> Receive[Receive Email]
    
    Send --> S1[Marketing Emails]
    Send --> S2[Transactional]
    Send --> S3[Notifications]
    
    Receive --> R1[Spam Scanning]
    Receive --> R2[Virus Detection]
    Receive --> R3[Mail Filtering]
    
    Receive --> Rules[Receipt Rules]
    Rules --> A1[S3 Action]
    Rules --> A2[SNS Action]
    Rules --> A3[Lambda Action]
    Rules --> A4[Bounce Action]
    
    style SES fill:#FF9900

SES Capabilities:

• Sending: Cost-effective email delivery for marketing, transactional, and notification emails
• High deliverability rates with built-in reputation management
• Receiving: Incoming email processing with spam and virus scanning
• Automatically rejects mail from untrusted sources
• Receipt Rules: Define conditions and actions for incoming emails
• Actions include storing in S3, publishing to SNS, invoking Lambda, bouncing
• Lambda integration enables custom email processing (extract attachments, parse content)
• Scalable solution replacing traditional mail servers

Q7: SES Email Processing Flow

sequenceDiagram
    participant Sender as External Sender
    participant SES as Amazon SES
    participant Lambda
    participant S3
    participant SNS
    
    Sender->>SES: Send Email with xlsx
    
    SES->>SES: Scan Spam Viruses
    SES->>SES: Check Trusted Source
    
    SES->>Lambda: Invoke Lambda
    Lambda->>Lambda: Extract xlsx
    Lambda->>Lambda: Convert to csv
    Lambda->>S3: Store csv
    
    SES->>SNS: Publish to SNS
    SNS->>SNS: Notify Subscribers
    
    SES->>S3: Store Original Email

Processing Workflow:

• SES receives incoming email and performs security checks
• Scans for spam and viruses before processing
• Evaluates receipt rules based on sender, recipient, or content
• Executes actions in defined order (Lambda, SNS, S3)
• Lambda can transform email content or attachments
• Original email stored in S3 for archival and compliance
• SNS notifies relevant parties of email receipt
• Entire workflow automated without manual intervention

Q8: AWS Services Integration

graph TB
    subgraph Monitoring[Monitoring]
        CW[CloudWatch]
        CT[CloudTrail]
    end
    
    subgraph Storage[Storage]
        EBS[EBS]
        EFS[EFS]
        S3[S3]
    end
    
    subgraph Messaging[Messaging]
        SNS[SNS]
        SQS[SQS]
        SES[SES]
    end
    
    subgraph Compute[Compute]
        EC2[EC2]
        Lambda[Lambda]
    end
    
    EC2 --> EBS
    EC2 --> EFS
    EC2 --> CW
    
    Lambda --> CW
    Lambda --> S3
    
    S3 --> SNS
    SNS --> SQS
    SNS --> Lambda
    
    CT --> S3
    
    style Monitoring fill:#E3F2FD
    style Storage fill:#FFF3E0
    style Messaging fill:#F3E5F5
    style Compute fill:#E8F5E9

Integration Patterns:

• Compute to Storage: EC2 uses EBS for disk, EFS for shared files, S3 for objects
• Monitoring: CloudWatch monitors all services, CloudTrail logs all API calls to S3
• Event-Driven: S3 events trigger SNS, which fans out to SQS, Lambda, and SES
• Serverless: Lambda processes events from SNS/SQS, reads/writes to S3
• Decoupling: SNS/SQS decouple services for better scalability and reliability
• Services designed to work together seamlessly
• Common patterns: event-driven architectures, microservices, data pipelines
• Understanding integration enables building robust, scalable AWS solutions