After years of working with Amazon Web Services (AWS), we are proud to announce that we are now officially an AWS Independent Software Vendor (ISV) Partner! We have deployed hundreds of environments on AWS and dedicated weeks to improving our solution in order to present the best PaaS solution possible. 

Now it’s time to celebrate and officialize this long-term collaboration together!

Artifakt joining the AWS Partner Network (APN) involves some pre-flight checks on the AWS side to guarantee the candidate meets all the requirements. Following a particular process helped us a lot to complete this task. Let’s have a look at the Artifakt journey to becoming one of the first AWS ISV Partner in France.

The process

In order to achieve the ISV Partner status, the typical process is to contact AWS and they will schedule a call with you to conduct a Foundational Technical Review (FTR). But most of the time you have to deal with some unexpected issues. Maybe the decisions you took a few months back were not scalable or secure enough to guarantee the high level of excellence required by the program.

To prepare ourselves, we decided to begin with the AWS Well-Architected Tool to have a better view of our architecture. The framework has 5 pillars: security, reliability, performance, operational excellence, and cost optimization. In order to check all the boxes, we needed to go through our own architecture and see if we had made the right decisions.

During this review, we realized that two important points were missing:

• The audibility of our AWS accounts was not properly configured. We had audit logs on the Artifakt platform, and we had configured some parts of our AWS services, but not for all of them. We configured AWS CloudTrail to catch all the events for all of our accounts in all the regions. Logs were then scanned to identify unusual activities and, finally, we store them on an isolated S3 bucket allowing write-only access.
• Our Disaster Recovery (DR) plan was not complete. Because we manage production for our customers, creating a DR plan was very important for us, but we focused too much on the technical aspect of the plan, and not enough on the compliance part. Properly defining Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) was still a work in progress. Now we can tell our customers with confidence what our RPO and RTO is, depending on their subscription and plan.

We did it!

After scheduling a review with an AWS Partner Solution Architect, we finally had this full review. We were proud to present what we did, how we achieved to build our platform, and how we plan to go beyond the requirements of the FTR.

And so we passed the Foundational Technical Requirements with flying colors! 

It was an interesting exercise, and we learned a lot from the official AWS recommendations. The discussion we had during the assessment was far beyond the required level of the FTR, but our auditor gave us good advice for improving some parts of our architecture, especially on leveraging some AWS services instead of managing them into our code. Finally, the auditor told us that we had achieved an excellent level of quality and compliance. Hearing that is a great reward for Artrifakt—deploying platforms in the cloud is our mission and we need to guarantee a level of excellence for our customers and partners.

Tips and tricks

As I mentioned before, we learned a lot during this assessment and I would like to share some tips that can help you with your journey to pass an FTR, or just harden your best practices.

• Use the AWS Well-Architected Tool. Anyone running a workload on AWS can benefit from this tool. It’s a great tool to identify attention points and weaknesses in your setup. It’s a free self-service tool and you can conduct the review directly in the AWS console. 
• You can also select different lenses on this tool—they highly depend on your business and what you want to achieve. They will give you more checks and points to verify.
• There is a specific list and lens for passing the FTR. Make sure you have a good look at all the items on the checklist and that you fulfill all requirements. Theoretically, if you succeed in building an AWS Well-Architected architecture, it shouldn’t be too difficult to validate these points as well. During the FTR, the Solution Architect will ask you related questions, and you should be able to produce evidence with your answers.

Last but not least, my personal advice is to invest time in creating a good, accurate, and complete architecture diagram. This will help you to have a better understanding of your architecture and will help the auditor to have a visual representation of what you’re talking about.

I hope this quick list is proven useful for you and your team and I wish you good luck in your AWS FTR journey! 

If you’re interested in partnering with Artifakt, check out our Partner Program and reach out to us!