Essential AWS Cloud Skills: Simplified Notes and Key Insights

1. AWS Global Infrastructure

• Regions

  • Physical location around the world.

  • Each region has multiple Availability Zones (AZs).

  • Regions differ in pricing, compliance, features, data residency regulations.

• Availability Zones (AZs)

  • Each AZ = one or more data centers with redundant power, cooling, networking.

  • At least 2 AZs per region (some have 3–6).

  • Used for redundancy, failover, high availability.

• Data Centers

  • Physical building with servers, storage, networking.

  • AWS abstracts them under AZs.

• Edge Locations

  • For Amazon CloudFront (CDN) and caching.

  • Close to end-users for low latency.

• Redundancy

  • Multi-AZ deployment for databases, EC2, etc.

  • Multi-Region for disaster recovery.

2. Ways to Interact with AWS

• AWS Management Console → Web GUI for humans.

• AWS CLI (Command Line Interface) → Scriptable, automation via terminal.

• AWS SDKs → APIs for developers (Python boto3, Java, Go, etc.).

• Infrastructure as Code (IaC) → CloudFormation, CDK, Terraform.

3. Security

• Shared Responsibility Model

  • AWS → Security of the cloud (hardware, networking, data centers).

  • User → Security in the cloud (IAM, data encryption, OS patches).

    

• Root User

  • Created when the AWS account is made.

  • Full access → should NOT be used for daily tasks.

  • Use IAM Users/Roles instead.

• Access Keys (Access Key ID + Secret Key)

  • Used for CLI & API calls.

  • Never hardcode; rotate regularly.

4. Identity and Access Management (IAM)

• Global Service (not region-specific).

• Users → People/apps that need access.

• Groups → Organize users & apply policies in bulk.

• Policies → JSON documents defining permissions.

• Roles → Temporary credentials, used by EC2, Lambda, or cross-account access.

• Federation → Use existing identity provider (Google, Microsoft AD, etc.).

Best Practices:

• Follow least privilege principle.

• Use MFA for root user & IAM users.

• Use IAM Roles for applications instead of long-term keys.

5. Compute Services

5.1 EC2 (Elastic Compute Cloud)

• AMI (Amazon Machine Image) = preconfigured OS + software template.

• Instance Types

  • General purpose → T3, M5.

  • Compute optimized → C6g.

  • Memory optimized → R6g.

  • Storage optimized → I3, D2.

  • Accelerated → P4 (GPU).

• EC2 Lifecycle

  • Pending → Running → Stopping → Stopped → Shutting down → Terminated.

  • Hibernate = RAM stored to disk.

    

• Pricing Models

  • On-Demand → Pay as you go.

  • Reserved → 1–3 year commitment, cheaper.

  • Spot → Bidding unused capacity, 90% cheaper, but can be interrupted.

  • Savings Plan → Flexible reserved pricing.

5.2 Containers

• ECS (Elastic Container Service) → AWS-native container orchestrator.

• EKS (Elastic Kubernetes Service) → Managed Kubernetes.

• Fargate → Serverless compute engine for ECS/EKS. No servers to manage.

5.3 Lambda

• Serverless functions.

• Triggered by events (S3 upload, DynamoDB stream, API Gateway).

• Pay per execution + duration.

6. Networking

• VPC (Virtual Private Cloud) → Isolated network in AWS.

• Subnets

  • Public Subnet → Internet-facing.

  • Private Subnet → Internal services (DBs, apps).

• Route Tables → Direct traffic between subnets, IGW, VPN.

• Internet Gateway (IGW) → Enables internet access for VPC.

• NAT Gateway → Private subnet instances access internet (outbound only).

• Security Groups (SGs) → Stateful firewall (default deny inbound, allow outbound).

• Network ACLs (NACLs) → Stateless firewall (applied at subnet level).

• VPN

  • Site-to-Site VPN → Connect on-premises to AWS VPC.

  • Client VPN → Users connect securely to AWS network.

  • Direct Connect → Dedicated fiber line to AWS (low latency).

• CIDR (Classless Inter-Domain Routing)

  • Defines IP ranges.

  • AWS VPC → Min /28 (16 IPs), Max /16 (65,536 IPs).

  • 5 IPs always reserved per subnet.

7. Storage

7.1 Block Storage

• EBS (Elastic Block Store) → Persistent storage for EC2.

  • SSD (gp3, io2) → Random I/O.

  • HDD (st1, sc1) → Sequential I/O.

• Instance Store → Ephemeral, tied to EC2 lifecycle.

7.2 File Storage

• EFS (Elastic File System) → NFS-based, scalable, shared across instances.

7.3 Object Storage

• S3 → Flat namespace with buckets and objects.

  • Versioning → Protect from accidental overwrite.

  • Encryption → SSE-S3, SSE-KMS, SSE-C, Client-side.

  • Storage Classes:

    1. Standard

    2. Intelligent-Tiering

    3. Standard-IA

    4. One Zone-IA

    5. Glacier Instant

    6. Glacier Flexible

    7. Glacier Deep Archive

    8. S3 Outposts

8. Databases

• RDS (Relational Database Service) → Managed MySQL, PostgreSQL, Oracle, SQL Server, Aurora.

• DynamoDB → NoSQL, key-value, serverless.

• DocumentDB → MongoDB-compatible.

• Neptune → Graph database.

• QLDB → Immutable ledger.

• Redshift → Data warehouse.

9. Monitoring & Optimization

Metrics

• AWS namespaces per service (e.g., AWS/EC2, AWS/ApplicationELB).

