What is a service-linked role - the roles AWS makes for you

A service-linked role is an IAM role that AWS itself creates, names, and owns inside your account so a specific service can call other AWS services on your behalf — you can look at it, but you can't edit its permissions, and that's on purpose. Here's the part almost nobody tells you: those roles are invisible to your organization's guardrails. Service control policies and resource control policies, the two big levers AWS Organizations gives you to lock an account down, are documented to have zero effect on a service-linked role. AWS wrote its own exception into the rulebook.

Jake found the role by accident. He was cleaning up IAM after a security scan flagged "too many roles" in his AWS account, and there it was — AWSServiceRoleForRDS, created on a date he didn't recognize, with a permissions policy he'd never written. His first thought was that someone had broken in. His second thought, once he calmed down, was to text Ethan.

"I didn't make this," Jake said. "It's just sitting in my account with permissions to touch EC2 and CloudWatch. Am I compromised?"

Ethan wasn't worried. "You're not compromised, you're just seeing an IAM role for the first time," he said. "That role is called a service-linked role, and AWS made it, not you. The moment you did something in RDS that needed it — probably just launching a database — AWS quietly created that role in the background so RDS could go do work in EC2 and CloudWatch Logs on your behalf. You didn't miss a step. There was no step to miss."

What a service-linked role actually is

A service-linked role is a unique type of IAM role that's linked directly to one specific AWS service. AWS's own IAM documentation is blunt about this: the role is predefined by the service and includes all the permissions that service needs to call other AWS services for you. The linked service also defines how you create, modify, and delete the role — not you. Regardless of the method, the whole design exists to simplify setting up a service, because you don't have to manually add permissions for the service to complete actions on your behalf.

An IAM role, if this term is new, is a set of permissions that something — a person, an application, or an AWS service — can temporarily "put on" to do a job, then take back off. It's different from an IAM user, which is a permanent identity with its own long-term credentials. A role has no password and no access keys of its own; whoever or whatever assumes it just borrows its permissions for a while, and gives them back when it's done. Service-linked roles are one very specific flavor of that idea: the "whoever" is always the same one AWS service, and only that service, unless the documentation for that particular role explicitly says otherwise.

Three things make a service-linked role different from every other role sitting in your account:

1. You can view it, but you cannot edit its permissions. AWS's IAM User Guide states this directly — an administrator can see the permissions attached to a service-linked role, but cannot change them, because the linked service owns that policy.
2. Its permissions policy cannot be reused anywhere else. The exact permissions policy attached to a service-linked role cannot be attached to any other IAM entity in your account — not a user, not a group, not a different role, no matter how similar the use case looks.
3. Only the named service can normally assume it. The trust policy on the role names the service (for example, rds.amazonaws.com) as the only principal allowed to assume the role, unless that service's own documentation says something else can assume it too.

Service-linked role vs. service role vs. IAM role

This is the single most common mix-up in every AWS forum thread on the topic, and AWS's own documentation repeats a "remember, these are different" note on nearly every service-linked-role page it publishes, which tells you how often people confuse the two.

A service role is the one people usually mean when they say "IAM role for a service" — you build it yourself, in IAM, choosing exactly which permissions to hand to, say, a Lambda function so it can write to one specific S3 bucket and nothing more. You can attach, detach, and rewrite the permissions on a service role any time you want, and you're the one accountable if it turns out to be too broad or too narrow.

A service-linked role skips that whole design process. The service ships with the role already designed, already scoped, and already wired to a specific trust relationship before you ever open the IAM console. You don't write the permissions policy; the service's own engineering team did, and it ships as part of the service itself, not as part of your account's day-to-day IAM hygiene. That's also why AWS CloudFormation documentation is explicit that to attach a policy to a service-linked role, you have to make the request through the AWS service that depends on the role — not through IAM directly, and not by editing the CloudFormation stack that created it.

Why AWS builds these roles instead of leaving it to you

According to AWS's IAM documentation, the whole point is to simplify setting up a service, because you don't have to manually work out and attach the exact permissions that service needs to do its job correctly on the first try. Think about what Amazon RDS has to be able to do just to run a single database for you: it needs to reach into EC2 to manage network interfaces, into Amazon SNS to send you event notifications when something changes, into CloudWatch Logs to export your database logs, and into Kinesis for certain streaming features. Nobody wants to hand-build that policy correctly the first time, and getting it wrong either breaks the service outright or over-grants access nobody asked for.

