CloudFront vs. Global Accelerator: Key Differences
| Feature | AWS CloudFront 🌍 | AWS Global Accelerator 🚀 |
|---|---|---|
| Primary Use Case | Content delivery (CDN) | Global traffic acceleration |
| How It Works | Caches static & dynamic content at Edge Locations | Routes traffic through AWS Global Backbone |
| Performance Optimization | Reduces latency by caching content at the edge | Uses optimal AWS backbone paths to reduce latency |
| Supports Dynamic Content | Yes (but optimized for caching static content) | Yes (optimized for real-time applications) |
| Best for | Websites, APIs, video streaming, software downloads | Multi-region applications, real-time gaming, VoIP, financial apps |
| Traffic Routing | Routes based on DNS (latency-based routing) | Uses Anycast IPs for direct traffic routing |
| Failover Handling | Limited failover (depends on TTL settings) | Fast failover between AWS Regions & endpoints |
| Integration | Works with S3, EC2, Load Balancers, HTTP/HTTPS origins | Works with ALB, NLB, EC2, and on-prem endpoints |
| Security | Integrates with AWS Shield, WAF, IAM, ACM (SSL) | DDoS protection built-in, IAM integration |
| Pricing | Pay per request & data transfer | Pay for provisioned bandwidth & data transfer |
EBS Fast Snapshot Restore (FSR) Overview
Amazon EBS Fast Snapshot Restore (FSR) is a feature that allows Amazon Elastic Block Store (EBS) snapshots to be restored instantly into fully initialized EBS volumes. Without FSR, volumes created from snapshots go through lazy loading, which means performance might be slow initially while data is fetched from Amazon S3.
Key Features of EBS Fast Snapshot Restore (FSR)
- Instant Read Access
- Volumes created with FSR are immediately available at full performance without waiting for data to be pulled from S3.
- Consistent Performance
- No performance degradation when accessing data for the first time after volume creation.
- Region-Specific Enablement
- You must enable FSR on a snapshot in a specific AWS region.
- Per-Snapshot, Per-AZ Pricing
- You pay an hourly fee for each FSR-enabled snapshot in each Availability Zone (AZ).
AWS Single Sign-On (SSO) is a cloud-based service that allows you to centrally manage access to multiple AWS accounts and third-party applications. With AWS SSO, you can control user access, manage credentials, and enable secure sign-on to apps without needing multiple logins.
🔹 Key Features of AWS SSO:
- Centralized User Management
- AWS SSO provides a centralized location for managing user identities and permissions across AWS accounts and applications.
- Integrates with Active Directory (AD), Azure AD, or you can use AWS SSO’s built-in identity store.
- Integrated Access to AWS Accounts
- You can set permissions to manage who can access which AWS accounts and roles, making it easy to give users secure access to different environments.
- Third-party Applications Integration
- Easily integrate with SaaS apps (e.g., Microsoft 365, Salesforce, etc.) using SAML 2.0 and OAuth for Single Sign-On.
- User Portal
- Users get a customizable portal where they can see all the apps and AWS accounts they have access to.
- No need for remembering multiple passwords.
- Multi-Factor Authentication (MFA)
- AWS SSO supports MFA for an additional layer of security during login.
- Custom Permissions
- You can map roles and permissions to AWS services (e.g., EC2, S3) based on your organization’s needs.
🔹 What is an Active Directory Forest Trust?
A forest trust is a type of trust relationship between two Active Directory forests that enables cross-forest authentication and resource access. Once a forest trust is established, users and groups in one forest can access resources in another forest, just as if they were in the same forest.
There are two main types of trust relationships:
- One-way trust: One forest (the trusting forest) allows users from the other forest (the trusted forest) to access its resources.
- Two-way trust: Both forests trust each other, allowing users from both forests to access resources in each other’s domains.
Summary of Key Types in AWS KMS
| Key Type | Description | Example Use Cases |
|---|---|---|
| Symmetric CMK | One key used for both encryption and decryption. | Encrypting data in S3, EBS, RDS. |
| Asymmetric CMK | Public key for encryption, private key for decryption. | Digital signatures, asymmetric encryption. |
| Data Keys | Temporary keys used for encrypting large data objects. | Encrypt large files or application data. |
Key Differences Between Multi-Region Keys and Standard Regional Keys
| Feature | Multi-Region Key | Regional Key |
|---|---|---|
| Region Accessibility | Available across multiple regions | Available only in the region it was created |
| Key Replication | Automatic replication of the key across regions | Must manually create and manage separate keys in each region |
| Cross-Region Use | Can be used for encryption and decryption across regions | Cannot be used across regions (region-specific) |
| Alias | Same alias used across regions | Separate aliases for each region |
| Key Material | Shared cryptographic key material across regions | Separate cryptographic key material for each region |
| Use Case | Multi-region applications, disaster recovery, data replication | Region-specific encryption and decryption |
When working with Amazon S3 and AWS Key Management Service (KMS), there are different KMS key types that you can use for server-side encryption (SSE) to protect your data stored in S3. AWS provides three main types of KMS keys for encryption in S3:
- SSE-KMS (Server-Side Encryption with AWS KMS-managed Keys): Using KMS to manage the encryption key.
- SSE-S3 (Server-Side Encryption with S3 Managed Keys): AWS-managed encryption keys (not KMS-specific).
- SSE-C (Server-Side Encryption with Customer-Provided Keys): Customer-supplied encryption keys.