Amazon Elastic Compute Cloud ( Amazon EC2 )

 

• A Linux-based/Windows-based/Mac-based virtual server that you can provision.
• You are limited to running On-Demand Instances per your vCPU-based On-Demand Instance limit, purchasing 20 Reserved Instances, and requesting Spot Instances per your dynamic Spot limit per region.

Features

• The AWS Nitro System is the underlying platform of the next generation of EC2 instances. Traditionally, hypervisors protect the physical hardware and bios, virtualize the CPU, storage, networking, and provide a rich set of management capabilities. With the Nitro System, these functions are offloaded to dedicated hardware and software, thereby reducing costs of your instances in the process. Hence, the Nitro Hypervisor delivers performance that is indistinguishable from bare metal and performs better than its predecessor: the Xen Hypervisor.
• Server environments called instances.
• Package OS and additional installations in a reusable template called Amazon Machine Images.
• Various configurations of CPU, memory, storage, and networking capacity for your instances, known as instance types
  • t-type and m-type for general purpose
  • c-type for compute optimized
  • r-type, x-type and z-type for memory optimized
  • d-type, h-type and i-type for storage optimized
  • f-type, g-type and p-type for accelerated computing

• Secure login information for your instances using key pairs
• Storage volumes for temporary data that are deleted when you STOP or TERMINATE your instance, known as instance store volumes. Take note that you can stop an EBS-backed instance but not an Instance Store-backed instance. You can only either start or terminate an Instance Store-backed instance.
• Persistent storage volumes for your data using Elastic Block Store volumes (see aws storage services).
• Multiple physical locations for deploying your resources, such as instances and EBS volumes, known as regions and Availability Zones (see AWS overview).
• A firewall that enables you to specify the protocols, ports, and source IP ranges that can reach your instances using security groups (see aws networking and content delivery).
• Static IPv4 addresses for dynamic cloud computing, known as Elastic IP addresses (see aws networking and content delivery).
• Metadata, known as tags, that you can create and assign to your EC2 resources
• Virtual networks you can create that are logically isolated from the rest of the AWS cloud, and that you can optionally connect to your own network, known as virtual private clouds or VPCs (see aws networking and content delivery).
• Add a script that will be run on instance boot called user-data.
• Host Recovery for Amazon EC2 automatically restarts your instances on a new host in the event of an unexpected hardware failure on a Dedicated Host.
• EC2 Hibernation is available for On-Demand and Reserved Instances running on freshly launched M3, M4, M5, C3, C4, C5, R3, R4, and R5 instances running Amazon Linux and Ubuntu 18.04 LTS. You can enable hibernation for your EBS-backed instances at launch. You can then hibernate and resume your instances through the AWS Management Console, or though the AWS SDK and CLI using the existing stop-instances and start-instances commands. Hibernation requires an EC2 instance to be an encrypted EBS-backed instance.

Instance states

• Start – run your instance normally. You are continuously billed while your instance is running.
• Stop – is just a normal instance shutdown. You may restart it again anytime. All EBS volumes remain attached, but data in instance store volumes are deleted. You won’t be charged for usage while instance is stopped. You can attach or detach EBS volumes. You can also create an AMI from the instance, and change the kernel, RAM disk, and instance type while in this state.
• Hibernate – When an instance is hibernated, it writes the in-memory state to a file in the root EBS volume and then shuts itself down. The AMI used to launch the instance must be encrypted, and also the root EBS volume of the instance. The encryption ensures proper protection for sensitive data when it is copied from memory to the EBS volume. While the instance is in hibernation, you pay only for the EBS volumes and Elastic IP Addresses attached to it; there are no hourly charges.
• Terminate – instance performs a normal shutdown and gets deleted. You won’t be able to restart an instance once you terminate it. The root device volume is deleted by default, but any attached EBS volumes are preserved by default. Data in instance store volumes are deleted.
• To prevent accidental termination, enable termination protection.

Root Device Volumes

• The root device volume contains the image used to boot the instance.
• Instance Store-backed Instances
  • Any data on the instance store volumes is deleted when the instance is terminated (instance store-backed instances do not support the Stop action) or if it fails (such as if an underlying drive has issues).
  • You should also back up critical data from your instance store volumes to persistent storage on a regular basis.

