1. Identity, Access & Secrets
Every layer below depends on this being correct first.
| Term |
What it is |
| IAM |
AWS's identity system — Users, Roles, Policies (JSON allow/deny), and STS for temporary credentials. Governs what a caller is allowed to do. |
| Ansible Vault |
AES256 encryption for secrets-at-rest in Ansible repos (passwords, keys) so they can live safely in version control. Governs what a human/CI job is allowed to read. |
| KMS |
AWS-managed encryption keys; used for envelope encryption (encrypt a small data key, use that to encrypt your actual payload). |
| Secrets Manager / SSM Parameter Store |
Runtime secret/config storage — Secrets Manager for rotating sensitive values, SSM for cheaper non-rotating config. |
How they connect: IAM controls API-level permission; Vault controls what's readable in your automation code; KMS/Secrets Manager control what's readable at runtime. Same principle (least privilege, encrypt at rest) applied at three different layers.
2. Networking
Everything provisioned below lives inside this.
| Term |
What it is |
| VPC |
An isolated network with a CIDR range, divided into subnets per Availability Zone. |
| Subnet (public/private) |
"Public" only if its route table sends 0.0.0.0/0 to an Internet Gateway — nothing else makes it public. |
| Security Groups |
Stateful, instance-level allow-only firewall rules (return traffic auto-allowed). |
| NACLs |
Stateless, subnet-level rules — need explicit allow rules in both directions. |
3. Provisioning & Configuration Management
How resources above actually get created and kept in the desired state.
| Term |
What it is |
| Ansible core loop |
Control node → SSH → module code pushed to target → executed → JSON result returned. Agentless, idempotent by design. |
| Inventory (static/dynamic) |
The list of hosts/resources Ansible acts on. Static = hand-maintained file; Dynamic = live query against AWS/Docker/etc. (amazon.aws.aws_ec2 plugin), essential once infrastructure is ephemeral. |
| Playbooks / Tasks / Plays |
YAML declarations of desired state. A playbook contains plays; a play maps hosts to an ordered list of tasks. |
| Variables & Facts |
Facts = auto-discovered host properties (ansible_os_family, IPs). Variables = any named value, resolved through a strict precedence chain (role defaults → inventory → play vars → facts → registered vars → extra-vars). |
| Jinja2 Templates |
The templating engine ({{ }}) used inline and in .j2 files rendered by the template module — lets one config file adapt per environment. |
Conditionals (when) & Loops (loop) |
when skips a task per-host based on a condition; loop repeats a task once per list item. |
| Handlers |
Tasks triggered by notify, run once at the end of a play — the standard "restart/reload after config change" pattern. |
| Roles |
Standardized, reusable directory structure (tasks/, handlers/, templates/, defaults/, vars/) packaging a unit of automation. |
| Ansible Galaxy / Collections |
Public registry (Galaxy) and modern packaging format (Collections, namespaced as namespace.collection.module) for sharing roles/modules. |
AWS equivalent of this layer: CloudFormation and Terraform. Both are declarative IaC tools — CloudFormation is AWS-native; Terraform (or OpenTofu) works cross-cloud and against Floci by pointing its provider endpoints at localhost:4566.
4. Storage & Data
| Term |
What it is |
| S3 |
Object storage — bucket + key addressing, versioning (delete = marker, not erasure), bucket policies vs IAM policies, presigned URLs for time-limited access without policy changes. |
| DynamoDB |
NoSQL key-value/document store — partition key (+ optional sort key) determines the primary key; GSIs enable querying by other attributes; Streams emit a change log (feeds Lambda). |
| RDS |
Managed relational database (Postgres/MySQL/etc.) — real SQL engine underneath, unlike DynamoDB's custom model. |
5. Messaging & Eventing
| Term |
What it is |
| SQS |
Durable queue decoupling producer/consumer. Standard = at-least-once/best-effort order; FIFO = strict order + exactly-once. DLQ catches repeatedly-failing messages. |
| SNS |
Pub/sub topic — one publish reaches every subscriber. Combined with SQS, gives the fan-out pattern (one event → many independent consumers). |
| EventBridge |
Event bus with pattern-matching rules — more sophisticated routing than SNS's simple fan-out. |
6. Compute — Serverless & Containers
| Term |
What it is |
| Lambda |
Event-driven compute with no server management. Triggers: S3 events, DynamoDB Streams, SQS, EventBridge, direct invoke. |
| API Gateway |
HTTP(S) front door for Lambda (or other backends) — HTTP API (simple/cheap) vs REST API (more features, more complexity). |
| ECR |
Private Docker image registry. |
| ECS |
Container orchestration — task definitions (blueprint) run on a cluster, via Fargate (no server management) or EC2 (self-managed instances) launch type. |
| EKS |
Managed Kubernetes — the heavier-weight container orchestration option. |
| EC2 |
Traditional VM compute — AMI + instance type + key pair + security group + (optionally) an IAM instance profile for role-based permissions instead of static keys. |
7. Testing & Delivery
| Term |
What it is |
| Molecule |
Ansible's role-testing framework — lifecycle: create → converge → idempotence (run twice, must show zero changes) → verify → destroy. Automates the idempotency principle as a test gate. |
| ansible-lint |
Fast style/best-practice linter — runs before Molecule in a pipeline since it's cheaper. |
| CI/CD (GitHub Actions, etc.) |
Wires lint → syntax-check → Molecule → --check --diff dry-run into a required pipeline gate before real deployment. Floci's fast startup makes spinning up a fresh AWS-shaped environment per CI job cheap. |
| CloudFormation / Terraform |
The IaC equivalent of Molecule/CI discipline — --check/plan as a dry-run gate before apply/deploy. |
8. Observability & Production Operations
| Term |
What it is |
| CloudWatch Logs/Metrics/Alarms |
Log groups + streams for output; custom/automatic metrics; alarms transition OK/ALARM based on threshold breaches over evaluation periods. |
| X-Ray |
Distributed tracing — latency contribution per hop across services. |
Strategy (linear/free) & serial |
Ansible's execution-safety levers: linear (default, safe, waits per-task) vs free (max throughput, less predictable); serial: "25%" batches a rollout so a bad release only affects one wave. |
block / rescue / always |
Ansible's try/rescue/finally — pairs naturally with serial for automatic rollback on a bad batch. |
| AWX / Ansible Tower |
Enterprise layer over core Ansible — centralized credentials, RBAC, scheduling, webhook triggers, audit log. The Ansible equivalent of moving from ad-hoc laptop deploys to a governed platform. |
How the Pieces Compose (End-to-End Flow)
IAM/Vault (who can do what)
│
▼
VPC (where it lives)
│
▼
Ansible Playbook/Role ──or── CloudFormation/Terraform (declare desired state)
│
▼
Compute created: EC2 / Lambda / ECS (using Storage: S3/DynamoDB/RDS)
│
▼
Messaging wires services together: SQS / SNS / EventBridge
│
▼
Molecule / ansible-lint / CI pipeline validates before real rollout
│
▼
serial + block/rescue rolls it out safely; CloudWatch/X-Ray watches it
│
▼
AWX/Tower (or a CI runner) is *how* all of the above actually gets executed,
governed, and audited in a real team — not from an individual laptop.