The immune system and the ID card
Your immune system decides what belongs in your body and attacks what doesn't. Your ID card proves who you are when you enter a building. A microservice needs both: protection against unwanted callers and inputs, and an identity that limits what it is allowed to do.
The ID card: the service's own identity (IAM role)
Every Lambda function runs with an IAM execution role — its ID card. The card lists exactly which doors it opens.
Least privilege: the Waiter's ID card opens the Waiter's table and lets it post on the notice board. It doesn't open the Cashier's table — even if a bug or attacker tries.
With CDK, you grant permissions precisely instead of writing broad policies:
ordersTable.grantReadWriteData(placeOrderFn); // only this table
eventBus.grantPutEventsTo(placeOrderFn); // only this bus
paymentsSecret.grantRead(chargeFn); // only this secret
The skin and front door: who may call the service
| Caller | Protection |
|---|---|
| App users (people) | Amazon Cognito user pools issue tokens; API Gateway's JWT authorizer checks them before your code runs |
| Other services inside AWS | IAM authorization on APIs (signed requests), or EventBridge/SQS permissions — services never share passwords |
| Partners and third parties | API keys with usage plans, or OAuth client credentials |
| The whole internet | AWS WAF rules (block SQL injection, bad bots, too many requests), throttling on API Gateway |
Antibodies: validating everything
Treat every input as potentially harmful:
- Validate shape and types at the skin (schemas).
- Enforce limits (sizes, ranges, counts).
- Never build database queries or shell commands from raw input.
- For AI features, treat user text as untrusted — it may try to manipulate prompts.
Protecting memory
- Encryption at rest — DynamoDB and S3 encrypt by default; use customer-managed KMS keys when you need control and audit of key use.
- Encryption in transit — HTTPS everywhere.
- No public buckets — keep S3 Block Public Access on; serve files through pre-signed URLs or CloudFront.
- Minimise personal data — store only what you need; expire it.
Secrets
- Store in Secrets Manager (with rotation) or SSM Parameter Store (SecureString).
- Grant read access only to the functions that need them.
- Never log secrets; be careful logging full requests.
Immune memory: learning from attacks
- CloudTrail records who did what in the account.
- GuardDuty detects suspicious activity.
- Alarms on unusual error rates or traffic spikes (see heartbeat and health).
A security checklist for one human
- Execution role grants only the actions and resources needed
- Every API route requires authentication (unless deliberately public)
- Inputs validated against schemas; sizes limited
- Throttling and, for public endpoints, WAF
- Data encrypted; no public storage
- Secrets in Secrets Manager/Parameter Store, never in code
- Logs don't contain secrets or unnecessary personal data
- Dependencies scanned and updated
In CDK, the grant… methods are your friend: they generate least-privilege policies automatically and keep permissions next to the code that needs them.
Senior Full-Stack Engineer · AI & AWS. I design and build serverless systems on AWS — and love explaining them simply.