Ethan puts it to Jake this way: "Imagine every time you sold someone a phone, you also had to personally wire up their SIM, their carrier account, and their warranty registration by hand, and if you got one wire wrong, the phone wouldn't ring on day one. That's what building the exact permissions for RDS yourself would feel like, every single time you launched a database. A service-linked role is the phone showing up pre-activated, straight out of the box."

How a service-linked role gets created

There isn't one single way this happens. AWS's documentation lays out several distinct paths, and which one applies depends entirely on the service you're using.

If you want to create one manually through IAM rather than waiting for a service to trigger it, here's the console path AWS documents, step by step:

1. Open the IAM console and go to Roles, then choose Create role. This is the exact same screen you'd use to build any other IAM role, which is part of why people expect to be able to edit these afterward — the creation screen looks completely identical to a regular role's.
2. Choose the AWS Service role type, then pick the specific use case for the service you're creating the role for. Use cases are defined by the service itself and already bundle in the trust policy that service needs.
3. Attach whatever permissions the wizard offers. Depending on the service, you might see the permissions already fixed, a limited set to pick from, or in rarer cases no policy attachment step at this stage at all.
4. Set the role name suffix, if the service allows one. Many services fix the role's entire name for you; others let you add a custom suffix so you can tell two service-linked roles for the same service apart. You cannot rename it after creation.
5. Review and create. You cannot attach tags to a service-linked role at creation time, in the console, the CLI, or through infrastructure as code — a limitation that trips people up if they're used to tagging everything for cost allocation.

The CLI equivalent is one line, and it's worth knowing even if you never plan to type it yourself, because you'll run into it eventually in someone else's shell script, CloudFormation template, or Terraform run:

aws iam create-service-linked-role --aws-service-name lex.amazonaws.com

That single command creates AWSServiceRoleForLexBots in your account, at the path /aws-service-role/lex.amazonaws.com/, with the trust policy and permissions Amazon Lex needs already attached. You never see a policy document to review, because there isn't one for you to write — it's already been written, tested, and shipped by the Lex team.

What permissions a service-linked role actually holds — and where they go

Every service-linked role has two parts: a trust policy, which decides who is allowed to assume the role at all — almost always just the one linked service — and a permissions policy, which decides what the role is allowed to do once it's been assumed. Neither part can be attached anywhere else in your account, and neither part is something you're expected to author.

Here's the piece that catches people off guard: those permissions don't just sit there unused, quietly waiting. AWS's IAM documentation calls this "indirect permissions," and the RDS example is the one AWS itself uses to explain the concept. When you create an Amazon RDS database instance, RDS's service-linked role gets created automatically if it doesn't already exist, and that role lets RDS call Amazon EC2, Amazon SNS, Amazon CloudWatch Logs, and Amazon Kinesis on your behalf, without asking you again each time. So if you give someone in your account permission to create and manage RDS databases, you have also — indirectly, through the role RDS itself uses — given them a path to interact with EC2, SNS, CloudWatch Logs, and Kinesis resources, simply by asking RDS to go do it for them.

Jake's face fell a little when Ethan walked him through this with a whiteboard marker. "So every developer I've given RDS access to can also poke at my CloudWatch Logs and EC2 stuff, just by making RDS do it for them?" Ethan nodded slowly. "Not directly — they can't assume that role themselves and go do whatever they want in EC2 on their own terms. But they can trigger RDS to use its role's permissions on their behalf, inside whatever RDS itself is designed to do. It's a narrower door than handing out full EC2 access outright, but it's still a door, and most people never notice it's there until someone asks the right question in an audit."

The governance blind spot: SCPs and RCPs don't touch these roles

This is the reveal from the top of the post, and it's worth sitting with for a moment rather than skimming past it. AWS Organizations documentation states this in plain language: service control policies never affect service-linked roles, and those roles are exempt from any SCP restriction, because they exist so other AWS services can integrate with your organization and simply can't be restricted by the very guardrail meant to restrict nearly everything else in a member account. The same exemption is documented for resource control policies, the newer sibling to SCPs that restricts what identities outside an account can do to resources inside it.

