Unit 6: AWS Storage and Database Services - Subjective Questions

Amazon EBS is a block-level storage service designed primarily for use with Amazon EC2 instances. An EBS volume behaves like a virtual hard disk that can be attached to an instance.

Key characteristics include:

• Persistent storage: Data remains available after an EC2 instance is stopped or restarted.
• Block-level access: Applications can directly read and write fixed-size blocks of data.
• Availability Zone scope: An EBS volume is created in a specific Availability Zone and is normally attached to an instance in the same zone.
• Flexible volume types: AWS provides SSD-backed and HDD-backed volumes for different performance and cost requirements.
• Snapshots: Point-in-time backups of volumes can be stored in Amazon S3 through the EBS snapshot service.
• Security: Volumes and snapshots can be encrypted using AWS Key Management Service.

EBS is commonly used for operating system disks, relational databases, enterprise applications, and workloads requiring low-latency persistent storage.

Amazon EBS volume types are optimized for different workload patterns:

• General Purpose SSD (gp3 and gp2): Suitable for boot volumes, development environments, virtual desktops, and general applications. gp3 allows performance to be provisioned independently of capacity.
• Provisioned IOPS SSD (io2 and io1): Designed for critical databases and applications requiring consistently high IOPS and low latency. io2 provides higher durability and performance capabilities.
• Throughput Optimized HDD (st1): Appropriate for frequently accessed, throughput-intensive data such as big-data processing, log processing, and data warehouses.
• Cold HDD (sc1): Intended for infrequently accessed data where low storage cost is more important than performance.

Selection should consider:

• Required IOPS, throughput, and latency
• Whether access is random or sequential
• Workload criticality and durability requirements
• Volume capacity
• Cost limits

SSD volumes are generally preferred for random transactional workloads, while HDD volumes are better for large sequential workloads.

An EBS snapshot is a point-in-time backup of an EBS volume. Snapshots are managed by AWS and stored redundantly through the Amazon S3 infrastructure, although users do not access them as ordinary S3 objects.

Important properties include:

• The first snapshot contains all used blocks of the volume.
• Later snapshots are incremental, storing only blocks changed since the previous snapshot.
• Each snapshot contains the information required to restore the volume at that point in time.
• A new EBS volume can be created from a snapshot.
• Snapshots can be copied across AWS Regions for disaster recovery or migration.
• Snapshots can be shared with other AWS accounts when permissions and encryption settings permit it.
• Lifecycle policies can automate snapshot creation and deletion.

For application-consistent backups, pending writes should be flushed and databases should be paused or use their own backup mechanisms. Snapshot encryption and access permissions must also be managed carefully.

Amazon S3 is a regional object storage service. It stores data as objects inside buckets. Each object includes data, a unique key, and optional metadata.

Main features include:

• Extremely high durability through redundant storage across multiple facilities
• Virtually unlimited storage capacity
• Access through REST APIs, SDKs, the AWS CLI, and the AWS Management Console
• Versioning for retaining multiple versions of an object
• Lifecycle rules for transitioning or expiring objects
• Event notifications for triggering automated processing
• Replication within or across AWS Regions
• Encryption in transit and at rest
• Fine-grained authorization using IAM policies, bucket policies, and access points
• Strong read-after-write consistency for object operations

Typical use cases are static website assets, backups, data lakes, software distribution, media storage, log archives, analytics input, and disaster-recovery copies. Unlike EBS, S3 does not expose a traditional block device or file system.

Amazon S3 provides multiple storage classes:

• S3 Standard: For frequently accessed data requiring low latency and high availability.
• S3 Intelligent-Tiering: Automatically moves objects among access tiers when access patterns are unknown or changing.
• S3 Standard-Infrequent Access: For infrequently accessed data that still requires rapid retrieval and multi-Availability Zone resilience.
• S3 One Zone-Infrequent Access: Stores data in one Availability Zone and is suitable for reproducible or secondary data.
• S3 Glacier Instant Retrieval: For archival data requiring millisecond retrieval.
• S3 Glacier Flexible Retrieval: For archives that can tolerate retrieval times ranging from minutes to hours.
• S3 Glacier Deep Archive: For long-term retention with retrieval generally measured in hours.

