Core AWS & Account Management

• A credit card is still required for Free accounts, so starting with a Paid account simplifies setup
• Paid accounts still allow you to take advantage of the $200 in AWS credits
• Workloads in Paid accounts will not be stopped unexpectedly
• Paid accounts provide access to all AWS services and features
• There is no time pressure, unlike Free accounts, which have a 6-month usage window
  • Free accounts may be suitable for students who can dedicate significant time over six months to learn AWS
• Be prepared to spend some money while learning AWS
  • Running resources incurs costs because they operate on AWS hardware
  • Learning to manage budgets and clean up unused resources early is essential for cloud engineers
  • Develop the habit of checking billing for each service (e.g., search “AWS service X billing”)
  • Experiencing a small billing surprise during learning is preferable to encountering unexpected costs in a real production environment

Demo: Creating an AWS Account

• A typical AWS account setup will include Multi-Factor Authentication (MFA), a budget alarm, and an iamadmin identity (all explained later)
• To sign up for an AWS account, visit: AWS Account Signup
  1. Enter your personal credentials and required information
  2. Paid accounts are recommended, although eligible users may choose a Free account (note that some features or services may be limited in Free accounts)
  3. When prompted to select a support plan, choose Basic Support – Free
  4. Enable IAM Access to Billing Information under the “Account” drop-down menu

• For the purposes of this course, it is recommended to use the Northern Virginia region (us-east-1) to ensure access to all services and resources
  • Not all AWS regions provide the latest services and features
  • Alternatively, you may select the region geographically closest to you for optimal performance

MFA (Multi-Factor Authentication)

Why Multi-Factor Authentication (MFA) is Needed

• Web-based authentication typically relies on usernames and passwords
  • If these credentials are compromised, anyone could impersonate the account owner
• Authentication factors are distinct pieces of evidence used to verify identity:
  1. Knowledge: Something you know (e.g., username and password)
  2. Possession: Something you have (e.g., bank card, MFA device/app, U2F key)
  3. Inherent: Something you are (e.g., fingerprint, facial recognition)
  4. Location: Where you are (e.g., geographic coordinates, network/IP address)
• Security versus convenience trade-off:
  • Using multiple factors increases security and makes impersonation more difficult
  • However, additional factors require more time and effort during authentication
• Types of authentication based on the number of factors:
  • Single-Factor Authentication (SFA/1FA): Uses only one factor
  • Two-Factor Authentication (2FA): Uses two factors
  • Multi-Factor Authentication (MFA): Uses more than one factor

MFA in AWS

• MFA can be activated for any user, such as the account root user or an IAMADMIN user
  • AWS provides a secret key and additional setup information, typically via a QR code
  • This information is entered into an MFA device or app, such as Google Authenticator
  • Passkeys and password managers (e.g., 1Password, Proton Pass) can also serve as a second factor
• Once configured, the MFA code in the device or app refreshes periodically
• During authentication, both the user credentials (username and password) and the current MFA code are required, providing enhanced security

Demo: Securing an AWS Account with MFA

• Navigate to the account drop-down menu → Security Credentials → Assign MFA
• Select “Authenticator App” as the MFA device and follow the setup steps
  • Any authenticator app can be used, including Google Authenticator, Authy, or 1Password

Budget Creation

AWS Free Tier

• Detailed information about the AWS Free Tier is available at: AWS Free Tier
  • Some services offer free trials, others provide a monthly free-tier allowance, and certain services offer free usage indefinitely
  • As discussed in Free vs Paid Accounts, eligible users can utilize a Free account. However, it imposes restrictions on accessible services and features and is valid for only six months
• AWS provides granular tools to track resource consumption in real time, such as AWS Cost Explorer
• Navigate to the drop-down menu → Billing and Cost Management → Bills
  • View a summary of past bills and current-month billing
• Under Billing Preferences, it is recommended to check all available options for convenience

Creating a Cost Budget

• AWS Budgets are highly effective for monitoring expenditures and sending alerts when spending approaches defined thresholds
• Navigate to the drop-down menu → Billing Dashboard → Budgets → Create a Budget
• A “Zero Spend Budget” is particularly useful for remaining entirely within the Free Tier
• In this course, demos and labs are designed to stay within the AWS Free Tier to avoid costs.
  • If unexpected charges occur, setting a budget will trigger alerts, reminding you to delete any resources that may be incurring costs

AWS IAM Fundamentals (AWS IAM 101)

Identity and Access Management (IAM) Service

• AWS IAM is a core AWS service responsible for managing identities
  • It has three primary functions:
    1. Manages identities – IAM serves as an Identity Provider (IDP)
    2. Authenticates identities – Verifies that an entity is who it claims to be
    3. Authorizes identities – Grants or denies access to resources based on policies
  • IAM is a free service
  • Public and global service ensures data security and availability across all AWS regions
• IAM provides full control permissions, but these are limited to local identities within the account
  • IAM cannot directly manage identities in external accounts
  • Each AWS account has its own IAM instance, separate from other accounts, and the account fully trusts its own IAM instance
• IAM can perform nearly all account tasks, except for billing management and account closure, which are restricted to the account root user
• IAM also handles:
  • Multi-Factor Authentication (MFA)
  • Identity Federation, allowing external identities (e.g., web identities like Facebook or Google, or corporate Active Directory accounts) to access AWS resources indirectly

Root User of the Account

• The account root user is the default identity of an AWS account
  • Linked to the account’s email address
  • The account fully trusts the root user, granting full, unrestricted access
    • The root user and the AWS account can be considered loosely equivalent
  • The root user is not an IAM identity and is outside IAM control
  • Best practice: Use the root user only for exceptional tasks that cannot be performed by other users
• Root User Privileges outlines these exceptional tasks
  • Important: The root user of an AWS account (effectively the account owner, and not an IAM identity) should not be used for routine tasks, as it cannot be restricted.
  • The root user is still required for certain critical tasks; this may be tested on exams
  • Key privileges of the root user (memorize these):
    • Change account settings (account name, email address, root user password, root user access keys)
    • Close or delete the AWS account
    • Change or cancel the AWS Support Plan
    • Register as a seller in the Reserved Instance Marketplace
      • Example: If you purchase a three-year reserved instance but only use it for two years, the unused capacity can be sold in this marketplace; root user access is required to register as a seller
  • Additional privileges (not essential to memorize):
• Principle of least privilege: Grant identities only the permissions necessary for their tasks and restrict all other access

IAM Identities and Policies

• IAM allows the creation of additional identities within an account, called IAM identities:
  1. IAM users: Individual humans or applications that require long-term access to an account
     • Each user represents a distinct entity
     • Long-term credentials (username and password and/or access keys) are used
  2. IAM groups: Collections of IAM users, such as development, finance, or HR teams
  3. IAM roles: Used by AWS services or to grant temporary access to external entities
     • Short-term credentials are used when the number of entities is uncertain
• IAM policies are documents attached to IAM identities that allow or deny access to AWS services and resources
  • Policies are written in JSON
  • Permissions granted by a policy are fully trusted by the account, similar to how the account trusts IAM

Demo: Adding an IAM Admin User to an AWS Account

• IAM users sign in via a sign-in URL:
  • https://<account-id>.signin.aws.amazon.com/console (account ID is a numeric string)
  • Account alias can be set for a more user-friendly URL (must be globally unique):
    • Example: https://<account-alias>.signin.aws.amazon.com/console
• In this demo, a new IAM user with full administrative permissions is created, named iamadmin
  • This allows the root user to be used only for exceptional tasks
  • The root user cannot be restricted, deleted, or recreated, so normal administrative tasks should not be performed with it
• Creating the IAM user: Navigate to IAM → Users → Add Users
  • Enter a username (unique within the account)
  • Grant permissions during creation, e.g., assign the AdministratorAccess policy to iamadmin
    • This policy provides full account access, except for a few privileges reserved for the root user, such as closing the account
• When signing in with iamadmin, the username is displayed in the top-right corner of the console

• Ensure that the iamadmin user is also secured with MFA

Logging into AWS Accounts

Three Methods for Accessing AWS Accounts, Services, and Resources

1. AWS Management Console (Web UI)
2. AWS CLI (Command Line Interface)
3. AWS SDK (Software Development Kit)

AWS Management Console (Console UI)

• Web-based user interface accessible through a browser
• Requires login with a defined identity in the account: root user, IAM user, or IAM role
  • Authentication is protected by password and optionally MFA
• Interacting with the Console UI is often referred to as “ClickOps”, since operations are performed primarily through clicks
  • In contrast, Infrastructure as Code (IaC) and DevOps workflows rely on scripts, code, and automation to manage AWS services and resources

AWS CLI (Command Line Interface)

• Enables interaction with AWS services via commands executed in a shell or terminal using public APIs
• Requires installation of the AWS CLI on your system
  • Installation instructions: AWS CLI Getting Started
• Open-source: AWS CLI on GitHub
• Requires IAM Access Keys

AWS SDK (Software Development Kit)

• Provides language-specific code libraries that can be integrated into application code or scripts
  • Enables programmatic access and management of AWS services
• Requires IAM Access Keys
• Example: AWS CLI is built on the AWS SDK for Python

AWS CloudShell

