Product owners, CTOs, & DevOps are responsible for ensuring product performance and resilience in the AWS cloud. This in turn can only be guaranteed when you are able to improve your products across the 3 pillars of security, reliability, and operational excellence. To enable this as a best practice, AWS wants you to conduct Foundational Technical Review (FTR) regularly and they mandate this as part of an Independent Software Vendor’s Partner Path in APN. Therefore doing FTR is akin to your car undergoing regular service checks to make sure the vehicle’s performance and resilience is good.

At VeUP, we have seen partners who aren’t running FTR for their product as a practice. Many aren’t aware of FTR and many though aware of FTR, never start it or complete it. Many others who are aware of the gaps do some remedial actions but it lacks a process-driven approach. In this article I will explain 10 reasons as to why product leaders & DevOps fail the AWS FTR process.

3 Strategic reasons of FTR failure at Leadership level

CTOs & product leaders are mostly responsible for the 3 strategic reasons as to why firms fail FTR. These reasons are:

• Cost Factor: Many partners start the FTR process but then not complete it after receiving the first report. They do not remediate and fix what they saw as gaps. The product leaders sees the costs aligned with doing the remediation and lose interest in completing the FTR.
• Time Factor: Many partners fail the FTR as they during the FTR believe the process will take too long or too much effort. If they got multi-account configuration and if they want cross-account access it can take time. Having dedicated account for Cloudtrail audit logs etc. takes time. Therefore they see no value in FTR because of the time they perceive they lose by implementing remediation.
• Talent Factor: Many partners got strong developers but lack AWS expertise. They have no AWS architects who understand essential AWS services such as CloudTrail. They were observed managing infrastructure in an ad hoc manner. Quite a few of them were seen applying on-premise knowledge onto cloud but that isn’t compatible with the way AWS works. All of these aspects causes gaps in expertise that leads to human-errors being caught as gaps in FTR.

4 Tactical Reasons of FTR failure at DevOps level

Along with understanding the strategic reasons, it is important product leaders & DevOps engineers are aware of the tactical reasons of FTR not being completed:

• Poor security practices: Some vendors may not have the necessary security controls in place to protect sensitive data and resources in the AWS environment. This can lead to data breaches, public S3 bucket access, and other security incidents. AWS looks to see if you are MFA-enabled, rotating credentials, have Network ACLs, security groups and additional AWS security services etc. and if you fail any of these, you will not meet the requirements of the FTR.
• Insufficient documentation and testing: Vendors may not have adequate documentation or testing procedures in place to ensure that their software is fully functional and compatible with the AWS environment. This can lead to bugs, errors, and other issues that may not be identified until after deployment. One of the ways AWS checks for this is by ensuring vendors do at least one Resiliency test that meets RTO and RPO requirements.
• Inadequate support: Vendors may not have the resources or expertise to provide adequate support for their software in the AWS environment, which can make it difficult for customers to troubleshoot and resolve issues. That is why AWS business support plan is highly recommended but if you don’t have the budget to pay for this support then you need to have a detailed action plan for managing incidents.
• Reactive Monitoring: Many AWS partners were observed to only monitor workloads and AWS services using CloudWatch and other tools when an issue is noticed. These partners didn’t automate, has ineffective usage of tags, don’t capture logs from diverse sources such as CloudTrail, applications, VPC, Database etc. It is important that DevOps monitor the key metrics around performance, security & cost, in a process-driven manner to meet AWS expectations of FTR.

3 atypical reasons behind FTR failure

Now, it’s rare for companies to fail an AWS FTR for truly “weird” reasons, as the review is focused on ensuring that companies are following best practices for security, networking, monitoring, scaling, and disaster recovery aligned with WAFR. However, some less common or unique reasons a company might fail an AWS FTR include:

• Not properly segregating development, staging, and production environments, which can lead to errors and security breaches.
• Not ensuring that all resources are properly tagged and organized, which can make it difficult to manage and optimize costs
• Financial processes around cost optimization is weak i.e. data duplication is seen, AWS Compute Optimizer isn’t used, lacklustre data lifecycle policies etc.

So in short, these 10 reasons must be understood clearly by AWS product leaders & DevOps teams. Like I said before, regularly doing FTR is like servicing your car, so your workloads and architecture are efficient, secure & well-optimized.