Unit 4: AWS Fundamentals - Subjective Questions

AWS cloud infrastructure consists of globally distributed resources that allow users to deploy applications and store data reliably.

• Regions: Geographical areas containing multiple AWS facilities.
• Availability Zones: Isolated data centers within a region, designed for fault tolerance.
• Edge locations: Sites used by services such as Amazon CloudFront to deliver content closer to users.
• Data centers: Facilities containing physical servers, storage systems, networking equipment, and security controls.
• Points of Presence: Locations that help AWS provide low-latency connectivity and content delivery.

This infrastructure enables scalability, high availability, disaster recovery, low latency, and global deployment. Applications can be distributed across multiple Availability Zones so that failure in one location does not necessarily interrupt the entire service.

An AWS Region is a separate geographical area containing multiple isolated Availability Zones. An Availability Zone is one or more discrete data centers with independent power, networking, and connectivity within a Region.

Deploying resources across multiple Availability Zones provides:

• High availability: The application can continue operating if one Availability Zone fails.
• Fault isolation: Problems in one zone are less likely to affect other zones.
• Improved reliability: Workloads can be replicated across separate facilities.
• Disaster recovery: Data and services can be restored or maintained from another zone.
• Load distribution: Traffic can be distributed among resources in different zones.

A multi-Availability Zone architecture is especially important for business-critical applications that cannot tolerate prolonged downtime.

AWS services are organized into categories based on the type of computing function they provide.

• Compute: Provides processing power for applications. Examples include Amazon EC2, AWS Lambda, and Amazon ECS.
• Storage: Stores files, objects, and block-level data. Examples include Amazon S3, Amazon EBS, and Amazon Glacier storage classes.
• Database: Provides managed database systems. Examples include Amazon RDS, Amazon DynamoDB, and Amazon Aurora.
• Networking and Content Delivery: Connects resources and delivers content. Examples include Amazon VPC, Elastic Load Balancing, and Amazon CloudFront.
• Security, Identity, and Compliance: Controls access and protects resources. Examples include AWS IAM, AWS KMS, and AWS WAF.
• Management and Governance: Helps monitor, configure, and manage AWS environments. Examples include Amazon CloudWatch, AWS CloudTrail, and AWS Config.
• Application Integration: Supports communication between applications. Examples include Amazon SQS, Amazon SNS, and Amazon EventBridge.

These categories help users select appropriate services according to application requirements.

Amazon EC2, Amazon S3, and Amazon RDS provide different types of cloud functionality.

EC2 offers greater control, S3 is designed for durable object storage, and RDS reduces the operational effort needed to run relational databases.

The AWS Management Console is a web-based interface used to access and manage AWS services and resources.

Its major features include:

• Service access: Users can open and configure services such as EC2, S3, IAM, and RDS.
• Resource management: Users can create, modify, monitor, and delete cloud resources.
• Regional selection: Resources can be viewed and managed in a selected AWS Region.
• Dashboard views: Frequently used services and resource information can be accessed quickly.
• Search functionality: Users can locate services and documentation efficiently.
• Monitoring information: Metrics, alarms, status information, and billing details can be reviewed.
• Security integration: Console actions are controlled by IAM users, roles, policies, and multi-factor authentication.

The console is useful for learning, administration, and occasional configuration, although automation tools are often preferred for repeatable large-scale deployments.

The AWS Management Console, AWS CLI, and AWS SDKs are different methods of interacting with AWS.

• AWS Management Console:

  • Browser-based graphical interface.
  • Suitable for visual administration, exploration, and one-time tasks.
  • Requires users to navigate forms and menus.

• AWS Command Line Interface:

  • Text-based tool for running AWS commands from a terminal.
  • Suitable for scripting, automation, and fast repetitive operations.
  • Commands can be included in shell scripts and deployment processes.

• AWS SDKs:

  • Programming libraries for languages such as Python, Java, JavaScript, and .NET.
  • Allow applications to call AWS APIs directly.
  • Suitable for building software that dynamically creates or manages AWS resources.

All three methods use AWS APIs and are governed by IAM permissions. The primary difference is the interaction style: graphical, command-based, or application-based.

The AWS Shared Responsibility Model defines security responsibilities between AWS and the customer.

• AWS responsibility: security of the cloud

  • Protecting AWS data centers and physical facilities.
  • Securing the underlying hardware, networking, and virtualization infrastructure.
  • Maintaining the infrastructure that runs AWS managed services.
  • Providing foundational security features and compliance capabilities.

