AWS Certified Solutions Architect – Professional Exam Guide (SAP-C02) E-Book

Patrick Sard

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 675

Veröffentlichungsjahr: 2024

Beschreibung

Known for its difficulty and ranking among the highest-paying IT certifications, the AWS Certified Solutions Architect Professional (SAP-C02) certification demands significant hands-on experience for success. This comprehensive guide reinforces your knowledge and enhances your skills in various solution architectures and services. Additionally, you’ll gain lifetime access to supplementary practice resources such as mock exams, flashcards, and exam tips from experts.
Aligned with exam objectives, this AWS certification study guide helps you assess your knowledge through timed mock tests that simulate exam conditions. Beyond exam preparation, you’ll develop advanced skills in designing distributed systems on AWS cloud and become proficient in providing architectural recommendations for complex application implementation, and enhancing infrastructure efficiency. As you advance, you’ll gain insights into how to foster unique thinking and factor diverse considerations while architecting solutions. You’ll also get to grips with designing multi-tier applications, deploying enterprise-grade operations, and migrating complex applications to AWS.
By the end of this book, you’ll be able to design and deploy innovative solutions on AWS, unlocking new opportunities and driving success in the dynamic world of cloud computing.

Leseprobe

AWS Certified Solutions Architect – Professional Exam Guide (SAP-C02)

Gain the practical skills, knowledge, and confidence to ace the AWS (SAP-C02) exam on your first attempt

Patrick Sard

Yohan Wadia

AWS Certified Solutions Architect – Professional Exam Guide (SAP-C02)

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Authors: Patrick Sard and Yohan Wadia

Reviewers: Vineethkumar Marpadge, Vishal Munguskar, and Subhajit Bhattacharya

Publishing Product Manager: Sneha Shinde

Editorial Director: Alex Mazonowicz

Development Editor: Shubhra Mayuri

Presentation Designer: Salma Patel

Editorial Board: Vijin Boricha, Megan Carlisle, Wilson D'souza, Ketan Giri, Saurabh Kadave, Alex Mazonowicz, Gandhali Raut, and Ankita Thakur

First Published: February 2024

Production Reference: 3171024

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB

ISBN: 978-1-80181-313-6

www.packtpub.com

Contributors

About the Authors

Patrick Sard, as an AWS Solutions Architect, specializes in capturing and conveying best practices, offering prescriptive guidance on application and systems design across Amazon platforms and technologies. His role involves direct interaction with customers and partners, creating technical content, conducting events, evangelism, training, and providing operational event support. Additionally, Patrick contributes to the evolution of Amazon platforms and technologies by providing direct input and feedback from the field to the engineering teams developing these offerings.

With more than 20 years experience in IT, in his current and past roles, Patrick has been responsible for establishing and maintaining strategic vision, driving and influencing innovation, and delivering integrated and persuasive architectural thought leadership. With end-to-end project lifecycle experience, encompassing sales, inception, design, implementation, and post-sales support, he combines acute capabilities and insights into technology and business. This enables him to analyze and address client needs from various perspectives. In close collaboration with technical leaders, he drives the creation and execution of strategies promoting growth and innovation.

Yohan Wadia is a seasoned Cloud Solutions Architect with expertise in designing, implementing, and optimizing cloud-based solutions to meet the diverse needs of modern businesses. With 14 years of hands-on experience in Cloud Computing, AWS, and other cloud technologies, he has demonstrated a strong proficiency in architecting robust, scalable, and cost-effective solutions tailored to his clients' specific requirements. Yohan is based out of Brussels, Belgium together with his wife, Anahita.

About the Reviewers

Vineethkumar Marpadage has more than 5 years of exceptional work experience in various cloud technologies. He is an active Subject Matter Expert in AWS CodeSuite and Elastic Beanstalk Services who holds an AWS Solutions Architect Professional Certification alongside 5 other AWS Certifications, including Security Specialty. With vast knowledge on AWS Technologies, he designed complex architectures and managed multiple projects on AWS that spans across Applications, DevOps, and infrastructure monitoring. His unwavering commitment to staying abreast of emerging technologies and opportunities underscores his dedication to continuous growth and innovation.

Vishal Munguskar is an AWS DevOps engineer with a passion for cloud-based solutions. He has spent the last three years honing his skills in design, implementation, and management. Vishal proudly holds two AWS certifications: AWS Certified Solutions Architect - Associate and AWS Certified DevOps Engineer – Professional. He has a rich background with experience in AWS DevOps tools and practices, including CI/CD, automation, monitoring, and security. Currently, he is engrossed in the DSA project (Healthpharma sector) and is responsible for maintaining the security and data integrity of the organization’s AWS cloud infrastructure. Vishal strives to ensure a smooth and reliable data flow and to work towards optimizing his organization’s AWS cloud resources for scalability. Collaborating with other engineers and stakeholders to deliver high-quality products and services is part of his daily routine.

Subhajit Bhattacharya is an AWS Solutions Architect with over 10 years of experience in creating secure, scalable, and resilient cloud solutions. He has a proven track record across IoT, insurance, financial, and banking sectors, with expertise in modernizing and migrating applications to the cloud. Skilled in a wide range of AWS services, Subhajit holds multiple certifications, including AWS Solutions Architect Professional, and is recognized for his innovative approaches and leadership in cloud architecture.

Table of Contents

Preface

1

Determining an Authentication and Access Control Strategy for Complex Organizations

Making the Most Out of this Book – Your Certification and Beyond

Diving into Identity and Access Management

IAM users

IAM User Groups

IAM Roles

IAM Policies

Examining Access Control

Role-Based Access Control (RBAC)

Attribute-Based Access Control (ABAC)

Leveraging Access Delegation

Temporary Access Delegation

Accessing Resources from One Account to Another

Considering User Federation

Reviewing AWS Directory Service

Simple AD

AD Connector

Managed Microsoft AD

Summary

Further Reading

2

Designing Networks for Complex Organizations

Establishing VPN Connections

AWS Managed VPN

AWS VPN CloudHub

Software VPN

Introducing AWS DX

Various Flavors of AWS DX

AWS DX Connectivity Overview

Additional Considerations for Resiliency

Cost Factor

Introducing AWS Storage Gateway

File Gateway

Volume Gateway

Tape Gateway

Additional Considerations

Leveraging VPC Endpoints

Interface Endpoints

GWLB Endpoints

Gateway Endpoints

Additional Considerations

Introducing AWS Transit Gateway

AWS Transit Gateway Overview

Routing with AWS Transit Gateway

Summary

Further Reading

3