• A terminal/CLI environment hosted within an AWS region and accessible directly from the Console UI
  • Includes AWS CLI, preloaded credentials, and the selected region
• Provides a small storage repository for the account to store files if needed
• Not available in all regions
  • Supported regions: AWS CloudShell Documentation

IAM Access Keys

Long-Term and Short-Term Credentials

• Credentials are pieces of information recognized by AWS and its identities that enable authentication, meaning access to an AWS account.
  • Long-term credentials are persistent and do not rotate automatically or on a schedule.
    • Examples include a username and password or IAM access keys.
    • The owner of long-term credentials is responsible for changing them manually, such as updating a password.
  • Short-term credentials are temporary and expire after a limited period.
    • Identities using short-term credentials must regularly request new ones to maintain continued access.
• The account root user and IAM users rely on long-term credentials, while IAM roles use short-term credentials.
• Credentials consist of both a public and a private component.
  • For example, a username is public, while a password is private. MFA serves as an additional private authentication factor.

IAM Access Keys

• Access to AWS through the AWS CLI and AWS APIs is typically performed using IAM access keys.
• IAM access keys are long-term credentials provided by AWS.
  • Each access key pair contains two components, both required for authentication:
    1. Access Key ID (public), for example: AKIAIOSF0DNN7EXAMPLESecret Access Key (private), which is longer and more complex (for example: wJalrXUtnFEMI…)
       • Once generated, the secret access key is never displayed again by AWS.
    • Example screenshot:

• Access keys can be created, deleted, deactivated, and reactivated.
  • Newly created access keys are active by default.
  • Access keys cannot be modified.
    • Instead, they can be rotated by deleting and recreating them, which results in new keys.
• An IAM user may have:
  • Zero or one username and password pair
    • Some IAM users are intended solely for CLI or API access and therefore do not require a password.
  • Zero, one, or two access key pairs
    • Having two access keys supports safe key rotation.
• Although root users can generate access keys, doing so is strongly discouraged.
  • The root user should not be used for routine tasks, making CLI or API usage unnecessary in most cases.

Demo: Creating Access Keys and Configuring AWS CLI v2

• Create access keys by navigating to: Drop-down menu → Security Credentials → Create Access Key
  • Download and securely store the access keys locally, such as by using the CSV file option.
• Install AWS CLI v2:
  https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • After installation, entering the aws command in your terminal should display usage instructions, confirming a successful setup.
  • Run aws --version to verify that version 2 or later is installed.
• AWS CLI v2 supports profiles for managing multiple configurations.
  • aws configure sets up the default profile.
    • Providing a profile name creates a named profile.
  • Example:
    • aws configure --profile iamadmin-general
      • Configures a named profile for the iamadmin user in the general AWS account.
      • Requires entering the access keys, a default region (such as us-east-1), and a default output format (None).
• Use aws s3 ls to list all S3 buckets in the account.
  • This is a commonly used command to confirm successful CLI access to an AWS account.
  • When using a named profile, it must be explicitly specified:
    • aws s3 ls --profile iamadmin-general
• Once the AWS CLI profile is configured correctly, you may safely delete any downloaded CSV files containing access keys.

AWS Fundamentals

Public and Private AWS Services

AWS Networking Ecosystem

• There are three distinct networking zones in AWS:
  1. AWS Private Zones
     These consist of customer-managed private networks, known as Virtual Private Clouds (VPCs).
     • VPCs are isolated and private by default
       • This isolation applies even between different VPCs.
     • External connectivity to a VPC can be explicitly configured:
       • Access from on-premises environments using VPN or AWS Direct Connect (DX)
       • Connectivity to the AWS public zone through components such as an Internet Gateway (IGW)
       • Access to the public internet through an IGW
       • Similar to a laptop connected to a VPN, a VPC only communicates externally when such connectivity is intentionally configured.
     • AWS private services require a VPC to deploy resources
       • For example, Amazon EC2 launches virtual servers (instances) within a VPC.
  2. AWS Public Zone
     This is an AWS-managed network that is connected to the public internet.
     • It operates between VPCs and the public internet.
     • AWS public services run in this zone, such as:
       • AWS Identity and Access Management (IAM)
       • Amazon Route 53
       • Amazon S3
     • These services expose public endpoints that are reachable from the internet.
     • AWS public services do not require a VPC.
     • When a VPC communicates with a public AWS service (for example, Amazon S3), traffic may pass through an IGW while never actually traversing the public internet.
  3. Public Internet Zone
     This represents the traditional global internet, the publicly accessible network of networks.
• The distinction between AWS private services and AWS public services applies only to networking.
  • It is not related to authentication or authorization.
  • AWS public services do not provide unrestricted access.
    • They simply expose public endpoints.
    • Any entity accessing those endpoints must still present valid credentials or meet authorization requirements.
    • By default, only the account root user can access public services. Other identities must be explicitly granted permissions.
• AWS Networking Zones 

High Availability (HA), Fault-Tolerant (FT) Systems & Disaster Recovery (DR)

High Availability (HA)

• A highly available (HA) system is designed to ensure a specified level of operational performance, usually measured as uptime, over an extended period.
  • HA focuses on maximizing system uptime.
    • When a component fails, it can be replaced or repaired quickly, often through automation.
  • HA systems incur additional costs compared to standard systems due to required redundancy and automation.
• Examples include:
  • Maintaining a spare physical server to replace a failed primary server.
  • Automatic failovers, where a standby or replica server replaces a failed instance.
• Important: HA does not prevent failures or outages, nor guarantee uninterrupted user experience.
  • HA systems may experience downtime, but it is shorter than in non-HA systems.
  • Users may experience brief disruptions while the system recovers.
• In essence, HA is about rapid and automated recovery from failures.
  • Real-life analogy: carrying a spare tire during a desert trip. Changing a flat is a disruption, but it is much faster and safer than waiting for external assistance.

HA Summary:

Fault Tolerance (FT)

• A fault-tolerant (FT) system continues to operate properly even if some of its components fail.
  • The system must stop using faulty components and reroute traffic automatically, ensuring uninterrupted operation.
  • FT systems are more robust and costly than HA, as they must tolerate failures without downtime.
• Example: a hospital heart monitoring system with redundant servers. Any downtime could endanger lives.
• Real-life analogy: an airplane with redundant engines and electronics must continue flying even if one fails. Repairs cannot occur mid-flight.

FT Summary:

Disaster Recovery (DR)

• Disaster Recovery (DR) is a set of policies, tools, and procedures designed to restore or maintain critical IT systems and infrastructure following a natural or human-induced disaster.
  • Essentially, DR addresses what to do if HA and FT fail.
  • DR planning involves two phases:
    1. Pre-disaster planning: preparing for potential system disruptions.
    2. Post-disaster recovery: restoring access to systems, data, and infrastructure.
  • Modern DR processes are highly automated to minimize human error.
• Business continuity (BC) focuses on maintaining operations during a disaster, while DR focuses on restoring IT functionality afterward.
• Effective DR plans require:
  1. A prioritized plan to protect critical assets for recovery.
  2. Investment in infrastructure resilience:
     • Additional hardware, servers, virtual machines, or instances.
     • Backups, stored offsite to prevent loss during a disaster.
  3. Investment in knowledge:
     • Comprehensive documentation of critical procedures, credentials, and resources.
     • Staff training, including periodic DR drills or dry runs.
• Real-life analogy: a plane’s ejection system (parachutes) prioritizes human life over replaceable assets.

DR Summary:

Global AWS Infrastructure

AWS Global Network 

• AWS infrastructure is distributed globally and organized into collections of interconnected infrastructure, linked with high-speed global networking.
  • Ref: AWS Global Infrastructure
  • The AWS global network is continuously expanding and evolving.
• Three primary types of AWS infrastructure groupings:
  1. Regions
  2. Availability Zones (AZs)
  3. Edge Locations / Points of Presence (PoPs)

AWS Infrastructure Groupings

AWS Region

• A region is a geographical area with complete AWS infrastructure, including compute, storage, databases, AI, analytics, and more.
  • Example: Asia Pacific (Sydney) region, or ap-southeast-2 region
    • “Asia Pacific (Sydney)” = region name ↔ ap-southeast-2 = region code
  • Regions are not equivalent to countries, states, or continents; they are defined by AWS for infrastructure deployment.
• Regions are interconnected at high speeds, supporting designs that can withstand global disruptions.
  • If one region experiences an outage, services can continue in another region.
• Non-global services require specifying a region; global services (e.g., IAM) do not.

Benefits of Regions:

1. Geographic separation → Isolated Fault Domain
   • Outages in one region do not affect others.
2. Geopolitical separation → Compliance & Governance
   • Data remains subject to the laws of the country where the region is located.
   • Data is not transferred between regions unless explicitly configured.
3. Location control → Performance
   • Deploying resources closer to users reduces latency and improves performance.

Factors to consider when selecting regions:

• Compliance with data regulations (e.g., EU data residency requirements).
• Latency and performance for end users.
• Service availability (not all services are available in all regions).
  • Reference: AWS Regional Services
• Pricing differences across regions, though most services have comparable costs globally.

AWS Availability Zone (AZ)

• AZs are subdivisions within a region, typically 3–6 per region.
  • Example: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c in the ap-southeast-2 region.
