AWS AI foundations

The AWS AI landscape in one map essential

Start with the moment that sends most people down the wrong path. You've decided to "add AI on AWS," you open the console, and you're staring at what feels like fifty services with overlapping names — Bedrock, SageMaker, Comprehend, Kendra, Q, Rekognition, Textract. Which one calls Claude? Which one is for training? You pick one at random, spend two hours in its docs, and discover it was the wrong door entirely. The confusion isn't you — it's that AWS never gives you the map, only the menu.

So here's the map, and it's simpler than the menu suggests. Think of AWS AI as a vending machine with three shelves, arranged from "just press a button" at the top to "bring your own ingredients" at the bottom. The top shelf is the pre-built AI services: you hand them a document, an image, or an audio clip and they hand back an answer — no model, no training, no ML knowledge. The middle shelf is Amazon Bedrock: someone else's foundation models (including Claude) that you rent by the token, plus managed wrappers for RAG, agents, and guardrails. The bottom shelf is Amazon SageMaker: the full workshop where you train, tune, and host your own models — maximum control, maximum responsibility.

Why does the shelf you pick matter so much? Because it decides three things at once: how much you build, how much you pay, and how much you can customize. Reaching for the bottom shelf (SageMaker) to do a job the top shelf already does (extract text from a PDF → Textract) is the single most expensive beginner mistake on this whole track — you end up training and babysitting a model to solve a problem AWS solved for you at a fraction of a cent per page. The instinct that costs teams the most money is treating "AI on AWS" as one thing instead of three.

The rule that keeps you out of trouble: climb down the shelves only when the shelf above genuinely can't do the job. Does a narrow, pre-built service already cover your task? Use it. If not, can a general foundation model on Bedrock do it with a good prompt? Use that. Only when you truly need a custom-trained or custom-hosted model do you drop to SageMaker. This whole track leads with Bedrock because that middle shelf — renting a capable model like Claude — is where the vast majority of generative-AI automation actually lives.

AWS AI splits into three layers. From highest-level to lowest: pre-built AI services (call an API, no ML knowledge — Textract, Comprehend, Rekognition, Transcribe), Amazon Bedrock (managed access to foundation models incl. Claude, plus managed RAG, agents, and guardrails), and Amazon SageMaker (the full ML platform — train, tune, host your own models). This track covers all three, but leads with Bedrock because that is where the generative-AI automation lives.

Authentication: the boto3 credential chain essential

Here's the failure that teaches this lesson the hard way. A developer, in a hurry, pastes their AWS access key and secret straight into the Python file — aws_access_key_id="AKIA..." — because it works instantly and they'll "clean it up later." They commit it. Weeks pass. Then a bill arrives for thousands of dollars: a bot scraped the key off GitHub within minutes of the push and spun up crypto miners in their account. This is not a rare horror story; it is one of the most common ways cloud accounts get compromised. The boto3 credential chain exists precisely so you never have to type a key into code at all.

The mental model is a doorman who checks several pockets in order until he finds your ID. When your code calls AWS, boto3 doesn't ask you for credentials — it goes looking for them itself, in a fixed sequence, and stops at the first place it finds them. The order is: environment variables first, then a named profile in your ~/.aws/credentials file, then — if the code is running on AWS — the temporary credentials handed out by an attached IAM role. Because the search is automatic, the same line of Python authenticates on your laptop (where it finds a profile) and inside a Lambda function (where it finds a role), with nothing to change between them.

Now the part that trips people up: the difference between a key and a role. A key (that AKIA... string plus its secret) is a long-lived password — it works until you rotate it, which means if it leaks, it keeps working for the attacker too. An IAM role is different: it's an identity your compute assumes, and AWS mints short-lived, auto-rotating credentials for it behind the scenes. Nothing long-lived is ever written down. That is why the rule for anything running in automation — Lambda, EC2, ECS, a CI job — is use a role, never a key. Keys are for the rare case of a human on a laptop who has no better option, and even then you scope them tightly.

