Starting a second Amplify Gen 2 project usually takes a few minutes. You clone the same Next.js starter you used for the first one, install the dependencies, and run npx ampx sandbox in the new folder.

That first deploy fails. When you look closer, the command targeted the sandbox of your other project. A quick search suggests giving the new sandbox its own name, so you run npx ampx sandbox --identifier blog, and this time it deploys cleanly.

The next morning you open the first project, start its sandbox as usual, and the deploy stops a few seconds in:

[ERROR] [UnknownFault] ToolkitError: ❌  amplify-awsamplifygen2-alex-sandbox-a8968da97f failed: NotFoundException: API key not found: da2-...

Nothing changed in that project. Its code is the same as yesterday, and its sandbox was healthy when you closed the terminal. The trouble comes from an assumption most of us make without noticing: that a sandbox belongs to the folder you run it from.

In this article, we will look at how two projects end up sharing one sandbox, how to recover from the ampx sandbox api key not found error, and how to prevent it with sandbox identifiers.

Where the Sandbox Name Comes From

The sandbox setup docs say a deploy creates a CloudFormation stack named amplify-<app-name>-<$(whoami)>-sandbox. The ampx source fills in the details. The app name is the name field of the package.json in the directory where you run the command. The second part is your system username, or the value of --identifier when you pass one. A short hash of those two values goes on the end.

The folder path is not one of the inputs. Two folders with the same package.json name, run by the same user, resolve to the same stack.

Starter templates make this easy to hit. The Next.js starter ships with "name": "aws-amplify-gen2" in its package.json, and many projects never change that line. Running the naming logic from @aws-amplify/backend-cli 1.10.0 for a user called alex gives these stack names:

~/code/shop                      amplify-awsamplifygen2-alex-sandbox-a8968da97f
~/code/blog                      amplify-awsamplifygen2-alex-sandbox-a8968da97f
~/code/blog --identifier blog    amplify-awsamplifygen2-blog-sandbox-8b27e47144
~/code/blog, name "blog-app"     amplify-blogapp-alex-sandbox-11c16b5c72

The first two lines are the same stack. The last two are separate stacks, which is what you expected to get from the start.

How a Shared Name Turns Into “API Key Not Found”

This exact sequence is recorded in amplify-backend issue #3044. The reporter started a new project, ran npx ampx sandbox, and got an error. They then realized the command was deploying to the existing project's sandbox, moved the new project to --identifier project2, and that deploy worked. Back in the original project, every redeploy failed with NotFoundException: API key not found.

A maintainer traced the failure to the AppSync API key. According to that investigation, “CloudFormation still has a reference to the old API key ID”, tries to update it, and AppSync replies that the key does not exist. The log in the issue shows UpdateApiKeyCommand as the last AWS call before the deploy failed.

The issue is still open, labeled as a bug at priority p2, and no fix or safe in-place repair has been published. Until then, the practical step is to stop two projects from sharing a stack, which is the part you can control.

Confirm It Before Deleting Anything

Before you remove anything, check that this Amplify sandbox redeploy error really comes from a shared name:

1. Read the stack name in the error line. It starts with amplify-, then the package name with punctuation removed, then the sandbox name.
2. Open package.json in each of your Amplify projects. If two of them have the same name and you ran both without --identifier, they shared a stack.
3. Open Manage sandboxes in the Amplify console, which lists the sandboxes in your account, their status, and last update.

If each project has a different name, the shared stack isn't the cause here. The issue thread is then a better place to compare your logs with the ones already reported.

Recovering the Sandbox

Clearing local build files is the usual first step. In the issue, rm -rf cdk.out .amplify did not help. The mismatch is in the deployed stack, so files on your machine are not where they can be repaired.

Deleting the CloudFormation stack from the AWS console is also tempting. The maintainer withdrew that suggestion in the same thread and advised against it without a full backup, because removing the stack can remove the data in your sandbox tables and buckets.

The route the Amplify team recommends is to delete the sandbox with ampx and create it again. Run this from the project whose sandbox is broken, before you rename anything:

npx ampx sandbox delete
npx ampx sandbox

If the broken sandbox was started with a name, pass the same name to the delete command, for example npx ampx sandbox delete --identifier blog.

This removes the data in that sandbox. The team is direct about it in the thread: sandboxes are meant to be ephemeral, and the setup docs already describe cases where Amplify drops and recreates tables or user pools during normal sandbox work. If you need test data in the new sandbox, the seed feature lets you script it and load it with npx ampx sandbox seed. The reporter resolved the issue the same way, by deleting the sandbox and creating a new one.

Preventing It: One Name per Project, One Identifier per Sandbox

The lasting fix is a unique name in every project's package.json, set before its first sandbox deploy. For the second project in this example, change "name": "aws-amplify-gen2" to "name": "blog-app".

Changing the name changes the stack name, so Amplify treats the project as a new sandbox. The old stack stays in your account until you delete it, which is why the recovery step comes first.

When you want more than one sandbox for the same project, use an ampx sandbox identifier:

npx ampx sandbox --identifier feature-auth

A few details matter once you start using identifiers:

• The CLI accepts letters, numbers, and hyphens, up to 15 characters.
• Secrets are stored per sandbox. According to the sandbox features docs, a named sandbox needs its own values, set with npx ampx sandbox --identifier feature-auth secret set <name>.
• You can switch between named sandboxes, but only one can run at a time.
• Each deploy writes amplify_outputs.json to the project root, so your frontend talks to whichever sandbox deployed last.

The same docs recommend one sandbox per developer per app, since multiple sandboxes make it harder to track which code is deployed where.

Final Thoughts

The API key in the error message is where the deploy failed. The cause happened earlier, when two projects resolved to the same sandbox name. Amplify builds that name from the package.json name and your username, and the folder you run the command in plays no part.

If you only ever work on one Amplify project, the default name is fine. The check matters on the day you start a second project from the same template, and it takes one line in package.json.

FAQ

What does “NotFoundException: API key not found” mean on a sandbox redeploy?

When you see the ampx sandbox api key not found error, CloudFormation is trying to update an AppSync API key that no longer exists. In the reported case, it followed two projects deploying to the same sandbox stack.

Will npx ampx sandbox delete remove my data?

Yes. It deletes the resources in that sandbox, including its tables. Use the seed feature if you need test data again.

What is a sandbox identifier?

A name you pass with --identifier. It replaces your username in the sandbox stack name, so one project can have several separate sandboxes. It accepts letters, numbers, and hyphens, up to 15 characters.

Next in this series: sandbox hot reload failing with an “already exists” error, and how to recover without starting over.

“API Key Not Found” on Sandbox Redeploy: Using Sandbox Identifiers was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 3 of 5 · SageMaker Without an ML Team. The full series is listed at the end.

Imagine hiring an events company to hand out name tags at a dinner for five friends. They’d do a great job, but you’d be paying for staff, scheduling, and coordination you never needed. You could just write the name tags yourself.

That’s how SageMaker Ground Truth, AWS’s service for labeling training images, felt for our small team. We stopped using it early in 2026. Then AWS closed it to new customers on 30 July 2026 and shut it down completely on 30 September 2026, alongside Mechanical Turk. Here’s why it didn’t fit us and the much simpler setup that replaced it.

What Ground Truth does

To train an image model, someone has to look at each photo and say what’s in it. That’s labeling. Ground Truth helped you manage that work: it found or organised the people doing the labeling, sent them photos, checked their quality, and combined their answers when several people labeled the same photo.

That’s genuinely useful if you need hundreds of thousands of photos labeled once by people you don’t employ.

Why it didn’t fit us

Our situation was the opposite:

