12 Things You Should (and Shouldn't) Do in AWS
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
An AWS consultant who has spent fifteen years fixing outages walks through twelve practical dos and don'ts for running production workloads on AWS: use infrastructure as code instead of hand-provisioning, always review Terraform plans before applying, prefer IAM roles over access keys, avoid wildcard permissions, assume leaked credentials are compromised immediately, keep backend resources in private subnets, segment security groups, use SSM Session Manager instead of a bastion host, treat servers as disposable containers rather than hand-tuned pets, learn CloudWatch cost-consciously, build a deployment pipeline, keep S3 private behind CloudFront with signed URLs, and use Cost Explorer with budgets and tagging. The conversation also covers safely giving AI agents access to infrastructure and databases (read-only tool calls, human-approved writes, pointing agents at a data lake instead of production), WAF strategies against DDoS and bots, and the guest's Cloud War Games platform for simulating outages so teams practice incident response before a real 3am crisis.
Questions this post answers
Should I give AI coding agents direct access to my production database?
No, agents should be pointed at a data lake or read-only tool calls instead of a live production database connection. Agents can fire a complicated read query in a loop and degrade a database that is not perfectly optimized, and if writes are needed, a separate tool call requiring human approval should be used so the agent suggests changes rather than making them directly. Anyone weighing how much access to grant AI agents can track real-world guidance like this on daily.dev.
Why is a public subnet dangerous for a database on AWS?
A public subnet gives resources a network path to the internet, so a misconfigured firewall rule can expose a database directly. Databases and sensitive resources belong in private subnets, with only the load balancer in the public subnet, because a private subnet means there is no network path from the outside even when a security rule is wrong. Developers hardening AWS network layouts can follow practical breakdowns like this on daily.dev.
What should I do immediately if AWS access keys get pushed to a public GitHub repo?
Assume the credential is compromised the instant it touches a public repo and rotate it immediately, since automated scanners like shhgit monitor the public GitHub commit firehose for anything resembling credentials in real time. Simply deleting or uncommitting the key is not remediation; one real incident saw leaked email-sending keys used to send roughly 16 million spam emails in about eight minutes before AWS shut the account down. Teams building credential-rotation habits can find incident stories like this on daily.dev.