Selection depends on access frequency, retrieval-time objectives, availability requirements, minimum storage duration, object size, retrieval charges, and whether the data can be recreated. Lifecycle policies can automatically transition objects as their access patterns change.

Amazon S3 provides several complementary data-protection mechanisms:

• Versioning: Preserves multiple versions of an object and helps recover from accidental overwrites or deletions.
• Encryption in transit: HTTPS protects data while it travels between clients and S3.
• Server-side encryption: AWS can manage encryption through S3-managed keys or AWS KMS keys. Customers may also provide keys for supported workflows.
• IAM policies: Control what authenticated users and roles may do.
• Bucket policies: Define resource-based permissions for a bucket and its objects.
• S3 Block Public Access: Prevents accidental public exposure at account or bucket level.
• Replication: Same-Region Replication and Cross-Region Replication automatically copy eligible objects to another bucket.
• Object Lock: Supports write-once-read-many retention and legal holds.
• Logging and auditing: AWS CloudTrail and S3 access logging can record relevant activity.

These controls should be combined using least privilege, appropriate retention rules, and tested recovery procedures.

Amazon EFS is a managed, elastic file-storage service that provides a shared file system using the Network File System protocol. Multiple supported compute resources can mount the same EFS file system concurrently.

Its main characteristics are:

• Elastic capacity: Storage grows and shrinks as files are added or removed.
• Shared access: Multiple EC2 instances and containerized workloads can access the same files.
• Regional resilience: Standard EFS file systems store data across multiple Availability Zones.
• File semantics: It supports directories, file permissions, and familiar file-system operations.
• Managed operation: AWS handles infrastructure capacity and availability.
• Security: Access can be controlled through security groups, IAM authorization, POSIX permissions, access points, and encryption.
• Performance options: Throughput and performance modes support different workload requirements.

EFS is suitable for content management, shared application data, web-serving farms, development environments, machine-learning datasets, and container storage.

The three services expose different storage models:

• Amazon EBS: Block storage presented as a virtual disk. It is normally attached to EC2 resources in one Availability Zone and is well suited to boot volumes, transactional databases, and low-latency applications.
• Amazon S3: Object storage accessed through APIs. It is regional, massively scalable, and appropriate for backups, static content, data lakes, logs, and media objects.
• Amazon EFS: Shared file storage accessed using NFS. Standard file systems can span multiple Availability Zones and support concurrent access by multiple compute resources.

Key distinctions are:

• EBS supports block-level operations and file systems created by the customer.
• EFS directly provides shared hierarchical file and directory semantics.
• S3 organizes data as objects and does not behave like a conventional mounted disk.
• EBS generally offers low latency for a specific compute workload.
• EFS is selected when shared file access is important.
• S3 is selected for scalable object storage, durability, and API-based access.

The correct choice depends primarily on application interfaces rather than storage capacity alone.

Amazon S3 Glacier refers to S3 archival storage classes designed for long-term, low-cost retention. They trade immediate or frequent access for lower storage cost.

• S3 Glacier Instant Retrieval: Delivers millisecond access and is suitable for archives that are rarely accessed but must be available immediately, such as medical images or media archives.
• S3 Glacier Flexible Retrieval: Supports retrieval options ranging from minutes to hours and is suitable for backups and archives without an immediate-access requirement.
• S3 Glacier Deep Archive: Provides the lowest-cost long-term storage for data accessed very rarely, with retrieval generally taking hours.

Important considerations include minimum storage duration, retrieval fees, retrieval time, and early-deletion charges. Organizations commonly use lifecycle policies to move older S3 objects into Glacier classes. These classes are appropriate for regulatory records, historical data, long-term backups, and digital preservation.

A cost-effective archival strategy begins by classifying data according to business value, access frequency, retention period, and recovery objectives.

A typical approach is:

1. Store newly created and frequently accessed objects in S3 Standard.
2. Use lifecycle rules to transition aging data to S3 Standard-IA or S3 Intelligent-Tiering.
3. Move long-lived archives to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive when slower recovery is acceptable.
4. Configure expiration rules to delete objects after legal and business retention periods end.
5. Use versioning-aware rules to manage noncurrent object versions and incomplete multipart uploads.
6. Apply Object Lock where immutable retention is required.
7. Test restore procedures and document expected retrieval times.