• Our labelers were our own colleagues. No outside workforce to manage.
• Nobody labeled the same photo twice, so there were no answers to combine.
• New photos arrived every day in small batches. The real job was “label last night’s 40 photos," a five-minute task, not a big labeling project.

Ground Truth is built around big, one-off labeling jobs. Every batch meant setting up a new job, waiting, and checking it the next day. And you can’t edit a job, only copy it. When someone mistyped a job name, the only fix was to stop it and start a new copy. The typo stayed in the console forever.

Our console ended up with seven jobs that produced two usable datasets. The per-photo fee was small. The real cost was all the setting up, waiting, and redoing.

The surprise: training only needs one file.

When we looked at what Ground Truth actually produced, it was just a text file. One line per photo, saying where the photo is stored and which labels it has:

{"source-ref": "s3://my-bucket/images/img_0417.jpg", "my-labels": [0, 3, 7]}

SageMaker’s training never talks to Ground Truth. It only reads this file. (The real file has a few more housekeeping fields, which the training ignores.) So once you have your own labelers, you don’t need the service. You just need to produce the file.

What we built instead

The file is only one piece. Replacing ground truth took four:

• A labeling screen where our team opens a photo, ticks labels, and saves. The biggest piece.
• A file writer that turns saved labels into that one file. About an afternoon of work.
• A train/test split that decides which photos are for training and which are for testing. Harder than it looks (that’s a later post).
• A missing-photo check before training starts, so one deleted photo doesn’t crash the job (see Part 1).

Our labeling tool, in four screens

The tool follows the life of a photo: Unlabeled → Labeled → Train → Stats. A new photo arrives with no labels, someone labels it; it’s used in training; and the results show up in the stats. Every screen stays clickable, so you can check the stats first and then go label whatever’s missing.

AI suggestions, with two rules

We added AI suggestions that propose labels for a photo. To keep the data trustworthy, two rules are written at the top of that part of the code:

• The AI only runs when you ask it to. Opening the screen costs nothing.
• Nothing is saved without a person clicking Accept.

There is an “Accept All” button, so a tired person could accept 50 suggestions without looking closely. To catch that, every accepted label records one of two values: accepted as suggested or edited before accepting.

That one small detail tells us how good the AI really is. If people edit a lot of suggestions, the AI isn’t good enough yet. If someone accepts hundreds with zero edits, they probably weren’t looking.

What we gave up

Our old, rough labeling tool had keyboard shortcuts: number keys for labels and Enter to save and move on. The new tool is mouse-only. It’s much better in almost every way but slower per photo. We chose trustworthy data over speed per photo, and keyboard shortcuts are on the list.

If you’re replacing a labeling service

1. Do you employ your labelers? If yes, you probably don’t need a workforce service.
2. What file does your training actually read? Produce that file yourself.
3. Does your labeling tool make it easy to label small batches every day?
4. If you use AI suggestions, does a person always approve them?
5. Do you record whether the AI’s suggestion was edited? That’s how you’ll know if it’s any good.

Final thoughts

Ground Truth was a good product for big, one-off labeling projects with outside workers. For a small team labeling a few photos every day, it was mostly overhead. The training only ever needed one file, and producing that file ourselves turned out to be the easy part.

Next in this series: why your train/test split might be quietly leaking, and how that makes a model look better than it is.

References

• Amazon is shutting down Mechanical Turk and SageMaker Ground Truth (Encord).
• Amazon closes Mechanical Turk on September 30 (Let’s Data Science)
• Augmented manifest files for SageMaker training

If this helped, give it a clap and follow for more practical breakdowns on cloud and AI.

Read the series: SageMaker Without an ML Team

1. 5 Mistakes That Wasted Our Money on AWS SageMaker
2. Your ML Experiment Just Became Everyone’s Default
3. Life After SageMaker Ground Truth (you are here)
4. Your Train/Test Split Is Probably Leaking
5. How We Moved Our Whole SageMaker Setup to Another AWS Region

Life After SageMaker Ground Truth: How We Replaced AWS Labeling With One File and Our Own Tool was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS Lambda environment variables are a convenient way to keep configuration outside your application code. But as a function grows and depends on more services, those values can eventually hit Lambda’s 4 KB total environment-variable limit.

When that happens, the better solution is usually not to keep removing or shortening variables. It is to reconsider where that configuration should live.

One practical option is AWS Systems Manager Parameter Store.

Why the 4 KB Limit Becomes a Configuration Problem

A Lambda function may start with only a few environment variables, but the list often grows as the application becomes more complex. It may eventually need database names, API endpoints, S3 bucket names, queue URLs, service configuration, feature settings, and environment-specific values.

For example:

DATABASE_NAME
API_BASE_URL
BUCKET_NAME
QUEUE_URL
SERVICE_URL
SERVICE_KEY
LOG_LEVEL
OTHER_CONFIGURATION

The important detail is that Lambda does not provide 4 KB for each variable. The combined size of all environment-variable names and values must fit within 4 KB.

This means a function can work normally for a long time and then suddenly fail during deployment after only one or two new values are added. The application code may be completely valid; the problem is simply that the function configuration has grown beyond what Lambda allows.

Removing an unused variable or shortening a value might temporarily make the deployment work again, but that does not really solve the problem. If the application continues to grow, the same limit is likely to appear again.

At that point, the issue is no longer just about fitting another value into Lambda. It becomes a configuration design question: does every configuration value really need to live directly inside the function?

Small values that are closely tied to the function can still remain as environment variables. But larger values, shared configuration, or settings that need to be managed centrally can be moved outside Lambda.

This is where AWS Systems Manager Parameter Store becomes useful. Instead of storing every full value inside the Lambda environment, the function can keep only a small reference and retrieve the actual configuration when it needs it.

Where AWS Systems Manager Fits

AWS Systems Manager is a broader AWS operations service, not just a configuration store. It includes several tools for managing AWS and hybrid environments.

For example, Session Manager can provide controlled access to managed machines without relying on traditional SSH connections. Run Command can remotely execute commands, Patch Manager helps manage patching, State Manager helps keep systems in a desired configuration, and Automation can run operational workflows.

For the Lambda environment-variable problem, the relevant part is Parameter Store. Parameter Store provides a central place to keep configuration values such as service endpoints, resource identifiers, environment settings, and other application parameters. Instead of copying every full value into the Lambda environment, the function can retrieve the values it needs from Parameter Store at runtime.

A Lambda environment could therefore contain only a small configuration reference such as:

CONFIG_PATH=/myapp/prod

while the actual values live in Parameter Store:

/myapp/prod/service-url
/myapp/prod/service-key

This reduces pressure on the Lambda environment-variable limit and also gives the configuration a more organized structure.

Moving Configuration from Lambda to Parameter Store

Suppose an application needs two values. One is a normal service URL, while the other contains sensitive configuration. Parameter Store allows them to be handled differently:

/myapp/prod/service-url
/myapp/prod/service-key

The service URL can be stored as a normal String, while the sensitive value can be stored as a SecureString.

The same path structure can also be used to separate environments:

/myapp/dev/service-url
/myapp/staging/service-url
/myapp/prod/service-url

This makes configuration easier to manage because development, staging, and production values don't need to be mixed together. More importantly, the Lambda no longer needs to hold every full value in its own environment. It only needs enough information to locate the correct parameters and permission to retrieve them.

Understanding Parameter Types and Parameter Tiers

One of the easiest things to confuse in Parameter Store is the difference between a parameter type and a parameter tier.

The parameter type describes how the value is stored. Parameter Store supports String, StringList, and SecureString. A normal String is suitable for ordinary configuration such as an endpoint URL, while SecureString is used when a value needs encryption with AWS KMS.

The parameter tier is a separate decision. The main tiers are Standard and Advanced, and they affect the size limits, available features, quotas, and cost.