• Amazon EBS-backed Instances
  • An Amazon EBS-backed instance can be stopped and later restarted without affecting data stored in the attached volumes.
  • When in a stopped state, you can modify the properties of the instance, change its size, or update the kernel it is using, or you can attach your root volume to a different running instance for debugging or any other purpose.
  • By default, the root device volume for an AMI backed by Amazon EBS is deleted when the instance terminates.
  • Previously, to launch an encrypted EBS-backed EC2 instance from an unencrypted AMI, you would first need to create an encrypted copy of the AMI and use that to launch the EC2 instance. Now, you can launch encrypted EBS-backed EC2 instances from unencrypted AMIs directly.

AMI

• Includes the following:
  • A template for the root volume for the instance (OS, application server, and applications)
  • Launch permissions that control which AWS accounts can use the AMI to launch instances
  • A block device mapping that specifies the volumes to attach to the instance when it’s launched

 

• Backed by Amazon EBS – root device for an instance launched from the AMI is an Amazon EBS volume. AMIs backed by Amazon EBS snapshots can use EBS encryption.
• Backed by Instance Store – root device for an instance launched from the AMI is an instance store volume created from a template stored in S3.

• You can copy AMIs to different regions.

Pricing

• On-Demand  – pay for the instances that you use by the second, with no long-term commitments or upfront payments.
• Reserved – make a low, one-time, up-front payment for an instance, reserve it for a one– or three-year term, and pay a significantly lower hourly rate for these instances. It has two offering classes: Standard and Convertible.
  • The Standard class provides the most significant discount but you can only modify some of its attributes during the term. It can also be sold in the Reserved Instance Marketplace.
  • The Convertible class provides a lower discount than Standard Reserved Instances, but can be exchanged for another Convertible Reserved Instance with different instance attributes. However, this one cannot be sold in the Reserved Instance Marketplace.

	Standard RI	Convertible RI
Terms (average discount off On-Demand)	1 year (40%) 3 years (60%)	1 year (31%) 3 years (54%)
Change Availability Zone, Instance size (for Linux OS), Networking type	Yes	Yes
Change instance families, operating system, tenancy, and payment option		Yes
Benefit from Price Reductions		Yes

• • When purchasing a Reserved Instance, you’ll need to determine its scope (regional or zonal).

	Regional RI	Zonal RI
Ability to Reserve Capacity	No	Yes
Availability Zone Flexibility	The discount is valid for instance usage in any Availability Zone within the specified Region.	The discount only applies to instance usage in the specified Availability Zone.
Instance Size Flexibility	The discount applies to instance usage within the instance family.	The discount only applies to instance usage for the specified instance type and size.
Queuing A Purchase	Yes	No

• Spot – request unused EC2 instances, which can lower your costs significantly. Spot Instances are available at up to a 90% discount compared to On-Demand prices.
  • A Spot Fleet is a collection of Spot Instances and optionally On-Demand Instances. The service attempts to launch the number of Spot Instances and On-Demand Instances to meet your specified target capacity. The request for Spot Instances is fulfilled if there is available capacity and the maximum price you specified in the request exceeds the current Spot price. The Spot Fleet also attempts to maintain its target capacity fleet if your Spot Instances are interrupted.
  • A Spot Capacity pool is a set of unused EC2 instances with the same instance type, operating system, Availability Zone, and network platform.
  • You can start and stop your Spot Instances backed by Amazon EBS at will.
  • You can modify instance types and weights for a running EC2 Fleet or Spot Fleet without having to recreate it.
  • Allocation strategy for Spot Instances
    • LowestPrice – The Spot Instances come from the pool with the lowest price. This is the default strategy.
    • Diversified – The Spot Instances are distributed across all pools.
    • CapacityOptimized – The Spot Instances come from the pool with optimal capacity for the number of instances that are launching.
    • InstancePoolsToUseCount – The Spot Instances are distributed across the number of Spot pools that you specify. This parameter is valid only when used in combination with the lowest Price.

