Contents
Our client, an e-commerce fulfillment company that combines inventory management software with physical warehouse operations, set a goal: become an official partner of Amazon. In practice, this meant passing Amazon’s security review and gaining access to the Selling Partner API.
This approval carried significant weight. Without it, every time Amazon’s data was needed, it was necessary to ask for it manually. With approval, their systems could connect directly to Amazon, with no delays, no manual requests, and no other workarounds.
And beyond the technical benefits, the partnership with Amazon could build trust with our client’s customers. If Amazon trusted the platform, customers would too.
But the process of getting that coveted access to the API never got that far.
The questionnaire went out and then came back rejected. Then rejected again. There were no specific comments and no hints about what was wrong from Amazon. The only thing that was clear was that something fundamental wasn’t meeting the bar. The client’s platform itself wasn’t built in a way that Amazon could confidently approve.
That’s when this team reached out to us.
Where It All Started
Originally, the entire setup of our client was based on DigitalOcean. And it was indeed a good choice at the beginning—simple to manage and easier on the budget than AWS.
Yet, it also meant the platform wasn’t operating inside Amazon’s ecosystem. In the context of Amazon’s review, being hosted outside their cloud environment doesn’t really assist with the review.
Just as importantly, there wasn’t a modern DevOps workflow behind our client’s platform, and their infrastructure heavily relied on manual configurations, which also didn’t make it easy to earn Amazon’s trust.
Here’s how the platform was initially set up:
- No dev/staging separation. Since there was a single environment in place, development changes were applied directly to the live system. This made it difficult to test changes safely and increased the risk of issues reaching production.
- Manual deployments. A release involved a long sequence of human steps—build, package, upload, verify. If one step failed, the deployment could break, and rollback wasn’t a simple process either.
- No rapid environment provisioning capabilities. Spinning up a fresh environment wasn’t a button-click operation but days (sometimes weeks) of manual server setup and configuration.
- Secrets managed locally. This made access harder to control and harder to audit.
- Little to no observability. Monitoring, logging, and alerting weren’t in place, so performance issues and errors were basically invisible until they became impossible to ignore.
Actually, none of this is rare. A lot of SaaS and e-commerce teams grow this way: build fast. And as long as the platform works, the need to redesign it never feels urgent.
Amazon’s security review changed that.
A Review Designed to Expose Weaknesses
The Amazon Selling Partner API, often referred to as SP-API, is Amazon’s official interface for approved partners to programmatically access operational data. It allows companies to work directly with orders, inventory, shipments, reports, and other marketplace data.
Amazon documents the API itself openly. The technical capabilities, endpoints, and onboarding steps are all described in their public documentation.
What’s less clearly documented is what it takes to be approved to use it.
Access to the Selling Partner API isn’t granted automatically. Companies must register as developers, request specific access roles, and, if these roles involve sensitive or restricted data, pass a compliance review. This review typically comes in the form of a detailed questionnaire covering how the platform is built and operated in real life.
Choosing to Fix the Foundation, Not Just Pass the Test
So, the repeated rejections from Amazon were a symptom of underlying infrastructure and process issues. Although our client’s platform worked, it wasn’t structured in a way that made the review easy to pass.
As we started examining our client’s setup, we understood that trying to pass the review without changing the underlying reality would only lead to the same result again. We simply couldn’t convincingly describe security controls and other practices that don’t exist.
So, we focused on what Amazon was actually testing for and made a decision to prepare properly.
Rebuilding the Platform: Decisions That Actually Moved the Needle
Once our team determined the direction, here’s what we eventually did.
Migrating the Platform from DigitalOcean to AWS
Migrating to AWS was about alignment. Running inside Amazon’s own cloud environment made it much easier to meet their expectations around networking, security controls, and infrastructure design.
At the same time, we were careful not to turn this into an uncontrolled cost increase. The migration was planned with cost optimization in mind.
Separating Environments
We introduced separate environments: development, staging, and production. Developers finally had space to test ideas, and releases became more deliberate.
Replacing Manual Deployments with Automation
As we previously mentioned, deployments used to rely on people following checklists. And while those checklists were well-intentioned, they were still fragile.
We implemented a CI/CD pipeline. Code changes went to the designated Git repository, and deployments followed automatically. The same steps, every time.
Our team also added automated testing, secret scanning, and vulnerability checks directly into this pipeline.
Introducing Kubernetes and Aurora Serverless
We replaced manual server management with Kubernetes, making it possible to create new, isolated environments quickly.
At the same time, we introduced Amazon Aurora Serverless, which scales automatically with demand and keeps the database available and responsive.
Locking Down Access and Fixing Secret Management
To make security the default state, we configured private networking with controlled entry points, tightened access using Kubernetes role-based access control (RBAC), and centralized secrets in AWS Secrets Manager.
Just as important, there’s no need for manually redeploying apps when modifying secrets
Finally Seeing How the System Is Performing
Our team added monitoring, logging, and alerting solutions to detect issues as early as possible. Alerts are now routed directly to the team.
Accelerating the Work with AMIX
What significantly shortened the path forward was the use of AMIX, our pre-configured infrastructure setup.
It let us avoid assembling the setup from scratch, choosing tools, wiring them together, and fixing edge cases along the way. We started with a solid baseline, which covered a large portion of the foundational work upfront: infrastructure as code, Kubernetes setup, CI/CD, secret management, monitoring, and more.
Navigating the Amazon Questionnaire. Together
Amazon, as expected, didn’t make the review easy. There were no instructions, no examples to follow, and no hints about what would be considered “enough.”
Our engineers were deeply involved in shaping every response and used their logic and experience during the process.
After the first submission, follow-up questions came in. Then more. Our engineers went back to the system when needed, validating configurations, checking workflows, and refining responses so that every answer stayed grounded in what was actually implemented.
The back-and-forth continued through several rounds.
Eventually, the confirmation came through.
The questionnaire was approved, and the client gained access to the Amazon Selling Partner API.
Results: What Changed After Approval
With direct access to the Amazon Selling Partner API, our client’s team no longer has to rely on manual data requests or any other workarounds. Their systems can finally connect to Amazon directly.
And while the approval itself is an important milestone, the teamwork began to change.
With separate environments and automated pipelines in place, new features can be developed, tested, and rolled out much faster. The new infrastructure can also scale with demand and do it in a cost-effective way.
Finally, customer trust improved as a result of all this. Fewer incidents, faster issue detection, and more reliable performance translated into a smoother user experience.
A Platform Ready for What’s Next
The original goal was to gain approval, unlock the API, and move forward. But along the way, it became clear that certification exposed what needed to change and created the right pressure to change it properly.
Today, the platform is in a very different place. It’s secure by design, automated, and flexible enough to grow without constantly reworking its foundations.
If you’re facing a security review, an audit, or any kind of compliance challenge, you don’t have to navigate it alone. IT Outposts has been through this process, and we can assist you with passing the review, as well as building a platform that doesn’t fear the next one. Contact us!
I am an IT professional with over 10 years of experience. My career trajectory is closely tied to strategic business development, sales expansion, and the structuring of marketing strategies.
Throughout my journey, I have successfully executed and applied numerous strategic approaches that have driven business growth and fortified competitive positions. An integral part of my experience lies in effective business process management, which, in turn, facilitated the adept coordination of cross-functional teams and the attainment of remarkable outcomes.
I take pride in my contributions to the IT sector’s advancement and look forward to exchanging experiences and ideas with professionals who share my passion for innovation and success.