Amazon EC2

EC2 is the foundation of AWS and the easiest product to buy wrong. Most "how do I choose a cloud server" questions come down to two decisions: which instance family, and which billing model. Get either wrong and everything afterwards is damage control — an oversized instance wastes money for months, and the wrong billing plan burns it just as steadily. We open AWS accounts and act as payment intermediary for clients every day. The most common mistakes we see: running Graviton-friendly workloads on m5.large, or leaving stable production on on-demand pricing forever. Here is the decision order we actually use.

Specs & pricing

Step 1: pick the family by workload, not by price

AWS instance families are not a price ladder — they are a division of labour. Classify the workload first: - Web and business systems → M family. Balanced CPU and memory; most workloads do not need specialisation. - Compiling, transcoding, batch jobs → C family. These saturate CPU, and M instances run them slower for the same money. - Databases, Redis, in-memory cache → R family. Higher memory per core means more of the working set stays cached. - GPU training and inference → G / P family; training cares about VRAM capacity, inference about unit price and concurrency. Picking the wrong family costs money continuously, not once: running compiles on M instances means paying general-purpose prices for specialised performance; running a database on C instances means paying for CPU cores you will never use.

If your service runs on ARM, try Graviton first

Step 2: region choice affects experience more than instance choice

This is the most underestimated and most consequential decision. Latency is determined by the distance and network path from *your users* to the region you picked — changing instance type does nothing for it. For Asia-Pacific users, Hong Kong (ap-east-1) typically lands in the 15–30ms range for users in Greater China, Taiwan, and Hong Kong. Tokyo (ap-northeast-1) and Singapore (ap-southeast-1) run closer to 45–95ms, and the numbers move with carrier and time of day. Measure it before you commit: launch a minimal instance, ping it for 24 hours from the network your actual users are on, and look specifically at the evening peak. The test costs a few dollars; choosing the wrong region costs you continuously.

Step 3: the billing model decides your long-run cost

Practical rule: pay on-demand while building, move to a Savings Plan or Reserved Instance once production is steady. Most teams cut cloud spend 30–50% not by buying cheaper machines, but by not paying full price for idle hours. If your instance shape will change over time — say M to R — choose a Savings Plan over a Reserved Instance. RIs are locked to a shape; once it no longer matches, they are wasted. Savings Plans meter on usage and follow your workload. For bursty work like GPU training, Spot with automatic checkpointing is the best value on the table — typically a fifth to a tenth of on-demand pricing.

How to get set up

1. Tell us the requirement: region, instance family, expected usage, whether you need an Elastic IP.
2. Confirm the quote: discount rate, billing model, and whether resizing costs extra are all written into the order confirmation.
3. Account opening: we handle AWS account provisioning and payment verification — you bind no personal credit card and submit no identity documents.
4. Payment and settlement: settled in the agreed currency, with the billing statement reconciled before hand-over.
5. Hand-over: once the account is live you order directly in the AWS console; we help initialise the instance environment.

Four common mistakes

• Leaving stable workloads on on-demand: a six-month-old production stack nobody thought to move to a Savings Plan.
• Cross-region data transfer: running your app and database in different regions can cost more in egress than the instances themselves.
• Forgotten EBS volumes and snapshots: deleting an instance does not delete its volumes, and snapshots keep billing per GB — the most common surprise on an AWS invoice.
• T-family CPU credit exhaustion: once you exceed the baseline performance, overages are billed, which makes burstable families a poor fit for sustained CPU work.