How do you keep up with AWS, and how do you decide whether to use a new service?

How you keep up: the What's New feed and release notes, the AWS Architecture Blog, and re:Invent sessions for the reasoning behind services rather than just their existence. Hands-on work in a personal account is what actually builds judgement — AWS documentation describes the happy path, and the limits only appear when you build something.

How you evaluate a new service:

• Is it generally available in the regions you use? Preview services carry no SLA and may change.
• Does it solve a problem you have measured? AWS releases hundreds of features a year and most are irrelevant to any given workload.
• What are the limits and quotas? This is the question people skip and regret. Concurrency caps, payload sizes, and throughput limits determine whether a service fits at your scale.
• What is the exit cost? The more proprietary the service, the harder it is to leave. That is often an acceptable trade for the operational savings — but it should be a decision, not an accident.
• Can your team operate it? Adopting EKS without Kubernetes experience creates a larger problem than it solves.

Note: The Well-Architected Framework's six pillars are worth naming as the structure you evaluate against — operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability.