<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AWS Certified Developer Associate (DVA-C02) on 🏠</title><link>https://tofl.github.io/</link><description>Recent content in AWS Certified Developer Associate (DVA-C02) on 🏠</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://tofl.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>1. IAM (Identity &amp; Access Management)</title><link>https://tofl.github.io/docs/1-cloud-iam-encryption-foundations/iam-identity-access-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/1-cloud-iam-encryption-foundations/iam-identity-access-management/</guid><description>&lt;h2 id="iam-identity--access-management"&gt;IAM (Identity &amp;amp; Access Management)&lt;a class="anchor" href="#iam-identity--access-management"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;AWS Identity and Access Management (IAM) is the service that controls &lt;strong&gt;who&lt;/strong&gt; can do &lt;strong&gt;what&lt;/strong&gt; in your AWS account. Every API call made to AWS — whether from the console, CLI, or SDK — is authenticated and authorized through IAM. Without it, there would be no way to distinguish between a developer who should read S3 buckets and an automated process that should write to DynamoDB. IAM is free and global (not region-scoped), and understanding it deeply is a prerequisite for everything else in AWS. &lt;a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>11. Error Handling &amp; Retry Patterns</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/error-handling-retry-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/error-handling-retry-patterns/</guid><description>&lt;h2 id="error-handling--retry-patterns--cross-cutting-theme"&gt;Error Handling &amp;amp; Retry Patterns — Cross-Cutting Theme&lt;a class="anchor" href="#error-handling--retry-patterns--cross-cutting-theme"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Before diving into individual services, it&amp;rsquo;s worth internalizing a set of patterns that appear repeatedly across SQS, SNS, Lambda, API Gateway, DynamoDB, Kinesis, Step Functions, and EventBridge. The exam tests these concepts in context — meaning you&amp;rsquo;ll see them embedded in scenario questions about specific services — so understanding them as a unified mental model first will save you significant effort later.&lt;/p&gt;</description></item><item><title>17. API Gateway</title><link>https://tofl.github.io/docs/6-api-layer-authentication-api-gateway-cognito/api-gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/6-api-layer-authentication-api-gateway-cognito/api-gateway/</guid><description>&lt;h2 id="api-gateway"&gt;API Gateway&lt;a class="anchor" href="#api-gateway"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon API Gateway &lt;a href="https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html"&gt;🔗&lt;/a&gt; is a fully managed service for creating, publishing, and securing APIs at any scale. The core problem it solves: your backend logic (a Lambda function, an EC2 service, or any HTTP endpoint) isn&amp;rsquo;t directly accessible to clients in a controlled, secure, or scalable way. API Gateway sits in front of those backends and handles routing, authentication, throttling, and protocol management — so you don&amp;rsquo;t have to build any of that yourself.&lt;/p&gt;</description></item><item><title>19. CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline)</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cicd-codecommit-codebuild-codedeploy-codepipeline/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cicd-codecommit-codebuild-codedeploy-codepipeline/</guid><description>&lt;h2 id="cicd-codecommit-codebuild-codedeploy-codepipeline"&gt;CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline)&lt;a class="anchor" href="#cicd-codecommit-codebuild-codedeploy-codepipeline"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Manual deployments are slow, inconsistent, and error-prone. When every release requires a developer to SSH into a server, run scripts by hand, or remember the exact sequence of steps, mistakes happen — and scaling that process across teams and environments becomes untenable. AWS provides a suite of managed services — &lt;strong&gt;CodeCommit&lt;/strong&gt;, &lt;strong&gt;CodeBuild&lt;/strong&gt;, &lt;strong&gt;CodeDeploy&lt;/strong&gt;, and &lt;strong&gt;CodePipeline&lt;/strong&gt; — that together let you automate the entire path from a code commit to a production deployment. This is the foundation of a modern CI/CD (Continuous Integration / Continuous Delivery) pipeline on AWS.&lt;/p&gt;</description></item><item><title>25. CloudWatch</title><link>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/cloudwatch/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/cloudwatch/</guid><description>&lt;h1 id="cloudwatch"&gt;CloudWatch&lt;a class="anchor" href="#cloudwatch"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;CloudWatch is AWS&amp;rsquo;s primary observability service — a unified platform for collecting metrics, logs, and events from virtually every AWS service and your own applications. Before CloudWatch, understanding what was actually happening inside your infrastructure meant stitching together custom scripts, third-party agents, and ad-hoc logging setups. CloudWatch solves this by providing a single place to monitor resource health, detect anomalies, trigger automated responses, and query logs — all without managing any underlying infrastructure.&lt;/p&gt;</description></item><item><title>28. KMS</title><link>https://tofl.github.io/docs/9-security-encryption-deep-dive/kms-deep-dive/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/9-security-encryption-deep-dive/kms-deep-dive/</guid><description>&lt;h1 id="kms-key-management-service--deep-dive"&gt;KMS (Key Management Service) — Deep Dive&lt;a class="anchor" href="#kms-key-management-service--deep-dive"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;AWS Key Management Service (KMS) is a managed service that lets you create, control, and use cryptographic keys to protect your data. Its core purpose is simple: rather than managing raw encryption keys yourself — which is error-prone and operationally burdensome — KMS centralises key management, enforces access control via IAM and key policies, and maintains an audit trail through CloudTrail. Every call to KMS is logged, which makes it the default choice for encryption across nearly every AWS service.&lt;/p&gt;</description></item><item><title>3. VPC Fundamentals</title><link>https://tofl.github.io/docs/2-networking-essentials/vpc-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/2-networking-essentials/vpc-fundamentals/</guid><description>&lt;h2 id="vpc-fundamentals"&gt;VPC Fundamentals&lt;a class="anchor" href="#vpc-fundamentals"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Virtual Private Cloud (VPC) lets you launch AWS resources inside a logically isolated virtual network that you define. Think of it as your own private data center within AWS — you control the IP address ranges, subnets, routing, and access rules. The core problem it solves is &lt;strong&gt;network isolation&lt;/strong&gt;: without a VPC, your resources would be exposed on a flat shared network. With a VPC, you decide what&amp;rsquo;s reachable from the internet, what&amp;rsquo;s reachable only internally, and what can talk to what.&lt;/p&gt;</description></item><item><title>32. ECS</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecs/</guid><description>&lt;h2 id="ecs-elastic-container-service"&gt;ECS (Elastic Container Service)&lt;a class="anchor" href="#ecs-elastic-container-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications are increasingly built as collections of small, independent services packaged in containers. Containers are lightweight, portable, and consistent across environments — but running them reliably at scale introduces real operational complexity: Where do containers run? How do you restart failed ones? How do you distribute traffic? ECS is AWS&amp;rsquo;s answer to these questions. It is a fully managed &lt;strong&gt;container orchestration service&lt;/strong&gt; that handles scheduling, placement, scaling, and lifecycle management of Docker containers on your behalf — without requiring you to operate Kubernetes.&lt;/p&gt;</description></item><item><title>35. RDS</title><link>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/rds/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/rds/</guid><description>&lt;h2 id="rds"&gt;RDS&lt;a class="anchor" href="#rds"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Relational Database Service (RDS) is a managed service that runs relational databases in the cloud. The problem it solves is operational: running a production-grade relational database requires provisioning hardware, installing software, configuring backups, applying patches, and managing failover — none of which is differentiated work for most applications. RDS handles all of that, so you interact with a standard SQL database engine while AWS takes care of the infrastructure underneath. &lt;a href="https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>38. AWS CLI, SDK &amp; API Limits</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/cli-sdk-api-limits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/cli-sdk-api-limits/</guid><description>&lt;h2 id="aws-cli-sdk--api-limits"&gt;AWS CLI, SDK &amp;amp; API Limits&lt;a class="anchor" href="#aws-cli-sdk--api-limits"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When you move beyond the AWS Console, you interact with AWS programmatically — through the CLI for scripts and automation, through SDKs for application code, and directly via HTTP APIs when you need full control. Understanding how these tools work, how credentials are resolved, and how to handle the rate limits AWS enforces on every API call is essential for building reliable, production-grade applications.&lt;/p&gt;</description></item><item><title>5. EC2</title><link>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/ec2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/ec2/</guid><description>&lt;h2 id="ec2-elastic-compute-cloud"&gt;EC2 (Elastic Compute Cloud)&lt;a class="anchor" href="#ec2-elastic-compute-cloud"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon EC2 (Elastic Compute Cloud) &lt;a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html"&gt;🔗&lt;/a&gt; is AWS&amp;rsquo;s service for renting virtual servers in the cloud. Before managed compute services like Lambda existed, every application needed a server — EC2 is that server, virtualized and billed by the second. Understanding EC2 gives you the mental model for what higher-level services like Lambda are actually abstracting away: OS management, patching, capacity planning, and runtime configuration.&lt;/p&gt;
&lt;p&gt;For the DVA-C02 exam, EC2 is foundational context rather than the primary focus. That said, several EC2 concepts — security groups, IAM roles on instances, and purchasing options — appear regularly in scenario questions.&lt;/p&gt;</description></item><item><title>9. S3</title><link>https://tofl.github.io/docs/4-core-storage-s3-dynamodb/s3/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/4-core-storage-s3-dynamodb/s3/</guid><description>&lt;h2 id="s3-simple-storage-service"&gt;S3 (Simple Storage Service)&lt;a class="anchor" href="#s3-simple-storage-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon S3 is an object storage service that lets you store and retrieve any amount of data from anywhere on the internet. Unlike a file system (which organises data in a folder hierarchy) or a block storage volume (which behaves like a hard disk), S3 stores data as discrete &lt;strong&gt;objects&lt;/strong&gt; — each one a self-contained bundle of data, metadata, and a unique key. S3 exists because applications need a place to persist files that is durable, infinitely scalable, and decoupled from any single server. It underpins a huge slice of AWS architectures: application assets, data lakes, backups, static sites, event pipelines, and more. &lt;a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>10. DynamoDB</title><link>https://tofl.github.io/docs/4-core-storage-s3-dynamodb/dynamodb/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/4-core-storage-s3-dynamodb/dynamodb/</guid><description>&lt;h2 id="dynamodb"&gt;DynamoDB&lt;a class="anchor" href="#dynamodb"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon DynamoDB is a fully managed, serverless NoSQL database built for applications that need consistent, single-digit millisecond performance at any scale. Unlike relational databases, you don&amp;rsquo;t provision or manage servers — AWS handles availability, replication, and scaling automatically. DynamoDB is the go-to database for serverless architectures on AWS, and it&amp;rsquo;s one of the most heavily tested services on the DVA-C02 exam.&lt;/p&gt;
&lt;p&gt;The core problem it solves: traditional relational databases struggle to scale horizontally and often become bottlenecks under unpredictable or high traffic. DynamoDB sidesteps this by distributing data across partitions and offering near-instant reads and writes regardless of load.&lt;/p&gt;</description></item><item><title>12. SQS</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/sqs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/sqs/</guid><description>&lt;h2 id="sqs-simple-queue-service"&gt;SQS (Simple Queue Service)&lt;a class="anchor" href="#sqs-simple-queue-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Simple Queue Service (SQS) is a fully managed message queuing service that lets you decouple the components of a distributed application. The core problem it solves is &lt;strong&gt;temporal coupling&lt;/strong&gt;: without a queue, if a downstream service (consumer) is slow, overloaded, or temporarily unavailable, the upstream service (producer) either fails or has to wait. SQS breaks that dependency — producers drop messages into the queue and move on, consumers process at their own pace. &lt;a href="https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>18. Cognito</title><link>https://tofl.github.io/docs/6-api-layer-authentication-api-gateway-cognito/cognito/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/6-api-layer-authentication-api-gateway-cognito/cognito/</guid><description>&lt;h2 id="cognito"&gt;Cognito&lt;a class="anchor" href="#cognito"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Managing user authentication from scratch is a significant engineering effort: you need to handle password hashing, account recovery, MFA, token issuance, session management, and more. Amazon Cognito &lt;a href="https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html"&gt;🔗&lt;/a&gt; solves this by providing a fully managed identity service that handles user sign-up, sign-in, and access control so you can focus on your application logic instead of reinventing auth infrastructure.&lt;/p&gt;
&lt;p&gt;Cognito has two distinct building blocks that are often used together but serve fundamentally different purposes: &lt;strong&gt;User Pools&lt;/strong&gt; and &lt;strong&gt;Identity Pools&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>2. KMS (Key Management Service) — Foundations</title><link>https://tofl.github.io/docs/1-cloud-iam-encryption-foundations/kms-foundations/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/1-cloud-iam-encryption-foundations/kms-foundations/</guid><description>&lt;h2 id="kms-key-management-service--foundations"&gt;KMS (Key Management Service) — Foundations&lt;a class="anchor" href="#kms-key-management-service--foundations"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;AWS Key Management Service (KMS) is a managed service that lets you create and control the cryptographic keys used to protect your data. The core problem it solves is straightforward: encrypting data is necessary, but managing encryption keys securely is hard. KMS offloads that complexity — key storage, access control, rotation, and audit logging — to AWS, so you never handle raw key material directly in your application code.&lt;/p&gt;</description></item><item><title>20. SAM (Serverless Application Model)</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/sam/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/sam/</guid><description>&lt;h2 id="sam-serverless-application-model"&gt;SAM (Serverless Application Model)&lt;a class="anchor" href="#sam-serverless-application-model"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Building serverless applications by hand means writing long, verbose CloudFormation templates just to define a Lambda function with an API Gateway trigger and a DynamoDB table. AWS SAM (Serverless Application Model) solves this by providing a shorthand syntax on top of CloudFormation, specifically designed for serverless resources. A few lines of SAM YAML expand into the dozens of CloudFormation lines you&amp;rsquo;d otherwise have to maintain. Beyond templating, SAM also ships a CLI that lets you build, test locally, and deploy serverless applications — making the entire development loop faster and safer.&lt;/p&gt;</description></item><item><title>26. X-Ray</title><link>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/x-ray/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/x-ray/</guid><description>&lt;h2 id="x-ray"&gt;X-Ray&lt;a class="anchor" href="#x-ray"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications rarely live in a single process. A user request might pass through an API Gateway, trigger a Lambda function, query DynamoDB, call an external HTTP service, and publish to an SQS queue — all before a response is returned. When something goes wrong (or is simply slow), finding &lt;em&gt;where&lt;/em&gt; in that chain the problem originated is genuinely hard with logs alone. AWS X-Ray solves this by tracing requests end-to-end across your distributed system, giving you a visual map of every service involved and exactly how long each hop took. For the DVA-C02 exam, X-Ray is the go-to answer whenever a question involves diagnosing latency, pinpointing errors in a microservice architecture, or understanding request flow.&lt;/p&gt;</description></item><item><title>29. Secrets Manager &amp; SSM Parameter Store</title><link>https://tofl.github.io/docs/9-security-encryption-deep-dive/secrets-manager-ssm-parameter-store/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/9-security-encryption-deep-dive/secrets-manager-ssm-parameter-store/</guid><description>&lt;h2 id="secrets-manager--ssm-parameter-store"&gt;Secrets Manager &amp;amp; SSM Parameter Store&lt;a class="anchor" href="#secrets-manager--ssm-parameter-store"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Applications constantly need access to sensitive configuration: database passwords, API keys, OAuth tokens, and feature flags. Hardcoding these into source code or environment variables is a well-known security risk. AWS provides two services to solve this: &lt;strong&gt;Secrets Manager&lt;/strong&gt; for sensitive credentials that need lifecycle management (rotation, auditing, cross-account sharing), and &lt;strong&gt;SSM Parameter Store&lt;/strong&gt; for general-purpose configuration storage, including secrets. Knowing which to reach for — and when — is a frequently tested decision on the DVA-C02 exam.&lt;/p&gt;</description></item><item><title>33. ECR</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecr/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecr/</guid><description>&lt;h2 id="ecr-elastic-container-registry"&gt;ECR (Elastic Container Registry)&lt;a class="anchor" href="#ecr-elastic-container-registry"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When you containerize applications, you need somewhere reliable to store, version, and distribute your Docker images. ECR is AWS&amp;rsquo;s fully managed container registry that solves exactly this: it gives you a private, secure, and highly available place to push images from your CI/CD pipeline and pull them into ECS, Fargate, or EKS at deploy time. Because ECR lives inside AWS, image pulls stay on the AWS network — no egress costs, lower latency, and no dependency on Docker Hub availability. &lt;a href="https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>36. Aurora</title><link>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/aurora/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/aurora/</guid><description>&lt;h2 id="aurora"&gt;Aurora&lt;a class="anchor" href="#aurora"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Aurora is a cloud-native relational database engine built by AWS from the ground up to overcome the performance and availability limitations of traditional relational databases. It is fully compatible with MySQL and PostgreSQL, meaning your existing drivers, tools, and queries work without modification. Aurora solves a core problem: standard relational databases weren&amp;rsquo;t designed with distributed cloud infrastructure in mind, so AWS re-architected the storage and replication layers entirely. The result is a managed database that delivers up to 5× the throughput of MySQL and 3× that of PostgreSQL, while offering durability and availability that would be complex and costly to achieve on your own. &lt;a href="https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>39. CloudFront</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/cloudfront/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/cloudfront/</guid><description>&lt;h2 id="cloudfront"&gt;CloudFront&lt;a class="anchor" href="#cloudfront"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;CloudFront is AWS&amp;rsquo;s Content Delivery Network (CDN). The core problem it solves is simple: if your application&amp;rsquo;s origin server sits in &lt;code&gt;us-east-1&lt;/code&gt; and a user requests a large image from Tokyo, that request travels halfway around the world and back. CloudFront fixes this by caching your content at &lt;strong&gt;edge locations&lt;/strong&gt; close to your users, so subsequent requests are served locally — slashing latency and reducing the number of requests that ever reach your origin.&lt;/p&gt;</description></item><item><title>4. Route 53</title><link>https://tofl.github.io/docs/2-networking-essentials/route-53/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/2-networking-essentials/route-53/</guid><description>&lt;h2 id="route-53"&gt;Route 53&lt;a class="anchor" href="#route-53"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Route 53 is AWS&amp;rsquo;s managed DNS (Domain Name System) service. DNS is the internet&amp;rsquo;s phone book — it translates human-readable domain names like &lt;code&gt;api.myapp.com&lt;/code&gt; into IP addresses that computers use to route traffic. Route 53 goes beyond basic DNS by adding health checking, traffic routing logic, and deep integration with AWS services. For developers, understanding Route 53 at an awareness level is enough to wire up custom domains, configure failover, and reason about how traffic reaches your application.&lt;/p&gt;</description></item><item><title>6. Lambda</title><link>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/lambda/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/lambda/</guid><description>&lt;h2 id="aws-lambda"&gt;AWS Lambda&lt;a class="anchor" href="#aws-lambda"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications often need to run small, discrete pieces of logic in response to events — a user uploads a file, a message arrives in a queue, an HTTP request hits an API. Traditionally, this meant provisioning and maintaining servers to host that logic, even when it was idle. AWS Lambda eliminates that overhead entirely: you upload your code, define what triggers it, and AWS handles everything else — infrastructure, scaling, patching, and availability. You pay only for the compute time your code actually consumes, billed in 1ms increments. This model is called &lt;strong&gt;serverless compute&lt;/strong&gt;, and Lambda is its cornerstone on AWS. &lt;a href="https://docs.aws.amazon.com/lambda/latest/dg/welcome.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>13. SNS</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/sns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/sns/</guid><description>&lt;h2 id="sns-simple-notification-service"&gt;SNS (Simple Notification Service)&lt;a class="anchor" href="#sns-simple-notification-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Simple Notification Service (SNS) &lt;a href="https://docs.aws.amazon.com/sns/latest/dg/welcome.html"&gt;🔗&lt;/a&gt; is a fully managed pub/sub messaging service. Where SQS decouples a single producer from a single consumer, SNS solves a different problem: &lt;strong&gt;broadcasting one message to many recipients simultaneously&lt;/strong&gt;. A single &lt;code&gt;Publish&lt;/code&gt; call to an SNS topic can trigger an email notification, invoke a Lambda function, and drop a copy of the message into an SQS queue — all at once. This makes SNS the natural choice for fan-out architectures and alert pipelines.&lt;/p&gt;</description></item><item><title>21. CloudFormation</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cloudformation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cloudformation/</guid><description>&lt;h2 id="cloudformation"&gt;CloudFormation&lt;a class="anchor" href="#cloudformation"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;AWS CloudFormation lets you define your entire AWS infrastructure as code — VPCs, databases, Lambda functions, IAM roles, and more — in a single declarative template. Instead of clicking through the console or running ad-hoc CLI commands, you describe &lt;em&gt;what&lt;/em&gt; you want, and CloudFormation figures out &lt;em&gt;how&lt;/em&gt; to create it, in the right order, handling dependencies automatically.&lt;/p&gt;
&lt;p&gt;The core problem it solves is repeatability. Without IaC, recreating a production environment in a new region, or letting a teammate spin up an identical dev stack, is error-prone and slow. With CloudFormation, you version-control your infrastructure alongside your application code and deploy it consistently every time.&lt;/p&gt;</description></item><item><title>27. CloudTrail</title><link>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/cloudtrail/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/8-observability-troubleshooting-cloudwatch-xray-cloudtrail/cloudtrail/</guid><description>&lt;h2 id="cloudtrail"&gt;CloudTrail&lt;a class="anchor" href="#cloudtrail"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Every action taken in your AWS account — whether from the console, CLI, SDK, or another AWS service — is an API call. CloudTrail records all of these calls, giving you a complete, auditable history of &lt;em&gt;who did what, when, and from where&lt;/em&gt;. This makes it the foundational tool for security auditing, compliance, and forensic investigation. Without CloudTrail, answering questions like &amp;ldquo;who deleted that S3 bucket?&amp;rdquo; or &amp;ldquo;which IAM role created this resource at 2am?&amp;rdquo; would be nearly impossible.&lt;/p&gt;</description></item><item><title>30. ACM / ACM Private CA</title><link>https://tofl.github.io/docs/9-security-encryption-deep-dive/acm-private-ca/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/9-security-encryption-deep-dive/acm-private-ca/</guid><description>&lt;h2 id="acm--acm-private-ca"&gt;ACM / ACM Private CA&lt;a class="anchor" href="#acm--acm-private-ca"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;TLS certificates are what enable HTTPS — they authenticate your server&amp;rsquo;s identity and encrypt traffic between clients and your application. Without them, browsers display security warnings and connections are unencrypted. The problem they solve sounds simple, but managing certificates manually is error-prone: you have to generate them, validate domain ownership, deploy them to the right services, and renew them before they expire (typically every 13 months). A missed renewal causes an outage. &lt;strong&gt;AWS Certificate Manager (ACM)&lt;/strong&gt; &lt;a href="https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html"&gt;🔗&lt;/a&gt; automates all of this — provisioning, validation, deployment, and renewal — at no cost for certificates used with supported AWS services.&lt;/p&gt;</description></item><item><title>34. Fargate</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/fargate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/fargate/</guid><description>&lt;h1 id="fargate"&gt;Fargate&lt;a class="anchor" href="#fargate"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;AWS Fargate is a serverless compute engine for containers that works with both ECS and EKS. It eliminates the need to provision, configure, or manage EC2 instances for running containers — you define what your container needs (CPU, memory, networking), and AWS handles everything underneath. Fargate exists to solve a very specific operational burden: cluster capacity management. With EC2 launch type, you&amp;rsquo;re responsible for the EC2 instances that form your cluster — choosing instance types, managing scaling of the underlying fleet, patching the OS, and ensuring there&amp;rsquo;s always enough capacity. Fargate removes that entirely. You pay per task, per second, for exactly the resources your container consumes. &lt;a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>37. ElastiCache</title><link>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/elasticache/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/11-additional-databases-caching-rds-aurora-elasticache/elasticache/</guid><description>&lt;h2 id="elasticache"&gt;ElastiCache&lt;a class="anchor" href="#elasticache"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications routinely hit the same database rows thousands of times per second — user profiles, product catalogues, leaderboards, session tokens. Every one of those hits costs latency and money. Amazon ElastiCache &lt;a href="https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html"&gt;🔗&lt;/a&gt; solves this by sitting an &lt;strong&gt;in-memory data store&lt;/strong&gt; in front of your database. Reads that would take milliseconds against RDS or DynamoDB take &lt;strong&gt;microseconds&lt;/strong&gt; from ElastiCache, and your database is freed from repetitive work it never needed to do.&lt;/p&gt;</description></item><item><title>40. AppSync</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/appsync/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/appsync/</guid><description>&lt;h2 id="appsync"&gt;AppSync&lt;a class="anchor" href="#appsync"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications often need to fetch data from multiple sources, support real-time updates, and work offline on mobile devices. Building all of this with REST APIs means writing a lot of custom glue code — separate endpoints, multiple round trips, and hand-rolled WebSocket logic. AWS AppSync &lt;a href="https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html"&gt;🔗&lt;/a&gt; solves this by providing a managed GraphQL API layer that connects directly to your data sources, handles real-time subscriptions over WebSocket, and supports offline data sync out of the box.&lt;/p&gt;</description></item><item><title>7. ASG</title><link>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/asg/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/asg/</guid><description>&lt;h2 id="auto-scaling-groups-asg"&gt;Auto Scaling Groups (ASG)&lt;a class="anchor" href="#auto-scaling-groups-asg"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;An Auto Scaling Group is an EC2 fleet management service that automatically adjusts the number of running instances based on demand, health, or a schedule. The core problem it solves is twofold: you don&amp;rsquo;t want to over-provision (wasting money on idle capacity), and you don&amp;rsquo;t want to under-provision (degrading user experience under load). ASG handles both by adding instances when demand rises and terminating them when it drops — all without manual intervention. &lt;a href="https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>14. EventBridge</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/eventbridge/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/eventbridge/</guid><description>&lt;h2 id="eventbridge"&gt;EventBridge&lt;a class="anchor" href="#eventbridge"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon EventBridge is a serverless event bus that connects AWS services, your own applications, and third-party SaaS platforms by routing events from producers to consumers based on rules you define. It exists to solve a fundamental integration problem: how do you let dozens of services react to things that happen in your system without coupling them together? Before EventBridge, you&amp;rsquo;d wire services directly — Lambda calls SQS, SQS triggers Lambda, Lambda calls another Lambda — creating brittle chains that are hard to change and harder to debug. EventBridge inverts this: producers emit events onto a bus, and any number of consumers subscribe to exactly the events they care about. Neither side knows about the other.&lt;/p&gt;</description></item><item><title>22. CDK</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cdk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cdk/</guid><description>&lt;h2 id="cdk-cloud-development-kit"&gt;CDK (Cloud Development Kit)&lt;a class="anchor" href="#cdk-cloud-development-kit"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The AWS Cloud Development Kit (CDK) is an open-source framework that lets you define cloud infrastructure using familiar programming languages — TypeScript, Python, Java, C#, and Go — instead of writing raw YAML or JSON templates. It solves a real pain point: CloudFormation templates are verbose, hard to reuse, and lack the abstraction tools developers rely on (loops, conditionals, functions, classes). CDK brings those tools back. Under the hood, CDK still generates and deploys CloudFormation — it&amp;rsquo;s a higher-level abstraction on top of it, not a replacement. &lt;a href="https://docs.aws.amazon.com/cdk/v2/guide/home.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>31. Macie</title><link>https://tofl.github.io/docs/9-security-encryption-deep-dive/macie/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/9-security-encryption-deep-dive/macie/</guid><description>&lt;h2 id="macie"&gt;Macie&lt;a class="anchor" href="#macie"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;As applications grow, so does the amount of data they store in S3 — user uploads, logs, exports, backups. It becomes increasingly difficult to track whether any of that data contains sensitive information like names, email addresses, credit card numbers, or API keys. Amazon Macie exists to solve exactly this problem: it automatically scans S3 buckets using machine learning to detect sensitive and personally identifiable information (PII), and alerts you when it finds something — or when your bucket configurations expose data in risky ways.&lt;/p&gt;</description></item><item><title>41. Amplify</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/amplify/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/amplify/</guid><description>&lt;h2 id="amplify"&gt;Amplify&lt;a class="anchor" href="#amplify"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;AWS Amplify is a set of tools and services that lets frontend and mobile developers build full-stack applications on AWS without needing to manually wire together individual services. The problem it solves is real: provisioning a Cognito user pool, an API Gateway endpoint, a Lambda function, and an S3 bucket — then connecting them to a React app — involves dozens of steps. Amplify collapses that into a single CLI command or a few lines of library code.&lt;/p&gt;</description></item><item><title>8. ELB</title><link>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/elb/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/3-core-compute-ec2-lambda-asg-elb/elb/</guid><description>&lt;h2 id="elastic-load-balancing-elb"&gt;Elastic Load Balancing (ELB)&lt;a class="anchor" href="#elastic-load-balancing-elb"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When you run multiple EC2 instances (or Lambda functions, containers, or IP targets) to serve user traffic, you need something to sit in front of them and distribute incoming requests evenly, route them intelligently, and stop sending traffic to unhealthy targets. That is exactly what Elastic Load Balancing does. ELB is a managed service — AWS handles provisioning, scaling, and availability of the load balancer itself, so you only configure behavior. &lt;a href="https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>15. Kinesis Data Streams</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/kinesis-data-streams/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/kinesis-data-streams/</guid><description>&lt;h2 id="kinesis-data-streams"&gt;Kinesis Data Streams&lt;a class="anchor" href="#kinesis-data-streams"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications often generate data faster than any single consumer can process it — user clickstreams, IoT sensor readings, application logs, financial transactions. Amazon Kinesis Data Streams &lt;a href="https://docs.aws.amazon.com/streams/latest/dev/introduction.html"&gt;🔗&lt;/a&gt; exists to solve exactly this problem: it lets you ingest large volumes of real-time data, durably store it, and allow one or more consumers to process it independently at their own pace. Unlike SQS, where a message is consumed and gone, Kinesis retains records in order for a configurable window, making it ideal for replay, auditing, and parallel processing by multiple consumers.&lt;/p&gt;</description></item><item><title>23. Elastic Beanstalk</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/elastic-beanstalk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/elastic-beanstalk/</guid><description>&lt;h2 id="elastic-beanstalk"&gt;Elastic Beanstalk&lt;a class="anchor" href="#elastic-beanstalk"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Deploying a web application on AWS from scratch means provisioning EC2 instances, configuring load balancers, setting up Auto Scaling groups, managing security groups, and wiring everything together — before writing a single line of application logic. Elastic Beanstalk &lt;a href="https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html"&gt;🔗&lt;/a&gt; solves this by handling all that infrastructure automatically. You upload your code, choose a platform, and Beanstalk provisions and manages the underlying resources. You retain full access to those resources if you need to customize them, but the heavy lifting is done for you.&lt;/p&gt;</description></item><item><title>42. Amazon OpenSearch Service</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/amazon-opensearch-service/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/amazon-opensearch-service/</guid><description>&lt;h2 id="amazon-opensearch-service"&gt;Amazon OpenSearch Service&lt;a class="anchor" href="#amazon-opensearch-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Relational databases like RDS are optimized for structured queries, and DynamoDB excels at key-value lookups — but both fall short when you need to search across large volumes of unstructured or semi-structured text, or to run real-time analytics on log data. Amazon OpenSearch Service &lt;a href="https://docs.aws.amazon.com/opensearch-service/latest/developerguide/what-is.html"&gt;🔗&lt;/a&gt; is a managed service built for exactly these use cases: full-text search, log and event analytics, and observability pipelines. It is the AWS-managed successor to Amazon Elasticsearch Service, based on the open-source OpenSearch project (itself a fork of Elasticsearch 7.10).&lt;/p&gt;</description></item><item><title>16. Step Functions</title><link>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/step-functions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/5-application-integration-sqs-sns-eventbridge-kinesis-step-functions/step-functions/</guid><description>&lt;h2 id="step-functions"&gt;Step Functions&lt;a class="anchor" href="#step-functions"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications rarely do just one thing — they chain together multiple operations: validate input, write to a database, call an external API, send a notification, and handle failures at each step. The naive approach is to wire these steps together inside Lambda functions, where one function calls another and so on. This creates tightly coupled, fragile chains that are hard to debug, retry, or modify. AWS Step Functions solves this by letting you define your workflow as a &lt;strong&gt;state machine&lt;/strong&gt; — a visual, auditable graph of steps and transitions that AWS manages for you. You describe &lt;em&gt;what&lt;/em&gt; should happen and &lt;em&gt;in what order&lt;/em&gt;; Step Functions handles the execution, retries, error handling, and state passing between steps. &lt;a href="https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>24. AppConfig</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/appconfig/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/appconfig/</guid><description>&lt;h2 id="appconfig"&gt;AppConfig&lt;a class="anchor" href="#appconfig"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Deploying a new version of your application every time you want to change a configuration value — a feature flag, a timeout, a rate limit — is slow, risky, and wasteful. AWS AppConfig &lt;a href="https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html"&gt;🔗&lt;/a&gt; solves this by letting you deploy configuration changes independently of code, with built-in validation, gradual rollout, and automatic rollback. It&amp;rsquo;s especially useful for &lt;strong&gt;feature flags&lt;/strong&gt;: you can enable a new feature for 10% of users, watch your error metrics, and expand (or roll back) without touching a deployment pipeline.&lt;/p&gt;</description></item><item><title>43. Amazon Athena</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/amazon-athena/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/amazon-athena/</guid><description>&lt;h2 id="amazon-athena"&gt;Amazon Athena&lt;a class="anchor" href="#amazon-athena"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon Athena is a serverless, interactive query service that lets you analyze data stored in Amazon S3 using standard SQL. It exists to solve a very specific and common problem: you have large volumes of data sitting in S3 — logs, exports, event archives — and you need to query it without first loading it into a database, building an ETL pipeline, or provisioning any infrastructure. You point Athena at your S3 data, define a schema, and run SQL. You pay only for the data scanned.&lt;/p&gt;</description></item><item><title>44. MSK</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/msk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/msk/</guid><description>&lt;h2 id="msk-managed-streaming-for-apache-kafka"&gt;MSK (Managed Streaming for Apache Kafka)&lt;a class="anchor" href="#msk-managed-streaming-for-apache-kafka"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Amazon MSK (Managed Streaming for Apache Kafka) &lt;a href="https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html"&gt;🔗&lt;/a&gt; is a fully managed service that runs Apache Kafka on AWS. The problem it solves is operational: running Kafka yourself means provisioning brokers, managing ZooKeeper (or KRaft), handling upgrades, configuring storage, and wiring up monitoring. MSK removes all of that, leaving you with native Kafka APIs and none of the cluster management overhead. If your team is already building on Kafka — or needs a battle-tested, high-throughput event streaming platform — MSK lets you do it without becoming a Kafka infrastructure expert.&lt;/p&gt;</description></item><item><title>45. SES</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/ses/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/ses/</guid><description>&lt;h2 id="ses-simple-email-service"&gt;SES (Simple Email Service)&lt;a class="anchor" href="#ses-simple-email-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Sending email from an application sounds simple until you have to deal with deliverability, spam reputation, bounce management, and mail server infrastructure. Amazon SES exists to solve exactly that: it is a cloud-based email sending service that lets you send transactional and marketing email at scale without operating your own mail server or worrying about IP reputation. It handles the SMTP infrastructure, deliverability optimizations, and feedback loops with inbox providers on your behalf.&lt;/p&gt;</description></item><item><title>46. Advanced Identity</title><link>https://tofl.github.io/docs/12-advanced-supplementary-services/advanced-identity/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/12-advanced-supplementary-services/advanced-identity/</guid><description>&lt;h2 id="advanced-identity"&gt;Advanced Identity&lt;a class="anchor" href="#advanced-identity"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;As AWS environments grow, managing identity across dozens of accounts and integrating with existing corporate directories becomes a challenge. This section covers the tools AWS provides to handle enterprise-scale identity: centralizing account governance, enabling single sign-on, sharing resources, federating with external identity providers, and applying fine-grained access control through attributes.&lt;/p&gt;
&lt;h3 id="aws-organizations"&gt;AWS Organizations&lt;a class="anchor" href="#aws-organizations"&gt;#&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;AWS Organizations &lt;a href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html"&gt;🔗&lt;/a&gt; lets you group multiple AWS accounts under a single management structure. Accounts are organized into &lt;strong&gt;Organizational Units (OUs)&lt;/strong&gt; — logical containers you can nest hierarchically (e.g., &lt;code&gt;Root &amp;gt; Production &amp;gt; Backend&lt;/code&gt;).&lt;/p&gt;</description></item></channel></rss>