Tag Archives: Amazon AWS

Amazon AWS – SNS – Simple Notification Service

Amazon AWS, Others September 21, 2013

Basic information about Amazon SNS Service:

 

AWS Free Tier availability:

  • 1 million Mobile Push Notifications
  • 100 SMS
  • 1,000 email/email-JSON
  • 100,000 HTTP/s
  • unlimited deliveries to SQS Queues

 

Developer Resources:

 

Features:

  • SNS lets you push messages to mobile devices or distributed services, via API or an easy-to-use management console.
  • you can publish a message once, and deliver it one or more times.
  • you can choose to direct unique messages to individual Apple, Google or Amazon devices, or broadcast deliveries to many mobile devices with a single publish request.
  • SNS allows you to group multiple recipients using topics. A topic is an “access point” for allowing recipients to dynamically subscribe for identical copies of the same notification. One topic can support deliveries to multiple endpoint types — for example, you can group together iOS, Android and SMS recipients. When you publish once to a topic, SNS delivers appropriately formatted copies of your message to each subscriber

 

 

 

Resources:

Amazon AWS – EBS – Elastic Block Store

Amazon AWS, Others September 21, 2013

Basic information about Amazon EBS Service:

 

AWS Free Tier availability:

  • 30GB of Storage,
  • 2 million I/Os,
  • 1GB of snapshot storage

 

Features:

  • storage volumes from 1 GB to 1 TB that can be mounted as devices by Amazon EC2 instances.
  • multiple volumes can be mounted to the same instance.
  • you can provision a specific level of I/O performance if desired, by choosing a Provisioned IOPS volume
  • storage volumes behave like raw, unformatted block devices, with user supplied device names and a block device interface.
  • you can create a file system on top of Amazon EBS volumes, or use them in any other way you would use a block device (like a hard drive).
  • they are placed in a specific Availability Zone, and can then be attached to instances also in that same Availability Zone.
  • each storage volume is automatically replicated within the same Availability Zone.
  • provides the ability to create point-in-time snapshots of volumes, which are persisted to Amazon S3. These snapshots can be used as the starting point for new Amazon EBS volumes, and protect data for long-term durability. The same snapshot can be used to instantiate as many volumes as you wish. These snapshots can be copied across AWS regions, making it easier to leverage multiple AWS regions for geographical expansion, data center migration and disaster recovery.
  • AWS also enables you to create new volumes from AWS hosted public data sets.
  • CloudWatch exposes performance metrics for EBS volumes, giving insight into bandwidth, throughput, latency, and queue depth
  • possible access to metrics through API

 

Volume Performance:

  • EBS provides two volume types: Standard volumes and Provisioned IOPS volumes. They differ in performance characteristics and price, allowing a user to tailor storage performance and cost to the needs of your applications. You can attach and stripe across multiple volumes of either type to increase the I/O performance available to your Amazon EC2 applications.
  • Standard volumes offer storage for applications with moderate or bursty I/O requirements. Standard volumes deliver approximately 100 IOPS on average with a best effort ability to burst to hundreds of IOPS. Standard volumes are also well suited for use as boot volumes, where the burst capability provides fast instance start-up times.
  • Provisioned IOPS volumes are designed to deliver predictable, high performance for I/O intensive workloads such as databases. With Provisioned IOPS, you specify an IOPS rate when creating a volume, and then Amazon EBS provisions that rate for the lifetime of the volume. Amazon EBS currently supports up to 4000 IOPS per Provisioned IOPS volume. You can stripe multiple volumes together to deliver thousands of IOPS per Amazon EC2 instance to your application.
  • To enable EC2 instances to fully utilize the IOPS provisioned on an EBS volume, you can launch selected instance types as “EBS-Optimized” instances. EBS-optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS, with options between 500 Mbps and 1000 Mbps depending on the instance type used. When attached to EBS-Optimized instances, Provisioned IOPS volumes are designed to deliver within 10% of the provisioned IOPS performance 99.9% of the time.

 

