Amazon Bedrock is a managed service that serves foundation models through one API, so AWS runs the servers, hosts the model weights, and keeps your data away from the model providers. Everything above that line is yours: who can call which model, what data you send, which KMS key encrypts it, whether the traffic stays on a private path, whether Guardrails run, and whether a single invocation is ever logged. Two of those default to off. This part draws the line precisely and hands you the baseline I set before any prompt reaches production.
The first Bedrock security review I ran went sideways over one question. A customer prompt had carried a real Social Security number into an application log, and the room wanted to know whose fault that was. Half the table assumed AWS owned it because Bedrock is managed. It does not. That log was written by the customer application, into a customer log group, under a customer policy. AWS never saw the number and never had a way to stop it. The confusion was not about the leak. It was about the line, and almost nobody in that room could draw it.
What Amazon Bedrock is
Amazon Bedrock is a fully managed service that gives you access to foundation models, the large pretrained models behind generative AI, through a single API without you running any inference servers. You pick a model from a catalog that in 2026 spans AI21 Labs, Anthropic, Cohere, DeepSeek, Luma AI, Meta, Mistral AI, OpenAI, Qwen, Stability AI, TwelveLabs, Writer, and Amazon own Nova family, then you call it. No GPU to provision. No container to patch. No model weights to download.
That convenience is exactly what muddies the security picture. When you run a model yourself on EC2, the split is obvious: AWS gives you the box, you own everything inside it. Bedrock hides the box. The model runs on infrastructure you cannot see, patched by people you will never meet, and that hidden layer makes people assume the whole thing is somebody else problem. It is not. The API is a door, and you still decide who walks through it and what they carry.
Security of the cloud, security in the cloud
AWS describes its whole platform with one sentence, and Bedrock inherits it unchanged. Security is a shared responsibility, split into security of the cloud and security in the cloud. AWS owns the first half: the data centres, the network, the hypervisor, the service software, and the model hosting. You own the second half, and what falls into your half depends entirely on which service you use and how you configure it.
For a service like Amazon S3, your half is large because you touch a lot of knobs. For a serverless service, your half shrinks. Bedrock sits closer to the serverless end. You never touch the model host, so a whole class of patching and isolation work leaves your plate. What remains is small, but it is the part that actually leaks data when you get it wrong. That is the trap. A smaller responsibility feels like a safer one, and teams relax exactly where they should not.
What AWS runs for you
Start with the good news, because it is real and it is a lot. AWS operates the infrastructure that serves every model, and third-party auditors test that infrastructure against the compliance programs Bedrock is in scope for, including SOC, HIPAA, and FedRAMP High. You do not patch the inference fleet. You do not manage tenant isolation between your calls and the next customer calls. You do not keep the model weights secure, and you do not scale the fleet when your traffic spikes.
The most important thing AWS runs on your behalf is a data boundary. Bedrock never shares your inputs or outputs with the model providers, and it never uses your prompts to train the base models. When you fine-tune a model, meaning you adapt it on your own examples, Bedrock makes a private copy for your account rather than folding your data back into the shared model. So the frontier model you call from Anthropic or Meta never sees your data as its owner. That single design choice is why regulated teams can use third-party models at all, and you get it without configuring anything. It is the default.
Where AWS responsibility genuinely ends is the moment a request leaves the service. Incident response for the Bedrock service itself is on AWS. Incident response for what your application does with a model response is on you.
What stays on your side
Your half is short to list and easy to underestimate. Identity comes first. Bedrock actions are IAM actions, so bedrock:InvokeModel and bedrock:Converse are the two you will govern most, and a policy that allows bedrock:* on every resource is the single most common mistake I find in a first review. Then the data: what you put in a prompt, what you keep from a response, and where both land. Then the key: Bedrock encrypts at rest, and you decide whether that uses an AWS-managed key or a customer managed key in AWS Key Management Service, the service that stores and controls encryption keys, so your security team can audit and revoke it.
After that comes the network path, the safety layer, and the audit trail. The table below is the version I keep pinned, because in a review the argument is never whether a control exists. It is who owns it and what it does before you touch it.
| Control | Owner | Default state | Where you set it |
|---|---|---|---|
| Model hosting and isolation | AWS | Always on | Nothing to do |
| Model access grant | You | No access | Bedrock console, Model access |
| Who can call a model | You | Deny by default | IAM policy |
| Encryption key | Shared | AWS managed key | KMS, set a customer key |
| Private network path | You | Public API endpoint | VPC endpoint via PrivateLink |
| Content safety | You | Off | Bedrock Guardrails |
| Invocation logging | You | Off | Settings, model invocation logging |
| API call audit trail | Shared | CloudTrail on | CloudTrail, already recording |
Defaults that surprise people
Three defaults trip up almost every team on their first build. The first is model access. A fresh account cannot call any model until you request access to it in the Bedrock console, per Region. People read that as a bug, retry the API, and collect AccessDeniedException until someone finds the toggle. It is a control, not a fault. It means nobody can quietly start calling an expensive frontier model in an account where you never intended to use one.
The second is logging, which I already flagged and will keep repeating because it matters. Off by default. If you cannot show an auditor the prompt that produced a bad answer, you did not turn it on. The third is cross-region inference, a feature that automatically routes a request to another Region in the same geography when your home Region is busy. It improves throughput, and it also means a request you assumed stayed in eu-west-1 can be served from eu-central-1. For most workloads that is fine and invisible. For a data-residency contract that names a single Region, it is a problem you need to know about before you sign, not after. You control which inference profile you call, so you can keep it in-Region when the contract demands it.
The safety numbers, and what they do not cover
Guardrails are your content safety layer, and AWS publishes effectiveness figures for them. They are useful, and they are not a finish line. Multi-modal toxicity filtering blocks up to 88 percent of harmful content. Contextual grounding checks filter over 75 percent of hallucinated responses in retrieval and summarization workloads. Automated Reasoning checks, which use formal logic rather than another model to verify a claim, identify correct responses with up to 99 percent accuracy. Read those numbers as strong defaults, not guarantees. Eighty-eight percent blocked means twelve percent got through, and the twelve percent is where your review time goes.
| Safeguard | What it does | Published figure |
|---|---|---|
| Toxicity filter | Blocks hate, insults, violence, prompt attacks | Up to 88 percent blocked |
| Contextual grounding | Flags answers not supported by source data | Over 75 percent of hallucinations filtered |
| Automated Reasoning | Formally verifies a factual claim | Up to 99 percent accuracy |
A security baseline I deploy
Here is what I set before the first real prompt, on every Bedrock account, regardless of team. Grant model access to only the specific models you plan to use, in only the Regions you plan to use them. Write an IAM policy that allows bedrock:InvokeModel and bedrock:Converse on those model ARNs and nothing else, never bedrock:* on a star resource. Set a customer managed KMS key so your security team can revoke it independently. Create a VPC endpoint so traffic never touches the public internet. Attach a Guardrail to every call. Turn on invocation logging to a locked S3 bucket. That is six steps, and CloudTrail is already recording the seventh thing you need, the API audit trail.
Worked example
A support bot in us-east-1 handles 10,000 chats a day. Attach a Guardrail, and on the toxicity figure of 88 percent it blocks roughly 8,800 of every 10,000 harmful attempts before a model ever answers. That still leaves about 1,200 slipping through per 10,000 that reach a model, which is exactly why you also log every invocation: the 12 percent is what your team reviews, and you cannot review what you never recorded. The percentages here are the same ones plotted in the chart above.
The call itself is short. This is the smallest thing worth running, a single guarded request with the Converse API, the unified Bedrock call that works across models. It uses Amazon Nova Lite, a low-cost model in the Nova family, and it attaches a Guardrail so the safety layer is on from the first request.
import boto3
client = boto3.client('bedrock-runtime', region_name='us-east-1')
resp = client.converse(
modelId='amazon.nova-lite-v1:0',
messages=[{'role': 'user',
'content': [{'text': 'Summarise our refund policy in two lines.'}]}],
guardrailConfig={'guardrailIdentifier': 'gr-0a1b2c3d4e5f',
'guardrailVersion': 'DRAFT',
'trace': 'enabled'},
)
print(resp['output']['message']['content'][0]['text'])
print(resp['stopReason']) # end_turn normally, guardrail_intervened when blockedExpected output: a two-line refund summary, then the word end_turn. Send an abusive prompt instead and the second line reads guardrail_intervened, with the response text replaced by your blocked-message string.
Failure mode: if you never requested access to amazon.nova-lite-v1:0 in us-east-1, this raises AccessDeniedException before any model runs. The fix is Model access in the Bedrock console for that Region, not a code change. A wrong guardrailIdentifier raises ValidationException instead.
Where teams get burned
The failures I see are boringly consistent. The IAM policy is too wide, so a service account that should call one model can call every model in the catalog, and your bill and your risk both grow quietly. Logging is off, so the first real incident has no evidence and the postmortem is a shrug. Guardrails are attached in the demo and forgotten in the batch job, so the safety layer covers the path a human watches and misses the path that runs at 3am. And cross-region inference quietly serves a residency-sensitive workload from the wrong geography because nobody read the routing behaviour before signing the contract.
None of these are Bedrock breaking. Every one is the customer half of the model, left unconfigured. The cost side deserves the same discipline, and it rewards it. Batch inference lists at half the price of on-demand for the same models, so a nightly summarization job that can wait a few hours has no reason to run at the on-demand rate. That is a relative figure AWS publishes, plotted below, and it is one of the easier wins in the whole service.
If you want the vendor-neutral view of what guardrails catch and miss across any platform, I wrote that up in the GenAI Series guardrails part. This part is the AWS-specific version of the same discipline.
What to lock down first
Use Bedrock, and treat the shared responsibility model as a checklist, not a slogan. AWS genuinely covers the hard infrastructure and the data boundary that keeps your prompts away from the model providers, and that is worth a lot. Your job is small and non-negotiable: least-privilege IAM, a customer KMS key, a private endpoint, Guardrails on every path, and logging on before the first prompt. Do not skip logging because it is off by default and nobody is forcing you. That default is the one that turns a minor incident into an unexplained one. Next, in Part 3, I walk the model catalog and how I actually choose a model, now that you know how to call one safely. If you run one thing today, turn on invocation logging.
References
- AWS Shared Responsibility Model
- Security, Guardrails, and Observability in Amazon Bedrock
- Amazon Bedrock security, privacy, and responsible AI
- Amazon Bedrock pricing
About The Author
DrJha