If you run a multi-account AWS Organization and you've built SCPs that, say, deny an entire category of actions across every member account as a blanket guardrail, that guardrail simply does not apply the moment a service-linked role is the one doing the work. The role still only does what its own predefined permissions policy allows — it isn't unlimited, and it can't reach beyond what AWS scoped it to — but your organization-wide deny statements have no say in the matter at all, because they were never in the room to begin with.

This matters most in regulated environments, where governance documentation has to hold up to outside scrutiny. If an auditor asks how you're certain a particular AWS service can't reach beyond its documented scope, "our SCP blocks it" is simply not a correct answer for anything running through a service-linked role. The honest, defensible answer has to be something closer to: "we trust the permissions policy AWS itself wrote for that role, and separately, we control exactly who can invoke the service that uses it."

How to recognize one in your account

Service-linked roles don't hide from you, but they don't announce themselves loudly either. Two things give them away every time, without exception: the name pattern and the path.

• Most follow the pattern AWSServiceRoleFor<ServiceName> — for example AWSServiceRoleForRDS, AWSServiceRoleForSSO (IAM Identity Center), AWSServiceRoleForServiceCatalogSync, or AWSServiceRoleForPCS (AWS Parallel Computing Service).
• Their path always starts with /aws-service-role/, followed by the service principal, for example /aws-service-role/rds.amazonaws.com/. Regular IAM roles you build yourself almost never live under that path.

In the IAM console, filter Roles by that path prefix, or just scan for names beginning with AWSServiceRoleFor, and you'll find every service-linked role in the account in a single pass. If your organization's tagging or asset-inventory tooling flags "untagged roles" as a compliance finding, expect a long list of these — they can't be tagged at creation, and most teams never circle back to tag them afterward, which usually isn't a real problem since ownership is already obvious from the path itself.

What you can and can't change once it exists

The permissions policy is off-limits, full stop — that's the entire premise the role is built on. But you're not locked out of absolutely everything about it:

• Description: editable on any service-linked role, provided the IAM entity making the change holds the iam:UpdateRoleDescription permission.
• Trust relationship: generally not editable by you, since it's defined by the linked service and controls exactly who's allowed to assume the role.
• Role name: fixed at creation; you cannot rename it afterward, because other parts of the service — and possibly other AWS resources — may reference that exact name.
• Tags: simply not attachable during creation, a limitation AWS's own IAM documentation notes explicitly.

To even edit the description, an IAM administrator needs the right permission granted to them specifically — it isn't automatic just because they're an administrator of the account as a whole. The same principle holds in reverse for creating or deleting one: someone needs an explicit policy statement allowing iam:CreateServiceLinkedRole or iam:DeleteServiceLinkedRole, scoped correctly to the right service path, before they're able to do either action at all.

Deleting a service-linked role — and why it fails the first time

Before you can delete a service-linked role, AWS documentation is explicit that you must first delete the resources in the linked service that still depend on it. This protects you from accidentally cutting off a service's access to resources it's actively managing on your behalf. Skip that step, and the deletion simply will not go through, no matter how many times you retry it.

1. Confirm the resource is really gone first. If RDS still has a database instance depending on its service-linked role, deleting the role before the database is the wrong order of operations. Delete the database, or whatever resource is actually using the role, first.
2. Submit the deletion request. Via the CLI: aws iam delete-service-linked-role --role-name AWSServiceRoleForLexBots. This doesn't delete anything immediately — it returns a DeletionTaskId because the actual deletion happens asynchronously.
3. Check the status. Use aws iam get-service-linked-role-deletion-status --deletion-task-id <the id you got back> to confirm it finished. If the linked service is still touching a resource somewhere, the task fails, and the status call names the exact resources you still need to clean up.
4. Resubmit if needed. If you call the delete command again for the same role while an earlier deletion task hasn't finished, AWS hands you back the ID of that earlier task rather than starting a new one, so you won't accidentally queue duplicates.

Why you suddenly see a role you didn't create

AWS has a dedicated troubleshooting entry for exactly this moment, titled "A new role appeared in my AWS account," and it exists specifically because this scares people every single time it happens for the first time. The scenario: you were already using a service before that service started supporting service-linked roles, or before it started requiring one for a feature you'd already turned on months earlier. When the service added that support, it created the role in your account automatically, sometimes accompanied by an email notification sent to the account owner.

