11. Management and Governance

These services provide the control plane for automation, compliance, and monitoring of AWS resources at scale.

AWS Auto Scaling

Service Introduction: A unified interface to configure automatic scaling for all resources in your application, including EC2, ECS, and DynamoDB.

Common Usage: Maintaining steady performance by coordinating scaling across multiple service tiers. EC2 Auto Scaling — Scaling Policy Types (exam-critical):

• Target Tracking — Set a target metric value (e.g., 50% average CPU) and Auto Scaling adjusts capacity to hold it there; the go-to answer for "optimize cost without impacting performance" on variable/unpredictable demand.
• Step Scaling — Scale by different step amounts based on the size of the alarm breach.
• Scheduled Scaling — Scale at known, predictable times (e.g., business hours); best when the load pattern is fully predictable, not variable. Default Termination Policy (exam-critical): On scale-in, Auto Scaling first identifies the AZ with the most instances (to fix any AZ imbalance), then within that AZ picks the instance using: oldest launch template/configuration → then instance closest to the next billing hour → then a random instance as a tie-breaker.

Project Examples:

• Scaling a multi-tier web application's web, app, and DB layers in unison.
• Managing the dynamic capacity of a fleet of ECS tasks based on memory usage.

AWS CLI

Service Introduction: A unified tool to manage your AWS services from the command line and automate them through scripts.

Common Usage: Interacting with AWS APIs for rapid resource management and DevOps automation.

Project Examples:

• Scripting the nightly snapshot of 100 EBS volumes across different regions.
• Automating the upload of static assets to an S3 bucket during a CI/CD build.

AWS CloudFormation

Service Introduction: An Infrastructure-as-Code (IaC) service that models and provisions AWS resources using JSON or YAML templates.

Common Usage: Ensuring consistent, repeatable deployments of entire application stacks across different accounts and regions. CloudFormation StackSets (exam-critical): Extends CloudFormation to deploy the same stack across multiple accounts and Regions from a single operation — the standard answer whenever a question asks to roll out identical infrastructure (e.g., a baseline security configuration, a standard VPC) org-wide with the least operational effort. Integrates directly with AWS Organizations to auto-deploy to every account in an OU, including new accounts as they're created.

Project Examples:

• Deploying a standard VPC architecture with subnets and routing in five minutes.
• Updating a production stack's security group rules via a version-controlled template.
• Using a StackSet to deploy a mandatory CloudTrail + Config baseline to every account in an Organization automatically.

AWS CloudTrail

Service Introduction: A service that records AWS API calls and delivers log files for auditing, security monitoring, and operational troubleshooting.

Common Usage: "Who did what and when?" Tracks all management actions (Create, Delete, Modify) within an AWS account.

Project Examples:

• Auditing which user deleted a critical S3 bucket.
• Monitoring for unauthorized API calls to the IAM service.

Amazon CloudWatch

Service Introduction: A monitoring and observability service that collects metrics, logs, and events for AWS resources and applications.

Common Usage: Setting alarms, visualizing metrics, and automating responses to performance changes (e.g., triggering Auto Scaling).

Project Examples:

• Setting an alarm to notify IT when CPU utilization on a web server exceeds 90%.
• Aggregating application logs from 50 Lambda functions to find common errors.

AWS Compute Optimizer

Service Introduction: A service that uses machine learning to recommend optimal AWS resources for your workloads to reduce costs and improve performance.

Common Usage: Analyzing historical utilization data to find "right-sizing" opportunities for EC2, EBS, and Lambda.

Project Examples:

• Identifying over-provisioned EC2 instances and recommending smaller instance types.
• Optimizing Lambda function memory settings based on actual execution patterns.

AWS Config

Service Introduction: A service that enables you to assess, audit, and evaluate the configurations of your AWS resources against desired policies.

Common Usage: Compliance and governance; tracks the history of configuration changes and alerts on policy violations (e.g., "S3 bucket is public"). Conformance Packs (exam-critical): A packaged, deployable collection of Config rules + remediation actions that can be deployed as a single unit across every account in an AWS Organization — the standard answer for "standardize governance evaluations and remediations across all member accounts with the least operational effort."

Project Examples:

• Enforcing a rule that all EBS volumes must be encrypted at rest.
• Generating a 90-day history of changes to a production security group.

AWS Control Tower

Service Introduction: A service to set up and govern a secure, multi-account AWS environment based on AWS best practices.

Common Usage: Implementing a "Landing Zone" with automated account provisioning and mandatory security guardrails.

Project Examples:

• Automatically applying data residency guardrails to all new accounts in an organization.
• Centrally managing logging and monitoring across 50 different departmental accounts.

AWS Health Dashboard

Service Introduction: Provides personalized information about the status of AWS services and the health of your specific AWS resources.

Common Usage: Tracking service interruptions or upcoming maintenance windows that specifically affect your environment.

Project Examples:

• Monitoring for scheduled hardware maintenance on a specific EC2 instance.
• Receiving alerts for regional outages affecting the S3 service in us-east-1.

AWS License Manager

Service Introduction: Simplifies the management of software licenses from vendors such as Microsoft, SAP, Oracle, and IBM across AWS and on-premises.

Common Usage: Enforcing licensing rules to prevent non-compliance and avoid costly audits.

Project Examples:

• Tracking the usage of SQL Server core licenses across a fleet of EC2 instances.
• Restricting the launch of instances that would exceed the number of purchased software seats.

Amazon Managed Grafana

Service Introduction: A fully managed service for open-source Grafana that allows you to visualize and analyze your metrics and logs from multiple sources.