Designing a Multi-Account AWS Environment for Complex Organizations

Deciding on Resource and Billing Isolation

Elements of Structure

Striking the Right Balance for Resource Isolation

One Bill or Multiple Bills

Establishing a Billing Strategy for Multiple Accounts

Introducing AWS Organizations

Managing Policies Across Accounts and Filtering out Unwanted Access

Authorization Policies

Management Policies

AI Services Opt-Out Policies

Backup Policies

Automating the Creation of New Accounts through APIs

Organizing Accounts into OUs

Setting up SCPs

Using SCPs as Deny Lists

Using SCPs as Allow Lists

Account Management at Scale with AWS Organizations

Leveraging Control Tower

What does Control Tower Deliver Exactly?

How does Control Tower Operate?

Summary

Further Reading

4

Ensuring Cost Optimization

Cost Optimization Principles

Establishing Governance with Tagging

Activating Cost Allocation Tags

Creating Cost Allocation Tags

Tagging Strategies and Considerations

Monitoring with Alerts, Notifications, and Reports

Enabling Billing Alerts

Creating a Billing Alarm

Setting Up Notifications

Viewing Reports

Summary

Further Reading

5

Determining Security Requirements and Controls

Managing Identity and Access

IAM Users and Roles

AWS Service Roles

Using Federation for Access Control and Authentication

Protecting your Infrastructure

Protecting the Network

Protecting the Compute

Protecting your Data

Data Classification

Protecting Data at Rest

AWS KMS and AWS CloudHSM

Protecting Data in Transit

Detecting Incidents

Picking the Right Tool for the Right Task

Centralizing and Analyzing Logs

Responding to Incidents

Summary

Further Reading

6

Meeting Reliability Requirements

Reliability Design Principles

Principle 1 – Automatically Recover from Failure

Principle 2 – Test Recovery Procedures

Principle 3 – Scale Horizontally to Increase Aggregate Workload Availability

Principle 4 – Stop Guessing Capacity

Principle 5 – Manage Change in Automation

Foundational Requirements

Resource Constraints

Network Topology

Designing for Failure

Designing Your Workload Service Architecture

Designing Interactions in a Distributed System to Prevent Failures

Designing Interactions in a Distributed System to Mitigate or Withstand Failures

Change Management

Monitoring Workload Resources

Monitoring End-to-End Tracing of Requests through Your System

Designing Your Workload to Adapt to Changes in Demand

Implementing Change

Failure Management

Backing Up Data

Using Fault Isolation to Protect Your Data

Summary

Further Reading

7

Ensuring Business Continuity

Disaster Recovery versus High Availability

Establishing a Business Continuity Plan

DR Options on AWS

Backup and Restore

Pilot Light

Warm Standby

Active-Active

Detecting a Disaster and Testing DR

Summary

Further Reading

8

Meeting Performance Objectives

Performance Design Principles

Principle #1 – Democratize Advanced Technologies

Principle #2 – Go Global in Minutes

Principle #3 – Use Serverless Architectures

Principle #4 – Experiment More Often

Principle #5 – Consider Mechanical Sympathy

Architecting for Performance

Compute Selection

Storage Selection

Database Selection

Network Selection

Monitoring Performance

Reviewing and Adapting Your Solution

Summary

Further Reading

9

Establishing a Deployment Strategy

Deployment Strategies

AWS Deployment Services

AWS OpsWorks

AWS Elastic Beanstalk

AWS App Runner

AWS CodeDeploy

AWS CloudFormation

The AWS Cloud Development Kit

Amazon Elastic Container Service (ECS)

Amazon Elastic Kubernetes Service (EKS)

AWS Copilot

AWS Proton

Tracking Deployment

Summary

Further Reading

10

Designing for Cost Efficiency

Understanding AWS Pricing Models

Compute

Storage

Databases

Network

Evaluating Costs

AWS Pricing Calculator

AWS Cost Explorer

AWS Cost and Usage Reports

Right-Sizing Workloads

Summary

Further Reading

11

Improving Operational Excellence

Design Principles

Principle #1 – Perform Operations as Code

Principle #2 – Make Frequent, Small, Reversible Changes

Principle #3 – Refine Operations Procedures Frequently

Principle #4 – Anticipate Failure

Principle #5 – Learn from All Operational Failures

Principle #6 – Use Managed Services

Principle #7 – Implement Observability for Actionable Insights

Improving the Organizational Fit

Organization Priorities

Operating Models

The Role of Organizational Culture

Identifying Operational Gaps

Designing Telemetry

Designing for Operations

Mitigating Deployment Risks

Operational Readiness and Change Management

Evolving Your Operations

Summary

Further Reading

12

Improving Reliability

Checking the Foundations

Resource Constraints

Assessing the Architecture

Understanding Application Growth and Usage Trends

Evaluating the Existing Architecture to Determine Areas that Are Not Sufficiently Reliable

Remediating Single Points of Failure

Enabling Data Replication, Self-Healing, and Elastic Features and Services

Adapting to Change

Adapting to Failure

Using Playbooks to Investigate Failures

Performing Post-Incident Analysis

Testing Functional Requirements

Testing Scalability and Performance Requirements

Testing Resiliency Using Chaos Engineering

Conducting Game Days Regularly

Summary

Further Reading

13

Improving Performance

Reconciling Performance Metrics against Objectives

Identifying and Examining Performance Bottlenecks

Recommending and Testing Potential Remediation Solutions

Summary

Further Reading

14

Improving Security

Evaluating the Environment for Security Vulnerabilities

Getting Started with the Evaluation

Auditing an Environment for Least Privilege Access

Evaluating a Strategy for the Secure Management of Secrets and Credentials

Reviewing Implemented Solutions to Ensure Security at Every Layer

Improving Infrastructure Protection

Improving Data Protection

Reviewing Comprehensive Traceability of Users and Services

Improving Incident Detection

Improving the Response to Security Events

Prioritizing Automated Responses to the Detection of Vulnerabilities

Designing and Implementing a Patch and Update Process

Designing and Implementing a Backup Process

Summary

Further Reading

15

Improving Deployment

Reviewing Your Deployment Strategy

Infrastructure Provisioning

Application Deployment

Reviewing Deployment Services

Evaluate Appropriate Tooling to Enable Infrastructure as Code

Test Automated Deployment and Rollback Strategies

Summary

Further Reading

16

Exploring Opportunities for Cost Optimization

Developing a Workload Review Process

Decommissioning Resources

Summary

Further Reading

17

Selecting Existing Workloads and Processes to Migrate

The Need to Migrate Workloads to the Cloud

