Amazon Web Services keeps launching new tools, but most announcements assume you already know the ecosystem. If you're running a VPS or considering cloud migration, the jargon can feel overwhelming. This guide defines what AWS actually is, explains why recent service launches matter for hosting workloads, and walks you through creating your first resource from scratch.
What AWS actually means
AWS is a collection of on-demand infrastructure services you rent by the hour or second. Instead of buying a physical server, you spin up a virtual machine (called an EC2 instance) in one of Amazon's data centers, pay only while it runs, and delete it when you're done.
Think of it as a utility. You don't own the power plant; you pay for electricity as you use it.
The platform includes compute (virtual servers), storage (file systems and databases), networking (load balancers and DNS), and dozens of specialized tools. Each service solves a narrow problem—database replication, image resizing, log aggregation—and charges separately.
Why new services keep appearing
Amazon announces hundreds of features every year at its re:Invent conference and through quarterly updates. Most are incremental: a new instance type with more RAM, support for an additional programming language runtime, or a regional expansion.
A smaller number are entirely new products. These usually fall into three categories:
Managed replacements for open-source tools. If teams are self-hosting Prometheus for monitoring or Grafana for dashboards, AWS will eventually offer a hosted version (Amazon Managed Service for Prometheus, Amazon Managed Grafana). You offload maintenance, patching, and scaling to Amazon in exchange for a premium over running it yourself.
Abstractions that hide complexity. Services like AWS App Runner let you deploy a container without configuring load balancers, auto-scaling groups, or networking rules. You push code; AWS handles the rest. The tradeoff is less control and higher per-request cost compared to managing EC2 directly.
Integrations between existing services. A new feature might let S3 automatically trigger a Lambda function when a file uploads, or allow RDS to replicate into Redshift for analytics. These glue pieces reduce the custom scripts you write.
Recent launches that matter for hosting
Let's focus on services relevant to hosting websites, APIs, and databases. I'll explain what problem each solves and who benefits.
EC2 instance families
EC2 is the core compute service—virtual machines you SSH into like a traditional VPS. Amazon regularly releases new instance families optimized for specific workloads.
Graviton processors are ARM-based chips Amazon designed in-house. Graviton3 and Graviton4 instances offer better price-performance than Intel or AMD equivalents for many workloads. If your stack runs on ARM (most modern languages and web servers do), you'll pay less per hour for the same throughput.
Why it matters: hosting costs drop without code changes. Check compatibility first, though—some legacy binaries only run on x86.
Spot instances aren't new, but AWS expanded capacity in recent years. Spot lets you bid on unused EC2 capacity at up to 90% off on-demand prices. Amazon can terminate your instance with two minutes' notice if someone pays the higher rate.
Why it matters: perfect for batch jobs, CI/CD runners, or dev environments. Not suitable for production databases or anything that can't tolerate sudden shutdowns.
Amazon Lightsail
Lightsail is a simplified compute service aimed at users migrating from shared hosting or basic VPS providers. You pick a bundle (memory, CPU, storage, bandwidth), choose an operating system or pre-configured app (WordPress, cPanel, GitLab), and launch.
Pricing is flat monthly. No surprise bills.
Why it matters: if you find EC2's pay-per-resource model confusing, Lightsail gives you predictable costs and a friendlier interface. You sacrifice flexibility—can't customize networking or attach advanced storage—but for a single WordPress site or staging server, it's enough.
Amazon RDS Blue/Green Deployments
RDS is managed relational databases (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). Amazon handles backups, patching, replication, and failover.
Blue/Green Deployments let you clone your production database, test schema changes or version upgrades on the clone, then promote it to production with a single click. DNS flips; downtime is under a second.
Why it matters: major version upgrades (MySQL 5.7 to 8.0) used to require maintenance windows. Now you validate the upgrade on the green environment while blue serves traffic. When green is stable, you switch. Rollback is instant if something breaks.
AWS App Runner
App Runner takes a container image or source code repository and runs it as a web service. You don't configure EC2 instances, load balancers, or auto-scaling rules. Push code; AWS deploys, scales, and provisions HTTPS automatically.
It auto-scales down to zero when idle, so you pay nothing between requests.
Why it matters: fastest path from code to production URL. Great for APIs, webhooks, or internal tools. Not cost-effective for high-traffic sites (EC2 or ECS becomes cheaper beyond a threshold), but for low-traffic projects, zero idle cost is compelling.
Amazon CloudFront integration improvements
CloudFront is AWS's CDN. Recent updates improved cache invalidation speed, added support for HTTP/3 and QUIC, and introduced CloudFront Functions—tiny JavaScript snippets that run at edge locations to modify requests or responses.
Why it matters: you can enforce security headers, rewrite URLs, or A/B test without touching origin servers. Functions execute in under a millisecond. Cheaper and faster than routing requests through a Lambda function in a single region.
AWS Certificate Manager (ACM) updates
ACM provides free SSL/TLS certificates for use with AWS services. Recent improvements include automatic renewal for certificates attached to CloudFront, Application Load Balancers, and API Gateway.
Why it matters: you'll never face a surprise certificate expiration again. ACM handles renewal 60 days before expiry. For multi-domain certs, wildcard support is included at no extra charge.
Amazon Aurora Serverless v2
Aurora is Amazon's high-performance MySQL- and PostgreSQL-compatible database. Serverless v2 scales capacity up or down in fine increments (0.5 ACU steps) within seconds, based on actual load.
Unlike v1, which had long cold-start delays, v2 keeps a minimum capacity warm. Scaling is instant.
Why it matters: eliminates over-provisioning. If traffic spikes at 9 AM and drops at 6 PM, you pay for high capacity only during the spike. For variable-load applications (SaaS platforms, marketing sites with campaign-driven traffic), this cuts database costs significantly.
How to deploy your first AWS resource
Let's launch an EC2 instance running Ubuntu and configure SSH access. You'll need an AWS account (free tier available) and a terminal.
Step 1: Create an IAM user
Never use your root account credentials for day-to-day work. Root has unrestricted access; compromise is catastrophic.
- Sign into the AWS Console
- Navigate to IAM (Identity and Access Management)
- Click Users → Add users
- Enter a username, enable Programmatic access and Console access
- Attach the AdministratorAccess policy (for learning; narrow this in production)
- Download the CSV with access keys
Step 2: Install the AWS CLI
The CLI lets you manage resources from the command line without clicking through the web console.
On Ubuntu or Debian:
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
Verify:
aws --version
Configure credentials:
aws configure
Enter your access key ID, secret key, default region (choose one geographically close, like us-east-1 or eu-west-1), and output format (json).
Step 3: Create a key pair for SSH
AWS won't let you SSH into an instance without a key pair.
aws ec2 create-key-pair --key-name my-first-key --query 'KeyMaterial' --output text > my-first-key.pem
chmod 400 my-first-key.pem
This generates a private key and saves it locally. Never share this file.
Step 4: Launch an EC2 instance
Find an Ubuntu AMI (Amazon Machine Image) ID for your region. AMI IDs differ per region. For us-east-1, Ubuntu 22.04 LTS typically starts with ami-0c7217cdde317cfec (check the official Ubuntu AMI locator for current IDs).
aws ec2 run-instances \
--image-id ami-0c7217cdde317cfec \
--instance-type t3.micro \
--key-name my-first-key \
--security-group-ids sg-xxxxxxxx \
--subnet-id subnet-yyyyyyyy
Replace sg-xxxxxxxx with a security group ID that allows SSH (port 22) from your IP, and subnet-id with a public subnet in your default VPC.
Simpler alternative: use the console for your first launch. Go to EC2 → Launch Instance, pick Ubuntu, choose t3.micro (free tier eligible), and follow prompts.
Step 5: Connect via SSH
Find your instance's public IP in the console or via CLI:
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,PublicIpAddress,State.Name]' --output table
SSH in:
ssh -i my-first-key.pem ubuntu@<public-ip>
You're now on a virtual server. Install packages, configure web servers, do whatever you'd do on a VPS.
Step 6: Terminate when finished
Running instances accrue hourly charges. Stop or terminate when not in use.
aws ec2 terminate-instances --instance-ids i-1234567890abcdef0
Or use the console: right-click the instance → Terminate.
Common beginner mistakes
Leaving resources running. Free tier covers 750 hours per month of t2.micro or t3.micro usage, but if you launch multiple instances or forget to terminate, you'll get a bill. Set up billing alerts in the console under Billing → Budgets.
Using the root account for everything. Root can't be restricted. Create IAM users with narrower permissions.
Open security groups. Allowing SSH (port 22) from 0.0.0.0/0 (anywhere) invites brute-force attacks. Lock it to your IP or use Session Manager instead.
Ignoring regions. Each region is isolated. An EC2 instance in us-east-1 can't talk to an RDS database in eu-west-1 without traversing the public internet. Keep related resources in the same region.
Skipping backups. Enable automated snapshots for EBS volumes and RDS databases. Recovery from accidental deletion is impossible without backups.
When to use AWS vs traditional hosting
AWS makes sense when you need elasticity (traffic spikes unpredictably), geographic distribution (serve users globally with low latency), or specialty services (managed Kubernetes, serverless functions, machine learning APIs).
It's overkill for a single WordPress blog with steady traffic. A $5/month VPS from a traditional provider is simpler and cheaper.
The break-even point is roughly when you'd otherwise need two or three dedicated servers, or when you can't predict load and want to pay only for actual usage.
Questions
Do I need to learn every AWS service?
No. Most hosting workloads use EC2 (compute), RDS (databases), S3 (file storage), and CloudFront (CDN). Learn those first. Specialize into other services as needs arise.
Is free tier actually free?
Yes, for 12 months, within limits. You get 750 hours/month of t2.micro or t3.micro EC2, 5GB of S3 storage, 750 hours of RDS, and more. Exceeding these limits or using non-free-tier services triggers charges. Monitor usage in the billing dashboard.
Can I migrate an existing site to AWS?
Yes. Lift-and-shift is the simplest approach: launch an EC2 instance, install your stack (Apache, MySQL, PHP), copy files and databases over, and point DNS. AWS also offers migration tools (Database Migration Service, Application Migration Service) for complex environments.
How do I avoid surprise bills?
Set a billing alarm for $10 or $20 in the Billing console. Enable cost allocation tags to track which projects consume what. Terminate or stop unused instances nightly.
What's the difference between stopping and terminating?
Stopping an instance powers it down; you still pay for EBS storage but not compute. Terminating deletes the instance and attached storage permanently (unless you set volumes to persist). Stop for temporary pauses; terminate when done.
Start small and expand as you learn
AWS can feel like drinking from a firehose. You don't need to understand every service on day one. Start with one EC2 instance running Ubuntu. Install your application stack, open the necessary ports, and confirm everything works. Once comfortable, explore RDS for managed databases, S3 for backups, or CloudFront for caching.
New services launch constantly, but the fundamentals—compute, storage, networking—change slowly. Master those, and the rest is just reading documentation and experimenting. Keep an eye on the AWS blog for announcements, but don't feel obligated to adopt every new feature. Use what solves your problem; ignore the rest.