### Slide 1: ![Slide 1](slide_1.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 2: ![Slide 2](slide_2.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 3: ![Slide 3](slide_3.png) ::: Notes This slide returns to the Example Corp. scenario to frame the module's purpose: the company needs to inventory and discover its AWS resources as part of a broader effort to standardize access management and account organization. Before covering the tools, ask students to think about what 'inventory' really means in a cloud environment — unlike a physical data center, resources can be created and destroyed at any time by many different people. #### Instructor notes #### Student notes As different departments provision more AWS resources, the chief information officer (CIO) of your company wants to standardize access management, organize existing AWS accounts, and inventory AWS resources. Your manager wants you to design permissions templates for groups and roles in your team's AWS accounts. In addition, your manager wants a plan to best organize the company's numerous AWS accounts. Your manager also wants an inventory of all your company's current resources. ::: ### Slide 4: ![Slide 4](slide_4.png) ::: Notes AWS exposes all of its functionality through a common REST-based API, and the Console, CLI, and SDKs are all built on top of it. Each access method suits different use cases: the console is good for exploration and one-off actions; the CLI enables scripting and automation; SDKs enable integration into application code. The key insight is that they're not separate systems — changes made in one are immediately reflected in the others. #### Instructor notes #### Student notes You can create and manage resources on the AWS Cloud in three ways. All three options are built on a common, REST-like API that serves as the foundation of AWS. * **AWS Management Console** : The console provides a *rich graphical interface* to most of the features that AWS offers. * **AWS CLI** : The *AWS Command Line Interface* (AWS CLI) provides a suite of utilities that can be launched from a command program in Linux, macOS, or Windows. * **SDKs** : AWS provides packages to *access AWS in a wide variety* of popular programming languages, so you can readily use AWS in your existing applications. You can create applications to deploy and monitor complex systems entirely through code. AWS CLI and the SDKs provide flexibility. With AWS CLI and the SDKs, you can create your own tools specific to your business and customize existing AWS features. For example, you might create your own scripts or applications for the following common tasks: * Launching Amazon Elastic Compute Cloud (Amazon EC2) instances that enforce using a specific set of Amazon Machine Images (AMIs) * Adding a standard set of tags You can use all modes of access interchangeably. For example, an Amazon EC2 server can be managed using AWS SDK calls, AWS CLI commands (such as `aws ec2 describe-instances`), or the AWS Management Console. It might take a few seconds or a few minutes for changes made through AWS CLI or the API to surface in the console. ::: ### Slide 5: ![Slide 5](slide_5.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 6: ![Slide 6](slide_6.png) ::: Notes The AWS CLI requires configuration before use, and that configuration matters for security. Running `aws configure` stores credentials locally — which is convenient but creates a risk if the machine is shared or compromised. Access key IDs and secret access keys stored in credential files are long-term credentials that should be rotated regularly and, where possible, replaced with role-based temporary credentials. #### Instructor notes #### Student notes Let's review some of the basics of the AWS CLI. The AWS CLI is available for use on Linux, Windows, and macOS platforms. You can install it on Linux and Windows EC2 instances. To set defaults for AWS CLI commands, you can run the aws configure command on servers hosting the AWS CLI. For example, these commands include the access key ID and the secret access key associated with the AWS Identity and Access Management (IAM) account that accesses AWS resources. You can also specify a default AWS Region for all commands. For more information, see "Install or Update the Latest Version of the AWS CLI" in the AWS Command Line Interface User Guide at https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html. ::: ### Slide 7: ![Slide 7](slide_7.png) ::: Notes The AWS CLI command structure follows a consistent pattern: service, subcommand, and parameters. Understanding this structure helps students predict how to construct commands for services they haven't used before. The `--query` option is worth emphasizing — AWS API responses are often verbose, and filtering output at the CLI level is more efficient than parsing everything in a script. Ask students what they would do if a command succeeds but the output is too large to interpret. #### Instructor notes #### Student notes The basic structure of an AWS command line call is the aws command, followed by these main elements: Command -- This is the top-level service that you are calling, for example, Amazon EC2 or Amazon CloudWatch. For a list of supported services, see AWS CLI Command Reference at http://docs.aws.amazon.com/cli/latest/reference. In the example, the command lines at the bottom call the Amazon EC2 service. Subcommand -- This is the operation to perform on that service, for example, run-instances or put-metric-data. In this Amazon EC2 example, the run-instances subcommand requests the creation of a new Amazon EC2 instance. Parameters -- These are any arguments required to perform the operation. Argument names are preceded by two dashes (--). For example, to perform the Amazon EC2 run instances operation, pass in parameters, such as the AMI ID, to create the instance. Options -- AWS CLI also provides options that you can specify when running the operation. For example, you can use the --query option to limit the response text, so it returns only the instance ID of your new instance. ::: ### Slide 8: ![Slide 8](slide_8.png) ::: Notes The `--dry-run` option validates permissions without making changes — a useful safety check before executing operations that could affect production resources. However, not all AWS CLI commands support `--dry-run`, so students should verify before relying on it. The error response pattern (`DryRunOperation` vs. `UnauthorizedOperation`) is a design worth noting: it confirms the permission check worked without producing a side effect. #### Instructor notes #### Student notes The `--dry-run` option checks whether you have the required permissions for the action, without actually making the request. The option also generates an error response. If you have the required permissions, the error response is `DryRunOperation`. Otherwise, it is `UnauthorizedOperation`. ::: ### Slide 9: ![Slide 9](slide_9.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 10: ![Slide 10](slide_10.png) ::: Notes Session Manager provides interactive instance access without requiring SSH or open inbound ports — a significant security improvement over traditional bastion-host architectures. The trade-off is a dependency on the SSM Agent being installed, configured, and connected. If the agent is unhealthy or the instance lacks network connectivity to Systems Manager endpoints, Session Manager won't work. Consider what your fallback access method is when Session Manager is unavailable. #### Instructor notes #### Student notes Session Manager, a capability of AWS Systems Manager, is a fully managed service that you can use to manage your EC2 instances, on-premises instances, and virtual machines (VMs). You can do this through an interactive, browser-based shell or through the AWS CLI. VPC endpoints -- You can further improve the security posture of your managed instances by configuring Systems Manager to use an interface virtual private cloud (VPC) endpoint. Interface endpoints are powered by AWS PrivateLink. With the PrivateLink technology, you can privately access Amazon EC2 and Systems Manager APIs by using private IP addresses. For more information, review "AWS Systems Manager Session Manager" in the AWS Systems Manager User Guide (https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). ::: ### Slide 11: ![Slide 11](slide_11.png) ::: Notes Session Manager's main security advantage is eliminating open inbound ports and SSH key management, but it introduces different requirements: IAM policies must be correctly configured, SSM Agent must be running, and session logging must be enabled to satisfy audit requirements. Centralizing access through IAM simplifies some management tasks but also means IAM misconfigurations become the single point of access failure. Ask students: what does your audit trail look like when someone uses Session Manager to connect? #### Instructor notes #### Student notes * **Centralized access control** : Administrators have a single place to grant and revoke access to instances. Using only IAM policies, you can control which individual users or groups in your organization can use Session Manager and which instances they can access. * **No bastion hosts** : Session Manager helps you to improve your security posture by letting you close these inbound ports. Doing this frees you from managing Secure Shell (SSH) keys and certificates, bastion hosts, and jump servers. For more information, see "Toward a Bastion-less World" in the Infrastructure & Automation Blog (https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/). * **Administrative permissions for ssm-user** : The AWS Systems Manager Agent (SSM Agent) creates a local user account called ssm-user. For Linux, it adds it to /etc/sudoers. For Windows, it adds to the Administrators group. This ssm-user is the default OS user when a Session Manager session is started. For more information, see "Step 7: (Optional) Turn On or Turn Off ssm-user Account Administrative Permissions" in the AWS Systems Manager User Guide (https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-ssm-user-permissions.html). * **Logging and auditing session activity** : To meet your company's operational or security requirements, you might need to provide a record of the connections made to your instances and the commands that were run on them. You can also receive notifications when a user starts or ends session activity. * **Amazon Simple Storage Service (Amazon S3)** : You can choose to store session log data in an Amazon S3 bucket for auditing purposes. * **Amazon EventBridge and Amazon Simple Notification Service (Amazon SNS)** : Use EventBridge to configure notifications from Amazon SNS when a user in your organization starts or stops a session. * **Amazon CloudWatch Logs** : Use CloudWatch Logs to monitor, store, and access log files from various AWS services. You can send session log data to a CloudWatch Logs log group for auditing purposes. For more information, see "AWS Systems Manager Session Manager" in the AWS Systems Manager User Guide (https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). ::: ### Slide 12: ![Slide 12](slide_12.png) ::: Notes Session Manager's additional capabilities — port forwarding, cross-platform support, and single-step access — address practical friction in day-to-day operations. Port forwarding is particularly useful for reaching databases and services in private subnets without a VPN, but it also means that an overly permissive Session Manager policy could be used to reach internal resources that should not be accessible from outside the VPC. Permissions on port forwarding actions deserve careful review. #### Instructor notes #### Student notes * **Single-step access to instances from the console and AWS CLI** : Using the Systems Manager console or Amazon EC2 console, you can start a session with a single step. Using the AWS CLI, you can also start a session that runs a single command or a sequence of commands. Because permissions to instances are provided through IAM policies instead of SSH keys or other mechanisms, the connection time is greatly reduced. * **Port forwarding** : Redirect any port inside your remote instance to a local port on a client. After that, connect to the local port and access the server application that is running inside the instance. Use cases include scenarios such as communicating with web servers and database servers hosted in private subnets. You can also manage a Windows-based instance with Remote Desktop Protocol (RDP) enabled by using Session Manager. Session Manager tunnels traffic from the instance without the requirement of a gateway server. * **Cross-platform support for both Windows and Linux** : Session Manager provides support for Windows, Linux, and macOS from a single tool. For example, you don't need to use an SSH client for Linux and macOS instances or an RDP connection for Windows Server instances. ::: ### Slide 13: ![Slide 13](slide_13.png) ::: Notes CloudShell provides a browser-based shell pre-authenticated with console credentials, which makes it convenient but also means it inherits the permissions of whoever is logged into the console. This is powerful for quick operations but also means CloudShell sessions should be treated with the same care as any other AWS access. Persistent home directory storage across sessions is useful, but students should consider what data they're storing there and who else might have access. #### Instructor notes #### Student notes AWS CloudShell is a browser-based shell that you can use to securely manage, explore, and interact with your AWS resources. CloudShell is preauthenticated with your console credentials. Every CloudShell session creates a new shell that comes with common development and operations tools that are preinstalled, so no local installation or configuration is required. With CloudShell, you can quickly run scripts with the AWS CLI, experiment with AWS service APIs using the AWS SDKs, or use a range of other tools to be productive. Store up to 1 GB of files within the home directory that can be shared across sessions initiated within the same Region. Shells are terminated when you close the session. ::: ### Slide 14: ![Slide 14](slide_14.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 15: ![Slide 15](slide_15.png) ::: Notes AWS Systems Manager provides a unified operational data view across resource groups, but its value depends on how consistently resources are tagged and grouped. Resource groups without a coherent tagging strategy produce noise rather than clarity. Before covering the features, ask students to think about what resource groupings would be meaningful for Example Corp. — and what tagging discipline would be required to make those groups accurate and useful. #### Instructor notes #### Student notes With AWS Systems Manager, you can centralize operational data from multiple AWS services and automate tasks across your AWS resources. You can create logical groups of resources such as applications, different layers of an application stack, production environments, and development environments. With Systems Manager, you can select a resource group and view the following details: Recent API activity, Resource configuration changes, Related notifications, Operational alerts, Software inventory, Patch compliance status. You can also take action on each resource group, depending on your operational needs. Systems Manager provides a central place to view and manage your AWS resources, so you can have complete visibility and control over your operations. * **Group resources** : Group your AWS resources and save them into resource groups. * **Visualize data** : View aggregated operational data by resource group. * **Take action** : Respond to insights and automate operational actions across resource groups. ::: ### Slide 16: ![Slide 16](slide_16.png) ::: Notes AWS Config provides a continuous inventory and configuration history for AWS resources, but it records what exists — not whether what exists is correct. The value of Config comes from defining rules that evaluate configurations against your policies and alerting when drift occurs. Without rules, Config is a data store; with rules, it becomes a compliance monitoring system. Ask students: what configurations in your environment would you most want to be alerted about if they changed? #### Instructor notes #### Student notes AWS Config is a fully managed service that provides you with the following to facilitate security and governance: AWS resource inventory, Configuration history, Configuration change notifications. With AWS Config, you can perform the following activities: * **Discover resources** : Discover resources that exist in your account for a complete AWS resource inventory. * **Record configurations** : Record current resource configurations. * **Capture changes** : Capture any changes to the configurations and save for historical data. * **Analyze changes and remediate** : Determine whether changes require action based on AWS Config rules and settings. Rules and settings can include remediation and notifications. These capabilities support compliance auditing, security analysis, resource change tracking, and troubleshooting. ::: ### Slide 17: ![Slide 17](slide_17.png) ::: Notes AWS Config's configuration history answers a critical operational question: what changed, and when? This is invaluable for troubleshooting — but only if Config was enabled before the incident. Multi-account, multi-Region aggregation addresses a real challenge in complex organizations, but it requires careful design of the aggregator account and access controls. Consider: who should have access to the centralized Config data, and what could an attacker learn from it? #### Instructor notes #### Student notes **Change management** : Use AWS Config to track the relationships between resources and review resource dependencies before making changes. After you make a change, you can quickly review the history of the resource's configuration and determine what the resource's configuration settings were any point in the past. AWS Config provides you with information to assess how a change to a resource configuration would affect your other resources. With this knowledge, you can minimize the impact of change-related incidents. **Enterprise-wide compliance monitoring** : AWS Config provides multi-account, multi-Region data aggregation. You can view compliance status across your enterprise and identify noncompliant accounts. You can examine more closely the status for a specific AWS Region or a specific account across Regions. You can view this data from the AWS Config console in a central account. This removes the need to retrieve this information individually from each account. ::: ### Slide 18: ![Slide 18](slide_18.png) ::: Notes AWS Config rules continuously evaluate resource configurations against defined policies, but they have a detection lag — a non-compliant resource may exist for some time before a rule catches it. Managed rules cover common compliance checks with minimal configuration; custom rules allow you to encode organization-specific policies, but they require Lambda functions that must be maintained. Consider: what are the consequences if a non-compliant resource exists for several minutes before a rule flags it? #### Instructor notes #### Student notes Using AWS Config rules, you can run continuous assessment checks on your resources to verify that they comply with your own security policies, industry best practices, and compliance standards. AWS provides several managed, prebuilt rules that require minimal to no configuration. For example, AWS Config provides a rule to ensure that encryption is turned on for all Amazon Elastic Block Store (Amazon EBS) volumes in your account. **Prebuilt, managed rules** : Managed rule examples: * Is multi-factor authentication (MFA) enabled for IAM console access? * Are access keys rotated? * Are all attached Amazon EBS volumes encrypted? * Do all Amazon EC2 instances belong to a VPC? * Are all resources tagged as expected? * Do all security groups in use deny unregulated, incoming SSH traffic? * Is AWS CloudTrail enabled in your AWS account? * Does the password policy for IAM users meet specified requirements? **Custom rules** : You can also write a custom AWS Config rule to code your own corporate security policies. Custom rules are associated with an AWS Lambda function that you create and maintain. When you invoke a custom rule, it runs the associated Lambda function. AWS Config alerts you in real time when a resource is misconfigured or when a resource violates a particular security policy. For more information, see "AWS Config Managed Rules" in the AWS Config Developer Guide (http://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html). ::: ### Slide 19: ![Slide 19](slide_19.png) ::: Notes Setting up AWS Config requires upfront decisions about scope: which resource types to record, where to store configuration data, and which rules to apply. These decisions have cost implications — Config charges per configuration item recorded and per rule evaluation. Recording all resource types in all regions is the most comprehensive approach but also the most expensive. Ask students to think about which resources are most critical for compliance in their environment and whether targeted recording might be more appropriate. #### Instructor notes #### Student notes **Setting up AWS Config from the console** : Enabling AWS Config requires you to specify the following settings in the console: * Resource types that you want the service to record * Whether to create or use an existing Amazon S3 bucket to receive configuration information * Whether to enable Amazon SNS to notify you of configuration changes * Whether to create an IAM role or use an existing one Determine which AWS Config rules you want to select for your setup. During the setup process, you can select only AWS Config managed rules. After setup, you can create your own custom AWS Config rules. After setup, AWS Config begins to discover your resources and records any changes to your account. View your AWS resource inventory or configuration details in the AWS Config dashboard. For more information, see the following in the AWS Config Developer Guide: "Setting Up AWS Config with the Console" (https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html) ::: ### Slide 20: ![Slide 20](slide_20.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 21: ![Slide 21](slide_21.png) ::: Notes Config and Systems Manager Inventory address different aspects of the discovery problem: Config tracks AWS resource configurations; SSM Inventory collects OS-level information from inside instances. Neither alone gives you a complete picture — Config doesn't see inside instances, and Inventory doesn't see AWS-level resource relationships. Together they cover more of the stack, but they also require more setup and governance to maintain. #### Instructor notes #### Student notes For visibility into your AWS resources, you have two options: AWS Config or Inventory, a capability of AWS Systems Manager. Or you can use both. As mentioned, AWS Config is a fully managed service that provides you with an AWS resource inventory and configuration history. By contrast, AWS Systems Manager Inventory collects information about your instances and the software installed on them. This information helps you to understand your system configurations and installed applications. You can collect data about the following system properties: Applications, Files, Network configurations, Windows services, Registries, Server roles, Updates. With the gathered data, you can manage application assets, track licenses, monitor file integrity, discover applications not installed by a traditional installer, and more. ::: ### Slide 22: ![Slide 22](slide_22.png) ::: Notes The integration between AWS Config and Systems Manager Inventory creates a more complete configuration record by combining AWS-level resource data with OS-level instance data. This integration is powerful, but it requires the SSM Agent to be running on all managed instances — any instances without the agent will have gaps in the combined record. Consider what your coverage looks like in practice and whether unmanaged instances represent a blind spot. #### Instructor notes #### Student notes AWS Config is designed to integrate with AWS Systems Manager and its capabilities. This integration makes it possible for AWS Config to record software configuration changes within your EC2 instances and servers running on premises. You can combine the ability of Systems Manager to inventory operating system (OS) configurations, system-level updates, and installed applications with the ability of AWS Config to record historical data. ::: ### Slide 23: ![Slide 23](slide_23.png) ::: Notes Multi-account Config aggregation centralizes inventory and compliance data across accounts, but it also creates a high-value target: the aggregator account holds configuration data for your entire organization. Access to this account should be tightly controlled. Also consider the latency — aggregated data reflects the state at the time of the last sync, not necessarily the current state, which matters for time-sensitive compliance decisions. #### Instructor notes #### Student notes If you need to inventory resources from multiple AWS accounts, use AWS Config to aggregate your inventory to a centralized location. ::: ### Slide 24: ![Slide 24](slide_24.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 25: ![Slide 25](slide_25.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 26: ![Slide 26](slide_26.png) ::: Notes This scenario illustrates a common IAM problem: a user has created a role with the right permissions but cannot assign it because they lack the PassRole permission. This is a deliberate security control — without it, users could escalate their own privileges by attaching more permissive roles to resources they control. Understanding why this restriction exists matters as much as knowing how to fix it. #### Instructor notes (x min for this module) #### Student notes You have been asked to set up your EC2 instances to work with Systems Manager. To do this, you must assign a role so that your instances can interact with Systems Manager. You created a new role with the appropriate permissions in your account named SSMmanagedInstanceRole. However, when you try to assign it to the instances, you are denied access. You discover that you have the permissions statement presented on the slide in your own role. ::: ### Slide 27: ![Slide 27](slide_27.png) ::: Notes #### Instructor notes (x min for this module) #### Student notes ::: ### Slide 28: ![Slide 28](slide_28.png) ::: Notes #### Instructor notes (x min for this module) #### Student notes ::: ### Slide 29: ![Slide 29](slide_29.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 30: ![Slide 30](slide_30.png) ::: Notes This lab gives students hands-on experience with the tools covered in the module, but lab environments are controlled — the messy reality of discovering and inventorying resources in a production account with years of accumulated drift is different. Encourage students to think about which of these procedures they could automate, and what challenges they might encounter applying them to an account where they didn't create all the resources. #### Instructor notes #### Student notes This lab will take you through the following procedures: * Setting up AWS Systems Manager * Using Session Manager to connect to an EC2 instance * Setting up AWS Config * Using AWS Config to audit IAM user permissions * Exploring inventory collected by Systems Manager ::: ### Slide 31: ![Slide 31](slide_31.png) ::: Notes #### Instructor notes #### Student notes :::