Steps for a Successful Cloud Migration

The Assess Phase

The Mobilize Phase

The Migrate and Modernize Phase

Migration Strategies

The 7 Rs of Migration Strategies

Best Practices to Keep in Mind for a Successful Cloud Migration

Summary

Further Reading

18

Selecting Migration Tools and Services

Selecting an Appropriate Database Transfer Mechanism

The Assess Phase

The Plan Phase

The Migrate Phase

Selecting an Appropriate Data Transfer Service

Online Data Transfer

Offline Data Transfer

Selecting an Appropriate Server Migration Mechanism

VMware Cloud on AWS

AWS Application Migration Service

Applying the Appropriate Security Methods to the Migration Tools

Summary

Further Reading

19

Determining a New Architecture for Existing Workloads

Understanding Your Candidate Application

Selecting the Appropriate Compute Platform

Selecting the Appropriate Storage Platform

Selecting the Appropriate Database Platform

Summary

Further Reading

20

Determining Opportunities for Modernization and Enhancements

Identifying Opportunities to Decouple Application Components

Opportunity 1: Rehosting

Opportunity 2: Replatforming

Opportunity 3: Rearchitecting

Opportunity 4: Refactoring

Identifying Opportunities for Containers and Serverless Solutions

Identifying Opportunities for Purpose-Built Databases

Opportunity 1: Rehosting

Opportunity 2: Replatforming

Opportunity 3: Refactoring

Opportunity 4: Rearchitecting

Selecting the Appropriate Application Integration Service

Pattern 1: API Gateway Pattern

Pattern 2: Messaging Pattern

Pattern 3: Publish/Subscribe Pattern

Summary

Further Reading

21

Accessing the Online Practice Resources

How to Access These Resources

Purchased from Packt Store (packtpub.com)

Packt+ Subscription

Purchased from Amazon and Other Sources

Troubleshooting Tips

Practice Resources – A Quick Tour

A Clean, Simple Cert Practice Experience

Practice Questions

Flashcards

Exam Tips

Why subscribe?

Other Books You May Enjoy

Share Your Thoughts

Download a Free PDF Copy of This Book

Preface

Amazon Web Services (AWS) has been the leading cloud service provider for over 15 years. Millions of companies across the globe—including the fastest-growing start-ups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

This book covers all four domains of the AWS Solutions Architect Professional (SA Pro) certification, an advanced certification from AWS that aims to give certified individuals credibility on the market and trust in their ability to design enterprise-grade solutions with AWS.

This book will help you reinforce your skills in delivering scalable, highly available, fault-tolerant, secure, performant, and cost-optimized solutions that keep up with the most demanding requirements and constraints. It will also stimulate you to think from multiple different perspectives before jumping into solution design.

By the end of this book, you will have validated your advanced AWS technical skills and expertise and, most likely, built enough confidence to take the AWS SA Pro certification exam with success.

Who This Book Is for

This book is for you if you are an experienced IT professional with a good understanding of designing cloud architectures on AWS. Prior knowledge of the AWS platform and services is expected.

Although not required for the exam, hands-on experience in working with AWS-based applications for two or more years is recommended.

What This Book Covers

This book is aligned with the AWS SA Pro certification contents outline updated in 2022 and covers the following topics.

Chapter 1, Determining an Authentication and Access Control Strategy for Complex Organizations, explains the concepts supporting Identity and Access Management (IAM) on AWS. It covers aspects such as cross-account access control and user federation, along with the multiple ways an organization can provide their users with access to AWS by leveraging their existing directory service.

Chapter 2, Designing Networks for Complex Organizations, covers the AWS services that can be used to design hybrid networks, allowing organizations to access AWS resources from their on-premises environments and vice versa and communicate across multiple AWS accounts.

Chapter 3, Designing a Multi-Account AWS Environment for Complex Organizations, explains how to organize resources across multiple AWS accounts for an organization. It discusses how to approach billing and resource isolation and how to increase security across your entire organization as well as for individual business units.

Chapter 4, Ensuring Cost Optimization, focuses on the various mechanisms and services available to keep your AWS bill under control.

Chapter 5, Determining Security Requirements and Controls, examines access control aspects for resources spread across your organization’s AWS accounts. It takes you through the relevant services and patterns to apply security and compliance controls.

Chapter 6, Meeting Reliability Requirements, explores several architectural patterns and relevant AWS services to help you choose a design and implementation strategy for your reliability requirements.

Chapter 7, Ensuring Business Continuity, walks you through different strategies to protect your critical workloads on AWS in case of a disaster.

Chapter 8, Meeting Performance Objectives, puts the focus on finding a solution design that meets your performance objectives. It covers the best practices and strategies to implement when designing for performance on AWS.

Chapter 9, Establishing a Deployment Strategy, explores the various options offered on AWS for deploying and updating workloads.

Chapter 10, Designing for Cost Efficiency, discusses the various pricing models offered by AWS and how to select the optimal one for your requirements and constraints.

Chapter 11, Improving Operational Excellence, discusses the importance of reviewing your existing operational strategy through AWS best practices to identify areas of improvement.

Chapter 12, Improving Reliability, guides you in assessing your workload design through the lens of AWS reliability best practices.

Chapter 13, Improving Performance, covers the specifics of performance engineering to help you improve your workload’s performance efficiency by following AWS best practices.

Chapter 14, Improving Security, focuses on AWS security practices to help you reinforce the security of your workloads.

Chapter 15, Improving Deployment, takes you through the deployment strategies and AWS capabilities that can help you improve deployment for an existing solution.

Chapter 16, Exploring Opportunities for Cost Optimization, discusses the aspects that can help you optimize your costs further on AWS.

Chapter 17, Selecting Existing Workloads and Processes to Migrate, dives into migration readiness, application discovery, application portfolio analysis, and how to select and prioritize workloads for migration.

Chapter 18, Selecting Migration Tools and Services, presents an overview of the tools and AWS services that you can leverage to prepare for a migration.

Chapter 19, Determining a New Architecture for Existing Workloads, guides you through the vast number of options available for compute, storage, and databases when migrating a workload.

Chapter 20, Determining Opportunities for Modernization and Enhancements, explores serverless and container options, as well as purpose-built databases and new cloud-native integration patterns.

SA Pro Certification – November 2022 Release

A new version of AWS’ SA Pro certification was released at the end of 2022. There are some small yet important differences compared to the previous version of the exam. The following table illustrates the changes made to the exam content outline.

AWS SA Pro certification v1 (SAP-C01)

AWS SA Pro certification v2 (SAP-C02)

Domain

