AWS Deep Dive Part 4: Security, Observability & DevOps — IAM, CloudWatch, CloudFormation, Secrets Manager

☁️ AWS DEEP DIVE SERIES (4 PARTS · 20 SERVICES)

• Part 1: Compute & Networking — EC2, Lambda, ECS, EKS, Fargate, VPC, Route 53 →
• Part 2: Storage & Databases — S3, EBS, EFS, RDS, DynamoDB, ElastiCache →
• Part 3: Application Integration — API Gateway, SQS, SNS, EventBridge, Step Functions →
• ▸ Part 4: Security, Observability & DevOps — IAM, CloudWatch, CloudFormation, Secrets Manager YOU ARE HERE

This is the closing post of our four-part tour through the 20 most-used AWS services. Parts 1, 2, and 3 covered the runtime, the state, and the connective tissue. This part covers the four services that keep a real workload safe, observable, and reproducible: IAM for identity and authorization, CloudWatch for telemetry and alarming, CloudFormation (and the CDK) for infrastructure as code, and Secrets Manager for credentials. Getting these four right is what separates a working AWS account from a maintainable one.

1. AWS IAM — Identity and Access Management

AWS IAM is the gate every API call passes through. Every action on AWS is authorized by IAM: the call carries an identity, AWS evaluates the applicable policies, and either allows or denies. Mastering IAM is mostly about understanding the policy evaluation order and the difference between the kinds of policies that exist.

The identities are users (long-lived; rare in modern accounts), roles (temporary, assumed by services or by federated humans through SSO), and the root user (the account owner; should be locked away with MFA and never used). Modern best practice is to centralize human identity in IAM Identity Center (the successor to AWS SSO) and have humans assume roles in member accounts via that, while workloads (Lambdas, ECS tasks, EC2 instances) get roles through service-specific trust policies.

The policy types you will actually write are identity policies (attached to a user, group, or role; the most common form), resource policies (attached to an S3 bucket, KMS key, SNS topic, Lambda function, or other resource), and at the org level Service Control Policies (which apply to every principal in an OU and act as a ceiling). Two helper constructs sit on top: permission boundaries (a maximum-permission ceiling for a delegated identity, used when one team needs to create roles for another), and session policies (passed at AssumeRole time to further restrict a session).

Practical IAM hygiene: scope policies to specific resources and actions instead of * whenever possible; use the IAM Access Analyzer to find unused permissions and externally accessible resources; rely on roles and STS rather than long-lived access keys; enable IAM Identity Center for humans; and keep production permissions strictly tighter than development through SCPs and account boundaries.

2. Amazon CloudWatch — Metrics, Logs, Alarms, and Traces

Amazon CloudWatch is the umbrella observability service. It has grown into four distinct sub-services that work together: Metrics (time-series data, both AWS-default and your own), Logs (a managed log aggregation and search engine), Alarms (rules on metrics or logs that fire actions), and now Application Signals with X-Ray (distributed traces tied back to metrics).

Metrics are emitted automatically by almost every AWS service. EC2 publishes CPUUtilization; Lambda publishes Invocations, Errors, Duration, Throttles; ALB publishes RequestCount and TargetResponseTime; RDS publishes DatabaseConnections and FreeableMemory. Your own application code can publish custom metrics with PutMetricData or, much more efficiently, by writing them as JSON inside CloudWatch Logs and letting the Embedded Metric Format (EMF) extract them server-side at no per-call cost.

Logs are organized into log groups (typically one per Lambda function, ECS service, or VPC Flow Log destination) and log streams. You can run CloudWatch Logs Insights queries with a simple pipe-style syntax to find the slowest requests, count errors by route, or correlate spikes. Retention is set per log group; set a sensible retention (often 30 to 180 days) because logs accumulate cost forever otherwise. For long-term analytics, ship logs to S3 via Logs subscription filter → Firehose and query them with Athena.

Alarms evaluate a metric (or composite expression) against a threshold over a sliding window and fire an action: notify an SNS topic, trigger an Auto Scaling adjustment, or invoke a Lambda. Anomaly Detection alarms learn a normal band for the metric and fire when reality drifts from it — helpful when static thresholds do not capture diurnal patterns.

3. AWS CloudFormation (and the CDK) — Infrastructure as Code

AWS CloudFormation is the foundational infrastructure-as-code service on AWS. You write a YAML or JSON template describing the resources you want — an S3 bucket, an EC2 instance, an RDS instance, a Lambda function, an IAM role — and CloudFormation creates, updates, or deletes them as a single stack. The state lives in CloudFormation itself; there is no separate state file to manage as with Terraform.