• Spot – request unused EC2 instances, which can lower your costs significantly. Spot Instances are available at up to a 90% discount compared to On-Demand prices.
  • Spot Instances with a defined duration (also known as Spot blocks) are designed not to be interrupted and will run continuously for the duration you select. This makes them ideal for jobs that take a finite time to complete, such as batch processing, encoding and rendering, modeling and analysis, and continuous integration.
  • A Spot Fleet is a collection of Spot Instances and optionally On-Demand Instances. The service attempts to launch the number of Spot Instances and On-Demand Instances to meet your specified target capacity. The request for Spot Instances is fulfilled if there is available capacity and the maximum price you specified in the request exceeds the current Spot price. The Spot Fleet also attempts to maintain its target capacity fleet if your Spot Instances are interrupted.
  • A Spot Capacity pool is a set of unused EC2 instances with the same instance type, operating system, Availability Zone, and network platform.
  • You can start and stop your Spot Instances backed by Amazon EBS at will.
  • You can modify instance types and weights for a running EC2 Fleet or Spot Fleet without having to recreate it.
  • Allocation strategy for Spot Instances
    • LowestPrice – The Spot Instances come from the pool with the lowest price. This is the default strategy.
    • Diversified – The Spot Instances are distributed across all pools.
    • CapacityOptimized – The Spot Instances come from the pool with optimal capacity for the number of instances that are launching.
    • InstancePoolsToUseCount – The Spot Instances are distributed across the number of Spot pools that you specify. This parameter is valid only when used in combination with the lowest Price.

• Dedicated Hosts – pay for a physical host that is fully dedicated to running your instances, and bring your existing per-socket, per-core, or per-VM software licenses to reduce costs.
• Dedicated Instances – pay, by the hour, for instances that run on single-tenant hardware.
• On-Demand Capacity Reservations – reserve capacity for your Amazon EC2 instances in a specific Availability Zone for any duration.
  • Unlike Reserved instances, you don’t need to have one-year or three-year term commitment.
  • When you create a Capacity Reservation, you specify:
    • The Availability Zone in which to reserve the capacity
    • The number of instances for which to reserve capacity
    • The instance attributes, including the instance type, tenancy, and platform/OS
  • Your Savings Plans and regional Reserved Instances can be applied with your capacity reservations to receive discounts. Without these, your capacity reservations do not have billing discounts.
  • Capacity Reservations can’t be created in placement groups
  • Capacity Reservations can’t be used with Dedicated Hosts
  • Your capacity reservation usage metrics can be monitored in Amazon Cloudwatch.
• There is a data transfer charge when copying AMI from one region to another
• EBS pricing is different from instance pricing. (see AWS storage services)
• AWS imposes a small hourly charge if an Elastic IP address is not associated with a running instance, or if it is associated with a stopped instance or an unattached network interface.
• You are charged for any additional Elastic IP addresses associated with an instance.
• If data is transferred between these two instances, it is charged at “Data Transfer Out from EC2 to Another AWS Region” for the first instance and at “Data Transfer In from Another AWS Region” for the second instance.

Security

• Use IAM to control access to your instances (see AWS Security and Identity Service).
  • IAM policies
  • IAM roles
• Restrict access by only allowing trusted hosts or networks to access ports on your instance.
• A security group acts as a virtual firewall that controls the traffic for one or more instances.
  • Create different security groups to deal with instances that have different security requirements.
  • You can add rules to each security group that allow traffic to or from its associated instances.
  • You can modify the rules for a security group at any time.
  • New rules are automatically applied to all instances that are associated with the security group.
  • Evaluates all the rules from all the security groups that are associated with an instance to decide whether to allow traffic or not.
  • By default, security groups allow all outbound traffic.
  • Security group rules are always permissive; you can’t create rules that deny access.
  • Security groups are stateful
• If you don’t specify a security group when you launch an instance, the instance is automatically associated with the default security group for the VPC, which has the following rules:
  • Allows all inbound traffic from other instances associated with the default security group
  • Allows all outbound traffic from the instance.
• Disable password-based logins for instances launched from your AMI, since passwords can be cracked or found.
• You can replicate the network traffic from an EC2 instance within your Amazon VPC and forward that traffic to security and monitoring appliances for content inspection, threat monitoring, and troubleshooting.