• AZs provide isolation within a region, including compute, storage, networking, power, and facilities.
  • Services can fail in one AZ but continue operating in others if designed for AZ resilience.
• Important: AZs are not single data centers (DCs).
  • Each AZ may contain one or more DCs, each with redundant power, networking, and connectivity, geographically separated to improve resilience.
• High-speed, low-latency connectivity exists between AZs in a region.
• Some services (e.g., VPC) are deployed across multiple AZs for resilience.

AWS Edge Location / Point of Presence (PoP)

• Edge locations are local distribution points for faster and more efficient data transfer.
  • Much smaller than regions.
  • Useful for applications like Netflix to store content near customers, reducing latency.
  • Typically consist of a few racks in third-party data centers.
  • Mostly used for storage (e.g., CloudFront caching) with occasional compute resources.
• Supports edge computing scenarios.
• Colloquially, edge locations and PoPs are treated as synonyms, though technically they may differ.

Resilience of an AWS Service

1. Global resilience
   • Service data is replicated across multiple regions, allowing continued operation even if one region fails.
   • Examples: IAM, Route 53.
2. Regional resilience
   • Service operates within a single region, with data replicated across all AZs in that region.
   • Can tolerate individual AZ outages but will fail if the entire region is down.
   • Examples: VPC, S3
     • S3 buckets must be globally unique, but the data resides in a region, making S3 regionally resilient.
3. AZ resilience
   • Service operates within a single AZ and is more prone to failure.
   • Some services are designed to be highly available within a single AZ.
   • Examples: EC2, RDS

Introduction to Amazon S3 (Simple Storage Service)

Amazon S3 – Key Concepts

• Amazon S3 is AWS’s default storage service.
  • It provides object storage (not file storage or block storage).
    • Stores objects (data) within buckets (containers of objects).
  • Ideal for hosting large datasets such as movies, audio, images, text, and unstructured data.
    • Cost-effective
    • Accessible via AWS Console, CLI, API, or HTTP(S)
  • Public service, supports unlimited storage and multiple users.
  • Many AWS services use S3 as the default data input/output platform.
• S3 is globally accessible, but data is regionally based.
  • Bucket names must be globally unique.
  • Data is stored in a specific region and replicated across that region’s AZs.
• As an object store:
  • Not a file store – you cannot browse S3 like a traditional filesystem.
    • Use Amazon EFS or Amazon FSx for file storage.
  • Not a block store – you cannot mount an S3 bucket as a drive (e.g., K:\ or /images).
    • Use Amazon EBS for block storage.

S3 Objects

• Objects are roughly analogous to files but are technically different.
• Components of an object:
  • Key – identifies the object within a bucket (e.g., koala.jpg), similar to a filename.
  • Value – the data or contents of the object, from 0B up to 5TB.
    • 5TB is the maximum size for an S3 object.
  • Other components: Version ID, metadata, access control list (ACL), and subresources.
• Objects cannot exist outside a bucket.

S3 Buckets

• S3 bucket = container for S3 objects.
  • Created in a specific region, ensuring data sovereignty.
  • Can store an unlimited number of objects, making S3 highly scalable.
• Bucket names must be globally unique across all regions and accounts.
  • Example: koaladata
  • ARN example: arn:aws:s3:::koalacampagin13333337
• Bucket naming rules:
  • 3–63 characters, all lowercase, no underscores
  • Must start with a lowercase letter or number
  • Cannot be formatted like an IP address (e.g., 1.2.3.4)
• S3 uses a flat structure – there are no true folders or directories.
  • AWS Console may display objects with prefixes as folders, but all objects are stored at the same level.
  • Example: A bucket contains objects flashcards.html, index.html, notes.html, /images/badges.jpg. The Console shows /images as a folder, but it is actually a prefix, not a directory.
• Bucket limits per account:
  • Default limit: 10,000 buckets per AWS account.
    • Requests beyond 10,000 require AWS support approval.
  • This limit affects architecture decisions (e.g., one bucket per user may not scale).
• Buckets are private by default.
  • AWS includes a public access block by default, preventing accidental public exposure.

• Disabling the block does not make the bucket public automatically; explicit configuration is still required.

Introduction to Amazon VPC (Virtual Private Cloud)

Amazon VPC – Key Concepts

• Amazon VPC allows you to create and manage virtual private networks (VPNs) inside an AWS account.
  • A Virtual Private Cloud (VPC) is a virtual private network within AWS.
    • VPC CIDR defines the IP address range for the VPC (e.g., 172.31.0.0/16).
  • Most AWS services and resources, particularly private services, run inside VPCs (e.g., EC2 instances).
• VPCs exist within a single AWS account and a single region, making them regionally resilient.
  • VPCs can create subnets, which are smaller network segments in different Availability Zones (AZs) of the region.
    • If one AZ fails, the VPC can continue to operate in the other AZs.
  • Subnet CIDR is a portion of the VPC CIDR and cannot be modified once configured.
• Types of VPCs:
  • Default VPC (0–1 per region)
    • Preconfigured by AWS with a static setup.
  • Custom VPCs (0+ per region)
    • Fully configurable and private by default.
• Custom VPCs are private and isolated by default.
  • They cannot communicate with any external networks, including other VPCs, unless explicitly configured.
  • Communication with external entities requires additional configuration:
    • Other VPCs
    • On-premises networks in hybrid setups
    • Other cloud platforms in multi-cloud deployments
    • Public internet
  • The Default VPC does not follow this strict privacy rule.

Default VPC

• Automatically created by AWS with a standard, pre-configured setup.
  • Predictable and useful for quick testing.
  • Less flexible, so not ideal for production environments.
• Default VPC CIDR is always 172.31.0.0/16.
• Each region can have 0–1 Default VPC.
  • Can be deleted and recreated.
    • Creating a VPC manually always creates a Custom VPC, not a Default VPC.
  • Some AWS services assume the Default VPC exists, so it is usually recommended to keep it.
• A /20 subnet is automatically deployed in each AZ in the region.
  • Example: us-east-1 (N. Virginia) has 6 AZs, so the Default VPC has 1 subnet per AZ.
• Preconfigured with:
  • Internet Gateway (IGW)
  • Security Groups (SG)
  • Network ACLs (NACL)
• By default, resources in the Default VPC are assigned public IPv4 addresses, making them accessible from the public internet.
  • Unlike Custom VPCs, the Default VPC is not private or isolated by default.

Amazon EC2 101: Basics of Elastic Compute Cloud

Amazon EC2 – Key Concepts

• Amazon EC2 is AWS’s default compute service.
  • It is an IaaS (Infrastructure-as-a-Service) offering, where the operating system (OS) is the primary unit of consumption.
  • Customers provision instances, which run on physical EC2 hosts.
    • Instances are also called virtual machines (VMs) or virtual servers (VSs).
    • Customers manage instances, while AWS manages the physical hosts (exception: dedicated hosts managed by customers).
• Instances run inside VPC subnets, making EC2 private by default and resilient within an AZ.

EC2 Instances

• An EC2 instance is essentially a virtual machine (VM).
  • Customers provision the OS and can configure the runtime environment (RTE), databases, and applications inside the instance.
• Instance size and capabilities are defined at launch, though some features can be adjusted after launch.
• Billing model: On-Demand, charged per second for the resources used.
• Networking: Instances are deployed in VPC subnets. Public access must be explicitly configured.
• Storage options:
  • Local block storage on the host (Instance Store)
  • External block storage via Amazon EBS (Elastic Block Store)

EC2 Instance States

• The state indicates the condition of an instance. Core states include:
  1. Running (Active) – billed for CPU, memory, networking, and storage.
  2. Stopped (Inactive) – billed only for storage; can be restarted.
  3. Terminated (Deleted) – permanently deleted and cannot be restarted; no further charges apply.

Connecting to EC2 Instances via SSH

• SSH (Secure Shell) is a secure protocol for connecting to Linux instances.
  • Uses port 22 and authentication via SSH key pairs (private + public key).
    • Private key is downloaded once and stored locally (e.g., A4L.pem).
    • Public key is stored on the EC2 instance by AWS.
• Once connected, a terminal is available for managing the instance.
• Private key permissions must allow only the owner to read it:
  • chmod 400 A4L.pem (Mac/Linux)
  • AWS rejects connections if permissions are incorrect.

SSH Connection

Connecting to Older Windows Instances via RDP

• Windows OS versions prior to Win10 do not natively support SSH.
• EC2 instances with older Windows require RDP (Remote Desktop Protocol) on port 3389.
• SSH keys are used to authenticate to the local administrator password, allowing access via RDP.

Amazon Machine Image (AMI)

• AMI is an image of an EC2 instance.
  • Contains a disk image, kernel, and VM configuration.
  • Can be used to launch new EC2 instances.
  • Can be created from an existing instance as a snapshot, capturing the OS and installed software.
• Components of an AMI:
  • Permissions: define which accounts can use the AMI.
    • Public AMI: anyone can launch instances.
    • Private AMI: owner-only by default; specific AWS accounts can be allowed.
  • Root/Boot Volume: the storage drive that boots the OS (C: in Windows, / in Linux).
  • Block Device Mapping: defines how storage volumes are presented to the OS.

AMI Overview

Introduction to Amazon CloudWatch (CW)

Amazon CloudWatch – Components and Architecture