This means these combinations are all possible:

• Standard String
• Standard SecureString
• Advanced String
• Advanced SecureString

The key point is that SecureString does not mean Advanced. A sensitive value can still be stored as a Standard SecureString.

For many Lambda configuration use cases, Standard parameters are enough. A Standard parameter supports up to 4 KB per parameter, while Lambda provides 4 KB for the entire collection of environment variables.

Advanced parameters increase the maximum size to 8 KB per parameter and provide additional features such as parameter policies and larger parameter quotas. They also have additional charges.

For a Lambda that only needs to move a few configuration values out of its environment, Standard parameters are often the simpler choice.

How SecureString and AWS KMS Work Together

A normal String parameter suits configuration that doesn't require additional protection. For sensitive values, Parameter Store provides SecureString, which works with AWS Key Management Service (KMS).

The two services have different roles. Parameter Store manages the parameter, while KMS performs the encryption and decryption operations used to protect SecureString values.

When Parameter Store creates a Standard SecureString, it uses a symmetric KMS key to encrypt the value before storing it. Later, when an authorized application requests the parameter with decryption enabled, Parameter Store works with KMS to decrypt it before returning the value.

A customer managed KMS key can also be used when stronger access control is required. This makes it possible to control more precisely which applications, users, or IAM roles are allowed to decrypt values protected by that key.

The choice depends on the security requirements. The AWS managed key is convenient for straightforward use cases, while a customer managed key provides greater control when different applications need clearly separated decryption permissions.

Lambda Still Needs IAM Permission

Moving configuration to Parameter Store does not automatically give a Lambda function access to it. The function uses its IAM execution role when requesting the parameters, so the role needs the required permissions.

For example, the Lambda may need:ssm:GetParameter or ssm:GetParameters . If a SecureString uses a customer managed KMS key, the execution role may also need:kms:Decrypt