Networking

• An Elastic IP address is a static IPv4 address designed for dynamic cloud computing. With it, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account.
• If you have not enabled auto-assign public IP address for your instance, you need to associate an Elastic IP address with your instance to enable communication with the internet.
• An Elastic IP address is for use in a specific region only.
• By default, all AWS accounts are limited to five (5) Elastic IP addresses per region, because public (IPv4) internet addresses are a scarce public resource.
• By default EC2 instances come only with a private IP when created in a private subnet, and public and private IP when created in a public subnet.
• An elastic network interface is a logical networking component in a VPC that represents a virtual network card, which directs traffic to your instance
• Every instance in a VPC has a default network interface, called the primary network interface (eth0). You cannot detach a primary network interface from an instance.
• You can create and attach additional network interfaces. The maximum number of network interfaces that you can use varies by instance type.
• You can attach a network interface to an instance in a different subnet as long as its within the same AZ
• Default interfaces are terminated with instance termination.
• Scale with EC2 Scaling Groups and distribute traffic among instances using Elastic Load Balancer.
• You can configure EC2 instances as bastion hosts (aka jump boxes) in order to access your VPC instances for management, using SSH or RDP protocols
• Enhanced Networking – It provides higher bandwidth, higher packet per second (PPS) performance, and consistent lower inter-instance latencies, which is being used in Placement Groups. It uses single root I/O virtualization (SR-IOV) to provide high-performance networking capabilities. SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization when compared to traditional virtualized network interfaces.
• Elastic Fabric Adapter (EFA) – This is a network device that you can attach to your EC2 instance to significantly accelerate machine learning applications and High Performance Computing (HPC). It empowers your computing resources to achieve the application performance of an on-premises HPC cluster, with the elasticity and scalability provided by AWS. Compared with a TCP transport that is traditionally used in cloud-based HPC systems, EFA provides lower and more consistent latency and higher throughput as it enhances the performance of inter-instance communication.

Monitoring

• EC2 items to monitor
  • CPU utilization, Network utilization, Disk performance, Disk Reads/Writes using EC2 metrics
  • Memory utilization, disk swap utilization, disk space utilization, page file utilization, log collection using a monitoring agent/CloudWatch Logs
• Automated monitoring tools include:
  • System Status Checks – monitor the AWS systems required to use your instance to ensure they are working properly. These checks detect problems with your instance that require AWS involvement to repair.
  • Instance Status Checks – monitor the software and network configuration of your individual instance. These checks detect problems that require your involvement to repair.
  • Amazon CloudWatch Alarms – watch a single metric over a time period you specify, and perform one or more actions based on the value of the metric relative to a given threshold over a number of time periods.
  • Amazon CloudWatch Events – automate your AWS services and respond automatically to system events.
  • Amazon CloudWatch Logs – monitor, store, and access your log files from Amazon EC2 instances, AWS CloudTrail, or other sources.
• Monitor your EC2 instances with CloudWatch. By default, EC2 sends metric data to CloudWatch in 5-minute periods.
• You can also enable detailed monitoring to collect data in 1-minute periods.

Instance Metadata and User Data

• Instance metadata is data about your instance that you can use to configure or manage the running instance.
• Instance metadata and user data are not protected by cryptographic methods.
• View all categories of instance metadata from within a running instance at http://169.254.169.254/latest/meta-data/
• You can pass two types of user data to EC2: shell scripts and cloud-init directives.
• User data is limited to 16 KB.
• If you stop an instance, modify its user data, and start the instance, the updated user data is not executed when you start the instance.
• Retrieve user data from within a running instance at http://169.254.169.254/latest/user-data

Placement Groups

• You can launch or start instances in a placement group, which determines how instances are placed on underlying hardware.
  • Cluster – clusters instances into a low-latency group in a single Availability Zone. Recommended for applications that benefit from low network latency, high network throughput, or both, and if the majority of the network traffic is between the instances in the group.
  • Spread – spreads instances across underlying hardware. Recommended for applications that have a small number of critical instances that should be kept separate from each other. Note: A spread placement group can span multiple Availability Zones, and you can have a maximum of seven running instances per Availability Zone per group.
