AWS Build Series: From Lightsail to Serverless
AWS Build Series: From Lightsail to Serverless
Five builds on one sheet: moving WordPress to Lightsail behind a CDN and a custom domain, a full-stack Rails app on Elastic Beanstalk with RDS and Rekognition, keeping it running under load, keeping cost down while it scales, and adding a serverless backend with path-based routing. Fourteen diagrams, and every detail checked against AWS as of October 2026. The tickable companion is bubim-awsbuild-run.
Where a website can run on AWS
Four common places to host a site, plus two more that the later builds use.
| Option | Fits | Does not fit | Notes |
|---|---|---|---|
| Amazon EC2 | anything, full control | teams without time to run servers | you size, patch and scale it yourself |
| Amazon S3 plus CloudFront | static sites: HTML, JavaScript, images | server-side code such as PHP, so no WordPress | the S3 website endpoint is HTTP only; serve through CloudFront with origin access control for HTTPS |
| AWS Amplify Hosting | single-page apps and SSR frameworks (React, Next.js, Vue) with Git-based CI/CD | WordPress, long-running back ends | formerly Amplify Console; branch previews, custom domains, managed certificates |
| Amazon Lightsail | WordPress, LAMP and small servers at a fixed monthly price | large fleets, complex network designs | bundles include data transfer; peer with a VPC when the site outgrows it |
| AWS Elastic Beanstalk | web apps on a supported platform that need load balancing and scaling | workloads that need control below the platform | provisions EC2, ALB and Auto Scaling; you deploy code |
| AWS Lambda behind API Gateway or an ALB | event-driven APIs, spiky traffic | jobs longer than 15 minutes, state kept in memory | pay per request; nothing billed while idle |
Lightsail essentials
A Lightsail instance is a virtual private server: easy to launch, managed from its own console. Choose a Region near your users, then an Availability Zone. Blueprints launch an OS or a full application stack in one click; snapshots are the backups.
| Component | What it is | Notes |
|---|---|---|
| Instance | virtual private server from a bundle (plan) | fixed monthly price, billed hourly up to that cap |
| Blueprint | OS only (Ubuntu, Debian, Amazon Linux, Windows) or an app stack (WordPress, LAMP, Node.js and others) | WordPress comes in two flavours: the Lightsail-built blueprint (February 2026) and the older Bitnami one |
| Snapshot | point-in-time copy of an instance or disk | manual or automatic daily; restore into a new instance, also into a bigger bundle |
| Static IP | fixed public IPv4 address | free while attached; the default public IP changes on every stop and start |
| DNS zone | Lightsail-hosted DNS for your domain | point the registrar at the Lightsail name servers, or keep your provider and add records there |
| Certificate | free TLS certificate for distributions, load balancers and container services | ownership is proven with CNAME records in DNS |
| Distribution | CloudFront-based CDN with presets such as Best for WordPress | caches images and static files close to the visitor |
| Load balancer | spreads HTTP and HTTPS across instances in one Region | health checks, free certificate, session stickiness |
| Managed database | MySQL or PostgreSQL, standard or high-availability plan | HA keeps a standby in a second AZ |
| Bucket | S3-backed object storage | target for WordPress media offload |
| VPC peering | links the Lightsail VPC with the default VPC of the Region | the bridge to RDS, Lambda and the rest of AWS |
Linux bundles (monthly)
| Bundle | vCPU | RAM | SSD | Transfer | With IPv4 | IPv6 only |
|---|---|---|---|---|---|---|
| Nano | 2 | 0.5 GB | 20 GB | 1 TB | $5 | $3.50 |
| Micro | 2 | 1 GB | 40 GB | 2 TB | $7 | $5 |
| Small | 2 | 2 GB | 60 GB | 3 TB | $12 | $10 |
| Medium | 2 | 4 GB | 80 GB | 4 TB | $24 | $20 |
| Large | 2 | 8 GB | 160 GB | 5 TB | $44 | $40 |
Plan choice At $5 a month the plan today is Nano, with 0.5 GB of RAM. WordPress with a migration plugin and a page cache is comfortable from Micro or Small. Larger, memory-optimized and compute-optimized bundles exist; transfer allowances vary by Region.
Moving WordPress to Lightsail
The classic flow still works: launch a WordPress instance, update it, move the site with a migration plugin installed on both ends, fix the upload limit, import. The paths changed because Lightsail now builds its own WordPress blueprint.
| # | Step | Detail |
|---|---|---|
| 1 | Launch | Lightsail console, Region, WordPress blueprint, plan, a name that is unique in your account |
| 2 | First login | browser SSH (Connect), read the admin password from the credentials file, sign in as user at /wp-admin |
| 3 | Update | the image is not current: update core, themes and plugins from the dashboard first |
| 4 | Plugin on both sites | All-in-One WP Migration on the old site and on Lightsail; it moves more than the built-in exporter |
| 5 | Export | old site: export to a .wpress file; it carries database, media, themes, plugins and users |
| 6 | Raise limits | upload_max_filesize and post_max_size in php.ini, then restart Apache |
| 7 | Import | the import replaces the users table: from now on sign in with the old site’s credentials |
| 8 | Snapshot | take one before any DNS change |
Lightsail blueprint against Bitnami blueprint
| Item | WordPress by Lightsail (new) | WordPress by Bitnami (legacy) |
|---|---|---|
| Admin password | cat ~/application_credentials | cat ~/bitnami_application_password |
| wp-config.php | /var/www/wp-config.php | /opt/bitnami/wordpress/wp-config.php |
| php.ini | /etc/php/<version>/apache2/php.ini | /opt/bitnami/php/etc/php.ini |
| Restart web server | sudo systemctl restart apache2 | sudo /opt/bitnami/ctlscript.sh restart |
| HTTPS on the instance | setup wizard in the console, Let’s Encrypt certificate | sudo /opt/bitnami/bncert-tool |
| Bitnami banner | none | older images only; current Bitnami images no longer show it |
| Defaults | IMDSv2 enforced, port 22 restricted at launch | update manually |
Ways to move the site
| Method | Moves | Watch out for |
|---|---|---|
| All-in-One WP Migration | database, media, themes, plugins, users in one file | the server upload limit, and the plugin’s own size limit on large sites |
| WordPress Tools, Export and Import | posts, pages, comments, menus as XML | no plugins, no settings, media only if the old site is still reachable; this is what the AWS Bitnami-to-Lightsail guide uses |
| Database dump plus wp-content copy | everything | needs SSH on both ends; run a URL search-and-replace afterwards |
CDN, custom domain and HTTPS
A content delivery network caches images and static files at edge locations close to the visitor. In Lightsail that is a distribution; underneath it is CloudFront. The domain needs a static IP first, then a certificate whose ownership you prove through DNS.
| Step | Where | Detail |
|---|---|---|
| Static IP | Networking | attach it before any DNS record points at the instance |
| DNS zone | Domains and DNS, or your provider | a Lightsail zone means changing the registrar name servers to the four Lightsail ones |
| Distribution | Networking, Create distribution | origin is the instance (uses its static IP), preset Best for WordPress; origin protocol HTTPS only if the instance serves HTTPS |
| Certificate | distribution, Custom domains tab | add the CNAME validation records it shows; that is the DNS proof of ownership |
| Point the domain | DNS zone | apex: A record as alias to the distribution; www: CNAME to the distribution’s default domain (the xxxx.cloudfront.net name) |
| Tell WordPress | wp-config.php on the instance | site URL on the domain, and treat the request as HTTPS when CloudFront says so |
wp-config.php: replace the two default WP_SITEURL and WP_HOME lines
define('WP_SITEURL', 'https://example.com/');
define('WP_HOME', 'https://example.com/');
if (isset($_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'])
&& $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}After a theme or plugin update Reset the distribution cache, or changes to CSS and JavaScript stay invisible until the cached copies expire.
Target architecture: highly available WordPress
Where the Lightsail build ends: one balancer, several stateless PHP instances, a managed database and the media in a bucket behind the CDN.
fig 1 · the Lightsail end state: balancer in front, stateless PHP instances, managed database, media through the CDN
| Piece | Why it is there |
|---|---|
| Lightsail load balancer | terminates TLS with a free certificate, health-checks the instances, drops a failed one from rotation |
| Two or more instances in different AZs | an AZ or instance failure takes away capacity, not the site |
| High-availability managed database | all instances share one database; the standby takes over on failure |
| Bucket plus distribution for media | uploads must not live on one instance’s disk; an offload plugin writes them to the bucket |
| Snapshots of the instance | a known-good image to launch more instances from |
AWS Elastic Beanstalk
Fully managed web application hosting: it builds the load balancer, the web servers and the scaling for you, keeps the management low, and is a gateway to modernising later. Use the console or the EB CLI; A/B tests come from traffic splitting.
fig 2 · Beanstalk is the shortest path from code to a load-balanced, auto-scaled environment; you still own the code and the data
| Term | Meaning |
|---|---|
| Application | container for versions and environments |
| Application version | a labelled source bundle stored in S3; any version can be redeployed |
| Environment | the running stack: web server tier (ALB plus Auto Scaling group) or worker tier (SQS queue plus daemon) |
| Environment type | load balanced, or single instance for development |
| Platform | OS, runtime and web server, for example Ruby on Amazon Linux 2023; managed updates keep it patched |
| Configuration | option settings from the console, eb config, .ebextensions/*.config or saved configurations |
| Deployment policy | all at once, rolling, rolling with additional batch, immutable, traffic splitting |
| Blue/green | clone the environment, deploy to the clone, swap the CNAMEs |
| EB CLI | Does |
|---|---|
| eb init | binds the folder to an application, Region and platform |
| eb create | creates an environment (size, VPC, env variables, single or load balanced) |
| eb deploy | zips the project, uploads a new version, rolls it out |
| eb status, eb health | environment state and per-instance health |
| eb logs | pulls or streams instance logs |
| eb setenv KEY=value | sets environment properties for the app |
| eb scale N | sets the instance count |
| eb clone, eb swap | copy an environment, swap URLs for blue/green |
| eb terminate | removes the environment and everything it created |
Full-stack app: Beanstalk, RDS, S3, Rekognition
The example app is Detekto, a Rails app that recognises what is in an uploaded image. The database sits inside the VPC but outside Beanstalk, because tearing down an environment wipes any database that Beanstalk itself created.
fig 3 · the full-stack app: Beanstalk for the web tier, RDS kept independent of the environment lifecycle
| Service | Role in Detekto |
|---|---|
| Elastic Beanstalk | runs the Rails app on EC2 behind an Application Load Balancer |
| Amazon RDS for PostgreSQL | managed relational database for users, posts and image metadata |
| Amazon S3 | stores the uploaded images |
| Amazon Rekognition | deep-learning image and video analysis; DetectLabels returns objects and scenes with confidence scores |
Database inside or outside the environment
| Aspect | Created by Beanstalk (coupled) | Created outside Beanstalk |
|---|---|---|
| Lifecycle | follows the environment; on termination the deletion policy decides: Delete, Snapshot or Retain | independent; survives rebuilds and blue/green swaps |
| Connection details | set for you: RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, RDS_PASSWORD | your own properties or a secret |
| Shared by several environments | no | yes |
| Use it for | a quick test of the connection code | production, which is what this build does |
Decoupling Since October 2021 an integrated database can be decoupled from its environment. Set the deletion policy to Retain and apply that first, as a separate change; applying it together with the decouple flag ignores the new policy and follows the old one.
RDS and Beanstalk setup
| Item | Setting |
|---|---|
| Engine and template | PostgreSQL, Dev/Test for the build, Production with Multi-AZ later |
| Name, user | instance identifier, master user name; let RDS keep the password in Secrets Manager |
| Security group | a firewall around the database: 5432 only from the app’s security group, never from 0.0.0.0/0 |
| Endpoint | the DNS name Beanstalk uses, passed in as an environment property |
| Platform | Ruby on Amazon Linux 2023; the code goes up as a zip and needs its configuration settings |
| Instance profile | the EC2 role gets s3:PutObject, s3:GetObject on the bucket and rekognition:DetectLabels |
Keeping the application running under load
The build load-tests Beanstalk with JMeter, sets alarms and scaling triggers, tries bigger machines and time-based scaling, and runs into burstable CPU credits. Each of those is a setting below.
| Setting | Namespace, option | Notes |
|---|---|---|
| Fleet size | aws:autoscaling:asg MinSize, MaxSize | min 2 keeps one instance per AZ |
| Trigger metric | aws:autoscaling:trigger MeasureName | default is NetworkOut; use CPUUtilization for a CPU-bound app |
| Thresholds | UpperThreshold, LowerThreshold | example: out above 50%, in below 20% |
| Evaluation window | Period, BreachDuration (minutes) | 1 and 1 react to the past minute; longer values damp flapping |
| Scaling interval | aws:autoscaling:asg Cooldown | seconds between scaling actions, default 360 |
| Time-based scaling | aws:autoscaling:scheduledaction | raise the minimum before the lunchtime peak; Recurrence is cron in UTC |
| Bigger instances | aws:autoscaling:updatepolicy:rollingupdate | without rolling updates every instance is replaced at once, an uncoordinated outage |
.ebextensions/scaling.config
option_settings:
aws:autoscaling:asg:
MinSize: 2
MaxSize: 8
Cooldown: 120
aws:autoscaling:trigger:
MeasureName: CPUUtilization
Statistic: Average
Unit: Percent
Period: 1
BreachDuration: 1
UpperThreshold: 50
UpperBreachScaleIncrement: 1
LowerThreshold: 20
LowerBreachScaleIncrement: -1
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateEnabled: true
RollingUpdateType: Health
MaxBatchSize: 1
MinInstancesInService: 1Burstable instances and CPU credits
| Mode | Behaviour | Watch |
|---|---|---|
| standard (T2 default) | credits build up while idle and are spent under load; at zero the CPU drops to the baseline and response times collapse | CPUCreditBalance |
| unlimited (T3, T3a, T4g default) | keeps bursting past the credits; the surplus is billed per vCPU-hour | CPUSurplusCreditsCharged |
Rule of thumb A fleet that sits above its baseline most of the day belongs on M or C instances, not on T in unlimited mode.
Load testing
| Tool | Use |
|---|---|
| Apache JMeter | the classic choice: thread groups against the environment URL from one machine |
| Distributed Load Testing on AWS | AWS Solutions stack that runs your JMeter scripts from Fargate tasks, in one or more Regions |
| CloudWatch and eb health | watch CPU, latency, 5xx and instance count while the test runs |
Database scaling
| Change | How | Impact |
|---|---|---|
| Bigger instance class | modify-db-instance –db-instance-class | restart; with Multi-AZ the standby is changed first and a failover keeps the outage short |
| When it happens | –apply-immediately, or the next maintenance window | immediately is possible but costs downtime now |
| More storage | –allocated-storage, –max-allocated-storage | online; storage autoscaling grows it by itself |
| More reads | read replicas | the app sends reads to the replica endpoint |
| Too many connections | RDS Proxy | pools connections from many instances or Lambda functions |
Keeping cost down while scaling
The scaled production environment plus a developer clone; the money is saved where the two overlap and where the steady base is committed.
fig 4 · scale production out, not up; give developers a clone that is small and only runs when they do
fig 5 · instance sizing: same capacity, same price, finer scaling granularity with more, smaller instances
| Price factor | Effect |
|---|---|
| Size | roughly linear with the machine size inside a family; more, smaller instances follow load more closely and can come out cheaper |
| Processor | Graviton (ARM) and AMD variants are priced below the Intel ones of the same class |
| Region | the same instance costs different amounts in different Regions |
| Licensing | Windows, SQL Server and RHEL add a licence share to the hourly price |
| Purchase option | On-Demand, commitment or Spot; Spot can be taken back with a 2-minute warning |
| Public IPv4 | every public IPv4 address is billed hourly since February 2024; IPv6 is free |
fig 6 · three ways to pay for the same instance; the cheapest mix uses all three
fig 7 · size the commitment to the floor of the curve, never to the average
| Commitment | Covers | Discount | Term | Flexibility |
|---|---|---|---|---|
| Compute Savings Plans | EC2 of any family, size, OS or Region, Fargate, Lambda | up to 66% | 1 or 3 years | highest |
| EC2 Instance Savings Plans | one instance family in one Region | up to 72% | 1 or 3 years | any size, OS, tenancy in that family |
| EC2 Reserved Instances | an instance type in a Region (or AZ for capacity) | up to 72% | 1 or 3 years | standard or convertible |
| RDS Reserved Instances | DB class family, engine, Region | large, see fig 8 | 1 or 3 years | size flexible for most engines |
| Database Savings Plans | Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS | up to 35% | 1 year, no upfront | any engine, class, size or Region |
Payment All upfront gives the deepest discount, partial upfront less, no upfront the least. Buy commitments for the floor of fig 7 and top up as the floor rises.
fig 8 · steady-state databases are the easiest commitment to make
Things to change
| Change | How | Why it saves |
|---|---|---|
| Commit the database | RDS RI for 1 or 3 years, or a Database Savings Plan | a database runs around the clock for years anyway |
| Stop development outside office hours | Instance Scheduler for EC2 and RDS; Beanstalk scheduled actions to scale dev to zero | a 55-hour week is a third of 168 hours |
| Small base instances | one always-on instance on a smaller size, more of them under load | the count follows demand more closely |
| Spot for the surplus | Beanstalk EnableSpot with an On-Demand base | stateless web servers tolerate a 2-minute notice |
| Tier the images | S3 Intelligent-Tiering | old uploads drop to cheaper tiers by themselves |
fig 9 · the follow-up list; Instance Scheduler now lives under AWS Solutions
Instance Scheduler on AWS
| Item | Detail |
|---|---|
| Deploy | CloudFormation stack from the AWS Solutions library (built with CDK) |
| Configuration | periods and schedules in a DynamoDB table; manage with the DynamoDB console, scheduler-cli or CloudFormation custom resources |
| Assignment | tag the resource Schedule=<schedule name>; EC2 instances and RDS DB instances |
| Engine | EventBridge invokes a Lambda orchestrator every 5 minutes by default; it starts or stops what does not match its schedule |
| Multi-account | hub and spoke in the same Region |
| Caveat | an instance stopped inside an Auto Scaling group (any Beanstalk environment) is seen as unhealthy and replaced; use scheduled scaling there |
Adding a serverless backend
Serverless is the native architecture of the cloud: it hands the operation of servers to AWS, all scaling is automatic, and you shift more operational responsibility away from your team. This build moves image labelling out of the web servers into a function.
fig 10 · what serverless buys you: operations shift to AWS, you keep the code and the configuration
fig 11 · event source, function, services: the whole serverless model in one line
fig 12 · Lambda and SAM side by side
| Lambda limit or setting | Value |
|---|---|
| Timeout | up to 15 minutes |
| Memory | 128 MB to 10,240 MB; CPU grows with memory |
| Package | zip up to 50 MB uploaded directly (250 MB unzipped), or a container image up to 10 GB |
| Temporary storage | /tmp from 512 MB to 10,240 MB |
| Billing | per request plus duration in 1 ms steps times memory; arm64 (Graviton) costs less per GB-second |
| Concurrency | an account quota per Region, plus reserved and provisioned concurrency per function |
| Cold starts | provisioned concurrency, or SnapStart for Java, Python and .NET |
template.yaml: image upload triggers labelling, labels land in DynamoDB
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Detekto image labelling
Resources:
ImagesBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub '${AWS::StackName}-images-${AWS::AccountId}'
LabelsTable:
Type: AWS::Serverless::SimpleTable
LabelFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.13
Architectures: [arm64]
Handler: app.handler
CodeUri: src/
MemorySize: 256
Timeout: 30
Environment:
Variables:
TABLE: !Ref LabelsTable
Policies:
- S3ReadPolicy:
BucketName: !Sub '${AWS::StackName}-images-${AWS::AccountId}'
- DynamoDBCrudPolicy:
TableName: !Ref LabelsTable
- RekognitionDetectOnlyPolicy: {}
Events:
Upload:
Type: S3
Properties:
Bucket: !Ref ImagesBucket
Events: s3:ObjectCreated:*
Outputs:
Bucket:
Value: !Ref ImagesBucketsrc/app.py
import os
import urllib.parse
import boto3
rekognition = boto3.client("rekognition")
table = boto3.resource("dynamodb").Table(os.environ["TABLE"])
def handler(event, context):
for record in event["Records"]:
bucket = record["s3"]["bucket"]["name"]
key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])
result = rekognition.detect_labels(
Image={"S3Object": {"Bucket": bucket, "Name": key}},
MaxLabels=10,
MinConfidence=80,
)
labels = [label["Name"] for label in result["Labels"]]
table.put_item(Item={"id": key, "labels": labels})
return {"processed": len(event["Records"])}Two traps The bucket in an S3 event must be declared in the same template, and naming it with a fixed string (as above) avoids the circular reference that a !Ref in the policy would create. Never let the function write back into the prefix that triggers it.
| SAM CLI | Does |
|---|---|
| sam init | scaffolds a project from a template |
| sam build | installs dependencies and stages the artifacts |
| sam local invoke -e event.json | runs the function in a local container with a sample event |
| sam deploy –guided | first deploy: asks for stack name and Region, saves samconfig.toml, creates the infrastructure through CloudFormation |
| sam sync –watch | pushes code changes to a dev stack in seconds |
| sam logs –tail | follows the function’s CloudWatch logs |
| sam delete | removes the stack |
fig 13 · the end state: image analysis moved off the web servers into an event-driven function
Path-based routing to the serverless backend
Path-based routing completes the build. One hostname, two back ends: requests under /api go to Lambda, the rest to the Beanstalk instances.
fig 14 · path-based routing on one ALB: /api to Lambda, the rest to Beanstalk
| Option | Routing lives in | Fits when |
|---|---|---|
| ALB listener rule to a Lambda target group | the load balancer | you already run an ALB; with Beanstalk use a shared load balancer you own, so the rule is not part of an environment you might rebuild |
| CloudFront cache behaviors | the CDN | you want caching and WAF at the edge and one domain over S3, the ALB and the API |
| API Gateway HTTP API routes | the API | the API stands alone and wants JWT authorizers, throttling and stages |
Lambda behind an ALB The function receives the HTTP request as a JSON event and must return statusCode, headers and body; the response body is limited to 1 MB. Grant elasticloadbalancing.amazonaws.com permission to invoke it.
If you need X, use Y
| Need | Use |
|---|---|
| WordPress for a small site at a predictable price | Lightsail WordPress blueprint, Micro or Small bundle |
| A static marketing site | S3 plus CloudFront, or Amplify Hosting |
| A React or Next.js front end with Git deploys | Amplify Hosting |
| Images closer to visitors | Lightsail distribution or CloudFront |
| Prove domain ownership for a certificate | CNAME validation records in DNS |
| A Rails, Django or Node app with scaling and no infrastructure code | Elastic Beanstalk |
| Keep the database when the app environment is rebuilt | RDS outside Beanstalk, or decouple with deletion policy Retain |
| Recognise objects in uploaded photos | Rekognition DetectLabels on the S3 object |
| A predictable lunchtime peak | scheduled scaling action |
| Response times collapse after a busy hour on T2 | CPU credits exhausted: unlimited mode or a non-burstable family |
| A database that runs all year | RDS Reserved Instance or Database Savings Plan |
| Dev environments idle at night | Instance Scheduler, or scheduled scaling to zero in Beanstalk |
| Interruptible, stateless capacity cheaply | Spot |
| Run code when a file lands in S3 | Lambda with an S3 event, defined in SAM |
| Send /api to functions and the rest to servers | ALB path-pattern rule or CloudFront behavior |
What changed since 2020
| In 2020 | Today |
|---|---|
| $5 Lightsail plan for WordPress | $5 buys Nano with 0.5 GB and a public IPv4; IPv6-only bundles start at $3.50; plan on Micro or Small |
| Bitnami WordPress, password file in the home folder, ctlscript | Lightsail-built WordPress blueprint since February 2026: ~/application_credentials, systemctl restart apache2, setup wizard with a Let’s Encrypt certificate; Bitnami stays for existing instances |
| Disable the Bitnami banner | not needed on current images |
| AWS Amplify Console for single-page sites | Amplify Hosting, which also serves SSR frameworks |
| 11 Beanstalk runtime platforms | 10 platform families, Linux on Amazon Linux 2023 plus .NET on Windows Server |
| Database outside Beanstalk so it survives teardown | still right; integrated databases can also be decoupled with deletion policy Retain (since October 2021) |
| RDS Reserved Instances | plus Database Savings Plans (December 2025), up to 35%, 1 year, any engine or Region |
| Instance sizing shown with c4 | same rule with current families such as c7i or c7g |
| T2 credit exhaustion | T3, T3a and T4g default to unlimited: no throttling, but surplus credits are billed |
| Instance Scheduler link under solutions/implementations | Instance Scheduler on AWS in the Solutions library, hub and spoke, scheduler-cli |
| Lambda runtimes listing Go | go1.x is deprecated; Go and Rust run on provided.al2023 |
| SAM at github.com/awslabs | github.com/aws/serverless-application-model; CLI adds sam sync |
| Public IP addresses free | each public IPv4 address is billed since February 2024 |
Details checked against the AWS documentation for Lightsail bundles and WordPress blueprints, Elastic Beanstalk platforms and database decoupling, Database Savings Plans, Instance Scheduler and Lambda runtimes.
0 comments