The official guidance is short and firm: you don't need to take any action, and you should not manually delete the role. Removing it can strip permissions the service genuinely needs to keep accessing the AWS resources it's already managing for you — meaning a database that's currently running, a load balancer that's currently routing live traffic, or a discovery agent that's currently reporting status back on a schedule.

Jake, hearing all this, finally relaxed. "So it's not a break-in at all, it's basically RDS filling out its own paperwork behind the scenes." "That's exactly it," Ethan said. "The only time a new role appearing should actually worry you is if it doesn't match any service you actually use, or the path doesn't start with /aws-service-role/. Then it's genuinely worth investigating properly — but honestly, that's true of any unexpected IAM entity showing up in your account, service-linked or not."

Service-linked roles and your IAM role quota

Every AWS account has a quota on the total number of IAM roles it can hold, and by default that number is smaller than most people expect going in — the default has historically sat at 1,000 roles per account, and it's an adjustable quota you can request an increase on through the Service Quotas console. In 2026, AWS raised the ceiling that quota can be adjusted up to, lifting the maximum for roles per account, along with several closely related quotas like customer-managed policies per account and instance profiles per account, higher across the board to give growing environments more room.

Here's the twist that matters for this specific topic: service-linked roles count toward that overall quota just like any other role does, but AWS documentation states plainly that they're allowed to push you over it anyway. If your account is already sitting right at its roles-per-account limit, a service can still go ahead and create the service-linked role it needs to function — only service-linked roles get that particular exception. Every other role you try to create yourself once you're at the limit will simply fail with a LimitExceeded error until you either delete something you no longer need, or formally request a quota increase.

Creating them through infrastructure as code

If your team manages infrastructure through CloudFormation or Terraform rather than clicking through the console by hand, service-linked roles have their own dedicated resource type in both, and it's worth knowing the shape of it before you hit an unfamiliar error mid-deployment.

In CloudFormation, the resource type is AWS::IAM::ServiceLinkedRole, and its documentation explains exactly why it exists as a separate resource type rather than just reusing AWS::IAM::Role: the service, not CloudFormation, controls the attached policies and controls when the role can actually be deleted, which helps keep the service from breaking if a role got unexpectedly changed or deleted out from under it. The template takes three properties: AWSServiceName, required, the same case-sensitive service principal string covered earlier; an optional CustomSuffix, which not every service supports; and an optional Description. AWS's own CloudFormation documentation adds that if you supply a custom suffix and the operation fails because that service doesn't support one, the fix is simply to retry the template without it.

The Terraform equivalent is the aws_iam_service_linked_role resource, taking the same shape: a required aws_service_name argument, an optional custom_suffix, an optional description, and support for tags at the Terraform level even though the underlying AWS API won't let you tag the role at creation. Terraform's own provider documentation notes that changing aws_service_name or custom_suffix on an existing resource forces Terraform to replace it entirely rather than update it in place, since neither can be changed on a role that already exists.

Whichever tool you use, the practical lesson is the same one from the console and the CLI: you're declaring which service should get its role, not designing what that role can do. If your CI/CD pipeline's deployment role doesn't have iam:CreateServiceLinkedRole permission scoped correctly, expect your very first apply against a brand-new service to fail on that specific action, even though every other part of your template is completely correct.

Service-linked roles across regions, accounts, and partitions

IAM itself is a global service, not a regional one — it doesn't live inside a single AWS Region the way an EC2 instance or an S3 bucket does. That means a service-linked role you see in the IAM console isn't tied to whichever region happens to be selected in the console; it exists at the account level, account-wide, the same way an IAM user or an IAM policy does. The linked service's actual work might well be regional — an RDS database certainly lives in one region — but the role itself doesn't move or duplicate per region the way the database instances it manages might.

Where this gets more interesting is across AWS partitions. Every AWS account is scoped to exactly one partition: the standard aws partition covering most commercial AWS Regions, the aws-cn partition covering the separate China Regions, and the aws-us-gov partition covering AWS GovCloud (US). A service-linked role created in a standard commercial account doesn't exist in, and has no relationship to, an account in a different partition — if you're running workloads in both a commercial account and a China-region account, each one needs its own service-linked role created independently, because they're genuinely separate accounts on genuinely separate infrastructure, not just separate regions of the same account.

