Static Web Delivery on a Sports Platform

An anonymized sports-platform engagement used CloudFront and S3 for static web delivery, separately from its application and authentication paths.

[Overview] Static web delivery within a wider sports platform

Ampity's work on a sports management platform included a static web application delivered through CloudFront with S3 as its origin. Route 53 provided DNS resolution. This is a focused delivery view of the same anonymized engagement described in the registration and payment recovery case and the broader serverless sports-platform account.

The static path was one part of the platform, not a description of every request or content class. Its documented role was to deliver the web application's static assets. Application API requests and authentication had separate responsibilities.

[Context] Delivery and access concerns

The original account reports slow content delivery, event-driven demand peaks and concerns about direct storage access. It also identifies access to sensitive player documents as a concern. Those statements explain the reported problem context; they are not a measured latency baseline or a record of an unauthorized-access incident.

The distinction matters because the documented S3 origin serves a static web application. The technical appendix does not identify where player documents were stored, how a document request was routed or which access rule applied to it. The static delivery path cannot stand in for a documented private-document design.

[Design] Separate static, API and identity paths

The historical logical view shows the browser receiving static web assets through CloudFront with S3 as the origin. It shows browser API calls separately, through API Gateway to Lambda application logic. An identity server on EC2 handles authentication into the API layer. Route 53's documented role is DNS resolution.

These paths describe different platform responsibilities. The appendix does not connect the identity server directly to S3 or supply a complete content-retrieval token exchange. Nor does it identify the effective distribution, viewer or origin-access policies. No additional document-delivery topology is inferred here.

Certificate Manager, IAM, KMS and Secrets Manager also appear in the security inventory. The appendix explicitly states that how each service was applied is undocumented. Their presence is not evidence of particular permissions, transport settings or a completed security assessment.

Historical logical view of static web delivery. Route 53 supplies DNS separately; arrows identify the documented path, not a per-request sequence or specified cache behaviour. API and authentication paths are outside this view.

[Delivery] Part of the platform's release workflow

The wider engagement included a pipeline that automated build, deployment and infrastructure provisioning. That release scope is documented separately from the browser's static and API request paths.

The appendix does not identify a particular content version receipt, cache-invalidation history or viewer-access test. A pipeline's presence therefore does not establish how a specific content update reached a reader or whether a restricted document was accessible to the intended audience.

[Results boundary] What this account establishes

The supported historical scope is a CloudFront and S3 static web application path within the wider sports-platform engagement, with DNS, API and identity responsibilities documented separately. The available material does not establish a measured delivery-speed or release-time improvement, uninterrupted availability, end-to-end transport security or effective access to sensitive documents.

That is the boundary of this focused case. The related platform accounts provide the wider customer journey and application context; they do not turn this static path into a separate engagement or supply the missing access results.

[Engineering takeaway] Classify the content before assessing its path

For a comparable platform, begin with an authorized read-only review of one sanitized item: its intended audience, serving route, applicable configuration revision and access rule. A public application asset and a restricted document need not share a delivery path. If the mapping or rule is missing, request it from its owner rather than conclude that access is allowed or denied. This is proposed guidance, not a test performed during the engagement, and it authorizes no retrieval, bypass attempt or configuration change.

Technical reference

The registration and payment recovery account describes the customer journey. The serverless sports-platform account covers the wider application, data, integration and delivery responsibilities of the same engagement.