• Dimensions identify a metric’s source (InstanceId, TargetGroup, LoadBalancer).

• Custom metrics: PutMetricData to publish app/business KPIs.

Common signals:

• EC2: CPUUtilization, NetworkIn/Out, StatusCheckFailed.

• ALB: HTTPCode_Target_5XX_Count, TargetResponseTime, RequestCount, UnHealthyHostCount.

• ASG: GroupInServiceInstances, GroupDesiredCapacity.

Alarms

• States: OK, ALARM, INSUFFICIENT_DATA.

• Actions: Notify via SNS, trigger Auto Scaling policies, invoke Lambda for remediation.

Logs & Tracing

• CloudWatch Logs: Application/system logs grouped by Log Group, split into Log Streams (per instance/worker).

• Logs Insights: SQL-like queries across logs.

• Dashboards: Pin charts/alarms for NOC view.

• X-Ray (optional): Distributed tracing for microservices.

• CloudTrail (complementary): API audit logs for governance & forensics.

10. Load Balancing on AWS

Internet-facing vs Internal load balancers

• Internet-facing: Has public endpoints; used to expose web/mobile APIs.

• Internal: Accessible only inside the VPC (e.g., service-to-service or private admin apps).

Application Load Balancer (ALB) — Layer 7

Best for HTTP/HTTPS and microservices.

• Smart routing: Path-based (/api, /upload), host-based (api.example.com), header/method-based.

• TLS offload: Terminate HTTPS at ALB with ACM/IAM certificates.

• Auth: OIDC/SAML/LDAP integrations at the edge before traffic hits your app.

• Algorithms:

  • Round-robin: even request spread.

  • Least outstanding requests: better when requests vary in cost or targets differ in capacity.

• Sticky sessions: Cookie-based affinity for stateful apps.

• Responses: Fixed responses and redirects (e.g., HTTP → HTTPS).

• Health checks: Per target group; unhealthy targets are drained and removed.

• Deregistration delay (“connection draining”): Waits for in-flight requests to finish before removing targets.

Use when: REST/GraphQL APIs, web apps, microservices fan-out, header/path routing, WAF integration.

Network Load Balancer (NLB) — Layer 4

Best for raw TCP/UDP/TLS and extreme performance.

• Protocols: TCP/UDP/TLS; does not parse HTTP.

• Flow-hash routing: Based on src/dst IP/port, protocol, TCP sequence number.

• Sticky sessions: Source-IP-based.

• TLS offload: Yes (no HTTP-aware features like path routing).

• Performance: Instantly handles millions of RPS.

• Static/Elastic IPs: Helpful when clients can’t use DNS or need IP-based firewalling.

• Preserves client IP to targets by default.

Use when: IoT, gaming, messaging, databases over TCP, SIP/VoIP, custom protocols, ultra-high throughput.

Quick chooser: HTTP/HTTPS features? → ALB. Non-HTTP or IP-based needs at huge scale? → NLB.

Core ELB components

• Listener: Front door (e.g., :80, :443).

• Rules (ALB): Conditions → actions (forward/redirect/fixed response).

• Target Groups: Where requests are sent (EC2, IPs, Lambda for ALB; EC2/IPs/ALB targets for NLB).

• Health Checks: Protocol/port/path, thresholds, intervals.

• Security: SGs (ALB), NACLs (subnets), WAF (optional), TLS policies/ciphers.

  

11. Auto Scaling: Elasticity for Compute

Building blocks

• Launch Template: Golden settings for instances (AMI, type, SGs, subnets, user data, IAM role).

• Auto Scaling Group (ASG): Desired/min/max capacity; spans multiple AZs.

• Scaling Policies:

  • Simple: Add/remove fixed number on a threshold.

  • Step: Scale by steps as metric moves further from threshold.

  • Target Tracking: Maintain a target (e.g., 50% CPU, ALB request count per target). Easiest and most common.

• Cooldowns & Warm Pools: Avoid thrashing; pre-warm instances for faster scale-out.

• Health checks: EC2 + ELB; replace unhealthy instances automatically.

• Lifecycle hooks: Run scripts on Launching/Terminating for graceful boot/tear-down.

• Termination policies: Control which instances to remove first (AZ balance, oldest/newest, etc.).

• Instance protection: Prevent critical instances from being scaled in.

Pattern: ALB health checks → ASG replaces bad nodes. Target tracking keeps latency steady as traffic shifts.

12. Optimization Strategies

• Prefer Horizontal Scaling (many small servers) over Vertical.

• Active-Passive (failover) vs Active-Active (load balanced).

• Use DNS (Route 53) for global failover.

• Spot + On-demand mix for cost optimization.

13. AI & ML

• Amazon Bedrock → Serverless foundation models via API (Anthropic, Meta, Amazon Titan).

• Amazon Q → Enterprise AI assistant (chatbot), integrates with Bedrock & AWS data (QuickSight, Redshift, S3).

  

---

Some architecture diagrams

Step-by-Step Example Deployment

1. Create EC2 Instance (with AMI, instance type, network, storage).

2. Create Security Group (allow HTTP/HTTPS/SSH).

3. Create Load Balancer (ALB with listener & target group).

4. Attach EC2 to Target Group.

5. Create Launch Template (define EC2 config).

6. Create Auto Scaling Group (attach to ALB).

7. Define Scaling Policy (scale-out/in with CloudWatch alarms).

8. Enable Monitoring with CloudWatch logs & metrics.

Thanks to AWS Cloud Technical Essentials