• Partition placement groups is an Amazon EC2 placement strategy that helps reduce the likelihood of correlated failures for large distributed and replicated workloads such as HDFS, HBase and Cassandra running on EC2.
• Partition placement groups spread EC2 instances across logical partitions and ensure that instances in different partitions do not share the same underlying hardware. In addition, partition placement groups offer visibility into the partitions and allow topology aware applications to use this information to make intelligent data replication decisions, increasing data availability and durability.

Rules

• The name you specify for a placement group must be unique within your AWS account for the region.
• You can’t merge placement groups.
• An instance can be launched in one placement group at a time; it cannot span multiple placement groups.
• Instances with a tenancy of host cannot be launched in placement groups.

Storage

• EBS (see AWS Storage Services)
  • Provides durable, block-level storage volumes that you can attach to a running instance.
  • Use as a primary storage device for data that requires frequent and granular updates.
  • To keep a backup copy of your data, create a snapshot of an EBS volume, which is stored in S3. You can create an EBS volume from a snapshot, and attach it to another instance.
• Instance Store
  • Provides temporary block-level storage for instances.
  • The data on an instance store volume persists only during the life of the associated instance; if you stop or terminate an instance, any data on instance store volumes is lost.

• Elastic File System (EFS) (see AWS Storage Services)
  • Provides scalable file storage for use with Amazon EC2. You can create an EFS file system and configure your instances to mount the file system.
  • You can use an EFS file system as a common data source for workloads and applications running on multiple instances.

• FSx Lustre and FSx for Windows File Server
  • Amazon FSx for Windows File Server is a fully-managed file storage built on Windows Server.
  • Amazon FSx for Lustre is a fully-managed file storage built on the world’s most popular high-performance file system, Lustre.
• S3 (see AWS Storage Services)
  • Provides access to reliable and inexpensive data storage infrastructure.
  • Storage for EBS snapshots and instance store-backed AMIs.

• Resources and Tagging

  • EC2 resources include images, instances, volumes, and snapshots. When you create a resource, AWS assigns the resource a unique resource ID.
  • Some resources can be used in all regions (global), and some resources are specific to the region or Availability Zone in which they reside.
    

Resource	Type	Description
AWS account	Global	You can use the same AWS account in all regions.
Key pairs	Global or Regional	The key pairs that you create using EC2 are tied to the region where you created them. You can create your own RSA key pair and upload it to the region in which you want to use it; therefore, you can make your key pair globally available by uploading it to each region.
Amazon EC2 resource identifiers	Regional	Each resource identifier, such as an AMI ID, instance ID, EBS volume ID, or EBS snapshot ID, is tied to its region and can be used only in the region where you created the resource.
User-supplied resource names	Regional	Each resource name, such as a security group name or key pair name, is tied to its region and can be used only in the region where you created the resource. Although you can create resources with the same name in multiple regions, they aren’t related to each other.
AMIs	Regional	An AMI is tied to the region where its files are located within S3. You can copy an AMI from one region to another.
Elastic IP addresses	Regional	An Elastic IP address is tied to a region and can be associated only with an instance in the same region.
Security groups	Regional	A security group is tied to a region and can be assigned only to instances in the same region. You can’t enable an instance to communicate with an instance outside its region using security group rules.
EBS snapshots	Regional	An EBS snapshot is tied to its region and can only be used to create volumes in the same region. You can copy a snapshot from one region to another.
EBS volumes	Availability Zone	An EBS volume is tied to its Availability Zone and can be attached only to instances in the same Availability Zone.
Instances	Availability Zone	An instance is tied to the Availability Zones in which you launched it. However, its instance ID is tied to the region.

• • You can optionally assign your own metadata to each resource with tags, which consists of a key and an optional value that you both define.

Backup and Restore vs Pilot Light vs Warm Standby vs Multi-site

 