Cost analysis must include storage charges, transition requests, retrieval requests, retrieved data volume, minimum storage durations, and early-deletion charges. The cheapest storage class is not necessarily the least expensive overall when objects are retrieved frequently.

Storage selection should begin with the interface required by the application:

• Choose EBS block storage when an EC2-hosted application requires a disk device, low-latency random I/O, or a database volume.
• Choose EFS file storage when multiple resources need concurrent access to a shared directory hierarchy through NFS.
• Choose S3 object storage when applications can use API-based access and require massive scalability, high durability, metadata, lifecycle management, or data-lake integration.
• Choose S3 Glacier classes for long-term data whose retrieval frequency and recovery-time requirements permit archival storage.

The decision should also evaluate:

• Latency, IOPS, throughput, and concurrency
• Availability Zone and Region scope
• Durability and availability requirements
• Access frequency and retrieval time
• Backup and disaster-recovery requirements
• Security, compliance, and immutability
• Expected growth and capacity management
• Storage, request, transfer, and retrieval costs

A workload may combine services, such as EBS for a database, EFS for shared files, and S3 Glacier for backups.

Amazon RDS is a managed service for deploying, operating, and scaling relational databases in AWS. It supports database engines such as MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server, and Amazon Aurora.

RDS manages or simplifies:

• Infrastructure provisioning
• Operating system and supported database software maintenance
• Automated backups and point-in-time recovery
• Database monitoring and metrics
• Storage allocation and scaling options
• High-availability deployment through Multi-AZ configurations
• Replacement of failed infrastructure
• Read replica creation for supported engines
• Encryption integration and network isolation through Amazon VPC

Customers remain responsible for database design, schema management, query optimization, user privileges, data governance, and selecting appropriate instance and storage configurations. RDS reduces operational effort without removing the need for sound database administration and application design.

Multi-AZ deployments and read replicas solve different problems:

• Multi-AZ is primarily a high-availability and disaster-recovery feature. RDS maintains a synchronized standby database in another Availability Zone. If the primary database or infrastructure fails, RDS can perform an automatic failover. The standby in a traditional Multi-AZ database instance deployment does not normally serve application read traffic.
• Read replicas are primarily used to scale read-heavy workloads. They receive replicated data from the source database and can serve read-only queries. Replication is commonly asynchronous, so replicas may temporarily lag behind the source.

A read replica can also support reporting or be promoted into an independent database, but promotion is not the same as automatic Multi-AZ failover. Production systems may use both: Multi-AZ for availability and read replicas for read scalability.

Amazon RDS provides managed operational capabilities in four major areas:

• Backup and recovery: Automated backups support point-in-time recovery within the configured retention period. Manual snapshots can be retained until explicitly deleted and copied to other Regions.
• Scaling: Customers can vertically scale by changing the database instance class, increase allocated storage, use storage autoscaling, and create read replicas for supported engines.
• Availability: Multi-AZ deployments maintain database capacity in separate Availability Zones and support managed failover.
• Security: RDS databases can run in private VPC subnets, use security groups, encrypt storage and snapshots with AWS KMS, protect network traffic with TLS, and integrate with IAM for selected authentication and management functions.
• Monitoring: Amazon CloudWatch metrics, database logs, Enhanced Monitoring, and Performance Insights help identify resource and query bottlenecks.

A complete design must align retention settings, recovery objectives, maintenance windows, access controls, and scaling choices with application requirements.

Amazon DynamoDB is a fully managed, serverless NoSQL database service designed for low-latency access at virtually any scale.

Its core concepts are:

• Data is stored in tables containing items.
• An item is a collection of attributes.
• A primary key is either a simple partition key or a composite partition key and sort key.
• The partition key determines how data is distributed internally.
• The sort key allows related items with the same partition key to be ordered and queried together.
• Secondary indexes provide alternative query keys.

DynamoDB supports on-demand and provisioned capacity modes, automatic scaling, encryption, backups, point-in-time recovery, streams, transactions, and global tables. It is commonly used for shopping carts, user profiles, gaming state, session data, Internet of Things workloads, and high-scale web or mobile applications.

