Rowan Udell

Developer AWS Access Management

rowan -

Access is another one of the 5 A's of AWS security. This covers how you (the owner of the AWS environment) and your team access the AWS services to provision resources like functions, instances, databases, buckets, etc. How your customers access those resources (and your applications and services running on those resources) is a much larger topic for another post. Application-level security has to take in to account a lot more variables, and depends more on your technology stack. Getting access to the AWS services via their APIs is the same for all customers using AWS.

Human Users

In 2025 all of your human users, including your developers, should be using AWS Identity Center (IDC) to access your AWS accounts and services.

Federation

Just because you should be using IDC, doesn't mean that it should also be your identity provider (IdP) as well. It can be, but that's usually only appropriate for smaller teams. Ideally you should have an single source of truth for all identities in your business, and IDC should federate with that provider (most likely via SAML integration) so that you only need to manage your users in one single location. Unfortunately the support for some providers (I'm looking at you Google Suite) is not great, so there may be times when you use IDC on its own.

Even without federation, you should still use IDC to access your AWS environments since it allows your human users to leverage short-term credentials. This is big improvement over the previous access method: Using IAM Users, which rely upon long-term credentials for access.

Credential theft is the most common form of attack on an AWS environment, and happens in a variety of different ways:

  • A developer accidentally committing their access keys to a public repository
  • Access keys stored on a local machine are copied via malware or takeover
  • A client-side application embeds access keys as part of the build process

Short-term credentials greatly improve your security posture by limiting the potential use of lost credentials to minutes or hours.

Automations

AWS is a fantastic platform for automation, since almost all of its services and features are available programmatically via API. Automations that use these APIs should only use IAM roles and policies that are locked-down to specific IAM actions. This is because a machine user's requirements should be clearly defined (in code) and understood, and not changing every time the automation executes.

This is different from a human user, who is likely to be investigating an unexpected issue or developing new functionality, and so might require new or different permissions to do their job on a regular basis.

External ID

If you're ever giving access to your environment to a 3rd party (eg. a SaaS vendor), and they ask you to provision a role in your AWS environment for them to leverage, ensure that the role's trust policy includes a Condition statement that checks for a specific sts:ExternalId that is unique to you. You should not be able to set the external ID, it should be given to you by the vendor. Using an external ID helps protect against the confused deputy problem.

Legacy Integrations

Unfortunately, not all vendors and services out there follow security best practices. Especially for older integrations, a disappointing number of vendors still request long-term access keys (usually via IAM users that they ask you to provision for their access) to use AWS on your behalf. This is a big security risk, because anyone who finds those keys (eg. if the vendor is compromised) can use them to access your environment. As much as possible, you should push-back on vendors asking you to give them long-term access keys.

If you can't avoid them, make sure that the access you grant is as limited as possible, and work with the assumption that they will require locking or rotating if there is any security incidents on the vendor's behalf.

As your AWS environment grows, prioritizing secure access becomes increasingly critical. Start by eliminating IAM users in favor of Identity Center, implement federation with your existing IdP, enforce short-term credentials for human users, and limit automation permissions to the minimum required.

Access control is a foundational element of your AWS security posture—one that can change and requires ongoing attention. If you focus on these fundamental access principles, you'll significantly reduce your risk while maintaining the agility that makes AWS so valuable to your business.