Common Usage: Creating rich, interactive operational dashboards for monitoring complex, multi-source environments.

Project Examples:

• Visualizing Prometheus metrics alongside CloudWatch metrics in a single pane.
• Creating an executive dashboard for application uptime and performance.

Amazon Managed Service for Prometheus

Service Introduction: A serverless, Prometheus-compatible monitoring service for container metrics at scale.

Common Usage: Monitoring EKS and ECS workloads using the industry-standard Prometheus query language (PromQL).

Project Examples:

• Collecting and querying container performance metrics from a 1,000-node EKS cluster.
• Setting up alerting for high latency in a Kubernetes-based microservice.

AWS Management Console

Service Introduction: A web-based user interface for managing AWS resources, exploring new services, and viewing billing.

Common Usage: Manual administration, rapid prototyping, and visual monitoring of cloud resources.

Project Examples:

• Manually launching an EC2 instance for a quick development test.
• Reviewing monthly billing trends and service usage visually.

AWS Organizations

Service Introduction: Central governance and management for multiple AWS accounts, including consolidated billing and service control policies (SCPs).

Common Usage: Managing a multi-account environment; SCPs allow for strict "guardrails" to prevent accounts from performing certain actions.

SCPs vs. IAM Policies (exam-critical — the single most-tested Organizations concept): SCPs are guardrails, not grants. An SCP defines the maximum available permissions for an account/OU — it can only restrict, never actually grant access, because it doesn't attach to a specific user or role. Even if an IAM policy grants a user s3:*, an SCP that denies s3:DeleteBucket at the OU level overrides it — the effective permission is always the intersection of what the SCP allows and what the IAM policy allows. Critically, SCPs do not apply to the AWS Organizations management (root) account — only to member accounts — which is a frequently-tested gotcha.

• IAM Policy — Attached to a user/group/role; can Allow or Deny specific API actions; this is the actual grant of permission.
• SCP — Attached to an account/OU in AWS Organizations; can Allow (if using an allow-list strategy) or Deny, but never independently grants access to anything — it just fences in what IAM policies inside that account are even allowed to grant.
• The tell: "no user in this account should ever be able to do X, even the root user of that member account" → SCP. "This specific user/role needs permission to do Y" → IAM policy.

Consolidated Billing and volume discounts (exam-critical): Consolidated Billing aggregates usage across all member accounts in an Organization onto the single management/payer account's bill. Because AWS volume-pricing tiers (e.g., S3, EC2) are based on cumulative usage, pooling usage this way lets the whole organization reach higher discount tiers faster than any single account could alone. This is a billing/finance feature only — it's distinct from SCPs (permission guardrails), RAM (cross-account resource sharing), and Cost Explorer (spend visualization/forecasting, not aggregation for discounts).

Project Examples:

• Consolidating billing for 100 department-level accounts into one payer account.
• Preventing any user in a "Test" account from launching high-cost instance types.
• Using an SCP to prevent every account in the "Sandbox" OU from disabling CloudTrail, regardless of what IAM permissions an individual user has.

AWS Service Catalog

Service Introduction: Allows organizations to create and manage catalogs of IT services that are approved for use on AWS.

Common Usage: Providing self-service provisioning for developers while maintaining corporate compliance and version control.

Project Examples:

• Creating a "Standardized Web Stack" that developers can launch with one click.
• Enforcing the use of specific, pre-hardened OS images across the company.

AWS Service Quotas

Service Introduction: A service that lets you view and manage your quotas (limits) for AWS services from a central location, and request quota increases. (Not listed on AWS's official SAA-C03 scope page, but frequently the correct answer in practice exams — e.g., resolving an "EC2 QUOTA EXCEEDED" error when an Auto Scaling group can't launch instances.)

Common Usage: Diagnosing "I hit a limit" errors and requesting an increase without opening a support ticket for most services.

Project Examples:

• Requesting a quota increase for the number of running On-Demand EC2 instances after Auto Scaling fails to launch new instances.
• Setting a CloudWatch alarm to warn before a resource count approaches its account quota.

AWS Systems Manager

Service Introduction: A central operational hub for managing AWS resources; includes Parameter Store, Patch Manager, and Session Manager.

Common Usage: Automating operational tasks like OS patching and managing application configuration without SSH/RDP. Parameter Store — SecureString type (exam-critical): Stores secrets (API keys, config values) encrypted via KMS, with fine-grained IAM-controlled, audited access. It's the low-cost, "good enough" answer for a single secret needing secure storage + audited access — reach for Secrets Manager instead only when automatic rotation is explicitly required.

Project Examples:

• Automating the monthly security patching for 500 EC2 instances across multiple regions.
• Storing and retrieving encrypted database credentials using Parameter Store.

AWS Trusted Advisor

Service Introduction: An online tool that provides real-time guidance to help you provision resources following AWS best practices across five pillars.

Common Usage: Identifying cost-saving opportunities, security gaps, and performance improvements in an existing account.

Project Examples:

• Identifying idle Elastic Load Balancers that are incurring unnecessary costs.
• Detecting S3 buckets with "Public Read" access that should be secured.

AWS Well-Architected Tool

Service Introduction: A tool that helps you review the state of your workloads and compares them to the latest AWS architectural best practices.

Common Usage: Guiding architectural reviews to ensure systems are secure, resilient, and optimized.

Project Examples:

• Conducting a "Security Pillar" review for a new production workload.
• Generating a report on architectural "High Risks" (HRIs) before a major product launch.