Traffic and compute spikes are different problems.
A product can have modest daily traffic while still needing serious bursts of CPU and memory during video processing.
VidShare Case Study
Practical AWS infrastructure for a media SaaS that needs both speed and sane costs
VidShare uses AWS in a way that fits an early product: the web app stays focused on users, video processing runs on its own path, and the overall system stays understandable for founders who need real capability without overbuilding.
- Web traffic and media processing are intentionally separated.
- ECS Fargate Spot handles bursty video jobs without permanent idle compute.
- One task per upload improves isolation, debugging, and operational clarity.
Architecture Snapshot
VidShare on AWS
Web App Tier
ALB + EC2 Auto Scaling keep user-facing traffic isolated from heavy video jobs.
User Requests
Upload Path
Files land in S3 first, creating a reliable handoff point.
Trigger Layer
Lambda reacts to events and starts processing without becoming the processor.
Processing Tier
Dedicated ECS Fargate Spot tasks run one upload at a time, then write results back to S3.
Burst Workloads
Storage
S3 Originals + Outputs
Deployments
CodePipeline Flow
Visibility
CloudWatch Logs
Early media SaaS has mixed workloads, not just traffic.
VidShare is a good example of why media products need a different conversation than a normal CRUD app. The web side has to stay responsive for sign-ins, dashboards, and uploads, while the processing side has to absorb unpredictable compute-heavy video jobs without dragging the whole product down.
Uploads should not compete with the web app.
If the same tier handles both, user experience and operational stability become harder to protect.
Founders still need something understandable.
The answer is not maximum complexity. It is a setup with clear boundaries, sane costs, and debuggable behavior.
Solution
How VidShare runs on AWS without turning into overbuilt infrastructure.
Web app stays isolated
The user-facing application lives on its own path so normal traffic is not dragged down by heavy media jobs.
Uploads go to S3
Original files are stored in S3 first, which creates a durable handoff point for the rest of the workflow.
Lambda triggers processing
Lambda reacts to the upload event and starts the job. It is the trigger, not the video processor.
ECS Fargate Spot handles video jobs
Each upload can get its own processing task, which is useful for isolation, retry behavior, and cost control.
Results go back to S3
Processed outputs return to S3 so playback, distribution, and downstream delivery can use the same storage base.
CloudWatch gives visibility
Logs and metrics make failures easier to trace, while deployment tooling stays understandable for a small SaaS team.
Architecture Flow
A step-based flow that stays readable and operationally sane.
The point is not novelty. It is a reliable sequence with clear ownership at each step.
1
User Uploads
A creator uploads video through the web app without tying up the main application servers.
2
Stored in S3
The original media lands in S3 first so storage stays durable and separate from the web tier.
3
Lambda Trigger
A Lambda event reacts to the upload and starts the next processing step instead of doing heavy work itself.
4
ECS Spot Task Runs
A dedicated Fargate Spot task handles the actual video job, giving each upload its own isolated worker.
5
Processed Output Saved
Completed renditions and derived assets are written back to S3 for downstream use and playback.
6
Logs / Deployment Visibility
CloudWatch plus straightforward deployment tooling keeps failures visible and operations understandable.
Principles
Three practical rules behind the architecture.
Split web and processing
The customer-facing app stays responsive because uploads and background media jobs are handled on separate paths.
Use spot compute for bursty jobs
Video workloads arrive unevenly, so spot-backed tasks help control cost without forcing permanent idle capacity.
Keep infrastructure simple early
This setup covers real operational needs without introducing unnecessary orchestration or platform theater too soon.
AWS Stack
A compact stack for an early-stage media product.
Each piece has a job. Together they support uploads, processing, deployments, and visibility without pretending the product needs an enormous platform team.
ALB
Routes web traffic cleanly into the application tier.
EC2 Auto Scaling
Keeps the main app tier stable as normal traffic changes.
Lambda
Acts as the event trigger between upload and processing.
ECS Fargate Spot
Runs isolated video jobs only when compute is actually needed.
S3
Stores original uploads and processed output in one durable place.
CodePipeline
Keeps deployments structured and understandable for a small team.
CloudWatch
Provides logs, metrics, and operational visibility.
Secrets Manager
Keeps application and integration secrets out of code and instances.
AWS Credits
Roughly $1,000 in AWS credits can meaningfully change the early math.
For a founder still proving product-market fit, credits at that level can materially help cover experimentation, deployments, storage, and early infrastructure decisions. That does not remove the need for discipline, but it can create breathing room to build sooner and learn faster.
Need AWS infrastructure that fits the stage your SaaS is actually in?
Custom PHP Design builds practical Laravel and AWS systems for products that need to ship, process real workloads, and stay understandable after launch. If your app has mixed workloads like VidShare, we can map out a version that is credible, scalable, and founder-friendly.