Backup and Restore	Pilot Light
This DR plan provides the slowest system restoration after a DR event. You take frequent snapshots of your data such as those in Amazon EBS Volumes and Amazon RDS databases, and you store them in a durable and secure storage location such as Amazon S3. There are many ways for you to move data in and out of S3 Transfer over the network via S3 Transfer Acceleration Transfer over a dedicated network line using AWS Direct Connect Transfer using transport hardware such as AWS Snowball Edge and Snowmobile With S3 Glacier, you get to reduce a large portion of your costs compared to using S3 Standard, since Glacier is meant for long term archival storage which is perfect for backups. AWS Storage Gateway enables snapshots of your on-premises data volumes to be transparently copied into S3 for backup. Storage-cached volumes allow you to store your primary data in S3, but keep your frequently accessed data local for low-latency access. Gateway-VTL of AWS Storage Gateway serves as a replacement for traditional magnetic tape backup. You can quickly create local volumes or Amazon EBS volumes from snapshots in S3. You can create AMIs out of your EC2 instances which preserve the following: A template for the root volume for the instance (for example, an operating system, an application server, and applications) Launch permissions that control which AWS accounts can use the AMI to launch instances A block device mapping that specifies the volumes to attach to the instance when it’s launched Backup and restore is used in combination with other DR plans since it is crucial to always have a working backup of your system.	The pilot light method gives you a quicker recovery time than the backup-and-restore method because the core pieces of the system are already running and are continually kept up to date, but is not as fast as Warm Standby. You can maintain a pilot light by configuring and running the most critical core elements of your system in AWS. When the time comes for recovery, you can rapidly provision a full-scale production environment around the critical core. Pilot light is an example of active/passive failover configuration. Infrastructure elements for the pilot light itself typically include your database servers, which would be configured for data mirroring replication. Restoring the rest of the system includes utilizing EBS snapshots and EC2 AMIs that you should be regularly generating. Pilot light tends to be more costly than backup and restore since you leave a few core AWS resources running all the time. From a networking point of view, you have two main options for provisioning web servers: Use Elastic IP addresses, which can be pre-allocated and pre-identified, and associate them with your instances. Use Elastic Load Balancing (ELB) to distribute traffic to multiple instances. You would then update your DNS records to point at your EC2 instance or point to your load balancer using a CNAME. Consider redundancy especially at your data layer (enable multi-AZ, cluster sharding, etc). If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.
Warm Standby	Multi-site
This DR plan is faster in system restoration than performing Pilot Light after a DR event, but is not as fast as having a Multi-site System. Warm standby describes a DR scenario in which a scaled-down version of a fully functional environment is always running in the cloud. Since it is not only your core elements that are running all the time, warm standby is usually more costly than pilot light. Warm standby is another example of active/passive failover configuration. Servers can be left running in a minimum number of EC2 instances on the smallest sizes possible. Once failover occurs, quickly resize them and add scaling capabilities. It is best to place these instances behind a load balancer as well. For the data layer, the practice is similar to pilot light where a standby resource is present and changing data is constantly being replicated to the other. In the case of failure of the production system, the standby environment will be scaled up for production load , and DNS records will be changed to route all traffic to AWS. If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.	This DR plan is the fastest in system restoration during a DR event. Multi-site is a one-to-one copy of your infrastructure that is located and running in another region or AZ, known as an active-active configuration. Because of this, multi-site is the most expensive among all DR plans. Multi-site gives you the best RTO and RPO as no downtime is expected and little to no data loss should be experienced. In addition to recovery point options, there are various replication methods, such as synchronous and asynchronous methods. You can use a DNS service that supports weighted routing, such as Amazon Route 53, to route production traffic to different sites that deliver the same application or service. During failover, you can quickly increase compute capacity by using AWS Auto Scaling or by resizing your instances to a larger size. Multiple services in AWS such as RDS offer a multi-AZ feature which allows you to provision resources in a different location for a more fault-tolerant setup. If your data is constantly changing and failover occurs, you would have to reverse replicate your data in the DR site back to the primary site, so that any data updates received while the primary site was down can be replicated back, without the loss of data.

