AWS Services with Root Privileges

⚠️ Important Update (2024): AWS OpsWorks Stacks reached End of Life (EOL) on May 26, 2024 and has been disabled for both new and existing customers. The recommended migration path is AWS Systems Manager. OpsWorks is retained below for historical/exam reference only.

AWS Services with Root/OS-Level Access

  • AWS provides root or system (OS-level) privileges only for services where the customer manages the underlying EC2 instances. These include:
    • Amazon EC2 (Elastic Compute Cloud)
    • Amazon EMR (Elastic MapReduce) – EMR on EC2 clusters provide SSH access to cluster nodes
    • AWS Elastic Beanstalk – provides SSH/RDP access to underlying EC2 instances
    • AWS OpsWorksEOL May 26, 2024 (see note above)
  • Additional services that provide OS-level access to underlying EC2 instances:
    • Amazon ECS (EC2 launch type) – full access to container instances; note: Fargate and ECS Managed Instances do NOT provide OS access
    • Amazon EKS (self-managed or managed node groups) – SSH access to worker nodes; note: EKS Auto Mode managed instances do NOT provide administrative access
    • AWS Batch (EC2 launch type) – access to compute environment instances
  • AWS does not provide root/OS privileges for fully managed services like RDS, DynamoDB, S3, Glacier, ElastiCache, Redshift, etc.
  • For RDS, if you need OS-level admin privileges or want to use features not supported by RDS, you should run a self-managed database on EC2 instead
  • This distinction aligns with the AWS Shared Responsibility Model: for services where AWS manages the infrastructure, the customer does not get OS access

Serverless and Managed Alternatives (No Root Access)

  • EMR Serverless – no underlying instances to manage; AWS handles infrastructure
  • ECS on Fargate – serverless containers; no access to host OS
  • EKS on Fargate / EKS Auto Mode – no SSH or administrative access to nodes
  • AWS Lambda – fully serverless; no OS access
  • Amazon RDS / Aurora – managed databases; no OS access

AWS OpsWorks – End of Life

  • AWS OpsWorks Stacks reached End of Life on May 26, 2024
  • The OpsWorks console, API, CLI, and CloudFormation resources have been discontinued in all AWS Regions
  • Migration alternatives:
    • AWS Systems Manager – recommended replacement for configuration management and automation
    • AWS CloudFormation – infrastructure as code
    • Direct EC2 management – instances detached from OpsWorks remain in the AWS account
    • Puppet Enterprise / Chef – third-party configuration management tools

Sample Exam Questions

  1. Which services allow the customer to retain full administrative privileges of the underlying EC2 instances? Choose 2 answers
    1. Amazon Elastic MapReduce
    2. Elastic Load Balancing
    3. AWS Elastic Beanstalk
    4. Amazon ElastiCache
    5. Amazon Relational Database Service
  2. Which of the following services provide root/OS-level access to the underlying instances? (Choose 3)
    1. Elastic Beanstalk
    2. EC2
    3. Amazon EMR
    4. DynamoDB
    5. RDS
    6. S3
  3. A client application requires operating system privileges on a relational database server. What is an appropriate configuration for highly available database architecture?
    1. A standalone Amazon EC2 instance
    2. Amazon RDS in a Multi-AZ configuration
    3. Amazon EC2 instances in a replication configuration utilizing a single Availability Zone
    4. Amazon EC2 instances in a replication configuration utilizing two different Availability Zones
  4. A company needs to run containers with full administrative access to the underlying host operating system. Which AWS service and launch type should they use?
    1. Amazon ECS with Fargate launch type
    2. Amazon ECS with EC2 launch type
    3. AWS Lambda with container image support
    4. Amazon EKS with EKS Auto Mode
  5. Which of the following is the recommended migration path for workloads previously managed by AWS OpsWorks Stacks?
    1. AWS CloudTrail
    2. AWS Systems Manager
    3. Amazon Inspector
    4. AWS Config