For day-to-day work most teams now reach for the AWS Cloud Development Kit (CDK), which generates CloudFormation under the hood but lets you write infrastructure in a real programming language (TypeScript, Python, Java, .NET, Go). The CDK gives you typed constructs, library reuse, IDE refactoring, and a much more compact expression for common patterns than raw YAML.

Operational features that make CloudFormation actually pleasant: change sets show you exactly what will be created, updated, and deleted before you apply (a must for production); automatic rollback reverts a failed update; drift detection finds resources that were modified out-of-band; StackSets deploy the same stack across many accounts and regions through one operation; and nested stacks let you compose larger systems from reusable modules.

Two adjacent services are worth naming. AWS SAM (Serverless Application Model) is a CloudFormation transform that gives you very compact syntax for serverless apps (Lambda, API Gateway, DynamoDB). CodePipeline + CodeBuild + CodeDeploy are the AWS-native CI/CD stack; many teams now use GitHub Actions with OIDC into AWS instead, but the native pipeline still wins for fully air-gapped environments or AWS-native ecosystems like CodeCatalyst.

4. AWS Secrets Manager — Credentials Done Right

AWS Secrets Manager stores secret values (DB passwords, API tokens, OAuth client secrets, signing keys) encrypted at rest with KMS, accessed at runtime through an IAM-authenticated API. Three things distinguish it from a homegrown approach.

First, automatic rotation: for RDS, DocumentDB, Redshift, and any custom secret, Secrets Manager can rotate the credential on a schedule by invoking a rotation Lambda. The rotation flow uses four staging labels — AWSCURRENT, AWSPENDING, AWSPREVIOUS, AWSPENDING — that let clients pick up the new value gracefully without coordinated restarts. Second, cross-account and cross-region replication: a secret can be replicated to other regions for DR, and shared with another account via a resource policy. Third, fine-grained access via IAM and KMS key policies, with full CloudTrail logging of every retrieval.

For client code, the recommended way to retrieve a secret is through the Secrets Manager Agent or Lambda extension, which caches the value in-process and refreshes it on a schedule. This avoids hammering the API on every cold start and gives you the latest version automatically. For Lambda specifically, the AWS Parameters and Secrets Lambda Extension is a single layer that handles caching for both Secrets Manager and Systems Manager Parameter Store.

Speaking of SSM Parameter Store, it is the lighter cousin of Secrets Manager: free for the standard tier, no rotation, no replication, but perfectly fine for non-rotating configuration values, feature flags, and image identifiers. A common pattern is to use SSM for plain configuration and Secrets Manager for anything that should be rotated.

Putting the 20 Services Together

Across this four-part series we have covered 20 services that account for the bulk of real AWS workloads. A canonical production architecture combining them looks like this: Route 53 resolves the domain to CloudFront, which fronts an Application Load Balancer in two public subnets. The ALB routes requests to ECS on Fargate tasks in private subnets, which talk to Aurora PostgreSQL (Multi-AZ) for OLTP, DynamoDB for hot key-value access patterns, ElastiCache Redis for sessions and caching, and S3 for user uploads and assets. API Gateway HTTP API fronts a separate set of Lambda functions for asynchronous workloads, which read from SQS and publish to EventBridge; Step Functions orchestrates multi-step processes; SNS handles user notifications. Behind the scenes, IAM roles authenticate every workload, Secrets Manager stores rotating credentials, CloudWatch collects metrics, logs, and alarms, and the whole thing is defined and deployed by a CDK app that synthesizes CloudFormation stacks.

What You Can Skip (For Now)

If you are new to AWS the 200+ service catalog can be paralyzing. The reassuring truth is that you do not need most of it on day one. You can ignore the analytics stack (Athena, Glue, EMR, Redshift) until you actually have a data warehouse use case; ignore the ML services (SageMaker, Bedrock) unless ML is a feature; ignore the IoT stack unless you build IoT; and ignore most managed-blockchain or quantum services entirely. Start with the 20 services in this series, get them tightly wired together with IaC, IAM, and observability, and add specialized services only when a concrete need appears.

Wrapping Up the Series

The four posts together — compute & networking, storage & databases, application integration, and security/observability/DevOps — give you a working mental model for the AWS platform as it is used in 2026. The services keep evolving (more serverless options, more Graviton, more AI-native primitives), but the underlying concepts and the way the 20 core services fit together are stable. Bookmark the series, build something with it, and the rest of AWS becomes far less intimidating.

☁️ REVISIT THE AWS DEEP DIVE SERIES

• Part 1: Compute & Networking →
• Part 2: Storage & Databases →
• Part 3: Application Integration →
• ▸ Part 4: Security, Observability & DevOps (you are reading this)