AWS Secrets Manager vs Systems Manager Parameter Store

 Managing the security of your applications is an integral part of any organization especially for infrastructures deployed in the cloud. One aspect of application security is how the parameters such as environment variables, database passwords, API keys, product keys, etc. are stored and retrieved. As a best practice, secret information should not be stored in plain text and not be embedded inside your source code. It is also recommended to set up an automated system to rotate passwords or keys regularly (which is easy to forget when you manage keys manually).

Managing and securing these types of data can be troublesome so Amazon provides the AWS Systems Manager Parameter Store and AWS Secrets Manager services for this purpose. Parameter Store and Secrets Manager are two distinct services but offer similar functionalities that allow you to centrally manage and secure your secret information. 

In this post, we’ll take a look at the similarities and differences between the two services to help you understand and choose what best fits your given security requirements. 

AWS Systems Manager Parameter Store

Parameter Store is part of the application management tools offered by the AWS Systems Manager (SSM) service. Parameter Store allows you to create key-value parameters to save your application configurations, custom environment variables, product keys, and credentials on a single interface. 

Parameter Store allows you to secure your data by encryption which is integrated with AWS KMS.

After you create your parameters in Parameter Store you can then have these parameters retrieved by your SSM Run Command, SSM State Manager, or reference them on your application running on EC2, ECS, and Lambda or even on applications running your on-premises data center. This eliminates the need to hardcode variables or embed plain text credentials on your code. Parameter Store makes it easy to update these variables without modifying your source code, as well as eliminate the need to embed confidential information such as database passwords in your code.

Here’s an overview of how applications can retrieve information on Parameter Store.

• Your application (on-premises servers, EC2, ECS, Lambda, etc.) sends a parameter request to SSM Parameter Store. 
• If this is a plaintext parameter request, Parameter Store checks with IAM if the user/role is allowed to retrieve the parameter. 
• If this is an encrypted parameter request, Parameter Store checks with IAM if the user/role is allowed to both retrieve and decrypt the parameter with AWS KMS. Decryption requires that the IAM has KMS Decrypt permission.
• If IAM verification is successful, Parameter Store sends back the parameter value to the application.

AWS Secrets Manager

AWS Secrets Manager enables you to rotate, manage, and retrieve database credentials, API keys and other secrets throughout their lifecycle. It also makes it really easy for you to follow security best practices such as encrypting secrets and rotating these regularly. 

If you are a security administrator responsible for storing and managing secrets, and ensuring that your organization follows regulatory and compliance requirements, you can use Secrets Manager to perform these tasks from one central location. Secrets Manager can offload the management of secrets from developers such as database passwords or API keys, so they don’t have to worry about where to store these credentials. 

AWS Secret Manager also follows the same process flow like Parameter Store shown above. With descriptions laid out for both services, we’ll take a look at their similarities and differences next. 

Similarities and Differences

Both services offer similar web interfaces on which you can declare key-values pairs for your parameters and secrets.

Creating a parameter in SSM Parameter Store web interface. 

Creating a secret in AWS Secrets Manager web interface. 

Parameter Store Standard Parameters accept values of up to 4096 characters (4Kb size) for each entry, and Advanced Parameters can store up to 8KB entries. Secrets Manager can store up to 64Kb secret size. They both offer the option to encrypt these values. Encryption for both services is integrated on AWS KMS, so your application referencing these parameters or secrets needs to have KMS Decrypt permission when retrieving encrypted values.

However, Parameter Store was designed to cater to a wider use case, not just secrets or passwords, but also application configuration variables like URLs, DB hostnames, custom settings, product keys, etc. which is why the default selection for creating a parameter is a plain text String value. You can enable encryption if you explicitly choose to. 

Secrets Manager was designed specifically for confidential information that needs to be encrypted, which is why encryption is always enabled when you create a secret. You can’t store data in plaintext in Secrets Manager.

Secrets Manager also provides a built-in password generator through the use of AWS CLI. This can be helpful when you want to create an RDS instance with a CloudFormation template, you can create a randomly itemized password and later reference it on your RDS configuration.

Both services have a versioning feature. This allows you to view previous versions of your parameters of secret in case you needed them. You can choose to restore the older version of the parameter. Parameter Store only allows one version of the parameter to be active at any given time. Secrets Manager, on the other hand, allows multiple versions to exist at the same time when you are performing a secret rotation. Secrets Manager distinguishes between different versions by the staging labels. You can check out staging labels here.