DynamoDB performance depends heavily on data modeling around known access patterns.

• A well-designed partition key distributes requests and data across many partition-key values. A low-cardinality or unusually popular key can create concentrated traffic and limit effective scalability.
• A sort key groups related items and enables range conditions, prefix queries, and ordered retrieval within a partition-key value.
• A global secondary index can use different partition and sort keys from the base table, supporting additional query patterns.
• A local secondary index uses the same partition key as the base table but a different sort key and must be defined when the table is created.
• On-demand capacity automatically handles changing traffic and charges per request, making it suitable for unpredictable workloads.
• Provisioned capacity specifies read and write capacity and can use auto scaling, making it useful for predictable workloads and cost optimization.

Good design starts with required queries, avoids scans where possible, distributes high-volume traffic, and selects indexes carefully because indexes consume storage and write capacity.

Amazon RDS and Amazon DynamoDB use different database models:

• RDS is relational and supports SQL, predefined schemas, joins, constraints, and familiar relational transactions.
• DynamoDB is a NoSQL key-value and document database optimized around primary-key access and predefined access patterns.
• RDS scales through instance, storage, and read-replica changes, while DynamoDB automatically distributes data and request processing across managed infrastructure.
• RDS is suitable for complex relationships, reporting queries, enterprise applications, and systems requiring broad SQL compatibility.
• DynamoDB is suitable for massive request volumes, predictable key-based queries, serverless applications, user sessions, carts, gaming state, and Internet of Things data.

RDS is generally selected when relational integrity and flexible SQL queries are central. DynamoDB is selected when consistent low latency, minimal infrastructure management, and horizontal scalability are more important. The choice should be driven by data relationships and access patterns rather than popularity alone.

Amazon Redshift is a managed cloud data warehouse designed for large-scale analytics and business intelligence. It is optimized for complex queries over large volumes of structured and semi-structured data rather than frequent single-row transactions.

Its analytical capabilities include:

• Columnar storage, which reads only the columns required by a query and improves compression
• Massively parallel processing, which distributes query work across compute resources
• SQL interfaces compatible with many reporting and business-intelligence tools
• Integration with S3-based data lakes
• Redshift Spectrum for querying supported data in S3 without loading all of it into warehouse tables
• Workload management, monitoring, concurrency, and scaling features
• Managed and serverless deployment options

Typical use cases include enterprise reporting, trend analysis, log analytics, customer intelligence, and combining data from operational systems. It is not normally a replacement for an online transaction-processing database.

Amazon Redshift and Amazon RDS are optimized for different workload categories:

• Redshift is designed for online analytical processing. It performs aggregations and scans over large datasets using columnar storage and parallel processing.
• RDS is generally designed for online transaction processing. It efficiently handles inserts, updates, deletes, constraints, and short queries involving a limited number of rows.
• Redshift data models often use fact and dimension tables, denormalization, and warehouse-oriented design.
• RDS applications commonly use normalized schemas to preserve integrity and reduce update anomalies.
• Redshift integrates with S3 data lakes and business-intelligence systems.
• RDS supports operational applications such as order processing, inventory, and financial transactions.

A common architecture uses RDS as the operational source and periodically loads or replicates data into Redshift for analytics. Running large analytical scans directly against the production RDS database can degrade transactional performance.

Amazon Aurora is an AWS-designed relational database engine available through Amazon RDS. It is compatible with MySQL or PostgreSQL, allowing many existing applications and tools to work with limited changes.

Important features include:

• A distributed storage layer that replicates data across multiple Availability Zones
• Storage that automatically grows within service limits
• Separation of database compute from the shared cluster storage layer
• Support for multiple Aurora Replicas to scale reads and improve availability
• Managed failover to an eligible replica
• Continuous backup to Amazon S3 and point-in-time recovery
• Cluster endpoints that direct connections to writers or readers
• Serverless options for workloads that benefit from automatically adjusted capacity
• Global Database capabilities for cross-Region reads and disaster-recovery designs

Compared with conventional RDS engines, Aurora uses an AWS-built distributed storage architecture rather than relying solely on the traditional engine storage design. It is suitable for demanding relational workloads requiring managed availability, read scalability, and MySQL or PostgreSQL compatibility.