Hello Reader,

I have been a Cloud Solutions Architect for 10 years now - 4 years at Verizon, 6+ years at AWS. I was an Application Cloud Architect at Verizon, and then I joined AWS, where I have had two different SA roles - first a General SA (Enterprise Architect) and then a Specialist SA, which is my current role. In this post, I will review my responsibilities as an SA in all these companies, including the hardest parts of the job (in my humble opinion). Let's get started:

Solutions Architect at Verizon

I became a SA at Verizon at their CCOE (Cloud Center of Excellence). I switched from Mainframe to AWS SA at Verizon via internal interview process.

Main responsibilities:

• Work with applications and help them migrate to AWS. Design AWS system considering their existing design in data center
• Help application teams accelerate AWS adoption. This could vary based on the applications I was helping. I created Jenkins CICD pipelines and CloudFormations to help out some teams. I learned Serverless when it was announced, did PoC, and helped an application team deploy Serverless for the first time at Verizon (This got me promoted to Distinguished Cloud Architect!). I picked up Kubernetes and helped migrate Pivotal Cloud Foundry apps, etc.
• Create patterns (think of IaC templates, helm charts, Jenkinsfile etc.) that can be reused by application teams
• Evaluating different products and vendors. For example, I evaluated both GCP and AWS. Obviously, AWS is better (I am a tad biased ;))
• Work with the security and governance team and evaluate AWS services to see if it can be approved to be used in the company
• As CCOE, you'd have visibility to all the team's cloud bills. Help optimize cost
• Train application teams on AWS features
• Present to executives on the progress and vision of cloud adoption of the company

Hardest part of the job:

• Pragmatic Design: When you study AWS, you play around in your account and have all the fancy services at your disposal. However, at any enterprise, only specific services will be approved. Even if I dreamed of creating a cloud-native and cutting-edge design, not all services were approved. For example, when I migrated an application to Lambda, Amazon API Gateway would have been a better fit. However, Verizon had licensing terms with Apigee at that point, and Verizon security did not approve the API Gateway. Hence I had to do a custom design to integrate Apigee with Lambda with Verizon security considerations in mind.

AWS General/Account SA

After spending 3 years as a Cloud Architect at Verizon, I joined as a Sr. Enterprise Account SA at AWS in Feb 2019. Typically you will be assigned one large customer or multiple smaller customers as a General SA. You will NOT handle customers outside of your assigned list. I joined AWS in the telecom vertical, given my telecom experience, and I was assigned a large telecom customer. General SAs are also called Account SAs because they are assigned to customer accounts.

Main responsibility - Help assigned customers on AWS projects. Obviously, you are thinking, what kind of help?

• Customer want to migrate applications from data center to AWS. Help determine migration strategy and drive the migration
• Customer is unsure whether to adopt AWS service X,Y, or Z which does similar things. Go over the differences, and pros/cons, and help them decide
• Customer wants to modernize their application on AWS to Service X. Create system design for it. Then show a PoC if needed
• Customer is facing challenges such as high scaling, high cost etc. Help them solve it
• Customer wants to skill up on certain services. Run training and immersion days where customer can try hands-on workshops for free
• Deal with technical teams as well as customer execs. Talk strategically to execs and talk technically to tech leads

Other responsibilities

• Write blogs
• Give feedback on services to the Specialist SAs/Service teams (more on this in the next section)
• Mentor other Amazonians
• Interviewing

Hardest part of the job

• Customers will always come to the Account SA assigned to them first for architectural guidance on ANY SERVICE. It's very hard to keep up with the wide range of AWS services at a deep level. I'd have days where one team would ask to discuss Kubernetes, and another team would ask deep questions on Ground Station! I ended up feeling like I was not able to help the customer in all the areas I wanted to. This is a great segue to the role I took next, Specialist SA at AWS.

AWS Specialist SA

Unlike General SAs, Specialist SAs (SSAs) are NOT assigned to a single large customer but to a wide range of customers in a domain. For example, one SSA can be assigned to financial services in the US, another SSA can be assigned to automobile customers in the US etc. Another important distinction is that, unlike General SAs, SSAs focus on a particular tech domain (e.g. Containers, Serverless, ML, Analytics etc.) and go super deep into it.

Remember what the hardest part of the General SA job was—keeping depth in a wide variety of areas. So, as a General SA, when you need help going deep on particular tech domains, you engage the Specialist SA assigned to the domain! For example, if a customer wants to talk deeper on Kubernetes running on Amazon EKS, and the General SA doesn't know it in depth, he/she will engage someone like me, a Containers/Serverless SSA.

Main Responsibilities:

• Work as Navy Seal. Tag team with Account SA, jump in to unblock the customer, then go help another customer
• Help customers with the AWS services he/she is a specialist in, on various areas - adoption, optimization, challenges, etc. For example, I recently helped a customer whose application on EKS was producing so many logs at a rapid pace that CloudWatch was not able to keep up. Hence I gave them couple solutions, and after some discussion they adopted one that solved the problem!
• Create system design of the customer applications using your tech domain. For example, if a customer is running a microservice on vanilla EC2, I will give them an equivalent microservice design on Kubernetes
• SSAs work closer with service teams than Account SAs. Since SSAs are working across many customers, they get better signals on what's working and what's lacking in that service. You are expected to give quality feedback to the service team and help shape the future roadmap
• Work with execs and technical teams
• Run training and immersion days with the customer on the specialized domain
• SSAs really need to scale their knowledge because it's hard to handle many customers. Writing blogs and workshops is one of the main goals for SSAs

Other responsibilities:

• Mentor other Amazonians
• As an SME, approve blog proposals and review the content that Account SAs are writing
• SSAs generally have more travel than Account SAs because our customers are spread all over
• Interviewing

Hardest part of the job

• The buck stops with you on your assigned tech! As an Account SA, you can always engage a SSA, but SSA can't pass it further. As a last resort, you can bring the service team members. But remember, service team time is THE most valuable, and they should be working on the service itself. Personally, as a Containers/Serverless SSA, keeping up to date with Kubernetes is hard, given so many CNCF tools are out there.

At the end of the day, I love being a Solutions Architect, help customers with their large and complex AWS projects, and also sharing the learnings with you all. Hopefully, this post gave you a realistic idea of SA roles and their activities. I wish you all the best on your SA journey 🙌🚀

If you have found this newsletter helpful, and want to support me 🙏:

Checkout my bestselling courses on AWS, System Design, Kubernetes, DevOps, and more: Max discounted links​

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement and more: https://www.sabootcamp.com/​

Keep learning and keep rocking 🚀,

Raj