AWS, From Zero to Usable: A Pragmatic Engineer’s Onboarding

Misconfigured, over-provisioned, or left running: AWS accounts can bleed money and expose production data fast if the basics are skipped. Start with core services. Build intuition for control and cost.

Orientation: What Actually Matters in AWS

Cloud platforms—AWS especially—hide infrastructure behind APIs. Finished workloads, not physical machines, are the output. The key primitives:

• Regions (e.g., us-east-1, eu-central-1)
• Availability Zones (think: physically isolated DCs within regions)
• IAM (Identity and Access Management)
• EC2 (Elastic Compute Cloud)
• S3 (Simple Storage Service)
• CloudWatch for observability

Skip “exploring every service.” Engineers who build fast learn the cost and failure boundaries of these foundational pieces.

Infrastructure Topology: Regions, AZs, and Real Latency

Pick the wrong region, and your app hits 200 ms latency for users or isn't legal for European data. Each region is independent—moving data between regions isn’t free or always quick.

Region/AZ Table:

Gotcha: Resources (e.g., EC2, S3 buckets) are scoped to regions. Backups in us-east-1 vanish if only eu-central-1 is inspected.

Practical check:

• Log into the AWS Console.
• Toggle the region dropdown; availability varies per region.
• Try launching an EC2 instance in two regions, note the AMI list isn't identical.

IAM: Gatekeeper, Single Point of Failure

IAM is often misunderstood until a permission issue halts all automation. Aim for “least privilege” and never use the root account for scripts.

Workflow:

1. Open IAM, create a user (aws-batch-user), select Programmatic access.

2. Assign the AmazonS3ReadOnlyAccess policy.

3. Extract credentials.

4. Test using AWS CLI:

   aws s3 ls --profile batch-user
   

   Output with insufficient permissions:

   An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
   

Note: Don’t rely exclusively on managed policies; sometimes you’ll need custom ones, especially in environments with dozens of microservices.

EC2: Elastic Compute, Non-Elastic Budgets

Provision a VM or you’re not using AWS in any meaningful way. t2.micro today (2024) remains the free tier for testing, but newer instance types have better EBS burst credits. Default to Amazon Linux 2 (ami-0c2b8ca1dad447f8a as of now) unless you need Ubuntu for compatibility.

Spin up and deploy Apache:

# From AWS Console → EC2 → Launch Instance
# Use Amazon Linux 2 AMI, t2.micro
# Attach inbound rule: TCP port 80
# Use a fresh SSH keypair
ssh -i ./my-key.pem ec2-user@public-ip

sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
echo 'Deployed from EC2 at $(date)' | sudo tee /var/www/html/index.html

Browser to public IP should show your deploy timestamp.

Known issue: Forgetting to set HTTP/HTTPS rules in the security group returns ERR_CONNECTION_TIMED_OUT in browser, no indication in SSH/CLI.

S3: Storage Without the Hardware Fun

Typical uses: image hosting, static site, backups.

• Bucket names must be globally unique (my-first-bucket-20240610 or you’ll get a conflict).
• For file hosting: enable “Block all public access” toggle only after you finish, then selectively permit objects (or use pre-signed URLs).
• Static website? Add index.html and enable “Static website hosting” in bucket properties for endpoint URL.

CLI upload

aws s3 cp ./logo.png s3://my-first-bucket-20240610/

Tradeoff: S3 is eventually consistent for overwrite/delete in some cases—test this if your workflow depends on up-to-the-second accuracy.

CloudWatch: Instrument First, Panic Less Later

Logging and monitoring are afterthoughts—until that SSH session freezes and there’s no metrics.

Steps:

• From EC2, enable “detailed monitoring” ($).
• CloudWatch graphs show CPU, network, disk IO.
• Set up alert: Notify if CPU > 80% for 5 mins.

Example alarm action: Integrate with Lambda or SNS to auto-isolate the instance.

Side note: By default, system logs aren’t forwarded; install and configure the awslogs agent for OS-level log streams.

Pitfalls and Overlooked Details

• Cleanup: Orphans (EBS volumes, elastic IPs) persist after EC2 termination. Major source of “why is my bill so high?” surprises.
• Never use root for automation: Disable programmatic root keys. Audit usage with IAM access analyzer.
• Region drift: S3 buckets and EC2 in different regions adds cost and confusion—double-check region during automation scripting.
• Security by default: Open TCP/22 or TCP/80 only as long as strictly necessary. Rotate all credentials every 90 days.

Continue the Technical Progression

After EC2/S3/IAM/CloudWatch:

• Lambda: Event-driven compute with python3.12 now generally available. Cold starts are shorter, but be aware of VPC attachment latency.
• RDS: Start with db.t3.micro for free tier PostgreSQL/MySQL, but inspect backup retention defaults.
• VPC networking: Single VPC, multi-subnet architecture = best practice for real prod; tweak route tables for hybrid deployments.
• CloudFormation: Use for declarative, versioned infrastructure instead of ad-hoc scripting (or try AWS CDK for TypeScript/Python devs).

Reference Links and Further Reading

• AWS Free Tier
• AWS Getting Started Resource Center
• EC2 Instance Types
• CloudWatch agent documentation
• Example YouTube: “AWS Console Crash Course” (search—content quality varies)

Scrutiny and iteration trump sweeping initial builds. Spin up, test, tear down. The bill (and security reports) will thank you. No cloud expertise comes from the console alone—real fluency arrives with a mix of terminal errors, keypair mismatches, and at least one forgotten-but-billed EBS disk.

Note: Many AWS tutorials gloss over cost and cleanup. Automate teardown scripts, preferably before you learn the hard way.