• CloudWatch collects and manages operational data, providing monitoring and operational management.
  • Operational data includes service performance, metrics, logs, and more.
  • It is a core support service used by most AWS services.
  • CloudWatch is a public AWS service.

Main Components of CloudWatch

1. CloudWatch Metrics
   • Provides the core metrics service.
   • Examples: CPU utilization of an EC2 instance, disk usage of an on-premises server.
   • Can collect metrics from AWS services, custom applications, or on-premises systems.
   • Some metrics are gathered natively by AWS.
   • A CloudWatch Agent is required to collect:
     • Non-native AWS metrics (e.g., internal processes in EC2 instances)
     • Metrics from outside AWS
   • Metrics should be organized and separated to avoid confusion.
2. CloudWatch Logs
   • Collects logs from AWS services, applications, or on-premises infrastructure.
   • Some logs are generated natively; others require the CloudWatch Agent.
3. CloudWatch Alarms
   • Trigger notifications (via Amazon SNS) or events based on monitored metrics.
   • Example: Send an SMS when an EC2 instance’s CPU usage exceeds 90%.
   • Billing alarms are also created in CloudWatch, sending notifications when costs exceed a threshold.
4. CloudWatch Events (now Amazon EventBridge)
   • Integrates with AWS services and scheduled events.
   • Generates events that can trigger actions, such as sending notifications.
   • Events are generated based on:
     1. Conditions (e.g., EC2 instance creation or termination)
     2. Schedules (e.g., specific times or recurring schedules)

Amazon CloudWatch – Key Concepts

• Datapoint = combination of a timestamp and a value.
  • Example: CPU usage = 98.3% at 08:45:45 on 2019-12-03.
• Metric = a time-ordered sequence of datapoints.
  • Examples: CPU usage, network I/O, disk I/O.
  • Metrics are not necessarily tied to a single instance; for example, CPU usage may represent all EC2 instances by default unless filtered.

• Namespace = container for related monitoring data.
  • Organizes metrics to avoid clutter.
  • Can use any valid naming convention.
  • Example: AWS/ contains all AWS metrics, and AWS/EC2 contains all EC2-related metrics.
• Dimensions = criteria to separate datapoints of the same metric into different perspectives.
  • Example: Within AWS/EC2, dimensions may separate metrics for Instance A and Instance B.
  • Dimensions are flexible and powerful for filtering and analysis.

• Alarms perform actions when a metric reaches a specified threshold.
  • Example: Send a notification when costs exceed a budget.
• States:
  • INSUFFICIENT DATA – initial state
  • OK – metric is within the threshold
  • ALARM – threshold exceeded; alarm triggers actions
  • Notifications are sent using Amazon SNS when the state is ALARM.

Introduction to AWS CloudFormation (CFN)

IaC Basics and AWS CloudFormation

• IaC (Infrastructure as Code)
  • Enables creation, updating, and deletion of infrastructure using code or templates.
  • Code and templates are consistent and repeatable, which:
    • Reduces human errors
    • Speeds up provisioning and deletion compared to manual methods
• AWS CloudFormation (CFN)
  • AWS’s official IaC service.
  • Templates are written in YAML or JSON to interact with AWS infrastructure.
  • External IaC tools like Terraform or AWS CDK are popular; they translate into CFN templates to manage AWS resources.

CFN Templates – Components and Examples

• By default, CFN templates are stored in an S3 bucket with the prefix CF.
  • Do not confuse CFN (CloudFormation) with CF (CloudFront).
• Resources – AWS resources to create, update, or delete.
  • Examples: VPCs, S3 buckets, EC2 instances.
  • Mandatory component – a template without resources does nothing.
  • Resources in templates are logical resources, not physical.
• AWSTemplateFormatVersion – Version of the template.
• Description – Optional text explaining the template.
  • Must appear after AWSTemplateFormatVersion if included.
• Metadata – Defines how the template appears in the AWS console.
• Parameters – Fields prompting users to provide required input values.
• Mappings – Key-value pairs used for lookups within the template.
• Conditions – Define criteria for resource creation (e.g., create a resource only if in a PROD environment).
• Outputs – Messages or values returned when the template is applied (e.g., “EC2 instance created”).
• Intrinsic Functions – Built-in functions used in templates:
  • LatestAmiId – Fetch the most recent AMI in a region.
  • !Ref – Reference an existing resource.
  • !GetAtt – Retrieve a specific attribute from a resource.
• Template Examples (YAML & JSON): CFN Template Examples

CFN Stacks

• A CFN template contains logical resources and other components.
• CFN Stack – The active representation of all resources defined in a template.
  • Created from a template.
  • Can be executed in an AWS account to create, update, or delete infrastructure.
  • Each logical resource in the stack corresponds to a physical resource in AWS.

Syncing Logical and Physical Resources

• Physical Resource – Exists in AWS infrastructure and is visible in the console.
  • Example: Running EC2 instance with ID i-1234567890abcdef0.
• Logical Resource – Defined in CFN templates and stacks.
  • Does not exist outside of CFN templates/stacks.
  • Includes a type (e.g., AWS::EC2::Instance) and properties (e.g., ImageID, KeyName).
  • Can be synced to the corresponding physical resource.
• CloudFormation’s Role
  • Keeps logical and physical resources synchronized.
  • Automates infrastructure management.
    • Allows approvals before committing changes.
    • Enables quick deployment of one-off resources.
    • Deleting a stack removes both logical and physical resources, ensuring automatic cleanup.
  • Widely used in labs and demos for SAA-C03 preparation.

Introduction to AWS Lambda

AWS Lambda – Key Concepts

• Function-as-a-Service (FaaS) – designed for short-lived, focused code execution.
  • A Lambda function is the unit of code executed by AWS Lambda.
  • “A Lambda” is commonly used to refer to “a Lambda function.”
• Each function must specify a Runtime Environment (RTE) (e.g., Python 3.8) before execution.
  • Memory is directly configured, while vCPU is indirectly determined based on memory.
  • When triggered, the function executes in the selected RTE.
• Billing is based only on the compute consumed during execution.
  • Ideal for serverless and event-driven architectures (EDA).
  • Cost-effective: the first million invocations are free under AWS Free Tier, and subsequent invocations are inexpensive.

AWS Lambda – Architecture

• A Lambda function consists of code, configuration, and runtime package.
  • Includes programming language, deployment package (downloaded and executed at runtime), and allocated resources.
  • Colloquially, “Lambda” may refer only to the code, but the function is more than just the code.
• Supported Runtimes: Python, Ruby, Java, Node.js, and more.
  • Lambda Layers allow custom runtimes (e.g., Rust via community support).
• Invocation Behavior:
  • Each invocation creates a new RTE. Code is loaded, executed, and terminated.
  • Subsequent invocations usually start with a fresh RTE, although some configurations can reuse RTE components.
  • Functions are stateless; no data persists between invocations.
• Docker Considerations:
  • Traditional Docker is considered an anti-pattern for Lambda.
  • Lambda supports Docker images, but these are specialized for Lambda, not standard containerized environments.
• Resource Allocation:
  • Memory: 128MB–10240MB (1MB increments).
  • vCPU: 1 vCPU per 1769MB of memory (scales linearly with memory).
  • Temporary disk: 512MB mounted at /tmp, can scale up to 10240MB. Data is wiped on each invocation.
• Timeout: Maximum 900 seconds (15 minutes). Functions requiring longer execution should use services like AWS Step Functions.
• Execution Role: IAM role that governs permissions and security for the function.

AWS Lambda – Common Use Cases

• Serverless Applications: e.g., S3 + API Gateway + Lambda
• File Processing: e.g., watermarking images uploaded to S3
• Database Triggers: e.g., DynamoDB Streams invoking Lambda on data changes
• Scheduled Tasks: Using EventBridge or CloudWatch Events to run periodic functions
• Real-time Data Processing: e.g., Kinesis Data Streams triggering Lambda functions

Demo: Create and Execute a Lambda Function

1. Deploy CloudFormation Stack to spin up two EC2 instances:
   • Stack link
2. Create Execution Role in IAM or during Lambda creation.
   • Example JSON for EC2 start/stop permissions:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“logs:CreateLogGroup”,
“logs:CreateLogStream”,
“logs:PutLogEvents”
],
“Resource”: “arn:aws:logs:::” }, { “Effect”: “Allow”, “Action”: [ “ec2:Start“,
“ec2:Stop” ], “Resource”: ““
}
]
}

3. Create Lambda Function:
   • Provide a name and select runtime (e.g., Python 3.9).
   • Assign the execution role created in step 2.
4. Add Code to the function:

Stop EC2 Instances Example:

import boto3
import os

region = ‘us-east-1’
ec2 = boto3.client(‘ec2’, region_name=region)

def lambda_handler(event, context):
instances = os.environ[‘EC2_INSTANCES’].split(“,”)
ec2.stop_instances(InstanceIds=instances)
print(‘Stopped instances: ‘ + str(instances))

5. Set Environment Variables:
   • Include EC2_INSTANCES with instance IDs (comma-separated).
6. Test the Function:
   • Click “Test” in the console; verify EC2 instances stop.
7. After the function executes successfully, output will be displayed in the console and the EC2 instances will be stopped. Confirm this by checking the EC2 console.
8. Create another function using the same approach to start the EC2 instances. Run or test the function and verify in the EC2 console that the instances have started.

