Watch now
September 2021
3 min. read

Artifakt becomes an AWS ISV Partner

aws isv

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!

Also on our blog

PlatformCon 2022 recap, from a public PaaS PoV
In June 2022 we joined PlatformCon, the first virtual event around the very core of our product vision: “Platforms”. In this blog post, we will share our recap of the most impactful talks for a public PaaS like Artifakt.
Djalal Elbe
01 July
8 min. read
[🇫🇷 FR] PaaS vs IaaS vs SaaS — différences, avantages et limites
Contrairement à l’hébergement traditionnel, les solutions IaaS, PaaS et SaaS offrent différents niveaux d'autonomie et de contrôle pour répondre à tous les enjeux business. Cependant, choisir entre les trois modèles peut être assez complexe.
Djalal Elbe
16 June
6 min. read
5 deciding factors when choosing a PaaS
The PaaS ecosystem is so vast, with dozens of opinionated platforms on how to run code in production. It’s very hard to pick the right platform on the first attempt. So here we lay down for you the 5 important questions that separate future-proof PaaS from the rest.
Djalal Elbe
25 May
5 min. read
Stay up to date and join the mailing list to get the newest articles!