The AWS server was fine, the credentials were fine, but the Subversion checkout was throwing 403s like clockwork.
When AWS access to SVN breaks, it’s rarely random. It’s permissions, network routing, or protocol mismatches. Version control over AWS can be stable for years, then collapse after a silent update or a rotated IAM key. The fix is methodical.
First, confirm the SVN repository URL. Many AWS-hosted SVN repos use HTTPS behind Amazon EC2 or S3-backed storage with reverse proxies. Outdated URLs break silently when endpoint DNS changes. Use svn info to check the active URL—verify it matches what aws s3 ls or your EC2 host configuration expects.
Next, audit AWS IAM policies. SVN over HTTP(S) via AWS often relies on IAM users with specific S3 or EBS access. If you use a federated login, ensure temporary credentials are valid. Review recent aws iam policy edits. Deny rules or expired permissions cause SVN read and write failures even when service health looks fine.
Then, inspect security groups and NACLs. If SVN sits on an EC2 instance, inbound rules must allow HTTP or HTTPS. Outbound rules must allow responses to the requesting client IP. One tightened ACL can block all commits.