Start EC2 Instances Example:

import boto3
import os

region = ‘us-east-1’
ec2 = boto3.client(‘ec2’, region_name=region)

def lambda_handler(event, context):
instances = os.environ[‘EC2_INSTANCES’].split(“,”)
ec2.start_instances(InstanceIds=instances)
print(‘Started instances: ‘ + str(instances))

9. Clean-up: delete the created functions, then delete the CloudFormation stack

Introduction to Amazon Route 53 (R53)

Amazon Route 53 (R53) – Core Concepts

• DNSaaS (DNS as a Service): an AWS-managed DNS offering
• A global service
  • Uses a single database that is replicated and accessible across all regions
  • Designed to be globally resilient
  • No region selection is required in the AWS console
• Two primary features:
  1. R53 Registered Domains
     • Route 53 can function as a domain name registrar
  2. R53 Hosted Zones
     • Route 53 can also act as a DNS hosting provider
• Note that in addition to domain registration and renewal costs, there are charges for maintaining hosted zones

R53 Registered Domains

• Route 53 maintains relationships with major TLD registries (such as .com, .io, .net)
  • For example, PIR (Public Interest Registry) manages the .org TLD
• Process for registering a new domain (for example, animals4life.org):
  1. Route 53 checks whether the domain name is available
  2. If available, the customer agrees to the terms and purchases the domain through Route 53
  3. Route 53 creates a ZoneFile, which stores the domain’s DNS data
  4. Route 53 assigns AWS-managed name servers for the DNS zone
     • Always four name servers
  5. A hosted zone is created
     • The ZoneFile is stored across the four assigned name servers
     • Entries are created in both Registered Domains and Hosted Zones referencing these servers
  6. Route 53 communicates with the TLD registry (for example, PIR for .org)
     • The TLD’s NS records are updated to point to the Route 53 name servers
     • These four servers become authoritative for the domain
• Registering a domain is not required to complete CLF-C02 or SAA-C03 coursework. You can simply observe the demonstrations. However, for projects such as the Cloud Resume Challenge, owning a domain is recommended and often necessary.
• Transfer lock (enabled by default)
  • Prevents the domain from being transferred out of Route 53
• If a hosted zone is deleted and recreated, the name server records in Registered Domains must be updated to reference the new servers
  • Failure to do so will cause DNS resolution issues

R53 Hosted Zones

• Route 53 stores DNS zones across four AWS-managed name servers
  • These servers hold DNS records (RRSETs)
• Network visibility options:
  1. Public Hosted Zones
     • ZoneFile is publicly accessible
     • Part of the global DNS system
     • Reachable from the public internet
  2. Private Hosted Zones
     • ZoneFile is private
     • Associated with specific VPCs
     • Accessible only within those VPCs
     • Commonly used for internal or sensitive DNS records
• Costs:
  • Monthly fee for each hosted zone
  • Small charge per DNS query
    • Query costs can become significant for high-traffic environments and should be monitored

Identity, Access, and Organizational Management

AWS IAM Basics

Identity and Access Management (IAM) Service

• AWS IAM is a fundamental AWS service used to manage identities
  • It performs three primary functions:
    1. Manages identities → IAM acts as an Identity Provider (IdP)
    2. Authenticates identities → verifies that an entity is who it claims to be
    3. Authorizes access → grants or denies permissions based on defined policies
  • No cost (free service)
  • A public and global service, providing high availability and resilience
    • IAM data is securely replicated across all AWS Regions
• IAM provides full administrative capabilities within an account, but it only manages internal identities
  • It does not have direct authority over external accounts or identities
  • Each AWS account contains its own IAM instance, with a separate identity database
    • This instance operates independently from IAM instances in other accounts
    • An AWS account places complete trust in its own IAM system
• IAM can manage nearly all operations within an account
  • Exceptions include billing management and account termination, which are restricted to the root user
• IAM also supports:
  • Multi-Factor Authentication (MFA)
  • Identity Federation
    • External identities (such as social logins like Facebook or Google, or corporate directory services like Active Directory) can be used to access AWS resources indirectly

Root User of the Account (Account Root User)

• The account root user is the original identity created with an AWS account
  • It is tied to the account’s email address
  • The account fully trusts the root user, granting complete and unrestricted access
    • In practice, the account and its root user are closely linked
  • The root user is not an IAM identity, meaning IAM policies do not apply to it
• Best practice: avoid using the root user for routine tasks
  • Use it only for specific actions that require root-level permissions
• Security best practice: apply the principle of least privilege
  • Grant users only the permissions they need to perform their responsibilities
  • Restrict all unnecessary access to reduce risk

IAM Identities and IAM Policies

• IAM enables the creation of additional identities within an AWS account, known as IAM identities:
  1. IAM users: represent individuals or applications that require long-term access to the account
     • Each user typically corresponds to a specific identifiable entity
     • They use long-term credentials, such as a username and password and/or access keys
  2. IAM groups: collections of IAM users with similar roles or responsibilities
     • For example, teams like development, finance, or HR
  3. IAM roles: used by AWS services or external entities to gain access to an account
     • Ideal when the number of users or entities is not fixed or predictable
     • They provide temporary (short-term) credentials
• An IAM policy is a document or object that can be attached to an IAM identity
  • It defines permissions by allowing or denying access to AWS services and resources
  • The account applies these permissions by trusting the identity and its assigned policies
  • Policies are written in JSON format

Demo: Creating an IAM Admin User in an AWS Account

• IAM users access an AWS account through a sign-in URL:
  • Format: https://<account-id>.signin.aws.amazon.com.console
    • The account ID is a numeric identifier
  • You can also use an account alias, which is easier to remember
    • Must be globally unique
    • Provides a more user-friendly login URL:
      https://<account-alias>.signin.aws.amazon.com.console
• In this demonstration, a new IAM user with administrator-level permissions is created, named iamadmin
  • This allows regular tasks to be performed without using the root user
    • The root user cannot be restricted, deleted, or recreated, making it unsafe for everyday use
• Steps to create an IAM user:
  • Navigate to: IAM → Users → Add Users
  • Set a username (e.g., iamadmin)
    • The username must be unique within the account, but not globally
  • By default, a new IAM user has no permissions, so access must be granted during setup
    • For the iamadmin user, attach the policy named AdministratorAccess
      • This policy provides full access to the account, except for certain actions reserved for the root user (such as closing the account)
• After signing in as the iamadmin user, the username will appear in the top-right corner of the AWS Management Console

• Enable Multi-Factor Authentication (MFA) for the iamadmin user to strengthen account security.

IAM Access Keys

Long-term and Short-term Credentials

• Credentials are pieces of information recognized by AWS and identities that enable authentication (logging in to an AWS account)
  • Long-term credentials remain valid until they are manually changed
    • Examples include username and password and IAM access keys
    • These must be updated manually by the owner when needed
  • Short-term credentials are temporary and expire after a limited period
    • Users or services must regularly request new credentials for continued access
• The root user and IAM users rely on long-term credentials, while IAM roles use temporary credentials
• Credentials consist of two parts:
  • A public identifier
  • A private secret
    • Example: username (public) and password (private), with MFA acting as an additional private factor

IAM Access Keys

• Access to AWS through the CLI and APIs is commonly performed using IAM access keys
• IAM access keys are a type of long-term credential in AWS
  • Each key pair includes:
    1. Access Key ID (public) (e.g., AKIAIOSF0DNN7EXAMPLE)
    2. Secret Access Key (private) (e.g., a longer, more complex string)
       • This secret is shown only once at creation and cannot be retrieved again

• Access keys can be:
  • Created
  • Deleted
  • Activated or deactivated
    • Newly created keys are active by default
• Access keys cannot be modified after creation
  • Instead, they should be rotated by deleting the old keys and generating new ones
• An IAM user can have:
  • Zero or one username/password pair
    • Some users are intended only for CLI or API access and may not require a password
  • Up to two access key pairs
    • This supports smooth key rotation without downtime
• Although the root user can have access keys, this is not recommended
  • The root user should not be used for regular operations, especially for CLI or API access

Demo: Creating Access Keys and Configuring AWS CLI v2

• Create access keys:
  • Go to: Account menu → Security Credentials → Create Access Key
  • Download and securely store the keys (for example, using the CSV file option)
• Install AWS CLI v2 tools:
  • Follow the official installation guide
  • Verify installation by running:
    • aws → should display usage instructions
    • aws --version → confirms the installed version (ensure it is version 2 or higher)
• AWS CLI v2 supports profiles for managing multiple configurations:
  • aws configure → sets up the default profile
  • aws configure --profile iamadmin-general → creates a named profile
    • Provide:
      • Access Key ID and Secret Access Key
      • Default region (e.g., us-east-1)
      • Default output format
• Example command:
  • aws s3 ls → lists all S3 buckets in the account
    • Commonly used to verify successful CLI access
  • When using a named profile:
    • aws s3 ls --profile iamadmin-general
• After configuration, it is recommended to delete downloaded credential files (such as CSV files) from your local machine for security purposes

IAM Permission Policies

IAM Policy

• An IAM policy is a document that defines permissions for accessing AWS resources and performing actions
  • Written in JSON format
  • Specifies whether access is allowed or denied for resources and operations
  • It is important to understand the structure of policies and how to read and create them

