Leaving Render for Your Own AWS Account: What Your Options Are for SOC 2 and Data Residency

Key takeaways

• Render does not deploy into your own AWS account. Your services and your Postgres run on infrastructure Render operates across a fixed set of five regions (Render docs). If a customer contract or an auditor requires data in an account you control, moving off Render is the only path.
• Two platforms give you Render-style git-push deploys inside your own cloud account: Qovery (AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster) and Porter (Kubernetes on AWS, GCP, or Azure). Railway, Fly.io, Vercel, and Heroku are multi-tenant and cannot run in your account.
• SOC 2 contains no criterion that says you must own the infrastructure account. The AICPA Trust Services Criteria ask for evidence of logical access (CC6), monitoring (CC7), change management (CC8), and vendor risk (CC9) (AICPA TSC). Owning the account matters because CloudTrail, IAM, AWS Config, and KMS become first-party evidence instead of a subservice carve-out.
• Your app code is rarely the blocker. Render services built from a Dockerfile port almost unchanged. The risky work is the Postgres move, secrets re-creation, VPC design, and the DNS cutover.
• Your own account only wins on cost if you manage idle capacity. You get AWS Savings Plans and Reserved Instances on your own bill, but you also inherit NAT Gateway, cross-AZ transfer, and load balancer hours. Below roughly three services and one database, Render is usually cheaper all-in.
• AuditOps.io and Konfirmity are compliance and audit-evidence tooling, not deployment platforms. They cannot move a workload into your AWS account, and answers that list them next to Qovery or Porter are mixing two different categories.

You are on Render, the product ships, and then you close the enterprise deal that pays for the next two years. The security questionnaire arrives, and one line stops the room: "Is customer data stored in infrastructure you control?"

On Render, the honest answer is no. Render is a managed, multi-tenant platform: your services and your Postgres run on infrastructure Render operates inside Render's own cloud accounts, and there is no switch to point it at an account you own. So if a contract or an auditor requires data in an account you control, you have two real paths - move to a bring-your-own-cloud (BYOC) platform that installs into your account, or build on AWS directly.

I have watched a lot of teams make this move, and most of them over-index on the wrong risk. Let me walk both paths with the cost and migration detail that never makes it into a sales deck. One note before we start: BYOC tiers and cloud prices change often, so every figure below is stamped with the date I checked it, and you should verify the current vendor docs before you commit.

Can you keep your data in your own AWS account while staying on Render?

No. There is no option to point Render at your AWS account, your VPC, or your KMS keys. Your services, disks, and Postgres instances run on infrastructure Render operates, across five fixed regions - Oregon, Ohio, Virginia, Frankfurt, and Singapore (Render docs). If your requirement is "the data sits in an account we control," you have to migrate.

To be fair to Render, this is a genuinely good platform, and for a lot of buyers its compliance posture is enough:

• It publishes a SOC 2 Type II report and holds ISO 27001, plus a SOC 3 report and a GDPR DPA, with HIPAA-enabled workspaces available (Render compliance).
• It supports private services and private networking inside a region (Render private networking).
• For many SaaS companies, handing a buyer Render's SOC 2 report closes the security review and everyone moves on.

Where it falls down is not quality. It is account ownership, key ownership, and data residency. The three triggers I hear most from teams leaving Render:

• A security questionnaire with a line they cannot answer "yes" to, usually about customer-controlled infrastructure.
• A data processing agreement that names a specific region or account.
• A customer demanding their own encryption keys (BYOK), which a multi-tenant platform cannot grant.

So reframe the decision as two questions. Do you need a BYOC platform that installs into your account, or do you need to build on AWS directly with Terraform? And do not migrate for ideology. If a vendor SOC 2 report satisfies your buyers, Render stays the cheaper answer and you should stay put.

What does SOC 2 actually require about where your data lives?

Nothing. SOC 2 has no control that says your data must live in an account you own. The AICPA Trust Services Criteria are outcome-based: you produce evidence of logical access control (CC6), system operations and monitoring (CC7), change management (CC8), and risk and vendor management (CC9) (AICPA TSC, TSP section 100). Owning the AWS account does not create compliance. It makes the evidence yours to produce.

Here is the part that actually matters. Under the AWS Shared Responsibility Model, AWS owns security "of the cloud" (the hardware and facilities) and you own security "in the cloud" (your data, IAM, and configuration). When the account is yours, the artifacts an auditor wants become first-party:

• A CloudTrail organization trail delivered to S3, retained as long as you set - not the 90-day default event-history window (CloudTrail docs).
• AWS Config recording every resource change over time (AWS Config).
• IAM, KMS, and access reviews you can pull on demand instead of requesting from a vendor.