One more thing worth naming, because beginners conflate the two: authentication is not authorization. The credential chain proves who you are (authentication). What you're actually allowed to do — call Bedrock, read a bucket, delete an endpoint — is decided separately by the IAM policies attached to that identity (authorization). A perfectly resolved identity can still get AccessDenied on the very next call because its policy doesn't grant the action. Keeping those two ideas apart saves you hours of debugging: "am I logged in?" and "am I permitted?" are different questions with different fixes.

boto3 (the AWS SDK for Python) never wants credentials hard-coded. It searches a chain: environment variables → shared config file (~/.aws/credentials profiles) → IAM role (on EC2/Lambda/ECS). In automation you almost always use an IAM role so there are no long-lived keys at all.

check_auth.pyimport boto3

# The credential chain resolves automatically. On your laptop this uses a
# named profile; in Lambda/EC2 it uses the attached IAM role — same code.
session = boto3.Session(region_name="us-east-1")   # region where Bedrock has Claude

# Prove who we are (STS = Security Token Service) without needing any AI service.
sts = session.client("sts")
ident = sts.get_caller_identity()
print("account:", ident["Account"])
print("arn:    ", ident["Arn"])

Regions & model access intermediate

You've probably already hit this wall without knowing what it was. Your credentials resolve perfectly — get_caller_identity prints your account, everything looks healthy — and yet the moment you try to list or call a Claude model, you get an empty list or an AccessDenied that mentions nothing about credentials. You double-check your keys. You re-run aws configure. Nothing. The real culprit is one of two invisible settings that have nothing to do with who you are: the region you're pointed at, and whether model access has been switched on there.

Start with region, because the analogy makes it click: AWS is not one building, it's a chain of warehouses in different cities (us-east-1 in Northern Virginia, us-west-2 in Oregon, and many more). Each warehouse stocks its own inventory. A model that's available in one region may simply not be carried in another — and your account's resources, quotas, and even the enablement switches are tracked per warehouse. When you write region_name="us-east-1", you're choosing which warehouse to walk into. Ask for Claude in a region that doesn't stock it and the shelf is bare, no matter how valid your ID is.

The second setting catches almost everyone once. On Bedrock, foundation models are opt-in per account, per region: even in a region that does carry Claude, a brand-new account sees zero models until a human clicks through Model access → request access in the Bedrock console and it's granted. This is deliberate — it's AWS making you consciously agree to each provider's terms before you can spend money on their model — but it means the fix for "my list is empty" is almost never in your code. It's a one-time, per-region checkbox in the console. The common mistake is enabling access in us-east-1, watching it work, then being baffled when the identical script fails in us-west-2: enablement doesn't travel between warehouses.

Why do practitioners bother with more than one region at all, if it's this fiddly? Latency (serving users closer to a warehouse near them), resilience (a fallback if one region has an outage), data-residency rules (some data must stay in a specific geography), and plain availability (a specific model or quota you need may only exist in certain regions). The practical habit this section is teaching: treat "which region?" and "is model access on here?" as the first two things you verify in any new environment — before you debug a single line of inference code.

Not every model is in every region. Claude on Bedrock is broadest in us-east-1 and us-west-2. Before a model works you must enable model access once in the Bedrock console (Model access → request). This is a one-time, per-account, per-region step.

list_models.pyimport boto3

# List the foundation models your account can see in this region.
bedrock = boto3.client("bedrock", region_name="us-east-1")   # control-plane client
models = bedrock.list_foundation_models(byProvider="Anthropic")

for m in models["modelSummaries"]:
    print(m["modelId"], "-", m["modelName"])

anthropic.claude-3-5-sonnet-20241022-v2:0 - Claude 3.5 Sonnet
anthropic.claude-3-5-haiku-20241022-v1:0 - Claude 3.5 Haiku
anthropic.claude-3-opus-20240229-v1:0 - Claude 3 Opus

The cost model advanced

The war story here is always the same, and it always stings. An engineer spins up a SageMaker endpoint on a Friday to test a model, gets it working, closes the laptop, and moves on. No calls go to it over the weekend — zero traffic. Monday morning the finance channel lights up: the endpoint quietly billed for every hour it existed, idle or not, and a "quick test" turned into a four-figure surprise. Nobody did anything wrong except misunderstand how the resource charges. Getting the cost model right — not the exact prices, which drift — is what separates an architecture that scales affordably from one that hemorrhages money while doing nothing.