• Customer responsibility: security in the cloud

  • Managing data, applications, operating systems, and configurations according to the service used.
  • Creating appropriate IAM users, roles, and policies.
  • Configuring network controls such as security groups and network access control lists.
  • Encrypting and backing up data when required.
  • Applying patches to customer-managed systems.

The exact division depends on the service. For example, with EC2, customers manage the guest operating system, while with a managed service such as Amazon S3, AWS manages more of the underlying infrastructure.

The division of responsibility differs because EC2 provides virtual machines while S3 provides a managed object storage service.

For Amazon EC2, the customer is responsible for:

• Selecting and configuring the operating system.
• Applying operating system and application patches.
• Installing and securing application software.
• Configuring security groups and network access.
• Managing user accounts and credentials inside the instance.
• Protecting and backing up application data.

For Amazon S3, the customer is responsible for:

• Creating and configuring buckets.
• Managing bucket policies, IAM permissions, and access control.
• Enabling encryption and selecting appropriate encryption settings.
• Managing object lifecycle, retention, and deletion rules.
• Monitoring data access and preventing accidental public exposure.

AWS protects the physical storage infrastructure and underlying service, but customers remain responsible for how they configure and use the resources.

AWS Identity and Access Management (IAM) is a service used to control authentication and authorization for AWS resources.

IAM helps organizations:

• Create and manage users and groups.
• Define permissions using JSON-based policies.
• Create roles that can be assumed by users, applications, or AWS services.
• Enforce the principle of least privilege.
• Use temporary security credentials instead of long-term credentials where possible.
• Enable multi-factor authentication for stronger identity verification.
• Control access to specific resources and actions.
• Review permissions and activity using AWS security tools.

IAM answers two key questions: Who is making the request? and What is that identity allowed to do? It is central to preventing unauthorized access and limiting the impact of compromised credentials.

IAM users, groups, roles, and policies serve different purposes.

• IAM user: Represents a person or application that requires long-term identity credentials. A user may have a password or access keys.
• IAM group: A collection of IAM users. Permissions assigned to a group are inherited by its members, simplifying administration.
• IAM role: An identity with permissions that can be assumed temporarily by users, applications, or AWS services. Roles do not normally have permanent credentials.
• IAM policy: A document that defines allowed or denied actions, resources, and conditions. Policies can be attached to users, groups, or roles.

For example, an administrator may place employees in a group, assign a policy to that group, and allow an EC2 instance to assume a role for accessing an S3 bucket without storing access keys on the instance.

The principle of least privilege means granting an identity only the permissions required to perform its intended tasks, and no more.

For an application that reads files from Amazon S3:

• Create an IAM role for the application or EC2 instance.
• Allow only the required action, such as s3:GetObject.
• Restrict access to the required bucket and object path.
• Avoid granting unrelated actions such as s3:DeleteObject or s3:PutObject.
• Avoid using a broad resource such as all S3 buckets when one bucket is sufficient.
• Use conditions when access must be limited by encryption, source identity, or network context.
• Review and remove unused permissions regularly.

Least privilege reduces accidental changes, limits the damage caused by compromised credentials, and improves auditability.

An IAM policy is a JSON document containing statements that specify permissions. A request is evaluated using the following general logic:

• The request is associated with a principal such as an IAM user, role, or AWS service.
• AWS evaluates applicable identity-based policies, resource-based policies, permissions boundaries, session policies, and organizational controls.
• An explicit deny overrides any allow.
• If there is no applicable allow, the request is denied by default.
• The request is allowed only when an applicable policy permits the requested action on the requested resource under the required conditions.

A policy statement commonly includes:

• Effect: Allow or Deny.
• Action: The AWS operation being requested.
• Resource: The resource to which the operation applies.
• Condition: Optional requirements that must be satisfied.

This evaluation model allows organizations to create precise access controls.

The AWS account root user is the identity created when an AWS account is initially established. It has unrestricted access to the account and is not controlled by ordinary IAM policies.

Its use should be restricted because compromise of the root user can expose all account resources, data, billing functions, and security settings.

Recommended protections include:

• Enable multi-factor authentication for the root user.
• Use a strong, unique password.
• Do not create or use root access keys for routine work.
• Store root credentials in a secure location.
• Use IAM users or roles for daily administration.
• Monitor root-user activity through AWS CloudTrail.
• Configure alerts for root-user sign-in and sensitive actions.
• Use the root user only for tasks that specifically require it, such as certain account-level configuration operations.

Multi-factor authentication (MFA) requires a user to provide at least two different types of evidence when signing in.

