What Is AWS? Definition & Examples

AWS is Amazon Web Services, a cloud computing platform that provides on-demand infrastructure, storage, networking and managed services. Practitioners use it to run applications and workloads without owning physical servers, while controlling access through IAM roles, policies, keys and account boundaries.

AWS as a cloud computing platform

AWS, or Amazon Web Services, is a cloud platform for renting infrastructure and managed services on demand. The key idea is that organisations consume compute, storage, networking, databases, and higher-level services without buying and operating all of the underlying hardware themselves.

That service model changes the security conversation: the main concerns shift from physical server ownership to account governance, tenant isolation, configuration, and the safe use of cloud-native controls. AWS becomes part of the organisation’s operating model, not just a hosting choice.

What practitioners mean by AWS access control

The practical meaning of AWS usually centres on how access is granted and bounded. Identity and privilege are enforced through IAM users, roles, policies, temporary credentials, API keys, and account boundaries, so access design is inseparable from cloud administration.

Because those controls determine who can launch resources, read data, change configurations, or assume roles, AWS security is often less about the platform itself and more about whether permissions are narrowly scoped and continuously governed. A weak access model can turn a routine cloud deployment into broad exposure.

For a deeper look at the access-control side of cloud security, see NIST SP 800-53 Rev 5 Security and Privacy Controls, which directly covers identification, authentication, access control, and configuration safeguards relevant to AWS estates.

AWS risk comes from configuration and credential handling

The most common AWS failures are not exotic platform flaws, but exposed keys, overbroad permissions, and insecure cloud configurations. Once a valid credential or misconfigured resource is exposed, an attacker can often move from discovery to data access, resource abuse, or persistence very quickly.

In practice, that means AWS risk is often a compound problem: secrets sprawl, poor inventory, weak role design, and internet-reachable services can align to create a high-impact compromise even when the underlying cloud service is healthy.

One recurring pattern is exposed credentials in code, repositories, images, or environment files, which can lead to account takeover or downstream data theft. Incidents such as the EmeraldWhale Git config credential theft and the Uber breach 2016 show how a single leaked AWS key can become a broad security event.

How AWS is governed in practice

AWS works best when organisations treat account structure, role boundaries, logging, and secret handling as core governance decisions. Cloud adoption without ownership clarity tends to produce duplicate accounts, shared credentials, and services that no one is explicitly accountable for.

Practitioners also need to distinguish between the platform and the workloads running on it. AWS may supply the control plane, but the organisation still owns identity design, secret rotation, service-to-service trust, and the review of permissions that accumulate over time.

For implementation guidance on cloud access patterns and secret hygiene, OWASP Non-Human Identity Top 10 is useful where AWS is being used by applications, automation, and other non-human actors that depend on credentials and scoped privileges.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	AWS access depends on governed accounts, roles, and lifecycle control.
	IA-5 — Authenticator Management	AWS security relies on managing API keys, tokens, and other authenticators.
	AC-6 — Least Privilege	AWS IAM policies and role scoping directly determine how much access each actor gets.
Recommendation — Review and remove unnecessary AWS accounts, users, and role assignments on a defined schedule. Rotate and revoke AWS credentials promptly and limit long-lived authenticator use. Scope AWS permissions to the minimum actions, resources, and conditions required.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	AWS keys and tokens are high-value secrets that often leak from code and configs.
	NHI-05 — Overprivileged NHI	AWS roles, service accounts, and automation often accumulate excessive permissions.
	NHI-07 — Long-Lived Secrets	AWS access keys are often long-lived and materially increase exposure if stolen.
Recommendation — Scan AWS-related code, images, and configs for leaked secrets before deployment. Reduce AWS role and automation privileges to the minimum needed for runtime tasks. Replace long-lived AWS secrets with short-lived credentials where possible.

Practitioner Guidance

Governance implication: Treat AWS account boundaries, IAM roles, and key usage as formal control surfaces, not convenience settings. The practical question is whether every workload and operator has only the access needed for its function, with clear ownership for review and revocation.

What to watch for: Reused access keys, long-lived secrets, and broad policy attachments are signs that AWS is being operated by exception rather than by design. In those environments, compromise of one credential often implies broader environment exposure.

Practitioner takeaway: The safest AWS environments are usually the ones where access is temporary, narrowly scoped, logged, and easy to remove.

AWS