Amazon Lightsail makes it quick to launch a WordPress site, a web app or a small server, and that speed means the customer-side security settings, firewall rules, SSH keys, console access, snapshots and DNS, need a deliberate pass soon after launch. Lightsail bundles compute, storage, networking and DNS behind a simplified console, and AWS documents clear controls for each: per-instance IPv4 and IPv6 firewalls, key pairs and browser-based SSH, IAM policies with tag conditions, automatic snapshots, managed certificates on load balancers and distributions, and DNS zones. This guide explains how each one works, which settings to change first, and how to keep a small hosting estate secure as it grows. It is for small businesses, agencies, developers and the AWS administrators who support them. Application hardening for WordPress itself is covered in the PHP and WordPress Security Guide and is not repeated here.
This is an independent guide from NHI Mgmt Group, based on AWS's public documentation for Amazon Lightsail as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.
Key takeaways
- Restrict SSH and RDP straight after launch. Most blueprints open port 22 to all source addresses by default; AWS recommends restricting SSH and RDP to specific addresses.
- The most permissive firewall rule wins. If two rules cover the same port, a rule open to everyone overrides a rule limited to your office address, so remove the open rule rather than adding a narrower one.
- Console access is server access. Browser-based SSH and RDP use a separate key pair from yours, so anyone with Lightsail console permissions can open a shell; control it with IAM and MFA.
- Protect and rotate private keys. Lightsail keeps only the public key on the instance; anyone holding the private key can connect, and the default key's private key can be downloaded from the Account page.
- Turn on automatic snapshots and keep manual copies. Lightsail keeps the latest seven daily automatic snapshots, and deleting an instance deletes its automatic snapshots, so copy important ones to manual snapshots.
How identity and access work in Amazon Lightsail
Lightsail has three access paths that need separate attention.
- The AWS account and Lightsail console or API: people sign in as the root user, an IAM user or an assumed role, and the Lightsail API (actions prefixed lightsail:) is controlled with identity-based IAM policies. AWS states that by default users can do nothing, recommends MFA, and strongly recommends not using the root user for everyday tasks.
- Instance access: SSH for Linux and Unix instances using key pairs, RDP for Windows instances using the administrator password, and browser-based SSH and RDP from the Lightsail console.
- Network exposure: the per-instance firewalls that decide which ports are reachable on the public IP address.
IAM policies for Lightsail
AWS's guidance is to start from AWS managed policies and move to customer managed policies scoped to your use cases, apply least privilege, add conditions, validate policies with IAM Access Analyzer and require MFA. Two points from the Lightsail policy examples shape practical design:
- Console users need broad access. AWS states that console users need full access to Lightsail actions and resources (lightsail:* on all resources), and that narrower policies can break the console. Users and automation that work only through the CLI or API can be limited to the actions they use.
- Tags scope who can create and delete. AWS's examples use aws:RequestTag to allow lightsail:Create* only when the request carries a given tag, aws:ResourceTag to allow lightsail:Delete* only on resources with that tag, and a Deny on lightsail:TagResource to stop people retagging protected resources.
Decision guidance: because console access implies wide Lightsail rights, the cleanest way to separate customers, environments or teams is a separate AWS account per workload, for example one account per client site for an agency, joined to AWS Organizations. Within a single account, keep the number of console users small and give automation narrow API-only policies with tag conditions. See the AWS Organizations and SCPs Guide.
Admin roles and privileged access
Account level
- Protect the root user with MFA, store its credentials offline and use it only for tasks that require it. The AWS Root Account Compromise Playbook describes how to respond if it is misused.
- Give each administrator an individual identity, ideally through IAM Identity Center or roles rather than long-lived IAM users with access keys. See the AWS Access Keys Security Guide.
- Agencies and freelancers supporting a client site should use their own named identity in the client's account, removed when the engagement ends, rather than shared root credentials.
Instance level
| Access method | How it works (AWS docs) | Security consideration | Recommended control |
|---|---|---|---|
| Default key pair | One per Region, created by Lightsail; private key downloadable at any time from the Account page | Anyone with that console access can retrieve it | Prefer custom or uploaded keys for Linux; restrict console access |
| Custom key pair | Generated by Lightsail; private key downloadable only at creation | The downloaded file is the only copy | Store in a password manager or vault straight away |
| Uploaded key | You upload the public key and keep the private key | Key generation and storage under your control | Use per-person keys; good for teams |
| Browser-based SSH and RDP | Uses a separate key pair from those configured on the instance | Works even if your keys are removed, so it is governed by console permissions | Limit console users; enforce MFA |
| Windows RDP | Windows instances always use the default key, whose private key decrypts the administrator password | Default key holders can obtain the password | Change the administrator password after first sign-in; restrict RDP |
One public key can be placed on many instances, so a single private key can reach all of them. Use per-person or per-site keys so you can remove one person's access without touching everyone else's. Public keys live in ~/.ssh/authorized_keys on Linux and Unix instances. AWS's rotation procedure is: add the new public key, test it, then delete the old line, and rotate when someone leaves, when a private key may be exposed, or when creating an instance from a snapshot of an instance whose key needs replacing. If you lose the private key, the browser-based SSH client lets you add a new one. See the SSH Key Management Guide and OpenSSH Server Hardening Guide.
Integrations, API tokens and service accounts
Small hosting estates still accumulate machine credentials, and each one needs an owner.
- Automation and CI/CD: deployment tools, backup scripts and monitoring that call the Lightsail API should use roles or short-lived credentials with API-only policies limited to the actions they need, rather than lightsail:*. Where access keys are unavoidable, rotate them and alert on their use from unexpected locations.
- Application secrets on instances: WordPress database passwords, SMTP credentials and plugin API keys sit on the instance and in every snapshot of it. Treat snapshots as containing those secrets, and rotate them after restoring a snapshot into a new environment.
- Plugins and third-party services: CDN, backup and security plugins often store API tokens. Record each one and the account it belongs to.
- DNS and certificate validation: certificates for Lightsail load balancers, distributions and container services are issued by AWS Certificate Manager and validated by adding a CNAME record to your DNS. Leave validation records in place for managed renewal, and remove those for retired domains.
Firewalls and network exposure
Each instance has two independent firewalls, one for IPv4 and one for IPv6, configured separately. They filter inbound traffic to the public IP address only, allow all outbound traffic, and contain allow rules only. Rules specify a protocol (TCP, UDP, ICMP or All), a port from 0 to 65535 and source addresses, which by default are all addresses. IPv4 sources can be a single address, a range or a CIDR block; IPv6 sources can be a single address or CIDR block. The console accepts up to 30 source addresses at a time and the API up to 60, applied separately to IPv4 and IPv6, so consolidate addresses into CIDR ranges.
| Blueprint type | Default inbound rules (all sources unless noted) | First change to make |
|---|---|---|
| Base OS (Amazon Linux, Ubuntu, Debian and others) | SSH 22, HTTP 80 | Restrict 22 to admin addresses; add 443 when TLS is configured |
| CMS (WordPress, Ghost, Joomla!, Drupal and others) | SSH 22, HTTP 80, HTTPS 443 | Restrict 22 to admin addresses |
| cPanel and WHM | SSH 22, DNS 53, HTTP 80, HTTPS 443, TCP 2078, 2083, 2087, 2089 | Restrict 22 and the control panel ports to admin addresses |
| Plesk | SSH 22, HTTP 80, HTTPS 443, TCP and UDP 53, TCP 8443, 8447 | Restrict 22, 8443 and 8447 to admin addresses |
| Windows Server 2016 to 2022, SQL Server Express | SSH 22, HTTP 80, RDP 3389 | Restrict 3389 and 22 to admin addresses or remove them |
| Windows Server 2025 | RDP 3389 restricted to Lightsail browser RDP | Keep the browser-only default unless a client is needed |
Remember to apply the same restrictions on the IPv6 firewall as on IPv4. Rules apply to the public IP address only, so traffic over the private address is unaffected. For database blueprints and managed databases, keep database ports off the public firewall entirely. Confirm the defaults for your blueprint in AWS's current documentation, as they change with new blueprints.
Snapshots, DNS and certificates
Snapshots
Automatic snapshots cover instances and block storage disks: one per day at a time you choose in UTC, with the latest seven kept. AWS documents that Windows instances and managed databases use manual snapshots instead (managed databases also offer point-in-time backups), that the console toggles automatic snapshots for instances while disks need the CLI, SDK or API, and that automatic snapshots do not keep source tags. Deleting the source resource deletes its automatic snapshots, while manual snapshots and manual copies of automatic snapshots remain. Copy the snapshots you need to keep, such as a pre-upgrade state, to manual snapshots. Because snapshots hold everything on the disk, restrict who can create instances from them and export them.
DNS zones
Lightsail supports up to six DNS zones, with A, AAAA, CNAME, MX, NS, SRV and TXT records and AWS name servers in the form ns-NN.awsdns-NN.com. Records use a fixed TTL of 60 seconds. Domains registered through Lightsail get a zone automatically; for others you can keep DNS at the registrar or move it to a Lightsail zone. AWS recommends Route 53 when you need more zones. Protect the registrar account with MFA and registrar lock, publish SPF, DKIM and DMARC TXT records for domains that send email, and remove records that point to deleted instances or static IPs to avoid dangling records. See the Authoritative DNS and Registrar Account Security Guide.
Certificates and HTTPS
Lightsail load balancers, distributions and container services take ACM certificates validated by DNS. Distributions and container services use HTTPS on their default domain; custom domains need a validated certificate. A load balancer has port 80 open by default and needs a certificate attached for HTTPS on 443; it can hold two certificates with one in use, and deleting the in-use certificate stops HTTPS for that domain, so attach the replacement first. For a single instance without a load balancer, configure TLS on the instance itself and redirect HTTP to HTTPS.
Logging and detection
Lightsail API activity, from the console, CLI and SDKs, is recorded by AWS CloudTrail as management events. Keep a trail delivering to S3 for retention beyond the event history window, and watch for:
| Activity | Example API operations | Why it matters |
|---|---|---|
| Firewall changes | OpenInstancePublicPorts, PutInstancePublicPorts | New exposure of SSH, RDP or admin ports |
| Key and access retrieval | DownloadDefaultKeyPair, GetInstanceAccessDetails | Someone obtaining instance access |
| DNS changes | CreateDomainEntry, UpdateDomainEntry, DeleteDomainEntry | Redirection of the domain or mail |
| Snapshot use | CreateInstancesFromSnapshot, ExportSnapshot | Copies of disks and their secrets |
| Snapshot and instance deletion | DeleteInstanceSnapshot, DeleteInstance | Loss of recovery points |
| IAM and root activity | Root sign-in, new IAM users or access keys | Account takeover |
On the instance, keep SSH authentication logs and web server logs, and ship them off the instance so they survive a rebuild. See the AWS CloudTrail Guide.
Metrics:
- Number of instances with SSH or RDP open to all addresses on IPv4 or IPv6, target zero.
- Percentage of instances using per-person or uploaded keys rather than the default key.
- Number of console users, and percentage with MFA.
- Percentage of production instances with automatic snapshots enabled, and age of the latest manual copy.
- Number of DNS records pointing at deleted resources.
- Days since the last test restore from a snapshot.
Hardening baseline
- Account first: MFA on root and every user, no root access keys, individual identities for administrators, and CloudTrail enabled.
- Firewall: restrict SSH, RDP and control panel ports to admin addresses on both IPv4 and IPv6, delete any rule open to all for those ports, and close ports you do not use. Test from an allowed and a disallowed address. To roll back, re-add the previous rule from your change record.
- Keys: move Linux instances to uploaded per-person keys, remove unused public keys from authorized_keys, and store any downloaded private keys in a vault.
- Snapshots: enable automatic snapshots on instances and disks, copy key restore points to manual snapshots, and test a restore into a new instance.
- TLS: attach ACM certificates to load balancers and distributions, or configure TLS on the instance, and redirect HTTP to HTTPS.
- DNS: registrar MFA and lock, email authentication records, and quarterly removal of stale records.
- Operating system and application: apply vendor security updates promptly and harden the application stack; see the PHP and WordPress Security Guide.
Small and growing estates: a single site can follow this list in an afternoon. Agencies and businesses running many sites benefit from one AWS account per client or environment, API-only automation roles with tag conditions, and a simple register of instances, keys, domains and owners.
Framework mapping
| Control | Lightsail setting | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|---|
| Account management | Individual identities, MFA, no root use | AC-2 | PR.AA-05 |
| Remote access | Restricted SSH and RDP, browser SSH via console permissions | AC-17 | PR.AA-05 |
| Boundary protection | IPv4 and IPv6 firewall rules | SC-7 | DE.CM-01 |
| Authenticator management | Key pairs and rotation | IA-5 | PR.AA-05 |
| Backup | Automatic and manual snapshots | CP-9 | PR.DS-11 |
| Transmission protection | ACM certificates, HTTPS | SC-8 | PR.DS-02 |
| Audit | CloudTrail, instance logs | AU-2, AU-6 | DE.CM-01 |
The access controls defend against misuse of valid cloud accounts (MITRE ATT&CK T1078.004) and of SSH for lateral movement (T1021.004).
Common misconfigurations
- Adding a narrow SSH rule while leaving the open one: the most permissive rule applies. Replace the open rule.
- Restricting IPv4 but not IPv6: the firewalls are independent; mirror rules on both.
- One shared key for every instance and person: use per-person keys so access can be removed individually.
- Relying only on automatic snapshots: they are deleted with the instance. Keep manual copies of important restore points.
- Many full-access console users: console access includes browser SSH. Keep the list short and enforce MFA.
- Stale DNS records after deleting instances: remove records for released static IPs and retired sites.
Practitioner checklist
- Enable MFA on the root user and every IAM user; remove root access keys.
- Restrict SSH, RDP and control panel ports to admin addresses on IPv4 and IPv6.
- Delete firewall rules that open admin ports to all addresses.
- Use uploaded per-person SSH keys and store any downloaded private keys in a vault.
- Remove departed users' keys from authorized_keys and rotate after any suspected exposure.
- Limit full-access console users; give automation API-only policies with tag conditions.
- Enable automatic snapshots and copy key restore points to manual snapshots.
- Serve sites over HTTPS with ACM certificates or instance TLS.
- Lock the registrar account and clean stale DNS records quarterly.
- Keep a CloudTrail trail and alert on firewall, key, DNS and snapshot operations.
Standards and references
- AWS: Instance firewalls in Amazon Lightsail
- AWS: SSH and key pairs in Amazon Lightsail
- AWS: Manage keys stored on a Lightsail instance
- AWS: Identity and access management for Amazon Lightsail
- AWS: Amazon Lightsail identity-based policy examples
- AWS: Configure automatic snapshots in Lightsail
- AWS: DNS in Amazon Lightsail
- AWS: SSL/TLS certificates in Lightsail
Related NHI Mgmt Group resources: PHP and WordPress Security Guide · SSH Key Management Guide · DNS Security Guide · AWS Security Checklist