Volume Durability:

  • EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component.
  • The durability of your volume depends both on the size of your volume and the percentage of the data that has changed since your last snapshot. As an example, volumes that operate with 20 GB or less of modified data since their most recent Amazon EBS snapshot can expect an annual failure rate (AFR) of between 0.1% – 0.5%, where failure refers to a complete loss of the volume. This compares with commodity hard disks that will typically fail with an AFR of around 4%, making EBS volumes 10 times more reliable than typical commodity disk drives.
  • Because Amazon EBS servers are replicated within a single Availability Zone, mirroring data across multiple Amazon EBS volumes in the same Availability Zone will not significantly improve volume durability. However, for those interested in even more durability, EBS provides the ability to create point-in-time consistent snapshots of your volumes that are then stored in Amazon S3, and automatically replicated across multiple Availability Zones. So, taking frequent snapshots of your volume is a convenient and cost effective way to increase the long term durability of your data. In the unlikely event that your Amazon EBS volume does fail, all snapshots of that volume will remain intact, and will allow you to recreate your volume from the last snapshot point

 

Snapshots:

  • EBS provides the ability to back up point-in-time snapshots of your data to Amazon S3 for durable recovery.
  • snapshots are incremental backups, meaning that only the blocks on the device that have changed since your last snapshot will be saved.
  • If you have a device with 100 GBs of data, but only 5 GBs of data has changed since your last snapshot, only the 5 additional GBs of snapshot data will be stored back to Amazon S3.
  • Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed.
  • regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume.
  • the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.
  • Snapshots can also be used to instantiate multiple new volumes, expand the size of a volume or move volumes across Availability Zones.
  • When a new volume is created, there is the option to create it based on an existing Amazon S3 snapshot. In that scenario, the new volume begins as an exact replica of the original volume. By optionally specifying a different volume size or a different Availability Zone, this functionality can be used as a way to increase the size of an existing volume or to create duplicate volumes in new Availability Zones. If you choose to use snapshots to resize your volume, you need to be sure your file system or application supports resizing a device.
  • New volumes created from existing Amazon S3 snapshots load lazily in the background. This means that once a volume is created from a snapshot, there is no need to wait for all of the data to transfer from Amazon S3 to your Amazon EBS volume before your attached instance can start accessing the volume and all of its data. If your instance accesses a piece of data which hasn’t yet been loaded, the volume will immediately download the requested data from Amazon S3, and then will continue loading the rest of the volume’s data in the background.
  • EBS shared snapshots allows to share these snapshots. With this feature, users that you have authorized can quickly use EBS shared snapshots as the basis for creating their own Amazon EBS volumes.
  • If you choose, you can also make your data available publicly to all AWS users. Users to whom you have granted access can create their own EBS volumes based on your snapshot; your original snapshot will remain intact.
  • Amazon EBS also provides the ability to copy snapshots across AWS regions, making it easier to leverage multiple AWS regions for geographical expansion, data center migration and disaster recovery.
  • Customers can copy any accessible Snapshots that are in the “available” status. This includes Snapshots that they created, Snapshots that were shared with them, and also Snapshots from the AWS Marketplace, VM Import/Export, and Storage Gateway

 

 

 

Resources:

Amazon AWS – DynamoDB – advanced NoSQL

Amazon AWS, Databases, NoSQL, Others September 20, 2013

Basic information about Amazon DynamoDB Service:

 

AWS Free Tier availability:

  • 100MB of Storage,
  • 5 Units of Write Capacity,
  • 10 Units of Read Capacity
  • up to 40 million free operations each month with eventually consistent reads, or 25 million operations each month with strictly consistent reads

 

Developer Resources:

 

Features:

  • Local secondary indexes
  • SSD-storage
  • automatic 3-way replication
  • you pay a flat, hourly rate based on the capacity you reserve
  • when creating or updating tables, you specify how much capacity you wish to reserve for reads and writes

 