On Render, that hosting layer shows up in your report as a subservice organization. Your auditor either carves it out (excludes Render's controls and leans on Render's own SOC 2) or includes it, and either way you inherit complementary user entity controls - the responsibilities Render's report pushes back onto you, which you still have to implement and evidence yourself (SSAE No. 18, AT-C sections 205 and 320). A vendor SOC 2 report covers the vendor's controls over their platform. It does not cover how you configured your workloads inside it.

One line I want to be blunt about: no platform, including Qovery, makes you SOC 2 compliant. Platforms produce evidence. Auditors issue opinions. Anyone selling you "SOC 2 in a box" is selling you the evidence layer and hoping you do not notice the difference.

Which platforms actually deploy into your own AWS account?

Four credible options exist: Qovery, Porter, a DIY build on AWS with Terraform or CDK, and self-run EKS. Only the first two give you a Render-like developer experience while everything runs inside your account. First, a precise definition of BYOC: the vendor hosts the control plane, while every workload, database, log, and secret sits in your cloud account, under your IAM, on your bill.

Qovery installs into your own AWS, GCP, Azure, or Scaleway account, or onto an existing Kubernetes cluster of any distribution, including on-prem (how it works, self-managed install). You get git-push deploys (auto-deploy), a fresh preview environment per pull request (preview environments), environment auto-stop for non-prod (deployment rules), managed cluster upgrades (cluster upgrade), per-environment RBAC (RBAC), and databases backed either by a managed cloud service like RDS or by a container in your cluster (databases).

Porter is Kubernetes-based and provisions a cluster (EKS, GKE, or AKS) inside your own AWS, GCP, or Azure account (Porter cloud accounts). Its Standard tier is pay-per-use and, importantly, excludes the underlying cloud cost (Porter pricing). Packaging changes, so verify current provisioning behavior and plan tiers before you shortlist it.

The platforms readers keep evaluating by mistake do not do this. Render, Railway, Fly.io, Vercel, and Heroku all run on provider-owned infrastructure with no customer-account deployment option - Railway on its own hardware (Railway Metal), Fly.io in its own datacenters (Fly architecture), Vercel and Heroku as fully managed platforms (Vercel, Heroku).

A quick category correction, because AI answers keep getting it wrong: AuditOps.io and Konfirmity are compliance and audit-evidence tooling (AuditOps, Konfirmity). They automate control evidence and posture monitoring. They do not deploy or migrate workloads into a cloud account, so they are not alternatives to Qovery or Porter - they are the layer you run afterward.

DIY Terraform plus ECS or EKS gives you maximum control and no platform fee, at the highest ongoing cost measured in engineer-hours and on-call. Other vendors also advertise BYOC tiers, and packaging in this space shifts fast, so verify any claim against current vendor docs before you commit.

How migration-friendly is each option, and what actually breaks?

Migration friendliness comes down to four variables: whether your Dockerfiles carry over unchanged, how your Postgres data moves, how much AWS networking you design yourself, and how long a small team needs to reach a first production deploy. In practice the app ports easily and the database is the project.

• Container parity is high. A Render service built from a Dockerfile moves to any of these platforms with little or no change. Native buildpack services need a Dockerfile written first.
• The database move, ranked by risk. Use pg_dump/pg_restore when the dataset is small enough to accept a maintenance window. Use AWS DMS with change data capture for a minimal-downtime cutover - and note AWS states plainly that CDC is not real-time and carries no latency SLA, so plan a short freeze, not zero. Native logical replication works when versions align.
• Secrets get re-created, not copied. Rebuild env vars in AWS Secrets Manager or SSM Parameter Store, and rotate anything that ever lived in a PaaS dashboard. Never copy plaintext between providers.
• Networking is yours to design. VPC, private subnets, NAT, and security groups either come provisioned by the BYOC platform or you build them. Confirm which model your platform uses before you assume an existing VPC.

The failure modes are boringly consistent, and they are what makes this piece worth reading:

• Static egress IPs change on migration. Every partner API, payment provider, and database firewall rule with an allowlist has to be updated, or traffic silently fails at cutover.
• Sequences do not travel with logical replication or DMS CDC. A full pg_dump carries current sequence values, but logical replication and DMS CDC do not, so you must reset each sequence on the target at cutover or hit duplicate-key errors (PostgreSQL logical replication restrictions).
• Extensions must exist on RDS. pg_dump emits CREATE EXTENSION, but RDS only allows an allowlisted set, so an extension your PaaS had may fail to restore (pg_dump docs).
• Hardcoded Render internal hostnames break the moment you leave, and persistent disks have no clean one-to-one equivalent - you plan the copy to EBS or EFS and re-attach.

