Becoming an Advanced Technology Partner or being included in an AWS Competency program are key achievements for AWS partners and distinguish them from their competitors in the market. Inclusion in these programs demonstrates a partner’s expertise across industry segments and technical domains, plus delivery of a solid product to their customers. The technical bar for becoming an APN Advanced partner or inclusion in an AWS Competency is high; partners must demonstrate both competency-relevant success and alignment with all four pillars of the AWS Well-Architected Framework. Join AWS Partner Solutions Architects as they outline what to expect from the process; describe how to best prepare for the conversation; and offer tips, tricks, and hints on how to get the most from the technical assessment process.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Scott Ward, Solutions Architect – AWS
November 29, 2016
Tips for Passing
APN Technical Validations
ISV Technical Track: GPSISV2

2. Why Should I Care?

3. Why Do We Do Technical Validations?
Reduce risk for joint customers
Verify alignment with a competency track
Build AWS confidence in the product or solution

4. Benefits of Technical Validation
Deeper AWS relationship
Finely-tuned architecture
Cost-effective architecture
New service visibility
A new perspective on your architecture
Competency inclusion or achieve advanced partner status

5. What Is a Technical Validation?
Validation that you, as a partner, know how to build
solid solutions using AWS best practices
This is not an audit!

6. What Is a Technical Validation?
This is all under NDA
Results are confidential

7. What are we looking for in a technical
validation?
Use of AWS best practices
Well Architected pillars
• Security
• Reliability
• Performance Efficiency
• Cost Optimization
• Operational Excellence
aws.amazon.com/archicture/well-architected

8. What Are We Looking For in a Technical
Validation?
Industry-specific requirements
How are you aligning to the specific technical requirements for your
industry/competency?
Do the solutions help customers in a specific area?

9. What Are We Looking For in a Technical
Validation?
Industry-specific requirements
Example #1:
Healthcare and life sciences
A reusable HIPAA pattern. You understand health care
specific requirements and you are not putting patient data
at risk.

10. What Are We Looking For in a Technical
Validation?
Industry-specific requirements
Example #2:
Security competency
Demonstrated understanding of AWS security best
practices. Use of AWS security services to help customers
have confidence in the AWS platform.

11. Tips for a Successful
Validation

12. Tips for a Successful Validation
Have a 15 minute kickoff talk with the SA and the PDM
Review what is going to happen in the validation
Discuss who should be involved in the validation
Ask clarifying questions

13. Tips for a Successful Validation
Detailed architecture diagram
More than this

14. Tips for a Successful Validation
Detailed architecture diagram
A little better

15. Tips for a Successful Validation
Detailed architecture diagram – Maybe something like this

16. Tips for a Successful Validation
People
Identify all the right technical resources for the
discussion
One or many people
Someone who can talk in-depth on the architecture
Have the right technical resources present

17. Tips for a Successful Validation
Be prepared to go deep
Our reference questions are just a starting point
We will be looking to go deeper based on “trigger words”

18. Tips for a Successful Validation
Understand what AWS services you use

19. Tips for a Successful Validation
Be prepared to speak to why you made the decisions
that you did

20. Tips for a Successful Validation
Budget time before, during, and after
Prep call (15-30 minutes)
Work to gather information (???)
Review call (3-4 hours, maybe more)
Follow up work and discussion (???)

21. Issues We See Regularly

22. Issues We See Regularly
Security
Not as much flexibility in this area
Can be the longest part of the review process
Be open and honest in your responses

23. Issues We See Regularly
Security
Protection of the root account
Too much IAM access
Everything in one account
Collection of access keys
Not enough log analysis

24. Issues We See Regularly
Reliability
Relying on manual processes
Workload profiling
DR planning and testing

25. Issues We See Regularly
Performance & Cost
Not keeping up with new services or enhancements
Not meeting with your account team (know new features,
program changes, etc.)

26. Cloud Service Management and Security
Security, cost, and asset management for public cloud users. Enterprisesneed a
web-based software application that allows them to view, understand, and secure their cloud environments.

27. CloudCheckr Architecture Review
• 4 hour technical review with Scott Ward
• Also sat through reviews for enterprise customers
• Covered everything from arch, security, reviewing access
from 3rd parties
• 10 pages of notes, 5 action items, 8 follow up items
• Pushing topics like retiring IAM access keys, cross AZ
What did we do?

28. CloudCheckr Architecture Review
• Approach review from positive perspective
• Unique experience to learn from insiders
• We needed to update the services we used in AWS
• Got some insights you don’t see “in the wild”
What did we learn?

29. Outcomes

30. Outcomes
What you don’t get
Official certification for the validation
A new design or architecture

31. Outcomes
Follow up questions
Full write up of your notes
Blockers
Suggested improvements
Confidence in your infrastructure
Mutually agreed-upon solution

32. Remember to complete
your evaluations!

33. Thank you!

34. Questions?