The next point of difference is the ability to rotate the secret. AWS Secrets Manager offers the ability to switch secrets at any given time and can be configured to regularly rotate depending on your requirements.

Another feature available for Secrets Manager is cross-account access. Secrets can be accessed from another AWS account. For example, you can have an application with an IAM role to retrieve secrets from another AWS account. This is useful if your secrets are centrally managed from another AWS account. 

One advantage of SSM Parameter is that it costs nothing to use standard parameters.  You can store up to 10,000 parameters and you won’t get billed. Advanced Parameters has a cost associated with it, however. AWS Secret Manager bills you a fixed cost for every secret per month and for every 10,000 API calls.

	SSM Parameter Store	AWS Secrets Manager
Store values up to 4096 Characters	4KB or 8KB	64Kb
Values can be encrypted with KMS	Yes	Yes
Can be referenced in CloudFormation	Yes	Yes
Built-in password generator		Yes
Automated secret rotation		Yes
Cross-account access		Yes
Additional Cost	Free for standard parameters. Advanced parameters are charged per parameter and API transaction	Yes

Parameter Store is integrated with Secrets Manager so that you can retrieve Secrets Manager secrets when using other AWS services that already support references to Parameter Store parameters. This is helpful if your application is configured to use Parameter Store APIs, but you want your secrets to be stored in Secrets Manager. 

To learn more on how to reference your AWS Secrets Manager secrets from Parameter Store parameters, you can check this documentation on the AWS site.

AWS Global Accelerator vs Amazon CloudFront

 In this day and age, your site speed performance is an important factor when it comes to user experience. It is widely recommended for websites to have an average load time of 3 seconds as users tend to abandon the site if a page takes longer than 3 seconds to load. According to Amazon, just 100 milliseconds of extra load time cost them 1% in sales. Indeed, every second counts in our fast-paced digital world.

Amazon Web Services has always been the global leader in Cloud Computing with its speed, performance, and reliability. With its breadth of services, AWS gives us numerous solutions that we can take advantage of to make our businesses better.

In this article, we will be discussing the purpose and differences between Amazon CloudFront and AWS Global Accelerator. The common denominator with these two services is that they use Edge Locations and they are data centers with the main purpose of reducing latency. There are currently over 200 Edge Locations in the world that are situated strategically in major cities. 

Amazon CloudFront is a Content Delivery Network (CDN) like Cloudflare and Akamai. CloudFront is used to deliver static assets (such as videos, images, and files) securely to various devices around the globe with low latency. 

To put this into perspective, let us say you have a streaming website with thousands of videos in your repository. It is inefficient to serve these videos uniquely whenever a user requests for it as this will lead to high bandwidth requirements and high CPU/Memory/disk utilization, which in turn results in frequent downtimes, endless video buffering, and irritated users who are trying to load their favorite shows. Speeding up the website is as simple as offloading the videos, thumbnails, and any static assets from your server to Amazon S3, and using CloudFront to serve and cache these assets. 

AWS Global Accelerator is a service that uses edge locations to look for the optimal pathway from your users to your applications. 

For example, you have a banking application that is scattered through multiple AWS regions and low latency is a must. Global Accelerator will route the user to the nearest edge location then route it to the nearest regional endpoint where your applications are hosted. 

The differences between CloudFront and Global Accelerator are:

• CloudFront uses multiple sets of dynamically changing IP addresses while Global Accelerator will provide you a set of static IP addresses as a fixed entry point to your applications.
• CloudFront pricing is mainly based on data transfer out and HTTP requests while Global Accelerator charges a fixed hourly fee and an incremental charge over your standard Data Transfer rates, also called a Data Transfer-Premium fee (DT-Premium).
• CloudFront uses Edge Locations to cache content while Global Accelerator uses Edge Locations to find an optimal pathway to the nearest regional endpoint.
• CloudFront is designed to handle HTTP protocol meanwhile Global Accelerator is best used for both HTTP and non-HTTP protocols such as TCP and UDP.