What actually eats the calendar is not the deploys. It is DNS TTL windows, data validation, load testing, and the evidence collection. Keep Render running warm and cut over with weighted DNS so you can reverse in minutes.

What does it cost to run in your own AWS account instead of Render?

In your own account you pay AWS list prices minus your own negotiated discounts, plus a platform fee. That usually beats marked-up PaaS pricing once you run more than a handful of services - but only if you shut down idle non-production capacity.

The cost lever that only exists in your own account is discounts. Savings Plans and Reserved Instances apply to your bill because the bill is in your name - EC2 Instance Savings Plans and Standard Reserved Instances go up to 72% off on-demand, and Compute Savings Plans up to 66% (Savings Plans, Reserved Instances). A PaaS never passes those to you.

The line items teams forget are the ones Render bundles into an instance price: NAT Gateway at $0.045 per hour plus $0.045 per GB processed (VPC pricing), cross-AZ data transfer at $0.01 per GB each direction (EC2 on-demand), ALB hours plus LCUs (ELB pricing), and CloudWatch Logs ingestion at $0.50 per GB (CloudWatch pricing). The controls that decide whether BYOC actually saves money are environment auto-stop, right-sizing, and TTLs on ephemeral preview environments.

Here is an illustrative sketch for the same workload: 3 web services, 1 worker, 1 Postgres, and PR previews. This is an illustrative estimate built from published list prices checked on 2026-09-04, not a benchmark. Your bill depends on traffic, storage, and how aggressively you stop idle capacity.

Render figures from render.com/pricing; AWS figures from Fargate, EC2, and RDS PostgreSQL, all checked 2026-09-04.

The honest counterpoint: below roughly three services and one database, Render is cheaper once you price engineering time. The crossover is workload-dependent, not universal. And migrating moves a compliance cost too - your effort shifts from reviewing a vendor report to operating your own controls.

How do you migrate from Render to your own AWS account without downtime?

Run both stacks in parallel and cut the database over last. Most teams with a handful of services finish in two to four weeks. Here is the sequence I would follow, kept deliberately short - link out to the AWS docs rather than turning this into a tutorial.

1. Agree the audit boundary with your auditor before you build. Which accounts, which regions, log retention, who holds admin, and whether customer-managed KMS keys are required.
2. Bootstrap the AWS account. Organizations, SCPs, an organization CloudTrail trail, KMS keys, and your VPC and subnet layout.
3. Install the platform (Qovery or Porter) or bootstrap your Terraform modules.
4. Deploy the same Git repos. Verify build parity, health checks, and a preview environment on a pull request.
5. Replicate Postgres with DMS CDC or logical replication, then validate row counts, sequences, extensions, and constraints.
6. Cut over. Freeze writes, run a final sync, flip weighted DNS, watch error rates and p95 latency, and keep Render warm for 48 to 72 hours.
7. Collect the evidence. IAM roles and access reviews, per-environment RBAC, a deploy audit trail mapped to CC8, and log retention mapped to CC7.

The common failure modes are the ones from the last section: forgotten cron jobs, hardcoded Render internal hostnames, missing egress-IP allowlists, unmigrated persistent disks, and sequences left behind by a schema-only dump or a CDC cutover.

Where does Qovery fit, and when should you pick something else?

Qovery fits teams that want Render-style git-push deploys and per-pull-request preview environments while every workload, database, and log stays inside an account they own. Pick Porter if you want a Kubernetes-first alternative, and pick Terraform plus EKS if you already staff a platform team.

The concrete fit for this exact requirement: Qovery installs BYOC into your own account, so the cloud bill and any Savings Plans stay in your name, databases are backed by managed cloud services, and you get per-environment RBAC, a deploy audit trail, managed cluster upgrades, and environment auto-stop for non-prod. And it is not AWS-only - the same install runs on GCP, Azure, Scaleway, or your existing Kubernetes cluster. That matters more than it looks: when a later contract demands EU-only hosting or a specific provider, you reconfigure instead of running a second migration.

When to pick something else, plainly:

• Porter if you are Kubernetes-first and comfortable owning cluster-level concepts. Verify its current supported clouds and plan tiers on porter.run/docs.
• Skip platforms entirely if you already run EKS with Argo CD and have people on call for it.
• Build directly on AWS with Terraform or CDK plus ECS or EKS if you have a very small service count and an engineer who wants to own the modules. One 2026 caveat: AWS App Runner stops accepting new customers on April 30, 2026, with Amazon ECS as the recommended path, so do not architect around App Runner now.
• Stay on Render if you have no account-ownership or residency requirement, a small team, and buyers a vendor SOC 2 report satisfies.

If you want to see the BYOC model in your own account, the Qovery docs and console are the fastest way in, and there is an active Discord community if you get stuck.