Policy Statements

• IAM policies consist of one or more permission statements
  • These statements enable fine-grained control over access
• Each statement includes the following components:
  • SID (Statement ID):
    • A human-readable identifier describing the purpose of the statement
    • Optional, but recommended for clarity
  • Resource:
    • Specifies the AWS resources affected by the statement
    • Defined using ARNs (Amazon Resource Names)
    • Supports wildcards (*) to match multiple resources
    • Example: arn:aws:s3:::catgifs/* refers to all objects within the catgifs bucket
  • Action:
    • Lists the operations that are allowed or denied
    • Based on AWS API actions
    • Supports wildcards (*)
    • Example:
      • s3:ListBuckets → lists all S3 buckets in the account
      • s3:* → allows all S3 actions
  • Effect:
    • Determines the result: Allow or Deny
• A statement can be understood as a rule:
  • If the action and resource match, then the specified effect is applied

• Example summary:
  • One statement allows all S3 actions on all resources
  • Another statement denies all S3 actions on the catgifs bucket and its contents

Permission Evaluation Logic

• Permission decisions follow this priority:
  • Explicit Deny overrides everything
  • Explicit Allow is applied if no deny exists
  • Otherwise, access is denied by default
  • In short: Explicit Deny > Explicit Allow > Implicit Deny
• Implicit Deny:
  • All access is denied by default unless explicitly allowed
  • To gain access, a user must have an explicit allow and no conflicting deny
• Exception:
  • The root user has full access and cannot be restricted by IAM policies
  • However, Service Control Policies (SCPs) can still impose restrictions at the account level

Applying Permission Logic (Example)

• A policy includes:
  • One statement that allows all S3 actions on all resources
  • Another statement that denies all S3 actions on the catgifs bucket and its objects
• If this policy is attached to an IAM user:
  1. The user cannot list EC2 instances
     • No explicit allow exists, so access is implicitly denied
  2. The user can list S3 buckets
     • s3:ListBuckets is explicitly allowed, and there is no deny for this action
     • The catgifs bucket will still appear in the list because the action applies at the account level, not within the bucket
  3. The user cannot access objects inside the catgifs bucket
     • Even though there is a general allow, the explicit deny for that bucket overrides it

IAM Policy Types

Attachment Types: Identity Policies vs Resource Policies

• IAM Identity Policies are attached to IAM identities (users, groups, or roles)
  • Define permissions from the identity’s perspective
  • Can be either inline or managed
  • AWS evaluates which policies are attached to an authenticated identity and processes all related statements
• IAM Resource Policies are attached directly to AWS resources
  • Examples include S3 bucket policies or SNS topic policies
  • Define permissions from the resource’s perspective
  • Must include a Principal element in each statement
    • Specifies which identities the policy applies to (internal or external)
    • Can grant or deny access to:
      • Identities from other AWS accounts
      • Anonymous users
      • Unauthenticated entities
• AWS evaluates all applicable policies (both identity and resource policies) when determining access to a resource or action

Management Types for Identity Policies: Inline vs Managed Policies

• Inline Policies
  • Attached to a single identity within one account
  • Designed for specific or exceptional use cases
  • Example: granting one developer access to a particular S3 bucket while restricting others
• Managed Policies
  • Can be attached to multiple identities and reused across accounts
  • Recommended as the default approach
  • Benefits:
    • Reusable across many users, groups, or roles
    • Easier to manage, since updates apply to all attached identities
  • Types of managed policies:
    1. AWS-managed policies
       • Predefined and maintained by AWS
       • Cover common use cases
       • Example: AdministratorAccess
       • May not always meet specific requirements
    2. Customer-managed policies
       • Created and maintained by the user
       • Allow customization to meet exact business needs

Amazon Resource Name (ARN)

• An ARN (Amazon Resource Name) is a globally unique identifier for an AWS resource
  • It uniquely identifies a resource across all AWS accounts and regions
• ARN formats vary slightly depending on the service:

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

• The <partition> is typically aws
• Examples:
  • arn:aws:iam::aws:policy/IAMUserChangePassword
    • Refers to an AWS-managed IAM policy
    • No region or account ID is required because IAM is a global service and the policy is shared
  • arn:aws:s3:::catgifs
    • Refers only to the S3 bucket named catgifs
  • arn:aws:s3:::catgifs/*
    • Refers to all objects within the catgifs bucket
• Important distinction:
  • :: indicates that a value is not required for identifying the resource
    • Example: no region needed for IAM resources
  • :*: represents a wildcard, meaning any or all values for that field
    • Useful for referencing multiple resources (such as all regions or all objects in a bucket)

IAM Users and Groups

Principals and IAM Identities

• Principal: an entity attempting to access AWS
  • Can be a person, application, service, computer, or group of entities
• Access Process:
  1. Authentication
     • The Principal authenticates against an IAM identity to prove its identity to AWS
     • IAM users authenticate with long-term credentials (username/password or access keys)
     • IAM roles authenticate with short-term credentials (via Amazon STS)
     • Once authenticated, the Principal becomes an authenticated identity and AWS knows which policies apply
  2. Authorization
     • The authenticated identity can perform only allowed actions
     • AWS evaluates all policies attached or applicable to the identity and merges them into an effective set of permissions

IAM User

• IAM user: an identity with long-term credentials
  • Used for humans, applications, or service accounts
  • Think of it as one named entity acting as a Principal
• Account Limit:
  • Maximum 5,000 IAM users per account
  • For large-scale apps (e.g., millions of mobile users), individual IAM users are not practical
    • Use IAM roles or identity federation instead

IAM Group

• IAM group: a container for IAM users
  • Simplifies policy management
    • A policy attached to the group applies to all users in the group
    • Updating the group policy automatically updates all its users
• Important Notes:
  • Not a Principal → cannot log in or act independently
  • Cannot be referenced in resource policies (e.g., S3 bucket policies)
• Limitations and Considerations:
  • A group can contain any number of IAM users (up to the account limit of 5,000 users)
  • AWS has no default all-users group; it must be created manually
  • Membership limit: an IAM user can belong to up to 10 groups
  • No nesting: subgroups are not supported
  • Soft limit: 300 groups per account (can be increased via support)

IAM Roles

IAM Roles – Key Concepts

• IAM role: an IAM identity with short-term credentials
  • Designed to be used by multiple Principals, unlike IAM users which are intended for one specific Principal
  • Examples of Principals that can assume a role:
    • IAM users within the same AWS account
    • IAM users from other AWS accounts
    • External identities (e.g., federated users, apps, services)
• Roles are assumed temporarily
  • A Principal becomes the role for a limited time, borrowing its permissions
  • Conceptually similar to “putting on a hat”:
    • You take temporary responsibility (e.g., opening the theater as an usher)
    • When finished, you return the permissions, and someone else can assume the role later
• Important:
  • An IAM role is not a Principal itself
  • It represents a level of access within an AWS account
• Use cases for IAM roles: Link

IAM Roles – Architecture

• IAM roles are fully valid IAM identities
  • Have short-term credentials that expire quickly
  • Can have identity policies attached, defining permissions
  • Can be referenced as a Principal in resource policies
• Two types of policies for roles:
  1. Permissions Policy (Identity Policy)
     • Defines the actions a Principal can perform while assuming the role
     • Same type used for IAM users and groups
  2. Trust Policy
     • Defines which identities are allowed to assume the role
     • Can include:
       • IAM users/services in the same AWS account
       • Identities/services from other AWS accounts
       • Federated external users (e.g., Facebook, Google)
       • Even anonymous usage

Process: Accessing AWS Resources with a Role

1. Principal attempts to authenticate as the role via IAM
2. IAM checks the trust policy to ensure the Principal is allowed to assume the role
   • Request is denied if the Principal is not trusted
3. Principal calls AWS Security Token Service (STS) using sts:AssumeRole
4. STS generates temporary credentials if allowed
   • The Principal assumes the role and becomes an authenticated identity for a limited time
5. When credentials expire, the Principal must reassume the role to get new temporary credentials
   • Some AWS services auto-renew STS credentials; external applications (e.g., mobile apps) may need custom auto-renewal logic

Use Cases for IAM Roles

1. Grant AWS Services Permissions

• AWS services need access rights to operate on your behalf → IAM roles provide this access
• Example: Lambda Execution Role
  • Lambda functions are not identities and have no permissions by default
  • The IAM role trusts Lambda and can be assumed to grant temporary permissions (e.g., writing objects to S3)
  • Multiple identical Lambdas can assume the same role simultaneously
• Avoid hard-coding long-term credentials in Lambda functions
  • Security risk: credentials exposed in code
  • Rotating keys is cumbersome
  • Multiple functions cannot use the same long-term keys simultaneously

2. Grant Additional Permissions in Extraordinary Situations

• Emergency or “break-glass” access
  • IAM roles can be assumed only in emergencies
  • Usage is fully logged and auditable, ensuring accountability
• Example: Help-desk staff normally have read-only access
  • During emergencies (e.g., admins unavailable), they can assume a temporary role with write permissions to resolve critical issues

3. Grant AWS Access to Existing Corporate Environments

• Corporations often have large identity directories (e.g., Microsoft Active Directory)
• External identities cannot access AWS directly → IAM roles with identity federation provide access
• Process:
  • Users log in with their corporate credentials via SSO
  • They assume an IAM role in AWS (becoming federated identities)
  • Temporary permissions are granted automatically
  • Multiple users can assume the same role simultaneously, with logging to track individual actions

4. Designing Applications with Many Users

• For apps with >5000 users (e.g., mobile apps), IAM users are not practical
• Web Identity Federation: IAM roles grant temporary access to users authenticating via external identity providers (Google, Facebook, Twitter)
  • Users log in with existing social accounts
  • No AWS credentials are stored in the app
  • Scales to millions of users efficiently
• Example: Mobile app users access DynamoDB
  • Each user assumes an IAM role under the hood to access resources

5. Cross-Account Access

• Multi-account environments require frequent account switching
• AWS Console Simultaneous Sign-in enables multiple accounts/roles in the same browser without logging out

• IAM roles facilitate access across accounts within an AWS Organization
  • Accounts/role history is stored in the AWS Management Console
  • Avoids duplicating IAM users across multiple accounts
  • Simplifies permission management
  • Example: When a Principal assumes a role to upload an object to an S3 bucket, the object is owned by the bucket’s account, avoiding cross-account ownership issues

Service-Linked Roles and PassRole

Service-Linked Role

• Definition: An IAM role that is tied to a specific AWS service
  • Grants a predefined set of permissions that the service needs to operate on your behalf
• Creation, modification, and deletion: Controlled by the service itself
  1. The AWS service automatically creates and manages the role
  2. You configure the role via a setup wizard
  3. You manually configure the role through IAM, if required by the service
• Important:
  • You cannot delete a service-linked role while the service requires it
  • It can only be deleted once the service no longer depends on it
  • Key difference from normal IAM roles: lifecycle is service-managed
• Reference: AWS Docs – Service-Linked Roles

Example: IAM policy referencing iam:CreateServiceLinkedRole

PassRole

• Definition: Allows an IAM identity to assign an existing role (including service-linked roles) to an AWS resource, without granting the role’s permissions to that identity
• Key Concept – Role Separation:
  • Identity performing iam:PassRole does not need:
    • Permissions of the role being passed
    • Permissions to create, edit, or delete the role
• Example Scenario:

• Bob cannot create EC2 instances directly
• Bob is allowed to perform iam:PassRole in CloudFormation
• Bob executes a CloudFormation stack that creates EC2 instances using a pre-existing service-linked role
• Bob cannot:
  • Create EC2 instances manually
  • Modify or delete the service-linked role
  • Create new service-linked roles

AWS Organizations

AWS Organizations – Overview

• Multi-account management service
  • Consists of 1 management (master) account and 0 or more member accounts
  • Useful when managing multiple accounts: simplifies IAM user management and payment handling

Key Benefits

• SwitchRole feature → seamless switching between accounts without logging out/in
• Centralized permissions management → use Service Control Policies (SCPs) attached to Organizational Units (OUs)
• Consolidated billing → one monthly bill for all accounts
• Aggregated usage discounts → benefit from combined service usage
• Automated account creation → e.g., via API

Limitation

• Free Tier usage is aggregated across accounts → you do not get Free Tier benefits for each account individually

Creating an AWS Organization

1. Start from a standard AWS account
   • Standard account = not yet part of any AWS Organization
   • Log in, create an organization → this account becomes the management account
2. Add member accounts
   • Invite existing accounts → standard account must accept invitation
   • Create new accounts directly inside the organization

Switching Roles in AWS Organizations

• OrganizationAccountAccessRole → IAM role inside a member account granting admin access to the management account
  • Created by default for newly created member accounts
  • Must be manually created if adding a previously standard account
• Using Switch Role:
  • From the management account console, click “Switch Role” and follow the wizard
  • Assign an alias (e.g., PROD, DEV) to track which account/role is active
  • Role switching is seamless and stored in the browser for convenience

Best Practices for Identity Administration:

1. Centralize logins:
   • Single account for IAM users, or
   • Identity Federation with external IDPs (e.g., Microsoft Active Directory)
2. Access other accounts via roles using Switch Role

Hierarchical Structure of AWS Organizations

• Organizational Units (OUs) can contain accounts or other OUs
• Organization Root = top-level OU (not to be confused with root user of management account)
• Nested structure allows complex hierarchies
• SCPs attached to an OU control permissions for all accounts under it
• Management account may or may not belong to an OU

Cost Benefits of AWS Organizations

1. Consolidated Billing
   • Member accounts’ bills are combined → one monthly invoice for the organization
   • Payer account = management account
2. Volume Discounts
   • Aggregated usage can reduce costs
3. Consolidated Reservations
   • Reserved instances can be shared across member accounts

DEMO: Creating an AWS Organization

1. Log in to GENERAL account, create an organization → GENERAL becomes the management account
2. Add existing PROD account
   • Invite PROD to join, PROD accepts → becomes member account
3. Add new DEV account
   • Create inside GENERAL → DEV becomes member account
   • Note: Increase AWS Organization account quota if needed: Service Quotas
4. OrganizationAccountAccessRole
   • Create in PROD to grant admin access to GENERAL
   • DEV role created automatically (since DEV was created inside the organization)
5. Switch Roles Feature
   • From GENERAL account, main menu → Switch Roles → fill in account, role name, alias (e.g., PROD = red, DEV = yellow)

• Role history stored in browser → switch seamlessly between accounts

Service Control Policies (SCPs)

AWS Organizations – Service Control Policies (SCP)

• An SCP is a JSON policy that defines permission limits for member accounts within an organization
  • It does not grant permissions, but instead controls the maximum permissions that can be assigned
  • It acts as an account-level permission boundary
• Important characteristics:
  • The management account is not affected by SCPs
    • Best practice: avoid using the management account for routine operations in production environments
• SCPs can indirectly limit the root user of a member account
  • While the root user cannot be restricted within its own account, SCPs apply at the organization level and therefore affect all identities in the account, including the root user.

SCP Scope and Attachment

An SCP can be applied to:

1. Organization Root → impacts all member accounts in the organization (excluding the management account)
2. Organizational Units (OUs) → affects the OU and all nested accounts and OUs
   • SCPs are inherited downward through the hierarchy
3. Individual member accounts

Default Behavior

• By default, SCPs do not impose restrictions.
• When SCPs are enabled, a FullAWSAccess policy is attached across the organization
• If this policy is removed:
  • The implicit deny model applies, effectively blocking all actions unless explicitly allowed by SCPs.

SCP Design Approaches

1. Allow List (Block by Default)

• Remove the default FullAWSAccess policy
• Define SCPs that explicitly allow only specific services or actions
• Advantages:
  • Stronger security control
• Disadvantages:
  • Higher risk of misconfiguration
  • Increased administrative effort
  • Requires updates whenever new AWS services are needed

2. Deny List (Allow by Default)

• Keep the default FullAWSAccess policy
• Add SCPs that explicitly deny specific services or actions
• Advantages:
  • Easier to manage
  • Lower administrative overhead
  • New AWS services are automatically allowed
• Disadvantages:
  • Broader access by default, which may reduce security
• This approach is commonly recommended for most environments

Overlap Between Identity/Resource Policies and SCPs

• SCPs must align with IAM identity policies and/or resource policies for access to be granted.
  • Permissions are effectively determined by the intersection of all applicable policies.
  • Access is only allowed if it is permitted by both the SCP and the identity/resource policies.
• SCPs do not grant permissions on their own.
  • For example, even if an SCP allows access to S3, an identity still cannot access it unless:
    • An IAM policy also allows the action, and/or
    • The resource policy (e.g., S3 bucket policy) permits it.
  • If either side does not allow the action, access is denied.
• SCPs follow the same evaluation logic as IAM policies:
  • Implicit Deny < Explicit Allow < Explicit Deny.
  • When combined with identity and resource policies, this evaluation model still applies across all policies.

Amazon CloudWatch (CW) 101

Amazon CloudWatch – Architecture and Key Components

• Gathers and processes operational information → enables monitoring and operational visibility
  • Operational information includes performance data, metrics, logs, and more
  • Acts as a foundational service leveraged by most AWS services
  • Available as a public AWS service
• Primary components include:

1. CloudWatch Metrics = the core CloudWatch functionality
   • Example: tracking EC2 CPU usage over time or disk usage from on-prem systems
   • Accepts metrics from AWS services, applications, and external environments
   • Certain metrics are automatically collected by AWS services
   • A CloudWatch Agent is required when:
     • Capturing metrics not provided by default within AWS
       • e.g., application-level or OS-level metrics inside an EC2 instance
     • Collecting metrics from non-AWS environments
   • Due to the large volume of metrics, proper organization and separation is important
2. CloudWatch Logs
   • Ingests logs from AWS services, applications, and on-premises systems
   • Some logs are automatically generated by AWS services, while others require the CloudWatch Agent
3. CloudWatch Alarms
   • Initiates alerts or automated actions based on metric thresholds
   • Can send notifications via Amazon SNS
   • Example: trigger an alert when EC2 CPU usage exceeds 90%
   • Billing alerts can also be configured to notify via email when costs exceed a defined threshold
4. CloudWatch Events (now replaced by Amazon EventBridge)
   • Integrates with AWS services and scheduled workflows
   • Produces events that can initiate actions (e.g., sending notifications)
   • Events can be triggered by:
     1. State changes (e.g., EC2 instance launch or termination)
     2. Scheduled timing (e.g., specific time or recurring intervals)

Amazon CloudWatch – Core Concepts

Diagram 1:

• Datapoint = Value + Timestamp pair
  • Example: CPU utilization is 98.3% at 08:45:45 on 2019-12-03
• Metric = A time-ordered collection of datapoints
  • Represents values tracked over time (e.g., CPU usage, network I/O, disk activity)
  • Metrics are not always tied to a single resource
    • For example, CPU utilization may by default represent all EC2 instances combined
    • You must apply filters to view data for a specific instance

Diagram 2:

Namespace = Logical container for related metrics

• Helps organize monitoring data and avoid confusion
• Names must follow AWS naming rules
• Example:
  • AWS/ → general namespace for AWS metrics
  • AWS/EC2 → dedicated namespace for EC2-related metrics

Dimensions = Attributes used to filter and segment a metric

• Allow the same metric to be viewed from different perspectives
• Example: Within the AWS/EC2 namespace, metrics can be separated by Instance ID (Instance A, Instance B, etc.)
• Provides high flexibility and granularity

Diagram 3:

• Alarms take actions based on a specific metric reaching specified values/thresholds
  • e.g., Send a notification when the budget has been exceeded (billing alarm)
  • States:INSUFFICIENT DATA (initial state), OK or ALARM
    • alarm uses Amazon SNS (Simple Notification System) when the state is ALARM

CloudWatch Logs

CloudWatch Logs – Overview

• Used to collect, store, and analyze log data
  • A log entry = timestamp + message content (YYYY-MM-DD::HH:MM:SS message)
    • Example: 2025-02-03::13:40:35 "User signed in"
• Public, region-based service
  • Can be accessed from AWS environments, on-premises systems, or other cloud platforms
• Natively integrated with multiple AWS services (e.g., EC2, VPC Flow Logs, Lambda, CloudTrail)
  • Access control is typically handled through IAM roles or service-linked roles
  • Many AWS services automatically push standard logs to CloudWatch Logs
• CloudWatch Unified Agent
  • A software agent used to send custom logs to CloudWatch from various sources
  • Required for:
    • External (non-AWS) systems to forward logs to CloudWatch
    • Custom application or OS-level logs from EC2 instances
  • Alternative method: use the AWS SDK within application code to send logs directly
  • The Unified Agent is the enhanced and current version of the older CloudWatch Logs Agent

CloudWatch Logs – Architecture

Log sources: AWS services, mobile applications, databases, external APIs, and non-AWS compute systems

• These sources send log events (timestamp + message) into CloudWatch Logs

Log Stream = Ordered sequence of log events from a single source

• Each stream represents logs coming from one specific origin

Log Group = Collection of related log streams

• Aggregates logs from multiple sources of the same type (e.g., several EC2 instances)
• Holds configuration settings for its streams (such as retention policies and access permissions)
• Defines metric filters, which can be used to generate metrics and trigger alarms

Example scenario:

• A fleet of EC2 instances sends /var/log/messages (Linux system logs) to CloudWatch Logs
• A single log group contains all /var/log/messages across those instances
• Each log stream corresponds to one EC2 instance
• Each stream stores its instance’s log events in time order

AWS CloudTrail

AWS CloudTrail (CT) – Overview

• Records API activity and events within an AWS account
  • Examples include launching EC2 instances, deleting S3 buckets, or modifying security groups
  • These actions are captured as CloudTrail Events, representing operations performed by users or services
  • Commonly used for auditing API activity, troubleshooting issues, and security investigations

Types of CloudTrail Events

1. Management Events
   • Represent control plane actions (resource management operations)
     • Examples: creating an EC2 instance, deleting an S3 bucket, setting up a VPC
   • Enabled by default
     • The first copy is free, while additional copies incur charges
2. Data Events
   • Represent data plane operations (interactions within a resource)
     • Examples: uploading objects to S3 or invoking a Lambda function
   • Disabled by default due to the potentially high volume of activity
     • For instance, frequent access to an S3 bucket can generate many events
3. Insight Events(less relevant for SAA-C03)
   • Detect unusual patterns or anomalies in account activity

• By default, CloudTrail stores events in the Event History, which retains data for up to 90 days
  • To persist logs in services like S3 or CloudWatch, a trail must be configured
• Not a real-time service
  • Events are delivered with a delay of up to ~15 minutes, as they are processed in batches multiple times per hour

AWS CloudTrail – Trail

• Trail = The main configuration unit in CloudTrail
  • Determines where and how CloudTrail events are recorded

Types of Trails

1. Single-region trail
   • Records events only within the region where it is created
   • Reminder: CloudTrail is a regional service
2. All-region trail
   • Captures events across all AWS regions
   • Technically, a collection of per-region trails, managed as one logical trail
   • Automatically updated when AWS adds new regions
3. Organizational trail
   • Logs events from all accounts in an AWS Organization across all regions
   • Also, a collection of per-account, per-region trails, managed as one logical entity

Global Services

• Some services (e.g., IAM, STS, CloudFront) are global
  • Their events are always logged in us-east-1 (N. Virginia)
  • A CloudTrail trail must enable global service logging to capture these events
    • Typically enabled by default if created via the AWS console

Trail Outputs

• Apart from the default CloudTrail Event History, trails can store logs in:
  1. Amazon S3 – logs formatted in JSON; durable and convenient for storage
  2. CloudWatch Logs – enables metric filters and alarms; more functionality than S3
• Key retention points:
  • Event History: limited to 90 days
  • S3 and CloudWatch Logs: can be stored indefinitely

AWS CloudTrail – Pricing

• Basic CloudTrail service (enabled by default)
  • Stores 90 days of management event history in CloudTrail Event History
  • Free of charge
  • No need to create a trail for this basic functionality
  • To use advanced features (e.g., custom trails, logging to S3/CloudWatch), you must create one or more trails, which incurs additional costs

Additional Costs

1. Management events
   • First copy in all regions is included in the free basic service
   • Extra copies cost $2 per 100,000 events
2. Data events
   • Charged at $0.10 per 100,000 events
   • Typically, much higher in volume than management events
   • No free allowance – charged from the first event

AWS Control Tower 101

AWS Control Tower – Key Concepts

• Service that automates the setup and governance of multi-account AWS environments
  • Orchestrates core services like AWS Organizations, IAM Identity Center (formerly AWS SSO), CloudFormation, and AWS Config
  • Think of it as AWS Organizations with superpowers

Control Tower Dashboard

• Provides a single-page overview of the entire AWS environment
  • Centralized visibility for monitoring accounts, OUs, and compliance

Control Tower Landing Zone

• A well-architected multi-account environment
  • Created automatically when an account enables Control Tower (takes <1 hour)
  • That account becomes the management account
• Home region
  • The region where the Control Tower is initialized
  • Guaranteed to be available; other regions are not automatically covered
• Centralized Identity Management via IAM Identity Center
  • Provides Single Sign-On (SSO) for users
  • Supports internal identities, cross-account identities, and federated identities
• Centralized Logging & Auditing
  • Uses AWS Config, CloudTrail, and CloudWatch to track compliance and activity
• Default Architecture Built by Control Tower:
  1. Security OU
     • Log Archive Account: Aggregates all logs from the environment
     • Audit Account: For 3rd-party auditing and security operations
  2. Custom OU (Sandbox)
     • Flexible security rules for testing or experimentation
     • Typically, where additional accounts are provisioned via Account Factory

AWS Control Tower – Guardrails

• Predefined rules for multi-account governance
  • Detect or enforce compliance across all accounts
  • Helps prevent accounts from drifting away from best practices

• Types of Guardrails:
  1. Mandatory – must be applied in all accounts
  2. Strongly Recommended – suggested, but can be overridden in rare cases
  3. Elective – optional, applied based on organizational needs
• Modes of Operation:
  1. Preventive – blocks non-compliant actions
     • Implemented via AWS Organizations Service Control Policies (SCPs)
     • States: enforced or not enabled
     • Example: restrict deployments to certain regions, enforce bucket policies
  2. Detective – observes compliance without preventing actions
     • Implemented via AWS Config rules
     • States: clear, in violation, or not enabled
     • Can log violations/events to CloudTrail
     • Example: detect if CloudTrail is enabled in an account, or if EC2 instances have public IPv4 addresses
  3. Proactive – checks compliance before resources are provisioned
     • Validates resources via CloudFormation templates
     • Prevents creation of resources that would violate guardrails

AWS Control Tower – Account Factory

• Automates and standardizes account creation and provisioning
  • Supports both long-term and temporary accounts
  • Accounts can be provisioned by cloud admins or end-users (self-service)
    • End-users typically provision through AWS Service Catalog, using pre-approved stacks
• Automatic application of guardrails to new accounts
• Standardized templates/blueprints ensure consistent account and network setup:
  • Account creator receives admin permissions
  • Configured IP addressing avoids overlaps across accounts
  • Predefined business-specific configurations
• Lifecycle management: accounts can be provisioned, closed, or repurposed
  • Fully integratable with SDLC using APIs, SDKs, IaC, and CI/CD pipelines