Keep these permissions as narrow as possible. A production function, for example, could be allowed to read only parameters under:/myapp/prod/* , while a staging function could be limited to:/myapp/staging/* . This provides a cleaner security boundary than giving every Lambda permission to read every parameter in the account.

Retrieving Parameters Without Adding Unnecessary Latency

Lambda can retrieve Parameter Store values through the AWS SDK. A simplified Node.js example looks like this:

import {
  SSMClient,
  GetParametersCommand,
} from "@aws-sdk/client-ssm";


const ssm = new SSMClient({});
async function loadConfig() {
  const response = await ssm.send(
    new GetParametersCommand({
      Names: [
        "/myapp/prod/service-url",
        "/myapp/prod/service-key",
      ],
      WithDecryption: true,
    })
  );
  const config = {};
  for (const parameter of response.Parameters ?? []) {
    config[parameter.Name] = parameter.Value;
  }
  return config;
}

The WithDecryption: true option tells Parameter Store to return decrypted values for SecureString parameters when the caller has the required permissions.

One important difference exists between environment variables and Parameter Store. Reading an environment variable happens locally inside the Lambda runtime, while retrieving a Parameter Store value normally involves an AWS API request.

For configuration that rarely changes, making that request on every Lambda invocation is unnecessary. The values can often be loaded once and cached in memory while the Lambda execution environment remains warm.

let cachedConfig;

export const handler = async (event) => {
  if (!cachedConfig) {
    cachedConfig = await loadConfig();
  }
  // Use cachedConfig
};

AWS also provides the Parameters and Secrets Lambda Extension, which can retrieve and cache Parameter Store and Secrets Manager values locally. For small functions, simple in-memory caching may be enough, while the extension becomes more useful when configuration access becomes more frequent or complex.

Cost and When Secrets Manager Makes More Sense

For this Lambda configuration problem, Standard Parameter Store is usually the cheapest option. Standard parameters have no additional storage charge, and applications using the default standard throughput can access them without additional Parameter Store API charges.

There is an important difference between Lambda’s 4 KB limit and Parameter Store’s 4 KB limit. In Lambda, the combined size of all environment-variable names and values must fit within 4 KB. With Standard Parameter Store, each individual parameter can contain a value up to 4 KB.

For example, these can all be separate Standard parameters:

/app/service-url      → up to 4 KB
/app/database-name    → up to 4 KB
/app/service-key      → up to 4 KB

These parameters do not share one 4 KB space. Each parameter has its own maximum value size. This is why moving larger configuration values out of Lambda can help: instead of forcing all configuration into Lambda’s single 4 KB environment-variable limit, the values can be stored separately in Parameter Store.

Suppose a Lambda moves two values into Parameter Store: a service URL stored as a String and a sensitive value stored as a SecureString. If both use the Standard tier and the application stays within normal throughput, there is no additional Parameter Store storage charge or standard-throughput API charge. For a small configuration like this, the Parameter Store cost itself can effectively be $0.

Advanced parameters are different. They support values up to 8 KB per parameter, compared with 4 KB for Standard parameters, and also provide features such as parameter policies, higher parameter quotas, and cross-account sharing. Advanced parameters have additional charges, so they are more useful when those extra capabilities are actually required rather than simply because a value needs encryption.

SecureString introduces another part of the cost because it uses AWS KMS for encryption and decryption. When Parameter Store uses the AWS managed AWS/SSM KMS key, there is no monthly storage charge for that AWS managed key. KMS request charges can still apply depending on usage, and AWS currently provides a free tier for eligible KMS requests. A customer managed KMS key, on the other hand, introduces a key charge as well as applicable request charges.

This is also where AWS Secrets Manager becomes worth considering. Parameter Store is well suited to application configuration and relatively static encrypted values, while Secrets Manager is designed more specifically for credentials such as database passwords, API keys, OAuth tokens, and other secrets that may need features such as automatic rotation and stronger secret lifecycle management. AWS charges Secrets Manager based on the number of secrets stored and the API requests made to the service.

For the Lambda 4 KB problem discussed here, Standard Parameter Store is usually enough when the goal is simply to move growing application configuration outside the Lambda environment. Advanced Parameter Store becomes useful when larger values or additional Parameter Store features are required, while Secrets Manager is generally the better choice when the value is a real credential that needs automatic rotation or more dedicated secret management.

The Better Way to Think About the 4 KB Limit

The Lambda 4 KB environment-variable limit may look like a simple quota issue, but it can also signal that application configuration is outgrowing the function itself.

Environment variables are still useful for small, function-specific values. But as configuration grows, AWS Systems Manager Parameter Store provides a cleaner way to manage those values outside Lambda.

For most cases, String works for normal configuration, SecureString KMS can protect sensitive values, and Standard parameters are usually enough unless you need advanced features. IAM controls which functions can retrieve the parameters, while caching helps avoid unnecessary requests.

The goal is not to replace environment variables completely. It is to use them where they make sense and move growing configuration to a service designed to manage it.

Connect with Me

LinkedIn: https://www.linkedin.com/in/pathumscj

How to Fix the AWS Lambda 4 KB Environment Variable Limit was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 2 of 5 · SageMaker Without an ML Team. The full series is listed at the end.

Imagine a shared office with one thermostat. You feel cold, so you turn it up “just to test. " It feels better, so you leave it. Now everyone in the office is living with your test, and three weeks later nobody remembers why it’s set to 26°C.

That’s what happened to our model training on AWS SageMaker. To try a new setting, we changed the default in the code. The test worked, so it stayed, and every training run after that quietly used our experiment. An experiment had become a rule, and nobody had decided that.

How it used to work

In our project, the training settings (how fast the model learns, how many rounds it trains for, and so on) lived in one place in the code. To try something new, you:

• Changed the number in the code.
• Saved it and deployed it.
• Started a training run.

The run looked a bit better, so you moved on. But the next person to train a model, maybe days later, got your test value without knowing it was ever a test.

The fix: settings for one run only

Now each training run can carry its own changes. You pick the settings you want to try; they apply to that run only, and they’re saved with the run. The defaults don’t move unless someone changes them on purpose.

That part is simple. Four small rules around it are what made it safe.

Rule 1: Reject setting names you don’t recognize.

SageMaker’s built-in training silently ignores settings it doesn’t recognize. No error, no warning.

So if you mistype learning_rate as learning_rte, the job doesn't fail. It trains with the normal value, finishes, and reports a score under the name of an experiment that never actually happened. That's worse than a crash, because you'd believe it.

The fix: check every setting name against a list of allowed names before the job starts. If it’s not on the list, stop and say which names are allowed.

Rule 2: Some settings are off-limits.

A few settings must never be changed by hand, like the number of labels the model predicts or the image size. Change those, and you get a model that gives confident, wrong answers. So the system fills them in itself last, after everything else, so nothing can overwrite them.

Other settings are fine to change, except in one case. When you build on top of an earlier model to save time, the new run must match the old model’s shape. If it doesn’t, SageMaker only notices after the GPU has started billing, and the job crashes. So we block those changes up front, for that kind of run only.

Rule 3: Save the full settings and what you changed.

Each run saves two things: all the settings it used and only the ones you changed.

Saving both sounds like overkill. But defaults change over time. If you only saved the full list, then six weeks later you’d compare it to today’s defaults, and it would look like you changed things you never touched. Saving “what I changed” at the time avoids that confusion.

Rule 4: Compare everything that changed side by side.

This is the rule that matters most, and it applies to any team running experiments.

Say a run improved by 1.4 points after you changed a setting. Great? Not necessarily. If 400 new training images were also added since the last run, you can’t tell which one caused the improvement.

So our comparison screen shows three things together:

• How much the score changed.
• Which settings changed.
• How much new data was added.

If both the settings and the data changed, it says so. A comparison that hides the data change would quietly give your settings the credit.

A small bonus: a word for “off”

Our team wanted an option called “none” for image augmentation (randomly cropping or tweaking photos during training). SageMaker has no “none” value. The only way to turn it off is to leave the setting out completely, and if you send the word "none," the job fails.

So when someone picks "none," our system simply removes the setting before the job starts. It’s two lines of code, and it’s a good reminder: sometimes what a user means and what the API accepts are different things, and your code has to translate.

Your checklist for safer experiments

1. Does trying something change the default for everyone? If so, make it a per-run setting instead.
2. Are setting names checked before the run starts?
3. Are the risky settings filled in by the system, not by hand?
4. Do you save what was changed at the time it was changed?
5. Does your comparison show the score, the settings, and the new data together?

Final thoughts

Trying something should never quietly change how everything works. Keep experiments separate from defaults, record what you changed, and always look at what else changed before you give a setting the credit.

Next in this series: why we left AWS’s labeling service, Ground Truth, before AWS shut it down, and what we built instead.

References

• Amazon SageMaker image classification settings (hyperparameters)
• Incremental training in Amazon SageMaker

If this helped, clap and follow for more practical breakdowns on cloud and AI.

Read the series: SageMaker Without an ML Team

1. 5 Mistakes That Wasted Our Money on AWS SageMaker
2. Your ML Experiment Just Became Everyone’s Default (you are here)
3. Life After SageMaker Ground Truth
4. Your Train/Test Split Is Probably Leaking
5. How We Moved Our Whole SageMaker Setup to Another AWS Region

Your ML Experiment Just Became Everyone’s Default (and How We Fixed It on SageMaker) was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our database wasn’t slow. It was in the way. We run a multi-tenant SaaS web app on Amplify Gen 2, with AppSync for the API and Lambda for the business logic. It started on Aurora Postgres, which felt like the safe choice. Queries were fine. The trouble sat around the database instead, in shared environments, network setup, and business rules that ran at the wrong moment.

In August 2026, we moved the whole data layer to DynamoDB. In this article, we will walk through why we switched, how we rebuilt it, what improved, what broke, and when Aurora is still the better choice.

What Changes Between Aurora and DynamoDB?

Here are the basics before the story.

Most of this article comes back to two rows of that table, the one about queries and the one about rules.

Aurora lets you ask any question later. DynamoDB asks you to decide your questions now.

Where We Started: The Aurora Setup

AppSync talked to Aurora through a schema file generated by npx ampx generate schema-from-database. Ours hardcoded the VPC, subnet and security-group IDs. So every developer pointed at the same cluster, inside the same VPC, using the same set of database roles.

The Lambdas ran inside that VPC too. Each one needed network permissions, SQL secrets, and SSM endpoints to reach its configuration from inside the private network.

The schema itself lived in about 20 SQL migration files. Business rules lived there too, written as database triggers.

Why We Switched

None of this showed up on a latency graph. It showed up in how hard the system was to work on.

• No isolated environments: With one shared cluster, a schema change from one developer affected every other developer the moment it ran.
• Cold starts that looked like firewalls: The cluster paused when idle, and the first connection afterward timed out. The error looked like a firewall problem, not a sleeping database. AWS documents a typical resume time of about 15 seconds, and 30 seconds or more after a pause longer than a day.
• A fragile setup: Connection strings broke whenever the password contained special characters, and Windows developers had to install Postgres tools locally.
• Triggers that ran too late: Our rules were AFTER triggers, which fire once the row is already written. That made them good at reacting and bad at refusing. The balance check could race under READ COMMITTED, where two concurrent writes both read the same balance and both pass. Deleting a record could also leave its linked claim record behind.
• A trust gap: The server accepted user IDs sent by the client instead of taking them from the login token.

Why Not Just Fix Aurora?

It’s a fair question, and both obvious fixes exist. A cluster per developer would solve isolation, but every developer would then carry their own cluster, secrets, and resume delay, and the generated schema still pins one network configuration. The RDS Data API puts an HTTPS endpoint in front of the cluster, so Lambdas no longer need to sit in the VPC. Neither fix changes when a rule runs or where the user ID comes from. Those two problems needed new code, whichever database sat underneath.

How We Rebuilt It on DynamoDB

The goal was to change the storage without changing what the frontend saw.

Same API, New Storage

We kept all 31 models with the same names and fields, so the 96 existing frontend calls still compiled. That one decision lowered the risk of the switch more than anything else we did.

Uniqueness moved into the key. Of 22 UNIQUE constraints, 15 became part of a composite primary key. That also fixed two live bugs where a value was unique across all tenants instead of within one organization.

// amplify/data/resource.ts (simplified, authorization omitted)
const schema = a.schema({
  Member: a
    .model({
      organizationId: a.id().required(),
      email: a.email().required(),
      role: a.string(),
    })
    .identifier(['organizationId', 'email']),
});

.identifier() makes the pair the primary key, and Amplify's generated create mutation refuses a key that already exists. A raw PutItem would quietly replace the item instead, which matters again below.

We added 20 GSIs for the reads we knew about. One is a sparse index that only holds open sessions, because DynamoDB leaves out any item missing the index key. A background job that used to scan the full table now queries it.

Rules Before the Write

Every trigger became a server-side custom mutation. Each one checks its rules before writing and reads the user from the verified token, never from the arguments (our authentication vs authorization guide covers why).

The balance check is now one TransactWriteItems call with a condition. DynamoDB checks the condition and applies the change atomically, so two concurrent requests can’t both spend the same balance. If the condition fails, nothing in the transaction is written.

const userId = event.identity.sub; // from the token, never from args
await ddb.send(new TransactWriteCommand({
  TransactItems: [
    {
      Update: {
        TableName: ACCOUNTS_TABLE,
        Key: { accountId },
        UpdateExpression: 'SET balance = balance - :amount',
        ConditionExpression: 'balance >= :amount',
        ExpressionAttributeValues: { ':amount': amount },
      },
    },
    {
      Put: {
        TableName: LEDGER_TABLE,
        Item: { accountId, entryId, amount, createdBy: userId },
        ConditionExpression: 'attribute_not_exists(entryId)',
      },
    },
  ],
}));

Special Cases, Designed Around Their Reads

The document-signing module uses a single-table design. Everything that belongs to one document lives in one partition, so loading a document is one Query instead of a six-way join.

The audit log is append-only, enforced by IAM. Its writer role can callPutItem, never UpdateItem or DeleteItem. IAM can't stop a PutItem from replacing an item with the same key, though, so every write also carries attribute_not_exists. That condition anchors a hash chain, with capped retries when two writers race for the same position.

Rate limiting moved from WAF to a TTL-based counter table. TTL deletion runs in the background and can lag, so a limiter like this has to compare timestamps rather than trust that expired items are gone.

What Got Better

The wins showed up in daily work.

• Isolated sandboxes: Every developer gets their own, with just two sign-in keys to set up.
• Less to run: No VPC, cluster, connection strings, or SQL secrets to manage.
• Lower idle cost: We pay per request; nothing runs when idle, and dropping WAF and CloudTrail saves about $11 to $20 a month.
• Rules at write time: Every rule is checked before the write, and the user comes from the token.
• Predictable reads: Planned reads are fast and stay predictable.

Real Problems After the Move

This is the section we wish someone had written for us. Several of these bugs returned something that looked like success.

1. List pages scanned the whole table

Some lists called list with a filter. In Amplify Data that runs aScan, which reads items first and filters afterward, so its cost grows with the table rather than with the result. We moved them to index queries with paging.

// Before: Scan, filtered after the read
client.models.Session.list({ filter: { organizationId: { eq: orgId } } });
// After: Query on a GSI, one page at a time
client.models.Session.listSessionByOrganizationId(
  { organizationId: orgId },
  { limit: 50, nextToken },
);

2. A job returned nothing, though matches existed

DynamoDB applies Limit to the items it reads, then filters them. So a page can hold zero matches while LastEvaluatedKey says more exist. Keep paging until that key is gone, or better, design an index that makes the filter unnecessary.

3. Revoke ran, and nothing was revoked

We stored revoked_at: null on new items. In DynamoDB, an attribute set to null still exists, with the NULL type. So every attribute_not_exists(revoked_at) check evaluated to false, and revoking silently did nothing.

4. One field name broke the hash chain

One code path wrote headSeq and another read head_seq. DynamoDB has no schema to object, so the hash-chain checkpoints broke without an error. Counting this one, we found 13 bugs after the move that our 263 unit tests had missed.

5. The sync finished, and users saw “failed”

AppSync caps request execution time at 30 seconds. A long sync kept running and finished its work, but the request had already timed out. Work that can pass 30 seconds has to be started by the request and finished somewhere else.

6. Deploys outgrew CloudFormation

A nested stack hierarchy can create, update, or delete at most 2,500 resources in one CloudFormation operation. Our backend reached about 2,995, so a fresh deploy now takes two steps. (IAM inline policy size is another ceiling large Amplify backends hit.)

Permissions added a quieter delay. Changes can take minutes to take effect after a deploy, so a test run straight afterward can fail on access that’s already granted.

Limitations and Trade-offs

DynamoDB asks for decisions up front, and some of its costs never go away.

• Access patterns come first: A new query usually means a new GSI.
• No joins or ad hoc SQL: Reporting and analytics get harder.
• GSIs are eventually consistent: A read right after a write can miss it.
• Denormalized counters drift: You need checks that catch it.
• Size limits: 400 KB per item, and a transaction holds up to 100 items or 4 MB.
• Security trade-offs we accepted: The rate limiter won’t stop a large DDoS the way WAF would, and the key-usage audit now runs weekly instead of in real time.

How to Choose, and What We’d Tell You

Choose Aurora when reporting is heavy, when new queries show up often, or when your data is full of relationships you need to join.

Choose DynamoDB when you know your access patterns, your stack is already serverless, your traffic rises and falls, or your developers need isolated environments.

The lessons we’d pass on are short. List your queries before you design a table. Never scan where a user is waiting. Treat null and missing as different values, because DynamoDB does. And run end-to-end checks, because unit tests can’t catch everything.

DynamoDB didn’t make things simpler. It moved the complexity from running servers to designing data, and for us that was the better place for it.

Aurora vs DynamoDB: Why We Switched, and What It Cost Us was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you want an AI that does more than answer questions. You want it to check a value, run a calculation, or call one of your own functions, and then explain the result in plain language.

Your first thought might be to write the whole thing yourself. Call the model, read the reply, check whether it wants to use a tool, run that tool, send the result back, and repeat until it is done.

And yes, that works. But it is a lot of plumbing for a first project, and most of it has nothing to do with what you actually want to build.

In this article, I’ll show you an easier way. We will build a working AI agent on AWS using Strands Agents, an open-source Python SDK, in under 30 lines of code. You do not need any agent experience to follow along.

By the end, you will know:

• What an AI agent really is, in simple words
• How to create your first agent in a few lines
• How to give it your own tools
• How the agent loop works behind the scenes
• Where Strands fits next to Amazon Bedrock AgentCore

What is an AI agent?

Before we write any code, let’s make sure we are talking about the same thing.

A normal chat model takes your question and gives you an answer. That is all it does. It cannot check anything, run anything, or call anything outside of itself.

An AI agent is different. It is a language model that can use tools and decide for itself which tool to use, when to use it, and when it is done.

Here is a simple way to see the difference:

• Chat model: “How much does a $0.05 per hour server cost per month if it runs 8 hours a day?” It tries to work it out in its head and writes an answer.
• Agent: It sees that you have given it a cost calculator, calls that calculator with the right numbers, reads the result, and then explains it to you.

The second one is more reliable because the maths is done by real code and not by a guess.

Every agent has three parts:

1. A model, which is the brain. It reads the request and makes decisions.
2. Tools, which are the hands. These are normal functions, such as a calculator, an API call, or a database lookup.
3. A prompt, which is the job description. It tells the agent what it is for and how to behave.

That is it. Everything else in the agent world is a variation on these three.

Can’t we just write the loop ourselves?

Absolutely, you can. An agent is not magic. It is a loop around a model call.

But as always, there are a few things to consider.

To do it by hand, you need to:

• Send the conversation to the model
• Check why the model stopped talking
• If it asked for a tool, check that the arguments are valid
• Find the right function and run it
• Catch any errors and pass them back
• Add the result to the conversation and call the model again
• Know when to stop

None of this is hard. But it is easy to get wrong, and you will rewrite it for every new project.

Enter Strands Agents

This is where Strands Agents comes into the picture.

Strands Agents is an open-source SDK from AWS for building AI agents. It runs that loop for you. You only describe three things: which model to use, which tools the agent can call, and what the agent is for.

A few things make it a good first choice:

• Small API. A working agent is a few lines of Python.
• Plain Python tools. A tool is just a normal function with a decorator on top.
• Amazon Bedrock by default. If your AWS credentials can call a Bedrock model, you are close to ready. You can also plug in other model providers.
• Open source. You can read the code and see what it does.

It also fits well with AWS’s bigger picture. In my Amazon Bedrock AgentCore article, I explained that AgentCore works with different agent frameworks. Strands is one of the frameworks you can build with before you decide where to run it.

Before you start

You only need a few things in place:

1. Python 3.10 or newer. The Strands quickstart asks for this.
2. An AWS account. A personal account is fine for learning.
3. AWS credentials on your machine. The simplest way is to run aws configure with the AWS CLI. Environment variables, IAM roles, and Bedrock API keys also work.
4. Access to a model in Amazon Bedrock. The Strands docs say you must enable model access for each model you plan to use. Open the Bedrock console in your region and check that the model you want is available to your account.
5. A region where that model is available. The Strands docs set the region in code in their examples, so we will do the same.

Two small tips before we continue.

First, never paste access keys into your code or commit them to Git. Let the AWS CLI or an IAM role handle credentials.

Second, every model call in Bedrock costs a little money. A few test prompts will cost very little, but it is a good habit to set up an AWS Budget alert before you experiment.

Step 01: Set up your project

Let’s start with a clean folder and a virtual environment, so the packages stay separate from the rest of your machine.

python -m venv .venv
source .venv/bin/activate
pip install strands-agents

On Windows, activate the environment with .venv\Scripts\activate instead.

That one package is enough for now.

Step 02: Create your first agent

Create a file called agent.py and add this:

from strands import Agent

agent = Agent()
agent("Explain in two sentences what Amazon S3 is.")

That is a complete agent. Run it with python agent.py.

The answer should appear in your terminal as the model writes it. Calling the agent also returns a result object, which is useful later when you want to use the answer in your own code.

So what just happened? With no settings at all, Strands picked a default model on Amazon Bedrock and sent your question to it. The Strands docs say the default model provider is Bedrock, and they name a Claude Sonnet model as the default.

If you see an access or region error, do not worry. It usually means your account cannot use that default model in your current region. We will fix that in Step 04 by choosing the model and region ourselves.

Right now, this is still just a chat model. It has no tools, so it cannot do anything except talk. Let’s change that.

Step 03: Give your agent a tool

Now for the interesting part.

In Strands, a tool is just a normal Python function with @tool on top. Let's build a small cost calculator, like the one we talked about earlier:

from strands import Agent, tool

@tool
def monthly_cost(hourly_rate_usd: float, hours_per_day: float = 24) -> float:
    """Estimate the monthly cost of a resource, using a 30-day month.

    Args:
        hourly_rate_usd: The price per hour, in US dollars.
        hours_per_day: How many hours per day the resource runs.
    """
    return round(hourly_rate_usd * hours_per_day * 30, 2)

agent = Agent(tools=[monthly_cost])
agent("A server costs $0.05 per hour. What does it cost per month if it runs 8 hours a day?")

Run it again. This time the agent should call your function. The correct answer is $12.00, because 0.05 × 8 × 30 = 12.

Notice what you did not do. You never called monthly_cost yourself. The agent read the question, decided the tool was the right one, filled in the arguments, and used the result in its answer.

Three small details make this work:

• The decorator. @tool tells Strands that this function is something the agent may call.
• The type hints. float and -> float tell the model what kind of values go in and come out.
• The docstring. This is the most important part. The model reads it to understand what the tool does and when to use it.

That last point is easy to miss. The model cannot see your code. It only sees the name, the types, and the description. If the description is vague, the agent will pick the wrong tool or skip it. The Strands docs give the same advice: read your descriptions from the model’s point of view, and make sure two tools never sound alike.

So write the docstring as if you were explaining the function to a new teammate.

Step 04: Choose your own model and region

So far, Strands picked the model for us. In real projects, you want to choose it yourself, for cost, speed, and quality. This is also the fix if you saw an access or region error earlier.

from strands import Agent
from strands.models import BedrockModel

model = BedrockModel(
    model_id="global.anthropic.claude-sonnet-4-6",
    region_name="us-west-2",
    temperature=0.3,
)

agent = Agent(model=model)

This is the same style the Strands quickstart uses. Here is what each setting means:

• model_id: which model to call. Use the ID of a model that your account can use. Model names and IDs change over time, so copy the current one from the Bedrock console instead of trusting this article.
• region_name: the AWS region where you call Bedrock.
• temperature: how creative the answers are. A lower number gives more consistent answers, which is usually what you want when an agent is calling tools.

Then pass the model to the agent with Agent(model=model), and add tools=[...] as before.

Step 05: Try the built-in tools (optional)

You do not have to write every tool yourself. Strands has a separate package with ready-made tools:

pip install strands-agents-tools

It includes tools for reading files, making HTTP requests, calling AWS services, running code in a sandbox, and more. You use them the same way as your own tools:

from strands import Agent
from strands_tools import http_request

agent = Agent(tools=[http_request])

A few honest notes before you use them:

• Some tools in that package are marked as deprecated in the project’s own tool list at the time of writing. Check the list before you depend on one. For something small, like our cost calculator, writing your own is often simpler.
• Tools that run code or write files, such as shell, python_repl and file_writeask for your permission first. Leave that safety check on while you are learning.
• The project describes these tools as experimental and recommends a security review before production use.

How does the agent loop work?

In Step 03, the agent decided on its own to call your tool. Here is what happened behind the scenes.

Each time around the loop, Strands sends the whole conversation to the model. If the model asks for a tool, Strands runs it and adds the result to the conversation. Then the model is called again. When the model stops asking for tools, its last message is your answer.

A few things are worth knowing:

• The loop can run more than once. If a question needs two tools, or the same tool twice, the agent simply goes around again. Each pass adds to the conversation, so the model can build on earlier results.
• A failing tool does not crash the agent. If your function raises an error, the error goes back to the model as a result. The model can then try again, pick another tool, or explain the problem.
• The loop can end in other ways. For example, you can cancel it, the answer can be cut off by the token limit, or a safety filter can block the output. Your application should be ready for these cases.

The full agent in under 30 lines

Here is everything together in one file. This is the agent we promised at the start, with a model, a tool, and a short job description (the system prompt):

from strands import Agent, tool
from strands.models import BedrockModel

@tool
def monthly_cost(hourly_rate_usd: float, hours_per_day: float = 24) -> float:
    """Estimate the monthly cost of a resource, using a 30-day month.

    Args:
        hourly_rate_usd: The price per hour, in US dollars.
        hours_per_day: How many hours per day the resource runs.
    """
    return round(hourly_rate_usd * hours_per_day * 30, 2)

model = BedrockModel(
    model_id="global.anthropic.claude-sonnet-4-6",
    region_name="us-west-2",
    temperature=0.3,
)

agent = Agent(
    model=model,
    tools=[monthly_cost],
    system_prompt="You are a friendly cloud cost helper. Use the tool for any cost maths.",
)

agent("A server costs $0.05 per hour. What does it cost per month if it runs 8 hours a day?")

That is 28 lines, blank lines included.

Run it with python agent.py. The exact words will be different each time, but the answer should come out as $12.00 per month.

Now try a follow-up on the same agent to see it reuse the tool:

agent("And what if it runs all day, every day?")

This time the answer should be $36.00, because 0.05 × 24 × 30 = 36. The agent remembers the earlier question, so you do not need to repeat the price.

That is a real agent. It has a brain, a tool, and a job, and it decides for itself when to use the tool.

Common beginner mistakes

Most first-time problems come from the same few places. Here are the ones to check first.

1. The model is not enabled for your account. You get an access error even though your code is fine. Open the Bedrock console, check model access in your region, and make sure your IAM user or role is allowed to invoke the model.
2. The region does not have that model. Not every model is available in every region. If one region fails, check the model’s availability, or change region_name.
3. No AWS credentials found. Python cannot see your login. Run aws configure, or use environment variables or an IAM role. Do not hard-code keys.
4. A vague tool description. If the agent ignores your tool or picks the wrong one, rewrite the docstring first. Say what the tool does, what each argument means, and when to use it.
5. Two tools that sound the same. The model chooses between tools by reading their descriptions. If two descriptions overlap, it is guessing. Make each one clearly different.
6. Turning off safety checks to save time. Strands tools that run code or write files ask for your permission. There is a setting to skip that check, but do not use it while you are learning.

Where does Strands fit with AgentCore?

If you read my earlier article, you may be wondering how this connects to Amazon Bedrock AgentCore.

The short answer is that they solve different problems:

• Strands Agents is how you build the agent. It is the code: the model, the tools, and the loop.
• Amazon Bedrock AgentCore is where you run and manage the agent in production. It gives you a place to run it, memory, secure tool access, identity, monitoring, and more.

You can learn Strands on your laptop first, with no extra services. When the agent starts to need real users, permissions, and monitoring, that is when AgentCore becomes useful. I explained that side in Amazon Bedrock AgentCore Explained for Developers.

AWS is also adding more around this area. For example, the October 13, 2026 AWS weekly roundup mentions Strands Box, open-source sandboxes for running agents more safely.

Final thoughts

Building an AI agent sounds like a big topic. But the core idea is small.

You give a model some tools, you tell it what its job is, and a loop does the rest. Strands Agents takes care of that loop, so you can spend your time on the tools and the problem you actually want to solve.

In this article, we:

• Learned what an AI agent is
• Created a first agent in three lines
• Added our own tool with @tool
• Chose a model and region with BedrockModel
• Put it all together in 28 lines

A good next step is to replace monthly_cost with a tool that does something useful in your own project, such as checking a status, looking up a record, or calling an internal API. Start with one tool, test it, and then add more.

Cheers!

Build Your First AI Agent with Strands Agents in Under 30 Lines was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building production-ready GenAI applications requires grounding your Large Language Models (LLMs) in real-time information. While static knowledge bases handle internal documentation well, applications often need to query the live web to fetch up-to-date data like regional product availability, breaking technical updates, or local compliance laws.

To solve this, developers rely on Web Retrieval-Augmented Generation (Web RAG).

However, untamed Web RAG introduces massive architectural vulnerabilities. If you let an LLM loose on the open internet, it will eventually pull data from low-quality forums, outdated blogs, or incorrect geographical regions, leading directly to hallucinations and confidently incorrect answers.

AWS just introduced a native fix for this engineering bottleneck.

Directly configured inside the web search tool payload, AWS Bedrock now supports Domain Filtering and User Location Controls. Here is a breakdown of why open-web RAG breaks at scale, and how to implement these new native boundaries to keep your enterprise AI agents accurate.

The Main Problem: The Chaos of Unfiltered Web RAG

When an AI model uses an open-web search tool to ground its answer, it typically behaves like a standard search engine without a human operator. It fetches the top structural results for a query and injects that context directly into the model prompt context window.

This introduces three critical points of failure:

• The Hallucination Vector: If a competitor’s site, a random Reddit thread, or a deprecated documentation page ranks highly for a specific query, the LLM will accept it as factual grounding text.
• Geographic Misalignment: Asking an LLM agent about “local logistics regulations” or “regional service availability” is useless if the underlying search engine defaults to a generic server region instead of the user’s actual location.
• Middleware Overhead: Up until now, preventing these issues required developers to write complex custom middleware to get search API results, parse URLs, filter out bad domains, and manually spoof headers for geolocation before passing clean text back to Bedrock.

The Solution: Native Bedrock Search Constraints

AWS has eliminated the need for custom preprocessing middleware by embedding structural search constraints directly into the Bedrock execution loop via the OpenAI Responses API.

1. Domain Filtering

You can now explicitly guide or restrict the model’s data sourcing by defining hard structural limits. The API allows you to pass up to 100 allowed domains to enforce strict whitelist restrictions (e.g., only pulling from your official documentation or trusted .gov entities). Conversely, you can specify up to 100 blocked domains to blacklist known problematic sites, outdated forums, or competitor pages.

2. User Location Controls

Instead of getting generic search results tied to the physical AWS data center hosting your infrastructure, you can now pass granular location parameters directly with the request metadata. This forces the underlying web search tool to retrieve geographically relevant snippets essential for bots handling localized pricing, local logistics, or regional product launches.

Architectural Implementation: The API Payload

These controls are configured directly within the existing web_search tool object. Below is a simulated example of how to implement both domain filtering and location parameters inside your standard Bedrock API request payload:

{
  "model": "amazon.titan-text-premier-v1",
  "messages": [
    {
      "role": "user",
      "content": "What are the latest compliance guidelines and registration requirements for commercial drone operators?"
    }
  ],
  "tools": [
    {
      "type": "web_search",
      "web_search": {
        "filters": {
          "allowed_domains": [
            "caa.lk",
            "gov.lk",
            "://amazon.com"
          ],
          "blocked_domains": [
            "unverifiedblogpost.com",
            "outdatedforum.net"
          ]
        },
        "user_location": {
          "country_code": "LK",
          "region": "Western Province",
          "city": "Colombo"
        }
      }
    }
  ]
}

Why this payload structure works:

• Zero Custom Scrapers: The whitelists and blacklists are enforced at the retrieval layer before data ever hits your application memory or the model’s context window.
• Context Preservation: By targeting the search specifically to Colombo, Sri Lanka, and whitelisting .lk domains, the model completely bypasses generic global regulations (like FAA rules in the US or CAA rules in the UK). This drastically reduces token wastage on irrelevant international text and eliminates geographic hallucinations.

Regional Availability

As of 23rd October 2026, native domain filtering and location controls are deployed across standard enterprise AWS environments, including:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• AWS GovCloud (US-West)

a massive win for highly secure public sector applications that require strict domain whitelists.

Building reliable GenAI isn’t just about picking the largest model; it’s about building deterministic guardrails around how that model consumes data. By locking down your web search boundaries directly at the tool layer, you ensure your application stays accurate, localized, and safe from internet noise.

For precise pricing metrics and architectural constraints, refer to the Web Search configuration segments inside the official AWS Bedrock User Guide.

Why Open Web RAG Fails in AWS Bedrock was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you are building an online store. Customers browse products, place orders, and check their purchase history. At the same time, admins need to look up orders and monitor the ones that are still being processed.

The real question is: how should you organize that data?

If you are used to relational databases, your first instinct may be to create separate tables and connect them with foreign keys. But DynamoDB works differently. Instead of designing the tables first, you start by thinking about the queries your application needs to support. Your key design determines which queries DynamoDB can handle efficiently.

Start With Access Patterns

Before designing a DynamoDB table, first understand how the application will use the data. In our store, customers need to view their profile and order history. Admins need to find individual orders and monitor orders that are still being processed.

Each of these is an access pattern. It describes how the application reads or writes data. Writing these access patterns down early makes the rest of the design much easier.

For our shopping application, the main access patterns are:

• Customer profile: Find a customer by customer ID.
• Recent orders: Get the latest 20 orders for a customer.
• Order history: Find a customer’s orders within a date range.
• Order lookup: Find an order using its order ID.
• Open orders: List orders that are still being processed.

Why Do These Details Matter?

Compare these two requirements:

• Get customer orders.
• Get the latest 20 orders for a customer, newest first.

The first tells us what data we want, but not much about how it should be returned. The second gives us more useful information.

We are retrieving orders for one customer, so the customer ID is a good candidate for the partition key. We also want the newest orders first, so the order timestamp belongs in the sort key. Now the key design begins to take shape.

With the customer ID grouping the orders and the timestamp keeping them in order, DynamoDB can return the latest orders directly without scanning the entire table.

Frequency matters too. A query that runs thousands of times an hour deserves more attention than an admin report that runs once a day. The goal is not only to know what data the application needs. You also need to understand how often that data will be requested and how it needs to be returned.

Design Keys Around Your Queries

Once the access patterns are clear, the key design usually becomes much easier.

Start With Customer Profiles

The first requirement is simple: find a customer by ID. A Customers table can use customerId as the partition key.

Table: Customers

customerId
----------
123
456
789

Every customer has a unique ID, so a GetItem request using customerId = 123 can return that customer’s profile directly. There is no need for a sort key here.

Design Keys for Customer Orders

Orders are a little more interesting. One customer can place many orders, and we need to retrieve those orders efficiently.

For this, we can create an Orders table with a partition key and a sort key.

Table: Orders

PK             SK
-------------  ------------------------------
CUSTOMER#123   2026-09-10T08:12:44Z#A102
CUSTOMER#123   2026-09-18T19:03:10Z#A117
CUSTOMER#123   2026-10-02T14:31:07Z#A145

The partition key groups all orders belonging to the same customer. The sort key contains the order timestamp followed by the order ID. The CUSTOMER# prefix is simply a naming convention that makes the purpose of the key easier to recognize when reading the data.

This structure supports several access patterns:

• Get customer orders: Query with PK = CUSTOMER#123.
• Get recent orders: Use ScanIndexForward: false and Limit: 20.
• Get orders within a date range: Use a BETWEEN condition on the sort key with timestamp boundaries.

The customer ID finds the group of orders, while the timestamp determines their order. Each part of the key has a clear job.

An Alternative: Single-Table Design

Now imagine the application often needs a customer’s profile and their orders together. Instead of keeping them in separate tables, you could store both types of items in the same table. This is one example of single-table design.

Table: Ecommerce

PK             SK
-------------  ----------------------------------
CUSTOMER#123   PROFILE
CUSTOMER#123   ORDER#2026-09-10T08:12:44Z#A102
CUSTOMER#123   ORDER#2026-09-18T19:03:10Z#A117
CUSTOMER#123   ORDER#2026-10-02T14:31:07Z#A145

All four items share the same partition key, which creates an item collection for the customer. The sort key prefixes, such as PROFILE and ORDER#, distinguish the different item types.

With this structure, you can:

• Get the profile and orders together by querying PK = CUSTOMER#123.
• Get only the orders with begins_with(SK, “ORDER#”).
• Get only the profile with GetItem using PK = CUSTOMER#123 and SK = PROFILE.

Both separate-table and single-table designs can work. Separate tables are often easier to understand when different entities have very different access patterns. Single-table design can be useful when related data is frequently read together.

The important point is not to force everything into one table or always separate everything into multiple tables. Choose the structure that best supports the application’s access patterns.

Make Sort Keys Work for You

Let’s return to the Orders table. We used the customer ID as the partition key and combined the order timestamp with the order ID in the sort key.

PK = CUSTOMER#123
SK = 2026-10-02T14:31:07Z#A145

CUSTOMER#123 tells us which customer the order belongs to. The sort key tells us when the order was created and includes the unique order ID, A145.

Why include the order ID? Two orders could be created at the same recorded timestamp. If the timestamp were the entire sort key, both items would end up with the same composite primary key. Adding the order ID keeps each order unique.

DynamoDB returns items with the same partition key in sort-key order. Because these timestamps use a consistent ISO 8601 format, their string order also follows chronological order. That makes it easy to retrieve the newest orders first.

For example:

const result = await db.send(
  new QueryCommand({
    TableName: "Orders",
    KeyConditionExpression: "PK = :pk",
    ExpressionAttributeValues: {
      ":pk": "CUSTOMER#123",
    },
    ScanIndexForward: false,
    Limit: 20,
  })
);

The partition key limits the query to one customer’s orders. ScanIndexForward: false reverses the normal sort-key order, so the newest orders are returned first.

Limit: 20 tells DynamoDB to evaluate up to 20 items for that request. A single Query response is also limited to 1 MB of data. If DynamoDB has more items to return, the response includes a LastEvaluatedKey, which can be used to continue the query on the next page.

The same sort-key structure can also support date-range queries with BETWEEN, as long as the range boundaries follow the same timestamp#orderId format.

Model Relationships Without Joins

So far, we have worked with customers and orders. But orders also contain products. One order can contain multiple products, and the same product can appear in many different orders.

That gives us a many-to-many relationship.

In a relational database, you might handle this with a join table. DynamoDB does not provide joins through the Query API, so relationships are usually modeled directly in the data.

One option is an OrderItems table.

Table: OrderItems

PK          SK
----------- -------------
ORDER#A145  PRODUCT#P9
ORDER#A145  PRODUCT#P31
ORDER#A153  PRODUCT#P9

Each item represents one relationship between an order and a product. The partition key identifies the order, while the sort key identifies the product.

You can also store extra information on the item, such as quantity or the price paid at the time of purchase.

Querying:

PK = ORDER#A145

Returns every product in that order.

That handles one direction of the relationship. But what if we want to ask the reverse question: which orders contain product P9?

The existing primary key cannot answer that efficiently. That is where a Global Secondary Index becomes useful.

Use GSIs for Additional Queries

Sometimes the table’s primary key is not enough for every query your application needs.

A Global Secondary Index, or GSI, gives you another way to query the same data using a different key structure.

For the OrderItems table, the primary key lets us start with an order and find its products.

Base table: OrderItems

PK          SK
----------- -------------
ORDER#A145  PRODUCT#P9
ORDER#A145  PRODUCT#P31
ORDER#A153  PRODUCT#P9

But what if we need the reverse query: which orders contain product P9?

We can add a GSI that uses the product as the partition key and the order as the sort key.

GSI: ProductOrdersIndex

Index PK      Index SK
------------  -------------
PRODUCT#P9    ORDER#A145
PRODUCT#P9    ORDER#A153
PRODUCT#P31   ORDER#A145

Now a query with:

Index PK = PRODUCT#P9

returns the orders that contain that product.

The important point is that the base table has not changed. The GSI simply gives the application another access path to the same items.

The same idea can support other queries too. For example, if the Orders table is grouped by customer ID, a GSI with orderId as its partition key lets you find an order A145 without knowing which customer placed it.

GSIs are useful, but they also add cost. They use additional storage, receive updates when indexed data changes, and reads from a GSI are eventually consistent. You also need to think about traffic distribution. If many requests target the same index key, such as OPEN, that key can become heavily concentrated.

The rule is simple: use a GSI when an important access pattern cannot be handled efficiently by the table’s primary key.

How It All Comes Together

The pieces now fit together. Partition keys decide which group of items DynamoDB should look at. Sort keys organize items within that group and allow ordered or range-based queries. GSIs provide additional access paths when the primary key is not enough.

For our shopping application, we created structures for customers, orders, and order-product relationships. We also explored single-table design, where related records share the same table and partition so they can be retrieved together.

No single design works for every application. Separate tables can be easier to understand and maintain, while single-table design can be useful when related data is frequently accessed together.

What matters is whether the design supports the queries your application needs as traffic and data volume grow.

The Key Takeaway

Before designing a DynamoDB table, keep these points in mind:

• Start with access patterns. Understand what the application needs to read and write before choosing the keys.
• Give each key a purpose. Use partition keys to group related data and sort keys to support ordering and range queries.
• Use GSIs when the primary key is not enough. They provide additional ways to access the same data.
• Think about traffic and growth. Consider how requests will be distributed across keys and how the design will behave as the application grows.

In DynamoDB, keys are more than identifiers. They are the access paths your application depends on, and designing them well starts before you write the first item.

DynamoDB Data Modeling: How to Design Tables for Scalability and Performance was originally published in AWS Fullstack on Medium, where people are continuing the conversation by highlighting and responding to this story.