% of exam

Domain

% of exam

Design for organizational complexity

12.5%

Design solutions for organizational complexity

26%

Design for new solutions

31%

Design for new solutions

29%

Migration planning

15%

Continuous improvement for existing solutions

25%

Cost control

12.5%

Accelerate workload migration and modernization

20%

Continuous improvement

29%

Table 0.1: The differences between both versions of the AWS SA Pro certification

In the new exam version, the domains have been re-balanced and, as you will note from the exam description, AWS underlines that they are now putting more emphasis on architecting solutions aligned with the AWS Well-Architected Framework. Also, notably, cost optimization has become an integral part of the solution design process, instead of being treated separately.

How to Get the Most Out of This Book

This book is directly aligned with the SA Pro certification from AWS. It is advisable to stick to the following steps when preparing for your SA Pro exam:

Read this book from end to end.Go through the AWS SA Pro certification guidelines.Refer to the AWS Well-Architected Framework and AWS whitepapers and documentation, many of which are highlighted in the Further Reading sections throughout this book.Review the practice exam questions in the book and in the AWS SA Pro certification guide.Attempt the online practice exam. Make a note of the concepts you are weak in, revisit them in the book, and re-attempt the practice questions.Keep attempting the practice exams until you are able to score at least 80% within the time limit.Review exam tips on the AWS website.

SA Pro certification candidates will gain a lot of confidence if they approach their SA Pro certification preparation using these steps.

Online Practice Resources

With this book, you will unlock unlimited access to our online exam-prep platform (Figure 0.1). This is your place to practice everything you learn in the book.

How to access the resources

To learn how to access the online resources, refer to Chapter 21, Accessing the Online Practice Resources at the end of this book.

Figure 0.1: Online exam-prep platform on a desktop device

Sharpen your knowledge of AWS SAP_C02 concepts with multiple sets of practice questions, interactive flashcards, and exam tips accessible from all modern web browsers.

Download the Color Images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book.

You can download it here: https://packt.link/euXEF.

Conventions Used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “You will use the detect_labels API from Amazon Rekognition in the code.”

Any block of code, command-line input, or output is written as follows:

class MyFirstCdkStack extends Stack { constructor(scope: App, id: string, props?: StackProps) {  super(scope, id, props);

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “In CloudWatch, each Lambda function will have a loggroup and, inside that log group, many logstreams.”

Tips or important notes

Appear like this.

Get in Touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details. We ensure that all valid errata are promptly updated in the GitHub repository, with the relevant information available in the Readme.md file. You can access the GitHub repository: https://packt.link/WDFVz.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read AWS Certified Solutions Architect – Professional Exam Guide (SAP-C02), we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a Free PDF Copy of This Book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily.

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below:

https://packt.link/free-ebook/9781801813136

Submit your proof of purchase.That’s it! We’ll send your free PDF and other benefits to your email directly.

1

Determining an Authentication and Access Control Strategy for Complex Organizations

This chapter introduces the first objective of this book, that is, determining an authentication and access control strategy to address the requirements of complex organizations.

To pass your Amazon Web Services (AWS) Solutions Architect Professional certification, you will start by revisiting the key concepts and mechanisms supporting Identity and Access Management (IAM) on AWS. You will then investigate cross-account access control and user federation, which are essential support for complex organizations. Finally, you will cover the multiple ways an organization can provide its users access to AWS by leveraging its existing directory service.

The following topics will be covered in this chapter:

Identity and Access ManagementExamining access controlLeveraging access delegationConsidering user federationReviewing AWS Directory Service

Since you are preparing for AWS Solutions Architect Professional certification, you should have already been exposed to AWS environments and services. You may already be familiar with most of the concepts covered in this chapter, but it’s worth revisiting them as to ensure you have the core knowledge needed to pass the certification.

Making the Most Out of this Book – Your Certification and Beyond

This book and its accompanying online resources are designed to be a complete preparation tool for your AWS SAP-C02 Exam.

The book is written in a way that you can apply everything you’ve learned here even after your certification. The online practice resources that come with this book (Figure 1.1) are designed to improve your test-taking skills. They are loaded with practice questions, interactive flashcards, and exam tips to help you work on your exam readiness from now till your test day.

Before You Proceed

To learn how to access these resources, head over to Chapter 21, Accessing the Online Practice Resources, at the end of the book.

Figure 1.1: Dashboard interface of the online practice resources

Here are some tips on how to make the most out of this book so that you can clear your certification and retain your knowledge beyond your exam:

Read each section thoroughly.Make ample notes: You can use your favorite online note-taking tool or use a physical notebook. The free online resources also give you access to an online version of this book. Click the BACK TO THE BOOK link from the Dashboard to access the book in Packt Reader. You can highlight specific sections of the book there.Practice Questions: Go through the practice questions provided online with this book. Use them to test yourself on the concepts learned. If you get some answers wrong, go back to the book and revisit the concepts you’re weak in.Flashcards: After you’ve gone through the book and start reviewing the online flashcards. They will help you memorize key concepts.Exam Tips: Review these from time to time to improve your exam readiness even further.

Now that you have gone through the preceding tips to help you maximize the benefits of this book and the online resources provided with it, you can proceed to the first main topic of this chapter.

Diving into Identity and Access Management

AWS Identity and Access Management (IAM) is used to define and control who can access which resources in an AWS environment. IAM concepts and how they provide security controls are a key part of the exam. Here are some key concepts:

Every new AWS account comes with a root user that has full access to all AWS services and all the resources in the account. As a best practice, it is recommended to do the following:

Immediately protect that root user with multi-factor authentication (MFA).Secure the root user credentials and only use them if you need to perform specific service and account management tasks that only the root user can perform.

Note

See https://packt.link/eVR8z for more details on tasks that only the root user can perform.

IAM users

An IAM user is an entity designed to be associated with a single individual or application. It is used to allow access to AWS resources either through the AWS Management Console (providing a username and password) and/or programmatically (using an access key and a secret access key) from the command-line interface (CLI) or one of the AWS software development kits (SDKs). IAM users are given permissions either by being directly assigned IAM policies or by being assigned to an IAM user group.

MFA

The security of IAM users can be enhanced by enabling MFA. Users then must provide two forms of authentication. The first is identity credentials such as username/password or access key/secret access key. The second form takes the shape of a temporary six-digit numeric code. This can be provided by a hardware device, an application on a mobile device such as a smartphone or tablet, or sent by AWS to a mobile device as an SMS.

IAM User Groups

An IAM user group is a collection of IAM users. It cannot be used to access AWS services directly. Its main purpose—other than grouping related users together—is to assign the same permissions to all the users in the group.

Instead of granting permissions individually to users, it is recommended that you give permissions to a group, and then you add the users who need these permissions to the group. When a user should no longer have the permissions granted to the group, you simply remove them from the group. Managing permissions for users then becomes a lot easier.

As an example, think of a group representing a company’s software developers and another group representing its system administrators. Because each user in a group automatically inherits the permissions assigned to the group, it then becomes easier for an AWS administrator to maintain the permissions required by each group member (software developers or system admins, in the given example) at a group level rather than individually at a user level.

An IAM user can be assigned to multiple IAM user groups, in which case it inherits the permissions of all the user groups it is a member of.

IAM Roles

An IAM role is an identity that possesses specific permissions. It is like an IAM user in which it provides access to AWS resources and defines what the user or application assuming that role can do on AWS. It is different from an IAM user in that a role is not associated with a single individual or application but can be assumed by multiple entities. IAM roles are used to provide temporary credentials to entities (individuals, AWS services, or applications).

Important Note

An IAM user or role cannot span multiple AWS accounts. The Leveraging Access Delegation section will cover how cross-account access (accessing resources in AWS account A from AWS account B) can be granted.

IAM Policies

An IAM policy is an object that allows access control on AWS. It can be assigned either to an IAM identity (user, user group, or role) or to an AWS resource. When access to an AWS resource is requested, IAM will evaluate the permissions defined by all the policies entering the scope of that request and based on their intersection, decide whether access is allowed or denied. IAM supports multiple types of policies: identity-based policies, resource-based policies, permissions boundaries, organizations’ service control policies (SCPs), access control lists (ACLs), and session policies. You will explore these in the following sections.

Identity-Based Policies

Identity-based policies are JavaScript Object Notation (JSON) policy documents that are attached to IAM identities (users, user groups, or roles). They control what actions an IAM identity (user, user group, or role) can perform on which AWS resources and under which conditions. They are further subdivided into the following categories:

Managed policies: Managed policies are named policies and can be assigned to any number of IAM identities. They can be of two sorts, as outlined here:AWS-managed policies: Policies created and managed by AWSCustomer-managed policies: Policies created and managed by youInline policies: Inline policies are permissions directly attached to a single IAM identity. Their life cycle is the same as that identity’s life cycle.

Here is an example of an identity-based policy that gives read-only access to all Simple Storage Service (S3) objects on its AWS account:

{   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Action": [         "s3:Get*",         "s3:List*"       ],       "Resource": "*"     }   ] }

Note

Remember that an IAM identity has by default no permissions at all on AWS. You must assign one or more identity-based policies for it to be able to do something on AWS.

Resource-Based Policies

Resource-based policies are JSON policy documents that are attached to AWS resources. They control what actions can be performed on the attached resource(s) by which principal (user or role) under which conditions. As opposed to identity-based policies, resource-based policies are always inline policies.

Here is an example of a resource-based policy providing permissions to any principal (user or role) in the account to get any object from the S3 bucket identified by the Resource attribute:

{   "Version": "2012-10-17",   "Id": "Policy123456789",   "Statement": [     {       "Sid": "",       "Action": [         "s3:GetObject"       ],       "Effect": "Allow",       "Resource": "arn:aws:s3:::my-bucket/*",       "Principal": "*"     }   ] }

Note

Remember that resource-based policies provide an opportunity to further protect your AWS resources by limiting not just what actions can be performed but also the IAM entities allowed to perform them.

Permissions Boundaries

Permissions boundaries allow us to define the maximum permissions that identity-based policies can give to IAM entities (user or role). An entity can then only perform actions allowed by both its identity-based policies and its permissions boundaries. Setting a permissions boundary does not give permissions on its own but it limits what the entity can do. It is also worth noting that permissions boundaries do not affect the permissions provided by resource-based policies. A resource-based policy can provide permissions to an IAM entity beyond the scope defined by permissions boundaries.

Look at an example to learn how this all works.

Suppose that you have an IAM user with the following identity-based policy:

{   "Version": "2012-10-17",   "Statement": {     "Effect": "Allow",     "Action": "iam:ChangePassword",     "Resource": "*"   } }

The policy gives them the ability to change their user’s password.

Now, imagine that you set for the same user the following permissions boundary:

{   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Action": [         "lambda:*",         "ec2:*"       ],       "Resource": "*"     }   ] }

The permissions boundary policy limits the user to any action on both AWS Lambda and Amazon Elastic Compute Cloud (EC2) resources in their AWS account.

Now, if the user tries to change their password (after all, they were given the permissions to do so) the operation will fail. Why? The user was given permissions in their identity-based policy to change their password, but their permissions boundary only allowed actions to be performed on AWS Lambda and Amazon EC2, not on AWS IAM. For the iam:ChangePassword action to work, the user’s permissions boundary would need to be expanded to include at least that action on AWS IAM.

On a second note, the user was not given permission to perform any other action than iam:ChangePassword. So, even though their permissions boundary would authorize them to perform any action on AWS Lambda and Amazon EC2, they simply cannot do so because their identity-based policy is too restrictive.

Additionally, imagine that you have defined on the same account the previous sample resource-based policy providing permissions to any principal (user or role) in the account to get any object from the S3 bucket identified by the Resource attribute. Even though the permissions boundary policy limits your user’s actions to AWS Lambda and Amazon EC2 resources, your user will nevertheless be able to get any object from the S3 bucket specified in the resource-based policy. Why is that? Because permissions boundaries only affect the scope of permissions defined by identity-based policies, not by resource-based policies.

That said, permissions boundaries are an efficient mechanism to thwart privilege escalation by limiting what IAM entities (user or role) can do independently of the identity-based policies that are attached to them. Diving deeper into this goes beyond the scope of this chapter.

Note

Make sure to review https://packt.link/4xWr4 to clearly understand how this can be achieved in practice.

Remember that permissions boundaries do not add permissions to what an IAM entity can do; they only limit what it can do.

Organizations SCPs

AWS Organizations is a service that allows us to centrally manage multiple AWS accounts belonging to the same organization. It provides the ability to structure them according to a hierarchy of organizational units (OUs). It also provides a feature called SCPs that allows us to limit permissions for all member accounts in either an entire organization or a single OU. It allows an AWS administrator to enforce those controls from a central place and easily adapt them to the evolution and needs of your organization over time.

You will cover SCPs in more detail while learning AWS Organizations in a later chapter.

Note

Remember that SCPs are one efficient mechanism to enforce security controls, following your organization’s security policies systematically and repeatedly without having to duplicate the same policies in each individual AWS account.

ACLs

ACLs are service policies that let you control which principals in another account are allowed to access a resource in the current account. They are somewhat like resource-based policies but present clear differences:

They are expressed using Extensible Markup Language (XML) and not JSONThey cannot be used to control access within the same account as the principal requesting access.

ACLs can help address some very specific use cases in which resource-based policies may not be your best option. Such use cases include, for instance, controlling access to S3 objects that do not belong to the S3 bucket owner, or setting different access permissions for individual objects inside the same folder within a given S3 bucket.

Amazon S3 but also services such as AWS Web Application Firewall (WAF), and Amazon Virtual Private Cloud (VPC)support ACLs.

Note

To dive deeper into ACLs and specific use cases where they can prove useful, consult the ACL overview page in the Amazon S3 documentation at https://packt.link/bd4MI.

Session Policies

Session policies are policies passed as a parameter when programmatically creating a temporary session for a role or a federated user. They are meant to limit the permissions from the role’s or user’s identity-based policy that are allowed during the session. Like permissions boundaries, they cannot be used to grant more permissions than those already allowed by the identity-based policy.

To create a temporary session for a role, you use either the AssumeRole, the AssumeRoleWithSAML, or the AssumeRoleWithWebIdentity application programming interface (API) operation from the AWS Security Token Service (STS). For federated users, temporary sessions are created using the GetFederationToken API operation from AWS STS.

You will review the importance of sessions when going through further details about access control later in this chapter.

Identity-Based Versus Resource-Based Policies

So, what most AWS administrators end up wondering is: Should I rather use identity-based policies or resource-based policies? Well, it depends—it really does.

It is not a binary decision. Very likely, you will end up using a combination of both plus several of the other types of policies we’ve previously discussed.

A first observation is that not all AWS resources support resource-based policies, so identity-based policies remain the only way of giving access to the resources that do not. A second key aspect is that identity-based policies provide a means to manage access to AWS resources independently of these AWS resources and their life cycle. So, it makes sense for an AWS administrator who wants to centralize access control as much as possible in a single place to rely on identity-based policies to control access to AWS resources.

Does this mean that resource-based policies would not be useful? No—they will prove very useful for providing additional control to the security-savvy resource owner who wants to further ensure that only specific entities within their organization are allowed to access their resources.

For instance, consider a situation where multiple teams have access to resources in your account. As the owner of sensitive data sitting in a specific S3 bucket, you want to restrict access to people who you know have been approved to access that data. You happen to know that these people are all part of a specific OU inside your organization. You could then make sure to restrict access, independently of the permissions that anyone is assigned in your organization, by enforcing specific conditions for accessing your sensitive data. For that, you would typically use resource-based policies. In this example, you could add a condition such as the following to the resource-based policy assigned to your resources sitting, for instance, in an S3 bucket:

"Condition" : { "ForAnyValue:StringLike" : { "aws:PrincipalOrgPaths":[" o-a1phab2avo/r-abcd/ou-wxyz- hal45678/*"] }}

And does this mean that other policies, such as SCPs and session policies, are not so important? No—it most certainly does not. Complex organizations with multiple AWS accounts will also, at least, leverage SCPs on top of identity-based and resource-based policies. You will cover SCPs in more detail when you learn AWS Organizations.

Note

Identity-Based Policies and Resource-Based Policies Are Permissions Policies

Provided that there are no further constraints (SCPs, permissions boundaries, session policies, or ACLs), an entity will have access to a resource in the same account if access is not explicitly denied and if at least one policy statement grants access, whether it is within an identity-based policy or a resource-based policy.

Now examine how these different functionalities offered by IAM can be leveraged to control access to AWS resources.

Examining Access Control

In this section, you will investigate two different approaches organizations can take to control access, either based on a principal’s role or based on specific properties, also known as attributes, characterizing a principal.

Role-Based Access Control (RBAC)

This is the traditional access control approach where the permissions defining the actions that a principal (user or role) can perform are based on the function that the person has in their job. You typically define different policies for the roles you need in your organization and then assign these policies to IAM identities (users, user groups, or roles). Note that AWS already includes some managed policies for job functions.

Since granting the least privilege is a best practice, you should restrict the permissions that you grant to the various job functions to the strict minimum each of them needs to perform its job. Typically, you do that by explicitly listing the AWS resources each job function has access to, including the relevant actions that can be performed.

The main issue in doing that effectively is that the AWS resources a job function needs access to are likely to be quite variable over time. Every time a new AWS resource that one or more job functions need access to get added (for instance, a new S3 bucket, a new DynamoDB table, or a new Relational Database Service (RDS) database), you must update the policies for these job functions. Every time a specific job function changes team or project, you must update its permissions. The more granular control you want to have, the more policies you will have, and the more often you will need to update them.

So, the temptation rapidly grows for an AWS administrator to provide slightly too wide permissions by using wildcards (‘*’) in job functions’ policies instead of actual resources’ Amazon Resource Names (ARNs).

Therefore, a lack of flexibility and management overhead is often the main drawback of a traditional RBAC approach.

Attribute-Based Access Control (ABAC)

This is where an ABAC approach can help. With ABAC, you can create fewer and more compact policies.

You can, for instance, give an identity access to all resources of a certain type (for example, all S3 buckets) within the account but then specify a condition filtering on the value of a certain tag (or attribute), which would only allow access to the resource if the principal tag matched the resource tag. That tag could represent anything meaningful to your organization and context (for example, business unit (BU) or project), and you could filter on multiple tags (or attributes).

ABAC allows much more flexibility and is far less painful in terms of administration while still providing fine-grained access control to implement the least-privilege best practice.

ABAC really shines in helping you simplify permissions management at scale; therefore, it comes in handy for complex organizations. These organizations are likely to use identity federation for their workforce to access AWS resources leveraging their already existing identity provider (IdP), such as Microsoft Active Directory (AD). What you will see later when discussing user federation is that you can pass session tags when you create a temporary session for a role or a federated user, and when integrating your IdP with AWS, you can specify which user attributes you would like to pass as session tags. So, imagine that you set up attributes such as job function, department, and team as session tags. These session tags are then assigned to the principal and can be used in your identity-based or resource-based policies.

As an example, to illustrate the preceding information, the following identity-based policy would give, to the identity it is assigned to, full access to EC2 resources in the account, with the condition that the principal is in a systems administrator (SysAdmin) job function, provided that the job function is being passed as a session tag through identity federation:

{   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Action": "ec2:*",       "Resource": "*",       "Condition": {"StringEquals": {"aws:PrincipalTag/         jobfunction": "SysAdmin"}}     }   ] }

So, now that you have covered IAM and how to leverage it to establish granular access control on AWS resources, which other security mechanisms do you need to investigate? Well, to start with, you need to consider cases where the permissions provided to a principal are simply not enough for what they need to achieve. What can you do in such cases while still adhering to your least-privilege best practice? This is where access delegation can help, and this is what you are going to cover next.

Leveraging Access Delegation

You are now going to investigate access delegation. Access delegation is essentially used for the following reasons:

Providing an entity temporary access to resources that they do not have access to with their current privileges. This could be one of the following:A user that needs temporarily elevated privileges to perform a specific taskAn application or AWS service that requires specific privilegesProviding an entity access to resources located in another AWS account.

Now, start by examining these cases.

Temporary Access Delegation

Take for instance, the first use case where you need to provide trusted users, applications, or AWS services with temporary security credentials so that they can access your AWS resources. As the name implies, the security credentials that will be provided are temporary, which has the following benefits:

The access provided is limited to a short period of time, typically ranging from a few minutes to a few hours.No need to store or manage (for example, rotate) temporary credentials like you would have to with permanent credentials because they are short-lived.No need to define an AWS identity for each user that requires access. Instead, you can leverage identity federation, which relies on temporary security credentials.

AWS STS is the central AWS service for requesting temporary security credentials on AWS. In a nutshell, AWS STS creates a new session on AWS with temporary security credentials that include an access key pair (access key, secret access key) and a session token. These credentials can then be used by end users or applications to access your resources. You can additionally programmatically pass session policies and session tags using AWS STS. As you noticed earlier, the resulting permissions are then the intersection of the temporarily assumed IAM role’s identity-based policies and the session policies.

Accessing Resources from One Account to Another

Complex organizations, as with most enterprises, will maintain multiple AWS accounts to host their workloads on AWS. In some circumstances, entities in one account need to access resources in another account. Access across accounts is not permitted by default on AWS; resources in one account are fully isolated within the account and cannot be accessed from other AWS accounts unless specific permissions are explicitly given.

IAM roles’ Trust Policies

Cross-account access is made possible because of IAM roles. IAM roles have a distinct capacity to act both as an identity and as a resource, and as such, you can associate both identity-based policies and resource-based policies with IAM roles. In the case of IAM roles, resource-based policies are also called trust policies.

To illustrate how this works, consider that an organization stores some data on S3 in a central account and makes it available to other accounts in the organization. By default, none of the other accounts has permission to perform any action on the S3 bucket belonging to the central account.

One solution consists of using resource-based policies and giving read or write access, as needed, to that central S3 bucket and to all the other accounts. But because not all AWS services support resource-based policies, look at a more generic solution that could also work with other AWS services and not just Amazon S3.

In this case, the generic approach consists of leveraging IAM roles and establishing trust between the central account and the other accounts. An IAM role can be assumed by another principal (user or role), including from another account, if they have the right permissions. For this, you create an IAM role in the account where the resources need to be accessed from other accounts, where you will establish trust. The central account is the trusting account, while all the other accounts that need to access resources in that account are the trusted accounts.

In the central account (call it AccountA), you define a role (call it roleA), and you assign that role a trust policy in which you specify that it can be assumed by other principals from any other accounts that need to. Suppose that you need to get it accessed by userB from another account, AccountB. The trust policy would look something like this:

{   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Principal": {         "AWS": "arn:aws:iam::AccountB:user/userB"       },       "Action": "sts:AssumeRole"     }   ] }

This trust policy instructs IAM that roleA in accountA can be assumed by userBfrom accountB.

So, you need to provide roleA enough privileges to be able to read or write to S3 on the account. You do this by either assigning an identity-based policy to roleA or by attaching resource-based policies to the relevant S3 buckets, to give the necessary permissions to roleA. See the previous sections on identity-based and resource-based policies for more details.

Now, most importantly, in accountB, you must also give userB permissions to assume roleA in accountA. You set such permissions in an identity-based policy that you assign to userB, such as this:

{   "Version": "2012-10-17",   "Statement": {     "Effect": "Allow",     "Action": "sts:AssumeRole",     "Resource": "arn:aws:iam::AccountA:role/roleA"   } }

When userB in accountB assumes roleA in accountA, they inherit the permissions assigned to roleA and can then perform any action roleA is entitled to on resources in accountA.

AWS Resource Access Manager (RAM)

There is also an alternative for sharing resources across multiple accounts.

AWS RAM is a central service that allows you to share resources you own in one account with multiple accounts either within your own AWS OU or beyond. There is one caveat, though: you cannot share all types of AWS resources with RAM as only a limited set is supported.

Note

For a list of shareable resources, check the documentation at https://packt.link/qEeQE.

That said, for those supported resources it is a convenient and easy way to share resources across your entire organization or with specific AWS accounts. It works quite simply. AWS RAM allows you to share resources in one account with a set of principals. Such principals can be individual AWS accounts, the member accounts of an organization, an OU in AWS Organizations, or even individual IAM entities (users or roles). It is worth noting that when you share resources within an organization that has resource sharing enabled, principals in your organization immediately get access to the shared resources. AWS RAM does not send them an invitation in this case. However, when you share resources in a standalone AWS account or in an organization without resource sharing enabled, AWS RAM would send the principals an invitation that they must accept to gain access to the shared resources.

This is a widespread approach among complex organizations since they often need to share resources located in and managed from a central AWS account with multiple AWS accounts (for instance, EC2 images, Route 53 Domain Name System (DNS) forwarding rules, AWS Transit Gateway, and more).

So far, you have covered IAM, how to leverage it to establish granular access control on AWS resources, and how to delegate access when you need either additional permissions on a temporary basis or access resources in a different AWS account. You will now investigate a security mechanism that enables organizations to reuse their existing IdP(s) to access AWS—namely, the concept of user federation.

Considering User Federation

It is only natural for organizations to want to reuse their existing IdPs to give their workforce, customers, or partners access to AWS without having to create and manage a separate set of identities on AWS. This avoids multiplying long-lived security credentials unnecessarily and, as such, limits the security risks. You can leverage either AWS Single Sign-On (AWS SSO) or AWS IAM to enable user federation depending on the use case.

AWS SSO is well suited for cases where you want to establish user federation across multiple AWS accounts and leverage your existing corporate or a third-party IdP. You can then assign permissions to your users based on their group membership in your IdP’s directory and control access by modifying users and groups on your IdP. You can also implement ABAC, whether via the user information synchronized with your IdP via System for Cross-domain Identity Management (SCIM) or by passing user attributes in Security Assertion Markup Language 2.0 (SAML 2.0) assertions.

You can also use AWS IAM for user federation with individual accounts. IAM is well suited to cases where, for instance, you want to use separate IdPs for different accounts—in some cases, your corporate IdP, and in others, a third-party OpenID Connect (OIDC) IdP. You can also implement ABAC by passing user attributes in SAML 2.0 assertions.

In both cases, if you use an ABAC approach you can easily change, add, or revoke user permissions by changing the user attributes centrally in your IdP. Whether these attributes get synchronized through SCIM or are passed in SAML 2.0 assertions, AWS SSO will pass them as session tags, which are temporary tags that remain valid for the duration of the federated session you establish. As you also saw previously, you can then use these session tags to filter access to AWS resources by using conditions within IAM policies.

So far, you have covered IAM, how to leverage it to establish granular access control on AWS resources, and how to delegate access when you need either additional permissions on a temporary basis or to access resources in a different AWS account and user federation to leverage your existing IdPs for authentication. The last part of your journey through authentication and authorization mechanisms on AWS will take you to the directory service provided by AWS: AWS Directory Service.

Reviewing AWS Directory Service

AWS Directory Service offers several choices for organizations to deploy existing applications on AWS that rely on Microsoft AD or Lightweight Directory Access Protocol (LDAP). This is the native AWS service to use when you need a directory to manage users, groups, devices, and access.

AWS Directory Service proposes different options to use Microsoft AD with AWS services, as follows:

Simple AD: A low-scale and low-cost directory with basic Microsoft AD compatibilityAD Connector: A proxy service to connect to a remote Microsoft AD on-premisesManaged Microsoft AD: A Microsoft AD environment managed by AWS

The following sections will discuss the main differences between these three options and when to use one or the other.

Simple AD

Simple AD is a Microsoft AD-compatible directory that provides basic AD features such as managing user accounts, group memberships, and group policies, joining a (Linux or Windows) EC2 instance to your directory, and Kerberos-based SSO.

Simple AD is a standalone directory running on AWS to create and manage user identities and control access to applications. It is compatible with various applications and tools that only require basic AD features. For example, Simple AD supports Amazon WorkSpaces and Amazon QuickSight, among others. You can also use it to log in to the AWS Management Console.

Limitations

Simple AD does not support MFA or trust relationships with other domains and many other advanced AD features. Simple AD is not compatible with Amazon RDS for SQL Server, and it can support applications or services on AWS only.

When to Use It

Use Simple AD if you need to support Windows workloads that need basic AD features, to work with compatible AWS applications, or to support Linux workloads that need an LDAP service.

AD Connector

AD Connector is a scalable proxy service that forwards requests to your on-premises AD. It offers an easy way to connect compatible AWS applications—for instance, Amazon WorkSpaces, Amazon QuickSight, or Amazon EC2 for Microsoft Windows Server instances—to your existing on-premises Microsoft AD. It does not require you to synchronize your directory and does not add extra cost or complexity—there’s no need, for instance, to set up a federation infrastructure.

AD Connector supports numerous AWS applications and services such as Amazon WorkSpaces, Amazon WorkDocs, Amazon QuickSight, or Amazon Connect. It also lets you join your EC2 Windows instances to your on-premises AD domain seamlessly. Users can also leverage it to sign in to the AWS Management Console and manage AWS resources using their existing AD credentials.

AD Connector does not cache any information on AWS, which has both benefits (your users’ information is never stored on AWS) and drawbacks (every sign-in request is a request back to your on-premises directory).

There is a one-to-one relationship between AD connectors and your AD domains; each on-premises domain requires a separate AD connector before it can be used for authentication.

Limitations

AD Connector is not compatible with Amazon RDS for SQL Server or with Amazon FSx for Windows File Server.

When to Use It

AD Connector is recommended when you want to use your existing on-premises directory with compatible AWS services.

Managed Microsoft AD

Managed Microsoft AD essentially lets you run Microsoft AD as a managed service on AWS. A fully featured AD, it supports Microsoft SharePoint, Microsoft SQL Server, Always On availability groups, and numerous .NET applications. Some AWS-managed applications and services are also supported, among which are Amazon WorkSpaces, Amazon QuickSight, Amazon Connect, Amazon RDS for Microsoft SQL Server, and Amazon FSx for Windows File Server.

Managed Microsoft AD is provided as a single-tenant solution; you do not share it or its components with any other AWS customer. It comes by default with two domain controllers deployed in separate Availability Zones (AZs) for increased resiliency.

You can leverage user credentials stored in AWS Managed Microsoft AD to work with compatible applications. Alternatively, you can also establish trust with your existing AD infrastructure and use credentials whether they are stored on an AD running on-premises or on Amazon EC2. By joining your EC2 instances to AWS Managed Microsoft AD, users can access Windows workloads on AWS with the same Windows SSO experience as on-premises.

AWS Managed Microsoft AD lets you sign in to the AWS Management Console. Leveraging AWS SSO, you can further obtain short-term credentials that you can use with the AWS SDK and CLI. It also gives you access, through integration with SAML, to sign in to various cloud applications. It also offers built-in integrations with Microsoft Office 365 and other business applications (for example, Salesforce) with credentials stored in AWS Managed Microsoft AD. You can further reinforce security by enabling MFA.

When to Use It

AWS Managed Microsoft AD is the recommended option when you need genuine AD features to support AWS applications or Windows workloads. That includes Amazon RDS for Microsoft SQL Server and Amazon FSx for Windows File Server. Similarly, it remains your best option if you require access to business applications such as Office 365, Salesforce, and more.

Summary

In this first chapter, you have reviewed the core IAM concepts of AWS. You then investigated cross-account access control and user federation, which are essential elements for supporting complex organizations. Finally, you looked at the various flavors offered by AWS Directory Service. All these functionalities are core for securing access to AWS resources for complex organizations. So, do make sure these elements are crystal clear in your mind before moving on and, especially if that is not the case, have a look at the additional resources provided in the next section.

The next chapter of this book will take you through the AWS networking capabilities you need to know about to select and configure the optimal network topology for your organization.

Further Reading

For more information, please refer the following resources:

Getting started with IAM: https://packt.link/jmFBwRBAC versus ABAC: https://packt.link/DxXF8Best Practices for Security, Identity, & Compliance: https://packt.link/IfCumSecurity Pillar – AWS Well-Architected Framework: https://packt.link/Y3LezAD services on AWS: https://packt.link/P0Ys5