Limits:

  • Table name: allowed characters are a-z, A-Z, 0-9, ‘_’ (underscore), ‘-‘ (dash), and ‘.’ (dot). Names can be between 3 and 255 characters long.
  • Local secondary index name: allowed characters are a-z, A-Z, 0-9, ‘_’ (underscore), ‘-‘ (dash), and ‘.’ (dot). Names can be between 3 and 255 characters long.
  • Table size: No practical limit in number of bytes or items
  • Tables per account: 256 per region (default). Increase can be requested.
  • Hash or hash-and-range primary key: No practical limit.
  • Number of hash key values: No practical limit.
  • Hash-and-range primary key: No practical limit for non-indexed tables (otherwise total sizes of all table and index items cannot exceed 10 GB)
  • Number of range keys per hash value: No practical limit for non-indexed tables (otherwise total sizes of all table and index items cannot exceed 10 GB)
  • Provisioned throughput capacity unit sizes: One read capacity unit = one strongly consistent read per second, or two eventually consistent reads per second, for items up 4 KB in size. One write capacity unit = one write per second, for items up to 1 KB in size.
  • Provisioned throughput minimum per table: 1 read capacity unit and 1 write capacity unit
  • Provisioned throughput limits: can request an increase but default values are:
    • US East (Northern Virginia) Region:
      • Per table – 40,000 read capacity units or 40,000 write capacity units
      • Per account – 80,000 read capacity units or 80,000 write capacity units
    • All Other Regions:
      • Per table – 10,000 read capacity units or 10,000 write capacity units
      • Per account – 20,000 read capacity units or 20,000 write capacity units
  • UpdateTable: Limits when increasing provisioned throughput: You can call UpdateTable as often as necessary to increase provisioned throughput. You can increase ReadCapacityUnits or WriteCapacityUnits for a table, subject to these conditions:
    • You can call the UpdateTable API to increase ReadCapacityUnits or WriteCapacityUnits (or both), up to twice their current values.
    • The new provisioned throughput settings do not take effect until the UpdateTable operation is complete.
    • You can call UpdateTable multiple times, until you reach the desired throughput capacity for your table.
  • UpdateTable: Limits when decreasing provisioned throughput: You can reduce the provisioned throughput on a table no more than four times in a single UTC calendar day. These reductions can be any of the following operations:
    • Decrease ReadCapacityUnits.
    • Decrease WriteCapacityUnits.
    • Decrease both ReadCapacityUnits and WriteCapacityUnits in a single request. This counts as one of your allowed reductions for the day.
  • Maximum concurrent Control Plane API requests (includes cumulative number of tables in the CREATING, UPDATING or DELETING state): In general, you can have up to 10 of these requests running concurrently. The only exception is when you are CREATING a table and you have defined a local secondary index on that table. You can only have one such request running at a time.
  • Maximum number of local secondary indexes per table: You can define up to 5 local secondary indexes per table.
  • Maximum number of projected attributes per table (local secondary indexes only): You can project a total of up to 20 attributes into all of a table’s local secondary indexes. This only applies to user-specified projected attributes.

    In a CreateTable operation, if you specify a ProjectionType of INCLUDE, the total count of attributes specified in NonKeyAttributes, summed across all of the local secondary indexes, must not exceed 20. If you project the same attribute name into two different indexes, this counts as two distinct attributes when determining the total.

    This limit does not apply for indexes with a ProjectionType of KEYS_ONLY or ALL.

  • Attribute name lengths: The following attribute names are length-restricted:
    • Primary key attribute names.
    • The names of any user-specified projected attributes (applicable only to local secondary indexes). In a CreateTableoperation, if you specify a ProjectionType of INCLUDE, then the names of the attributes in the NonKeyAttributes parameter are length-restricted. The KEYS_ONLY and ALL projection types are not affected.
    • For any of the attribute names listed above, the name must be between 1 and 255 characters long, inclusive. The name can be any UTF-8 encodable character, but the total size of the UTF-8 string after encoding cannot exceed 255 bytes.
  • Item size: Cannot exceed 64 KB which includes both attribute name binary length (UTF-8 length) and attribute value lengths (again binary length). The attribute name counts towards the size limit. For example, consider an item with two attributes: one attribute named “shirt-color” with value “R” and another attribute named “shirt-size” with value “M”. The total size of that item is 23 bytes. These limits apply to items stored in tables, and also to items in local secondary indexes.
  • Attribute values: cannot be null or empty
  • Attribute name-value pairs per item: The cumulative size of attributes per item must be under 64 KB
  • Hash primary key attribute value: 2048 bytes
  • Range primary key attribute value: 1024 bytes
  • String: All strings must conform to the UTF-8 encoding. Since UTF-8 is a variable width encoding, string sizes are determined using the UTF-8 bytes.
  • Number: A number can have up to 38 digits precision and can be between 10^-128 to 10^+126.
  • Maximum number of values in an attribute set: No practical limit on the quantity of values, as long as the item containing the values fits within the 64 KB item limit.
  • BatchGetItem item maximum per operation: Up to 100 items retrieved, with the request size not exceeding 1 MB.
  • BatchWriteItem item maximum per operation: Up to 25 items put or delete operations, with the request size not exceeding 1 MB.
  • Query: Result set limited to 1 MB per API call. You can use the LastEvaluatedKey from the query response to retrieve more results.
  • Scan: Scanned data set size maximum is 1 MB per API call. You can use the LastEvaluatedKey from the scan response to retrieve more results

 

 

 

Resources: