Hey there! 👋

Once you understand the building blocks of AWS, the next question is practical: how do you get an app onto AWS, and how do you manage it afterward? Five services cover this, and they group neatly by the job they do. The mental map ┌─────────────────────────────────────────────────────┐ │ DEFINE infrastructure as code │ │ • CloudFormation (YAML/JSON templates) │ │ • CDK (real code → compiles to CFN) │ ├─────────────────────────────────────────────────────┤ │ DEPLOY applications │ │ • Elastic Beanstalk (PaaS, all-in-one) │ │ • CodeDeploy (push code to existing fleet) │ ├─────────────────────────────────────────────────────┤ │ MANAGE running infrastructure │ │ • Systems Manager (SSM) │ └─────────────────────────────────────────────────────┘ CloudFormation CloudFormation is declarative AWS infrastructure as code....

Both AWS Batch and Lambda run your code without making you manage servers — but they are built for very different shapes of work. Knowing which is which saves you from forcing a long job into a service that caps out at 15 minutes. The core difference Lambda Batch Built for Short, event-driven tasks Long, heavy batch jobs Execution time ≤ 15 min Hours or days — no limit Trigger Events (S3, API, schedule) Job submission Resources Up to 10 GB RAM Any EC2/Fargate size, including GPUs Runs on Lambda’s managed runtime EC2 or Fargate (you don’t manage them, but they exist) Scaling Instant, per invocation Queues jobs, then provisions compute Use case Glue code, reactions, APIs Data processing, ML training, simulations Mental model Lambda: "Run this small function NOW, fast....

Serverless is a shift in how you think about compute: instead of provisioning and running servers, you just deploy code. AWS Lambda is the service that pioneered it, and it is the third compute option in the AWS model — alongside EC2 and Fargate. What serverless means A new paradigm — developers don’t manage servers, they just deploy code (functions). It started as FaaS (Function as a Service), pioneered by AWS Lambda....

If your app is packaged as a Docker container, AWS gives you three services that work together to run it: ECS to orchestrate containers, Fargate to run them without managing servers, and ECR to store the images. ECS — Elastic Container Service ECS launches Docker containers on AWS. The key thing about it: you provision and maintain the EC2 instances — the infrastructure — and AWS handles starting and stopping containers across those EC2s....

AWS has a lot of data services, and the names alone don’t tell you what each one is for. This post is a mental map — how the database, analytics, and data-movement services fit together, and how to pick between them. The mental map ┌─────────────────────────────────────────────────────────────┐ │ DATABASES (operational, low latency) │ ├─────────────────────────────────────────────────────────────┤ │ RDS relational SQL │ │ DynamoDB NoSQL key-value, serverless │ │ ElastiCache in-memory cache (Redis/Memcached) │ │ DocumentDB MongoDB-compatible document DB │ │ Neptune graph DB (nodes + edges) │ │ Timestream time-series DB │ │ Managed Blockchain Hyperledger/Ethereum │ ├─────────────────────────────────────────────────────────────┤ │ ANALYTICS (batch, big data, querying) │ ├─────────────────────────────────────────────────────────────┤ │ Redshift data warehouse (columnar SQL at scale) │ │ EMR managed Hadoop/Spark cluster │ │ Athena SQL queries directly on S3 │ │ QuickSight BI dashboards/visualization │ ├─────────────────────────────────────────────────────────────┤ │ DATA MOVEMENT │ ├─────────────────────────────────────────────────────────────┤ │ Glue managed ETL (extract/transform/load) │ │ DMS Database Migration Service │ └─────────────────────────────────────────────────────────────┘ Databases These are operational, low-latency stores — the databases an application reads and writes in real time....