Amazon Lightsail is the clearest AWS path for a single self-managed Next.js server. It reduces the number of AWS services required for the first deployment while keeping a path into the wider AWS ecosystem. This simplicity is also the boundary: an EC2, ECS, or serverless design needs a separate guide.
Select an OS-only blueprint
Choose a maintained Linux OS blueprint so the application stack remains explicit. A prepackaged application blueprint can introduce a web server, runtime, directory layout, or update process that conflicts with the intended Next.js deployment. Select a bundle from measured memory and CPU needs; 1 GB is a constrained starting point for builds and image processing, even when it can serve a small prebuilt application.
Bundle transfer allowances vary by Region. Confirm the target Region and current allowance rather than copying a US figure into every estimate. Place databases and storage with the application when latency and transfer costs matter.
Stabilize the address before DNS
Lightsail’s default public IPv4 changes after stopping and restarting the instance. Create a same-Region static IP and attach it before creating the A record. Static IPv6 is not supported, so an AAAA record can require maintenance after resource replacement or IPv6 changes.
Lightsail exposes separate IPv4 and IPv6 firewalls. Review both when dual stack is enabled. Open only HTTP and HTTPS publicly, restrict SSH where feasible, and do not expose the private Next.js listener.
Build recovery beyond snapshots
Use snapshots as one server-recovery input, not the whole backup plan. Databases, object storage, DNS, certificates, and secrets can live outside the instance. Record how each is restored and test that process.
For release validation, create a candidate instance or restore point, test the production hostname and critical routes, then move the static IP or DNS only after health checks pass. Preserve the previous compatible release through the rollback window.