Architecting Fundamentals Flashcards
AWS Local Zones
Not as big as regions but mitigate places where there is no region where latency is an issue
Allows services to be close to your data center
AWS infrastructure at the edge
Local compute, storage, DB and other services
Connecting to services in AWS region
Delivers new low latency applications
Doesn’t have access to global storage services (e.g. S3, dynamoDB, EFS, etc.)
Edge Locations
Edge locations based on proximity to people with computers and mobile devices - 2 main services running Cloud Front, Route53
Uses cache to distribute content/DNS
Well Architected Framework
Six PDFs that list best practices for :
Security
Cost Optimization
Reliability
Performance Efficiency
Operational Excellence
Sustainability
Well Architected Tool
Based on the AWS Well-Architected Framework
Can review your applications and workloads
Central place for best practices and guidance
Used in tens of thousands of workload reviews
AWS data centers
AWS services operate within AWS data centers.
Data centers host thousands of servers.
Each location uses AWS proprietary network equipment.
Data centers are organized into Availability Zones.
Availability Zones
A group of one or more data centers is called an Availability Zone.
An Availability Zone is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region
Data centers in a Region
Designed for fault isolation
Interconnected by using high-speed
private links
Used to achieve high availability
Policy types
Policies that grant/deny permissions:
Identity-based policies
Resource-based policies
Policies that set maximum policy:
AWS Organizations service control policies (SCPs)
IAM permissions boundaries
Resource based policies
Attach inline policies to resources. The most common examples of resource-based
policies are Amazon S3 bucket policies and IAM role trust policies.
AWS Organizations service control policies (SCPs)
Use Organizations SCPs to define the maximum
permissions for account members of an organization or organizational unit (OU).
IAM permissions boundaries
AWS supports permissions boundaries
for IAM entities (users or roles). Use IAM permissions boundaries to set the maximum permissions that an IAM entity can receive.
Identity based policies
Attach managed and inline policies to IAM identities. These identities include users,
groups to which users belong, and roles.
What policies need to explicitly allow if present?
IAM identity based policies, IAM permissions boundary, AWS Organization SCP
What policy type works independently of the others
IAM resource based policies
Identity-based policies can be categorized by the following types?
Managed policies –Standalone identity-based policies that you can attach to multiple users, groups, and
roles in your AWS account. There are two types of managed policies:
AWS managed policies –Managed policies that AWS creates and manages. They are built to provide
specific service access or permissions for job functions.
Customer managed policies –
Managed policies that you create and manage in your AWS account.
Customer managed policies provide more precise control over your policies than AWS managed
policies.
*Inline policies –Policies that you add directly to a single user, group, or role. Inline policies maintain a strict
one-to-one relationship between a policy and an identity. They are deleted when you delete the identity.
An inline policy is a policy that you create and embed directly to an IAM group, user, or role. Inline policies can’t be reused on other identities or managed outside of the identity where they ex
Why might you want to create a multi-account structure in your organization?
*To group resources for categorization and discovery (many teams)
*To improve your security posture with a logical boundary
*To limit potential impact in case of unauthorized access
*To simplify management of user access to different environments (billing)