The distinction that governs everything is pay-per-use versus pay-per-time. Picture two ways of getting somewhere: a taxi charges only while you're riding and costs nothing parked at the curb; a rental car charges by the day whether it moves or sits in the driveway. Bedrock and the pre-built AI services are taxis — you're billed only for the work you actually request (tokens processed, pages read, minutes transcribed), and when no requests arrive, the meter reads zero. They scale to zero. A SageMaker real-time endpoint is a rental car: you're paying for a provisioned instance by the hour, and that clock runs whether or not a single prediction flows through it.

This is why "scales to zero?" is the one column in the table below worth memorizing. It reframes the cost question from "how much per call?" to the far more important "does this thing keep charging me when I'm not using it?" For a service that scales to zero, forgetting about it costs you nothing — a prototype you abandon simply stops billing. For a service that doesn't, forgetting about it is exactly how the weekend-endpoint story happens. The discipline this teaches is a habit, not a formula: anything billed per instance-hour must be explicitly torn down when idle — deleted, or fronted by autoscaling that can drop to zero — because AWS will never do it for you.

A second, subtler point for the token-billed layers: Bedrock, like the Anthropic API, prices input and output tokens separately, and output is usually the pricier of the two. That means the cheapest lever you have on Bedrock spend often isn't switching models — it's writing prompts that produce tighter answers, since every extra sentence the model generates is billed. Cost on the taxi layers is a simple, predictable, linear function of tokens you can estimate offline before you ever send a request (which is exactly what the practice exercises below build).

Bedrock bills per token, like the Anthropic API, but on the AWS bill. Pre-built AI services bill per unit (per page for Textract, per minute for Transcribe). SageMaker endpoints bill per hour the instance is running — a real trap: an idle endpoint still costs money. The rule for automation: Bedrock and AI services are pay-per-use (scale to zero); SageMaker real-time endpoints are pay-per-hour (remember to delete them).

import boto3

session = boto3.Session(region_name="us-east-1")
ident = session.client("sts").get_caller_identity()
print(ident["Account"], ident["Arn"])

import boto3

bedrock = boto3.client("bedrock", region_name="us-east-1")
resp = bedrock.list_foundation_models(byProvider="Anthropic")
for m in resp["modelSummaries"]:
    print(m["modelId"], "-", m["modelName"])

import boto3

control = boto3.client("bedrock", region_name="us-east-1")          # manage
runtime = boto3.client("bedrock-runtime", region_name="us-east-1")  # run

control.list_foundation_models()          # OK on control plane
# control.converse(...)                    # AttributeError -- wrong client
runtime.converse(                          # inference lives here
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role":"user","content":[{"text":"hi"}]}],
)

def call_cost(in_tok, out_tok, in_per_k, out_per_k):
    return in_tok/1000*in_per_k + out_tok/1000*out_per_k

c = call_cost(1200, 400, 0.003, 0.015)
print(round(c, 6))   # 0.0096  (0.0036 in + 0.0060 out)

def choose_layer(need_custom_model, task_is_narrow_prebuilt):
    if task_is_narrow_prebuilt:
        return "prebuilt"     # Textract/Comprehend/Rekognition, pay-per-unit
    if need_custom_model:
        return "sagemaker"    # train/host your own; endpoint billed per hour
    return "bedrock"          # managed FMs, pay-per-token, scales to zero

print(choose_layer(False, True))   # prebuilt
print(choose_layer(True,  False))  # sagemaker
print(choose_layer(False, False))  # bedrock

PRICES = {"anthropic.claude-3-5-sonnet-20241022-v2:0": (0.003, 0.015)}

def monthly_projection(model, in_tok, out_tok, reqs_per_day, budget, days=30):
    in_k, out_k = PRICES[model]
    per_call = in_tok/1000*in_k + out_tok/1000*out_k
    total = per_call * reqs_per_day * days
    return {"per_call": round(per_call, 6),
            "monthly": round(total, 2),
            "over_budget": total > budget}

print(monthly_projection("anthropic.claude-3-5-sonnet-20241022-v2:0",
                         in_tok=1500, out_tok=500, reqs_per_day=20000,
                         budget=5000))

Knowledge check check yourself