How to access S3

There are a few general approaches, with many variations on how they can be adapted for use in specific customer environments. The most common approaches are the following.

The generally preferred option is to deploy AWS IAM Identity Center (IDC). You can either use its internal identity directory to store your users, not requiring any pre-existing infrastructure, or you can federate IDC with an existing identity provider (IdP) that you might have, such as Okta or Microsoft Entra ID.

The general principle is that users first authenticate to IDC, either as internal users or via a federation. Based on this initially authenticated session, IDC will issue temporary credentials for the users for the IAM roles in the various AWS accounts where they have been granted access using a construct in IDC called a permission set. IDC integrates with AWS Organizations, making it quite straightforward to deploy across an AWS landscape of almost any size. IDC works both for the AWS management console and for AWS CLI and SDK access. No long-term IAM access keys are needed at all; the only long-term credentials will be the ones users use to authenticate to IDC or the identity provider federated with IDC. Detailed documentation for IDC and implementation instructions are available here: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

Another approach would be to use AWS IAM Roles Anywhere. This isn't the generally preferred option, because it practically has to be configured separately for each AWS account, as opposed to integrating natively with AWS Organizations. IAM Roles Anywhere is based on users being authenticated based on TLS client certificates issued to the users by a trusted certificate authority (CA). Many companies already have such as a CA for purposes such as authenticating client computers to the internal office network, WiFi, or VPN, and to issue TLS certificates for internal-facing servers. The static part of the credentials in this option consists of the private key of each user's TLS certificate, which could be rotated regularly using the features of the internal certificate infrastructure (such as certificate auto-enrollment in Windows), and which can be secured using the TPM (trusted platform module) chip present on typical laptops. IAM Roles Anywhere has its own documentation here: https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html and a walkthrough of connecting it to a self-managed, external CA is here: https://aws.amazon.com/blogs/security/iam-roles-anywhere-with-an-external-certificate-authority/

A more classical alternative that predates IDC but still works and is supported is to federate the standard AWS IAM in each of your AWS accounts with an external identity provider (IdP), such as Okta or Microsoft Entra ID. The principle is similar to IDC, in that users first authenticate to the IdP, not needing any static access keys from AWS IAM. Once authenticated against the IdP, they can assume standard AWS IAM roles in all your accounts where you configured the federation, receiving temporary access keys and session tokens for the role sessions. Note that this option doesn't have any compelling general advantages over IDC, but this can be somewhat more flexible, for example, by allowing implementation across multiple AWS accounts without involvement by the owners of your AWS Organization. This alternative is explained in IAM documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html