Inside a single AWS Organization spanning many member accounts, the picture is simpler but still worth stating plainly: a service that creates its service-linked role automatically per account, like IAM Identity Center does, will end up creating that same role separately in every member account where it's needed, not just once at the organization level. Nothing about SCPs, RCPs, or delegated administrator status changes that per-account creation behavior, since those Organizations features are about restricting permissions, not about consolidating how many copies of a role exist across the accounts you manage.

Auditing service-linked roles across a real AWS environment

If you're managing more than a handful of accounts, service-linked roles show up unpredictably and often in bulk: an account team enables IAM Identity Center once, and AWS creates AWSServiceRoleForSSO in every account across the organization, not just the one where somebody clicked the button. That's documented, expected behavior for IAM Identity Center specifically — enabling it creates the role in every existing account in the organization at once, and again in every new account added afterward, with zero further action required.

A few practical habits keep this from turning into confusion the next time an audit comes around:

• Track the API call, not just the role. The CreateServiceLinkedRole action is a normal, loggable IAM API call, so it shows up in CloudTrail like any other API call in your account. If you want a record of when and why a role appeared, that event is where to look.
• Don't flag every AWSServiceRoleFor* role as anomalous by default. You'll drown your security team in false positives from completely expected service behavior, and they'll start ignoring the channel within a month.
• Keep a short, living list of "expected" service-linked roles per account type. An account running RDS, EC2 Auto Scaling, and IAM Identity Center should always show those three and nothing unexpected beyond them. A new one that isn't on the list is the signal worth chasing.

When a service lets you pass an existing role instead

Not every service forces you into a service-linked role, and it helps to know the alternative exists. Some allow you to pass an existing role you've already built, instead of having the service create a brand-new one. AWS documentation is clear that doing this requires a specific permission: your IAM entity needs iam:PassRole scoped correctly to the role you want to hand over, and typically iam:ListRoles as well, so the console can show you which roles are available to choose from.

If you're not sure which model a given service uses, that's normal — it varies service by service, and the definitive answer lives on that specific service's own security or IAM documentation page, not in a general concept page like this one. The tip-off that a service supports this pattern is usually a dropdown or radio option in its console that says something like "use an existing service role" sitting right alongside "create a new service-linked role."

Common mistakes people make with service-linked roles

A few patterns come up again and again once you've watched enough IAM cleanups play out in real accounts.

Deleting one during a "security cleanup" without checking dependencies first

Someone runs a routine audit, spots an unfamiliar role, and deletes it to "reduce attack surface" without first checking whether the linked service still has active resources genuinely depending on it. If the linked service was still using it, this either fails outright with a clear error, or in the worst case, quietly breaks whatever that service was actively managing. Always check for active resources in that service before requesting any deletion.

Assuming SCPs are guarding everything, everywhere

Teams write a strict SCP, run a permissions review, and confidently conclude the environment is fully locked down — without accounting for the fact that any service-linked role in that account operates completely outside the SCP's reach, exactly as covered above. The SCP is still genuinely valuable for what it does cover; it just isn't the whole picture.

Trying to guess the service principal name

When manually creating a service-linked role via CLI, API, or infrastructure as code, typing a guessed service principal — assuming it's always exactly the product name plus .amazonaws.com — is a common source of failed calls, because the format is case-sensitive and inconsistent across services. AWS's own guidance says explicitly not to guess it; always pull the exact string from that specific service's own service-linked-role documentation page.

Expecting to tag it like everything else in the account

Tagging strategies that assume every IAM role can be tagged at creation hit a wall here — service-linked roles can't be tagged during creation, through any interface. If your cost-allocation reporting or ownership tagging policy depends on that, you'll need a documented separate process, or an accepted, written exception for this role type.

Forgetting that IaC deployment roles need this permission explicitly

A pipeline that's allowed to create ordinary IAM roles isn't automatically allowed to create service-linked roles too — iam:CreateServiceLinkedRole is its own distinct action, and if the deployment role's policy only grants iam:CreateRole, the very first CloudFormation stack or Terraform apply that touches a new service will fail on that specific action, even though the rest of the template is completely correct.

A short checklist before you touch any service-linked role

1. Identify it by path, not name alone. Confirm it lives under /aws-service-role/ before assuming it's safe to leave, or dangerous to remove.
2. Match it to a service you actually use. Cross-reference the service principal in the path against your active AWS services.
3. Check for active resources in that service before requesting a deletion of any kind.
4. Don't expect SCPs or RCPs to restrict it further. If you need tighter control, that has to come from restricting who can trigger the linked service's actions in the first place.
5. Leave the permissions alone. You can't edit them, and if you find yourself trying to work around that with a workaround policy attached elsewhere, stop and ask why — that usually signals a design problem worth reconsidering, not a permissions gap to patch.