Common factors include:

• Something the user knows, such as a password.
• Something the user has, such as a hardware token or authenticator application.
• Something the user is, such as a biometric characteristic.

MFA improves AWS security because a stolen password alone is not sufficient to access the account. It is especially important for:

• The AWS account root user.
• IAM users with administrative permissions.
• Privileged roles and sensitive operations.
• Access to billing, security, and production resources.

MFA should be combined with strong passwords, least-privilege permissions, monitoring, and secure credential handling. It is a protection against credential theft, but it does not replace proper authorization controls.

Important AWS account security practices include:

• Protect the root user with a strong password and MFA.
• Avoid using the root user for normal administration.
• Create individual IAM identities instead of sharing credentials.
• Apply least-privilege permissions.
• Prefer IAM roles and temporary credentials for applications and cross-account access.
• Rotate or remove access keys that are no longer required.
• Enable CloudTrail to record API activity.
• Use Amazon CloudWatch alarms and security services to detect suspicious behavior.
• Configure billing alerts and budgets to identify unexpected usage.
• Encrypt sensitive data in transit and at rest.
• Keep operating systems and applications patched.
• Review IAM policies and account activity regularly.
• Use AWS Organizations and service control policies where multiple accounts are managed.

Account security requires both preventive controls and continuous monitoring.

Authentication verifies the identity of a requester. Authorization determines what that verified identity is permitted to do.

For example:

• An administrator signs in using an IAM user name, password, and MFA code. This process authenticates the administrator.
• IAM policies then determine whether the administrator may create an EC2 instance, read an S3 object, or modify a security group. This process authorizes the requested actions.

Authentication answers "Who are you?" Authorization answers "What are you allowed to do?"

A user may be successfully authenticated but still receive an access-denied response if no policy permits the requested action. Both controls are necessary for secure AWS access.

IAM roles provide permissions that can be assumed temporarily by trusted users, applications, or AWS services. Temporary credentials include an access key, secret key, and session token with a limited lifetime.

Advantages include:

• Reduced exposure: Long-term secrets do not need to be embedded in source code or configuration files.
• Automatic rotation: Temporary credentials expire and are replaced through the role-assumption process.
• Least privilege: A role can grant only the permissions needed by the application.
• Improved auditing: Role sessions can be tracked in CloudTrail.
• Better integration: AWS services such as EC2 and Lambda can use attached roles.
• Reduced operational effort: Developers do not need to manually distribute and rotate application keys.

This approach is more secure than placing permanent credentials in application files, scripts, or machine images.

A suitable high-level architecture could include the following components:

• Deploy resources in an AWS Region with at least two Availability Zones.
• Place EC2 instances in private subnets across multiple Availability Zones.
• Use an Application Load Balancer in public subnets to distribute incoming traffic.
• Configure Auto Scaling to add or remove EC2 instances according to demand.
• Store static files, backups, and media in Amazon S3.
• Configure S3 bucket policies to prevent unauthorized public access and enable encryption.
• Deploy Amazon RDS with Multi-AZ support for database availability.
• Place the database in private subnets and allow access only from the application security group.
• Use Amazon VPC, route tables, security groups, and network access control lists to isolate traffic.
• Assign IAM roles to EC2 instances instead of storing access keys.
• Enable CloudWatch for monitoring and CloudTrail for activity auditing.
• Use backup, retention, and disaster-recovery policies for important data.

This design combines compute, storage, database, networking, management, and security services while distributing critical resources across isolated facilities.

Shared IAM credentials create several security and operational risks:

• Individual actions cannot be reliably attributed to one person.
• A compromised password or access key can affect every person using it.
• Removing access for one employee requires changing credentials for everyone.
• Users may receive more permissions than they need.
• Password and access-key sharing encourages insecure storage and communication.
• Incident investigation becomes difficult because audit records do not identify the actual user.

A corrected design should:

• Create a separate IAM identity or federated identity for each person.
• Use groups or permission sets to assign job-based access.
• Apply least-privilege policies.
• Require MFA for privileged access.
• Use roles and temporary credentials for applications and elevated tasks.
• Remove inactive users and rotate or revoke unused access keys.
• Enable CloudTrail and review access activity.
• Use centralized identity federation when integrating with an organizational identity provider.

This design improves accountability, reduces exposure, and makes access changes easier to manage.

Public cloud infrastructure and traditional on-premises infrastructure differ in several important ways.

Cloud infrastructure improves flexibility and speed, but customers still need to configure services securely and manage their portion of the security model.