What’s the Complexity of Cases for Cloud Support Engineers at AWS?

As a former Cloud Support Engineer in Premium Support focused on EKS, I can say that the complexity of cases really varies. While you'll face some of the simpler issues, like VPC CNI IP exhaustion, the trend is definitely shifting toward more complex challenges as customers increasingly use AI for simple problems. With experience, you'd dive deeper into nuanced issues and can really hone your skills.

Regarding AWS tools, yes, you definitely gain more visibility into service operations, unlike regular CloudWatch logs limited to customer views.

As for collaboration with engineering teams, you might start mostly handing off bug reports, but over time, you could get involved in the escalation process, allowing you to work directly with service teams on fixes and improvements!

As a current CSE in the Containers group, I find the cases can be quite varied. You're not forced into shallow responses—you can really take the opportunity to dig deep into cases, but it may require more effort on your part. The internal tools do provide better insights into configurations compared to what customers see.

Collaboration with service teams does happen, especially as you gain experience, but keep in mind there's also some level of micromanagement. Overall, it feels like a stepping stone role for those starting out in the field, but you can emerge as an expert if you put in the work.

I spent three years as a Cloud Support Engineer II. The job is pretty mixed; you’ll handle both basic inquiries and some super complex cases, often spanning several services. While AI is improving the experience for many customers, you can stand out by tackling those tricky, high-severity issues that require a lot of detective work. You'll have access to more internal tools to help with investigations, but be mindful that customer data is heavily restricted.

When it comes to bugs, you'll sometimes need to reproduce issues for evidence or work with engineering to test fixes—though often it might just be passing it along. Overall, expect the role to involve metrics, and sometimes it can feel a bit like a call center job, dealing with a wide range of customers. I learned a ton, but after a while, I was eager to get back to a more traditional engineering role.

It's a mix of case complexities. Some issues can be repetitive and simple, but more challenging edge cases tend to arise with experience. You’ll find that many who enter this role see it as valuable exposure to real-world architectures and can decide their career path later on— whether back to engineering or moving toward architecture roles.

I worked in Containers at AWS from mid-2020 to late-2022. If you're starting at L4, expect a mix of simple to moderately complex issues, especially around EKS. It’s not uncommon to help with major scaling issues down the line, depending on how you progress. Things could have evolved with the introduction of new tools like LLMs, though.

For the tools, there's a mix of internal visibility and customer-facing access—you'll often need to instruct customers on uploading logs. Bug collaboration can happen directly with the engineering teams, but that’s typically reserved for when you've built some rapport in your role!