Difference between revisions of "IT-Exam-AWS"
Jump to navigation
Jump to search
Samerhijazi (talk | contribs) (→Amazon RDS (Relational Database Service)) |
Samerhijazi (talk | contribs) (→Amazon DynamoDB (NoSQL)) |
||
| Line 34: | Line 34: | ||
* You need high-speed reads/writes at any scale | * You need high-speed reads/writes at any scale | ||
* You don’t need complex relationships (no joins) | * You don’t need complex relationships (no joins) | ||
| − | * Your data is semi-structured or unstructured | + | * Your data is semi-structured or unstructured (Schema-less or flexible schema) |
* You expect massive scale (e.g., millions of users, IoT, gaming) | * You expect massive scale (e.g., millions of users, IoT, gaming) | ||
| + | * High scalability: Designed to scale horizontally across servers | ||
=XXX= | =XXX= | ||
Revision as of 20:01, 11 April 2025
Contents
Core AWS Services
- EC2 – Instances, types, autoscaling
- S3 – Storage classes, performance, hosting static websites
- ELB (Elastic Load Balancer) – For distributing traffic
- RDS & DynamoDB – When to use what (relational vs NoSQL)
- Lambda – For serverless scenarios
- CloudFront – CDN to reduce latency
- IAM (roles, policies, least privilege)
Architecture Best Practices
- Operational Excellence
- Security
- Reliability
- Performance Efficiency
- Cost Optimization
- Sustainability (recent addition)
Low-Latency Architecture
- Use CloudFront for global distribution
- Place backend services in multiple Availability Zones
- Use Auto Scaling for EC2 or Lambda
- Use Elasticache for caching (Redis/Memcached)
- Choose regions close to the end users
- Use Global Accelerator if needed
Databases
Amazon RDS (Relational Database Service) & Aurora
- You need structured data with relationships (foreign keys, joins).
- Your application depends on SQL queries (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle).
- You require ACID transactions (Atomicity, Consistency, Isolation, Durability).
- You need complex reporting or analytics using joins, aggregations, etc.
Amazon DynamoDB (NoSQL)
- You need high-speed reads/writes at any scale
- You don’t need complex relationships (no joins)
- Your data is semi-structured or unstructured (Schema-less or flexible schema)
- You expect massive scale (e.g., millions of users, IoT, gaming)
- High scalability: Designed to scale horizontally across servers
XXX
ACID (Atomicity, Consistency, Isolation, Durability) transactions
- A (Atomicity): A transaction is all or nothing — if one part fails, the entire thing rolls back.
- C (Consistency): The database must move from one valid state to another — rules and constraints are respected.
- I (Isolation): Transactions don't interfere with each other — even when run at the same time.
- D (Durability): Once a transaction is committed, the data is permanently saved, even if the system crashes.
ACID-Example
Let’s say you’re transferring $100 from Account A to Account B.
- Subtract $100 from Account A
- Add $100 to Account B
For it to be an ACID-compliant transaction, both steps must happen together, or neither should.
Here’s how each ACID property applies:
- Atomicity: If step 1 succeeds but step 2 fails — rollback step 1.
- Consistency: The total balance in the system must remain the same.
- Isolation: Another transfer happening at the same time won't mess this one up.
- Durability: Even if the server crashes right after the transfer — the change will persist.
In AWS Context:
- RDS: Fully supports ACID across all supported engines.
- DynamoDB: Supports transactional APIs, but not as flexible as RDS for complex multi-table transactions.