Amplify

Services

The decision worth arguing about

The non-obvious decision is how OAuth token custody works, and it matters more than anything else in this system because token expiry is the number one cause of a social tool silently failing. Meta's long-lived page tokens last around sixty days and must be refreshed by use; LinkedIn's refresh tokens have their own lifetime; a password change, a revoked app permission or an admin removing someone from a Facebook Page can invalidate a connection at any moment. The failure mode is the dangerous part: nothing breaks visibly until the morning a campaign was supposed to go out, and then a week of scheduled posts fails at once. So tokens live in Secrets Manager, never in Postgres, with a rotation schedule per connection, and a daily health job that calls a cheap read endpoint on every connection purely to verify the credential still works — alerting the named account owner fourteen days before a known expiry and immediately on an unexpected revocation. The trade-off is genuine and worth stating: that health check consumes calls from the same rate-limit budget the publisher uses, and on a platform with a tight per-application quota those calls are not free. So it runs once a day at the account's lowest-traffic hour rather than continuously, which means an unexpected revocation can go undetected for up to twenty-four hours. We chose a twenty-four-hour detection window over spending scarce quota, and we made the window a configuration value so a customer publishing time-critical content can pay the quota to shorten it. The related design point is that the rate-limit token bucket in Redis is keyed by platform application, not by social account, because Meta and LinkedIn meter per app — a naive per-account bucket lets forty accounts collectively blow through one app-level quota while every individual bucket still looks healthy. MediaConvert handles per-platform video renditions, which is one of the few places AWS has a clearly better managed answer than Azure.

Services

The decision worth arguing about

The token-custody design ports directly to Key Vault, so the Azure-specific decision is elsewhere: video. Azure Media Services was retired in mid-2024 and Azure has no general-purpose managed transcoder to replace it, while AWS has MediaConvert sitting right there. Every platform has its own video constraints — aspect ratios, maximum durations, codec and bitrate ceilings, cover-frame requirements — so a single source video routinely needs five or six renditions before it can be submitted anywhere. On Azure that means running FFmpeg ourselves as a Container Apps Job, and it is the one part of Amplify where the two clouds diverge in real engineering effort rather than in configuration. The trade-offs we take: transcoding runs on CPU rather than GPU, because a GPU-enabled workload profile costs more per month sitting idle than the entire rest of this deployment and the reference org uploads perhaps forty videos a month; a three-minute 4K source therefore takes several minutes per rendition rather than seconds, so the composer marks media as pending and lets the user carry on scheduling rather than blocking on the encode. We also pin the FFmpeg version in the job image and treat an upgrade as a change requiring a re-render of a reference set, because codec defaults shift between releases and a silently changed bitrate on a LinkedIn video is the kind of thing nobody notices for three months. The upside of owning the pipeline is that when a platform changes its spec — and they do, without much notice — the fix is a parameter change in a job template rather than waiting for a managed service to add a preset.