Frequently asked questions

What is a service-linked role in AWS, in plain English?

It's an IAM role that an AWS service builds for itself inside your account, with permissions already scoped to exactly what that service needs to call other AWS services on your behalf. You can see it, but you can't edit what it's allowed to do.

How is a service-linked role different from a regular IAM role?

A regular IAM role is something you design and fully control — you write the trust policy and permissions policy, and you can edit both at any time. A service-linked role's permissions come predefined by the AWS service itself, and you can view but not edit them.

How is a service-linked role different from a service role?

A service role is also meant for an AWS service to assume, but you build and own it in IAM, choosing its permissions yourself. A service-linked role is predefined by the service, appears automatically or through a guided flow, and its permissions policy can't be attached to any other IAM entity.

Why did a role I never created suddenly show up in my account?

Most likely a service you were already using added support for service-linked roles, and it created the role automatically to keep functioning. AWS's guidance is not to delete it; doing so can remove access the service still needs.

Can I edit the permissions on a service-linked role?

No. An IAM administrator can view the permissions attached to a service-linked role, but cannot change them, because the linked service defines and owns that policy.

Can I rename a service-linked role after it's created?

No. The role's name is fixed once it's created, because other parts of the service may reference that exact name. Some services let you add a custom suffix at creation time to tell multiple instances apart, but you can't change the name later.

Can I attach tags to a service-linked role?

Not at creation. AWS's IAM documentation states you cannot attach tags to a service-linked role during creation, which is a change from how you'd normally tag an IAM role, even through infrastructure as code.

Do service-linked roles count against my IAM roles quota?

They count toward it, but they're allowed to push you over the limit. If your account has already reached its roles-per-account quota, a service can still create the service-linked role it needs — that exception applies only to service-linked roles, not regular ones.

Why won't AWS let me delete a service-linked role?

Because the linked service is still using it to manage an active resource. AWS requires you to delete those resources first; only then will the role's deletion succeed.

How do I check the status of a service-linked role deletion?

Deletion is asynchronous: the delete call returns a deletion task ID, and you check its progress (or the reason it failed) with the get-service-linked-role-deletion-status operation.

Do service control policies (SCPs) restrict what a service-linked role can do?

No. AWS Organizations documentation states that SCPs never affect service-linked roles; those roles are exempt from any SCP restriction so the linked service can keep integrating with your organization.

Do resource control policies (RCPs) affect service-linked roles?

No, they don't either. Service-linked roles operate outside the reach of both SCPs and RCPs by design, which is why the actual control point has to be who can trigger the linked service's actions, not an organization-wide policy layer.

What happens to my resources if I delete a service-linked role by mistake?

If the linked service was still actively using it, the deletion attempt should fail rather than succeed, since AWS requires dependent resources to be removed first. If it does succeed on a role that was still needed, the linked service can lose the permissions it needs to keep managing those resources, so treat any accidental deletion attempt as a signal to check the service's status immediately.

Can I create a service-linked role manually before I need it?

For services that support it, yes — through the IAM console, the CLI's create-service-linked-role command, the CreateServiceLinkedRole API call, or infrastructure-as-code resources like AWS::IAM::ServiceLinkedRole in CloudFormation or aws_iam_service_linked_role in Terraform, specifying the correct service principal name.

What does "indirect permissions" mean for a service-linked role?

It means the permissions granted to a service through its service-linked role can flow through to anyone who has permission to use that service. For example, RDS's service-linked role lets RDS call EC2, SNS, CloudWatch Logs, and Kinesis, so anyone allowed to create or manage RDS databases indirectly gains a path into those other services via RDS.

Is it safe to just leave unused service-linked roles in my account?

Generally yes, since the permissions are locked and can't be reused elsewhere. Some services, like AWS PCS, recommend deleting a service-linked role once you've fully stopped using the related feature simply so you're not carrying an unmonitored entity, but there's no urgency, and you should always confirm dependent resources are gone before deleting anything.

Revision note. Written September 2026. If you found that unfamiliar role in your account and it scared you a little — you're not alone, and you didn't break anything.