CyberSecurity: Best practices to prevent password attack

Preventing password attacks is crucial for maintaining the security of user accounts and sensitive data. Here are some best practices to help prevent password attacks:

  1. Enforce Strong Password Policies:
    • Require users to create strong passwords that meet specific criteria, such as minimum length, complexity (including a mix of uppercase and lowercase letters, numbers, and special characters), and avoidance of common dictionary words or predictable patterns.
    • Implement password expiration policies that prompt users to change their passwords regularly, reducing the risk of long-term compromise.
  2. Implement Multi-Factor Authentication (MFA):
    • Require users to authenticate using multiple factors, such as passwords combined with one-time codes sent via SMS, email, or generated by authenticator apps.
    • MFA adds an extra layer of security, making it significantly harder for attackers to compromise accounts even if they obtain the user’s password.
  3. Use Account Lockout Mechanisms:
    • Implement account lockout mechanisms that temporarily lock user accounts after a specified number of failed login attempts. This helps prevent brute-force attacks by limiting the number of attempts attackers can make.
    • Configure account lockout policies with appropriate thresholds and durations, balancing security with usability to avoid inconveniencing legitimate users.
  4. Monitor and Analyze Authentication Logs:
    • Regularly monitor authentication logs for signs of unusual activity, such as repeated failed login attempts, login attempts from unusual locations or devices, or concurrent logins from multiple locations.
    • Implement automated alerts and notifications to alert administrators of suspicious authentication events in real-time, enabling prompt investigation and response.
  5. Implement CAPTCHA and Rate Limiting:
    • Use CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) challenges on login pages to deter automated bots and scripts from performing credential stuffing or brute-force attacks.
    • Implement rate-limiting mechanisms to restrict the number of login attempts allowed within a certain timeframe, preventing attackers from rapidly guessing passwords.
  6. Educate Users on Password Security:
    • Provide user education and awareness training on password security best practices, such as creating strong, unique passwords for each account, avoiding password reuse, and safeguarding passwords from unauthorized disclosure.
    • Encourage users to use password managers to securely generate, store, and manage their passwords, reducing the likelihood of weak or easily guessable passwords.
  7. Regularly Update and Patch Systems:
    • Keep systems, applications, and authentication mechanisms up-to-date with the latest security patches and updates to address known vulnerabilities and security weaknesses.
    • Regularly review and assess the security configurations of authentication systems to ensure they are configured securely and in accordance with best practices.

By implementing these best practices, organizations can significantly reduce the risk of password attacks and enhance the overall security of their authentication mechanisms and user accounts.

Cybersecurity: Type of attacks for each layer of OSI model

Attacks can occur at various layers of the OSI (Open Systems Interconnection) model, targeting different aspects of network communication. Here’s a list of common types of attacks that can occur on each OSI layer:

  1. Physical Layer (Layer 1):
    • Eavesdropping/Tapping: Unauthorized individuals physically intercept network traffic by tapping into cables or network equipment.
    • Electromagnetic Interference (EMI): Deliberate interference with network signals through electromagnetic radiation, causing data corruption or loss.
  2. Data Link Layer (Layer 2):
    • MAC Address Spoofing: Attackers forge or impersonate MAC addresses to gain unauthorized access to the network.
    • ARP Spoofing/Poisoning: Attackers manipulate Address Resolution Protocol (ARP) messages to associate their MAC address with the IP address of a legitimate device, redirecting traffic to their own machine.
  3. Network Layer (Layer 3):
    • IP Spoofing: Attackers forge or spoof IP addresses to impersonate trusted hosts, bypass access controls, or launch denial-of-service (DoS) attacks.
    • ICMP Attacks: Attackers exploit weaknesses in the Internet Control Message Protocol (ICMP) to perform various attacks, such as ICMP flood attacks or ICMP redirect attacks.
  4. Transport Layer (Layer 4):
    • SYN Flood: Attackers flood a target server with a large number of TCP SYN packets, overwhelming its resources and preventing legitimate connections.
    • UDP Flood: Attackers flood a target server with a large number of UDP packets, consuming its bandwidth and causing denial-of-service (DoS) or distributed denial-of-service (DDoS) attacks.
  5. Session Layer (Layer 5):
    • Session Hijacking: Attackers take control of an existing session between two parties by stealing session identifiers or cookies, gaining unauthorized access to sensitive information or resources.
    • Man-in-the-Middle (MitM) Attacks: Attackers intercept and modify communication between two parties without their knowledge, allowing them to eavesdrop on or manipulate the data exchanged.
  6. Presentation Layer (Layer 6):
    • Code Injection: Attackers inject malicious code into data streams or files to exploit vulnerabilities in applications or systems that process the data.
    • Format String Attacks: Attackers exploit vulnerabilities in software that handles format strings, leading to information disclosure or arbitrary code execution.
  7. Application Layer (Layer 7):
    • SQL Injection: Attackers inject malicious SQL queries into web application inputs, exploiting vulnerabilities to access or manipulate databases.
    • Cross-Site Scripting (XSS): Attackers inject malicious scripts into web pages viewed by other users, stealing session cookies or redirecting users to malicious sites.
    • Distributed Denial-of-Service (DDoS): Attackers flood a target application or server with a large volume of traffic from multiple sources, rendering it unavailable to legitimate users.

Network: Local, fog and cloud resources

“Local,” “fog,” and “cloud” resources refer to different levels of computing infrastructure and data storage, each with its own characteristics and applications. Here’s a breakdown of each:

  1. Local Resources:
    • Local resources refer to computing resources (such as servers, storage devices, and networking equipment) that are located on-premises, within an organization’s physical facilities.
    • These resources are typically owned, operated, and maintained by the organization itself.
    • Local resources offer direct control and physical access, which can be advantageous for certain applications that require high performance, low latency, or strict security measures.
    • However, managing local resources requires significant upfront investment in hardware, software, and IT personnel, and scalability may be limited by physical constraints.
  2. Fog Resources:
    • Fog computing extends the concept of cloud computing to the edge of the network, closer to where data is generated and consumed.
    • Fog resources typically consist of computing devices (such as edge servers, routers, and gateways) deployed at the network edge, such as in factories, retail stores, or IoT (Internet of Things) devices.
    • The term “fog” emphasizes the idea of bringing the cloud closer to the ground, enabling real-time data processing, low-latency communication, and bandwidth optimization.
    • Fog computing is well-suited for applications that require rapid decision-making, real-time analytics, or offline operation in environments with intermittent connectivity.
    • By distributing computing tasks across fog nodes, organizations can reduce the reliance on centralized cloud data centers and improve overall system performance and reliability.
  3. Cloud Resources:
    • Cloud resources refer to computing services (such as virtual machines, storage, databases, and applications) that are delivered over the internet by third-party providers.
    • These resources are hosted in remote data centers operated by cloud service providers (e.g., Amazon Web Services, Microsoft Azure, Google Cloud Platform).
    • Cloud computing offers scalability, flexibility, and cost-effectiveness, as organizations can provision resources on-demand and pay only for what they use.
    • Cloud services are accessed over the internet from anywhere with an internet connection, enabling remote access, collaboration, and mobility.
    • Cloud computing is ideal for a wide range of use cases, including web hosting, data storage and backup, software development and testing, big data analytics, machine learning, and more.

In summary, while local resources provide direct control and physical proximity, fog resources enable edge computing capabilities for real-time processing and low-latency communication, and cloud resources offer scalability, flexibility, and accessibility over the internet. Organizations may choose to leverage a combination of these resource types to meet their specific requirements for performance, reliability, security, and cost-effectiveness.

Network: What is the diference between NAT and PAT?

NAT (Network Address Translation) and PAT (Port Address Translation) are both techniques used in networking to allow multiple devices on a private network to share a single public IP address for internet communication. However, they differ in how they achieve this and the level of granularity they provide in mapping private IP addresses to public IP addresses.

  1. NAT (Network Address Translation):
    • NAT translates private IP addresses to a single public IP address. It operates at the IP address level.
    • In traditional NAT, each private IP address is mapped to a unique public IP address.
    • NAT maintains a one-to-one mapping between private IP addresses and public IP addresses.
    • NAT does not modify port numbers in the TCP/UDP headers.
    • NAT is commonly used in scenarios where a limited pool of public IP addresses is available, such as in small to medium-sized networks.
  2. PAT (Port Address Translation), also known as NAT Overload:
    • PAT translates private IP addresses to a single public IP address but uses unique port numbers to distinguish between different connections. It operates at both the IP address and port number level.
    • In PAT, multiple private IP addresses are mapped to a single public IP address, but each connection is distinguished by unique port numbers.
    • PAT maintains a many-to-one mapping between private IP addresses and public IP addresses, using different port numbers to differentiate between connections.
    • PAT modifies both the IP addresses and port numbers in the TCP/UDP headers.
    • PAT allows a much larger number of devices to share a single public IP address compared to traditional NAT, as it can multiplex connections based on port numbers.
    • PAT is commonly used in scenarios where a large number of devices need to access the internet through a single public IP address, such as in home networks, small offices, or large enterprises.

In summary, while both NAT and PAT serve the purpose of allowing multiple devices to share a single public IP address for internet communication, PAT provides a higher level of scalability and efficiency by using unique port numbers to differentiate between connections, allowing a larger number of devices to share a single public IP address.

Network: What is a perimeter network

A perimeter network, also known as a DMZ (demilitarized zone), is a network segment that sits between an organization’s internal network (intranet) and an external network, typically the internet. It acts as a buffer zone between the internal network, which contains sensitive resources and data, and the outside world.

The primary purpose of a perimeter network is to provide an additional layer of security by placing services that need to be accessible from the internet but are not directly part of the internal network within this segment. This separation helps protect the internal network from external threats and attacks.

Key characteristics and components of a perimeter network include:

  1. Firewalls: Perimeter networks are typically protected by firewalls, which control the flow of traffic between the internal network, the perimeter network, and the internet. Firewalls enforce security policies, such as allowing or blocking specific types of traffic based on predefined rules.
  2. Public-Facing Services: Services that need to be accessible from the internet, such as web servers, email servers, and DNS servers, are often placed in the perimeter network. These services are accessible to external users but are isolated from the internal network to minimize the impact of potential security breaches.
  3. Proxy Servers: Proxy servers may be deployed in the perimeter network to handle incoming and outgoing internet traffic on behalf of internal clients. Proxies can provide additional security by inspecting and filtering traffic, caching content, and masking the internal network’s IP addresses.
  4. Intrusion Detection/Prevention Systems (IDS/IPS): Intrusion detection and prevention systems may be deployed at the perimeter to monitor network traffic for signs of suspicious activity or potential security threats. These systems can help detect and block unauthorized access attempts or malicious traffic.
  5. VPN Gateways: Virtual Private Network (VPN) gateways may be located in the perimeter network to allow remote users to securely access the internal network over the internet. VPNs establish encrypted tunnels between remote clients and the internal network, ensuring the confidentiality and integrity of data transmitted over the internet.

Overall, a perimeter network plays a crucial role in securing an organization’s network infrastructure by providing a boundary between trusted internal resources and untrusted external networks, helping to mitigate the risk of unauthorized access and potential security breaches.

Network: IPv4 private addressing

IPv4 private addressing refers to a range of IP addresses reserved for use within private networks. These addresses are not routable on the public internet, meaning routers on the internet will not forward packets destined for these addresses. Instead, they are intended for use within local area networks (LANs) or for internal communication within organizations.

The Internet Assigned Numbers Authority (IANA) has reserved three blocks of IP addresses for private networks, as defined in RFC 1918:

  1. 10.0.0.010.255.255.255 (a single Class A network)
  2. 172.16.0.0172.31.255.255 (16 contiguous Class B networks)
  3. 192.168.0.0192.168.255.255 (256 contiguous Class C networks)

These ranges provide a significant number of addresses for use in private networks, allowing for the creation of large networks without the need for public IP addresses for each device.

Private addressing is commonly used in home and business networks where multiple devices need to communicate with each other but do not need direct access to the internet. Network Address Translation (NAT) is often used in conjunction with private addressing to allow devices with private addresses to access the internet indirectly through a router that has a public IP address.

Private addressing helps conserve public IP address space by allowing many devices to share a single public IP address for internet communication, reducing the demand for public IP addresses.

AWS: Event-Driven Architectures on AWS

Event-Driven Architectures on AWS

This week’s customer currently uses a synchronous web application to host the orders service, which is causing various issues—for example, the code is too tightly coupled with downstream API calls. Morgan suggested that they move to an event-driven architecture to solve this problem.

An event-driven architecture uses events to invoke and communicate between decoupled services. It’s a common architecture in modern applications that are built with microservices. An event is a change in state, or an update, such as placing an item in a shopping cart on an ecommerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).

Event-driven architectures have three key components: event producers, event routers, and event consumers. A producer publishes an event to the router, which filters and pushes the events to consumers. Producer services and consumer services are decoupled, which means that they can be scaled, updated, and deployed independently.

The following diagram shows an example of an event-driven architecture for an ecommerce site. By using this architecture, the site can react to changes from various sources during times of peak demand, without crashing the application or overprovisioning resources.

For more information about event-driven architectures, see What is an Event-Driven Architecture?

Amazon EventBridge compared to Amazon SNS

You can use both Amazon EventBridge and Amazon Simple Notification Service (Amazon SNS) to develop event-driven applications. Your choice will depend on your specific needs.

We recommend EventBridge when you want to build an application that reacts to events from software as a service (SaaS) applications or AWS services. EventBridge is the only event-based service that integrates directly with third-party SaaS AWS Partners. EventBridge also automatically ingests events from over 90 AWS services without requiring developers to create any resources in their account. In addition, EventBridge uses a defined, JSON-based structure for events, and you can also select events to forward to a target by creating rules that are applied across the entire event body. EventBridge currently supports over 15 AWS services as targets, including AWS Lambda, Amazon Simple Queue Service (Amazon SQS), Amazon SNS, Amazon Kinesis Data Streams, and Amazon Kinesis Data Firehose, and more. At launch, EventBridge has limited throughput (see the service limits), which can be increased on request. It also has a typical latency of about half a second.

We recommend Amazon SNS when you want to build an application that reacts to high throughput or low-latency messages that are published by other applications or microservices. Amazon SNS provides nearly unlimited throughput. You can also use it for applications that need very high fan-out (thousands or millions of endpoints). Messages are unstructured and can be in any format. Amazon SNS supports forwarding messages to six different types of targets, including AWS Lambda, Amazon SQS, HTTP/S endpoints, Short Message Service (SMS), mobile push, and email. The typical latency of Amazon SNS typical is under 30 milliseconds. A range of AWS services—more than 30, including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), and Amazon Relational Database Service (Amazon RDS)—send SNS messages by configuring the service to send them.

Amazon EventBridge

EventBridge is a serverless event bus service that you can use to connect your applications with data from various sources. EventBridge delivers a stream of real-time data from your applications, software as a service (SaaS) applications, and AWS services to targets such as AWS Lambda functions, HTTP invocation endpoints using API destinations, or event buses in other AWS accounts.

EventBridge receives an event, which is an indicator of a change in environment. EventBridge then applies a rule to route the event to a target. Rules match events to targets based on either the structure of the event (which is called an event pattern), or on a schedule. For example, when an EC2 instance changes from pending to running, you can have a rule that sends the event to a Lambda function. For more information about events, see Amazon EventBridge events. For more information about rules, see Amazon EventBridge rules. Finally, for more information about event patterns, see Amazon EventBridge event patterns.

All events that come to EventBridge are associated with an event bus. Rules are tied to a single event bus, so they can only be applied to events on that event bus. Your account has a default event bus, which receives events from AWS services. You can also create custom event buses to send or receive events from a different account or Region. For more information about event buses, see Amazon EventBridge event buses.

For more information about Amazon EventBridge, see the Amazon EventBridge FAQs or What is Amazon EventBridge?

Amazon SNS

Amazon SNS is a managed service that provides message delivery from publishers to subscribers (which are also known as producers and consumers). Publishers communicate asynchronously with subscribers by sending messages to a topic, which is a logical access point and communication channel. Clients can subscribe to the SNS topic and receive published messages by using a supported endpoint type, such as Amazon Kinesis Data Firehose, Amazon SQS, AWS Lambda, HTTP, email, mobile push notifications, and mobile text messages through Short Message Service (SMS).

Morgan chose Amazon SNS the customer’s architecture because it’s simple to use and supports a straightforward way to send messages between application components.

Service Update: Amazon SNS now supports payload-based message filtering click here for more information.

Amazon DynamoDB Streams

DynamoDB Streams captures a time-ordered sequence of item-level modifications in any DynamoDB table, and stores this information in a log for up to 24 hours. Applications can access this log and view the data items as they appeared, before and after they were modified, in near-real time.Encryption at rest encrypts the data in DynamoDB streams.DynamoDB Streams helps ensure the following:

  • Each stream record appears exactly one time in the stream.
  • For each item that is modified in a DynamoDB table, the stream records appear in the same sequence as the actual modifications to the item.

DynamoDB Streams writes stream records in near-real time so that you can build applications that consume these streams and take action based on the contents.You can enable a stream on a new table when you create it by using the AWS Command Line Interface (AWS CLI) or one of the AWS SDKs. You can also enable or disable a stream on an existing table, or change the settings of a stream. DynamoDB Streams operates asynchronously, so table performance isn’t affected if you enable a stream.All data in DynamoDB Streams is subject to a 24-hour lifetime. You can retrieve and analyze the last 24 hours of activity for any given table. However, data that is older than 24 hours is susceptible to trimming (removal) at any moment.

AWS: Databases on AWS

Databases are purpose-built on AWS, which means that each AWS database service is built for a specific use case or set of use cases. Using a database that is a best fit for the use case can save a lot of time in development hours. In the past, it was common to use relational databases for everything because they were the most commonly operated database on premises. With AWS, you can run different types of databases more easily without managing the infrastructure yourself. This can lead to making decisions that are more aligned with the use case and aren’t limited to in-house skill for database administration.

For this weeks customer, Morgan chose Amazon DynamoDB as the database choice because the customer is using it as a simple lookup table, there is no need for complex SQL queries or joins across tables, and the serverless nature of the table makes it easy to operate over time.

For a high-level overview of the AWS database services, see AWS Cloud Databases.

Amazon Aurora

Amazon Aurora is a fully managed relational database engine that’s compatible with MySQL and PostgreSQL. You can use the code, tools, and applications for your existing MySQL and PostgreSQL databases with Aurora.

Aurora wasn’t chosen for this architecture because the customer doesn’t need the complex, enterprise-database features that Aurora offers.

As an enterprise-level database, Aurora can—with some workloads—deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL without requiring changes to most of your existing applications.

Aurora includes a high-performance storage subsystem. Its MySQL-compatible and PostgreSQL-compatible database engines are customized to take advantage of that fast, distributed storage. The underlying storage grows automatically as needed. An Aurora cluster volume can grow to a maximum size of 128 tebibytes (TiB). Aurora also automates and standardizes database clustering and replication, which are typically among the most challenging aspects of database configuration and administration.

Aurora is part of the managed database service Amazon Relational Database Service (Amazon RDS). Amazon RDS is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. Aurora Serverless v2is an on-demand, automatic scaling configuration for Aurora.

Aurora Serverless v2 helps automate the processes of monitoring the workload and adjusting the capacity for your databases. Capacity is adjusted automatically based on application demand. You’re charged only for the resources that your database clusters consume. Thus, Aurora Serverless v2 can help you to stay within budget and reduce the need to pay for computer resources that you don’t use.

This type of automation is especially valuable for multitenant databases, distributed databases, development and test systems, and other environments with highly variable and unpredictable workloads.

Amazon RDS Proxy

By using Amazon RDS Proxy, your applications can pool and share database connections to improve their ability to scale. RDS Proxy makes applications more resilient to database failures by automatically connecting to a standby DB instance, while preserving application connections. By using RDS Proxy, you can also enforce AWS Identity and Access Management (IAM) authentication for databases, and securely store credentials in AWS Secrets Manager.

With RDS Proxy, you can handle unpredictable surges in database traffic that otherwise might cause issues because of oversubscribing connections or creating new connections at a fast rate. RDS Proxy establishes a database connection pool and reuses connections in this pool without the memory and CPU overhead of opening a new database connection each time. To protect the database against oversubscription, you can control the number of database connections that are created.

RDS Proxy queues or throttles application connections that can’t be served immediately from the pool of connections. Although latencies might increase, your application can continue to scale without abruptly failing or overwhelming the database.

Amazon DynamoDB

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. By using DynamoDB, you can offload the administrative burdens of operating and scaling a distributed database so that you can reduce your need to handle hardware provisioning, setup and configuration, replication, software patching, or cluster scaling. DynamoDB also offers encryption at rest, which reduces your operational burden and the complexity involved in protecting sensitive data.

With DynamoDB, you can create database tables that can store and retrieve virtually any amount of data and serve virtually any level of request traffic. You can scale up or scale down your tables’ throughput capacity with minimal downtime or performance degradation.

If you are an application developer, you might have some experience using a relational database management system (RDBMS) and Structured Query Language (SQL). As you begin working with Amazon DynamoDB, you will encounter many similarities, but also many things that are different.

NoSQL is a term used to describe nonrelational database systems that are highly available, scalable, and optimized for high performance. Instead of the relational model, NoSQL databases (such as DynamoDB) use alternate models for data management, such as key-value pairs or document storage.

In DynamoDB, tables, items, and attributes are the core components that you work with. A table is a collection of items, and each item is a collection of attributes. DynamoDB uses primary keys to uniquely identify each item in a table, and secondary indexes to provide more querying flexibility. You can use DynamoDB Streams to capture data modification events in DynamoDB tables.

AWS: Compute on AWS

When you consider what compute service to use for a specific use case, you should ensure that you are up to date on any new AWS service or feature releases. To review a high-level overview of the different AWS compute services AWS, see Compute on AWS – Compute for any workload.

AWS Lambda

For this weeks architecture, we have chosen AWS Lambda as the compute service due to it’s serverless nature and ability to support a web backend. Lambda is a compute service that provides serverless compute functions that run in response to events or triggers. When an event or trigger is detected, a Lambda function is spun up in its own secure and isolated runtime environment, which is called an execution environment. Lambda functions can run for up to 15 minutes. Any processes that need longer than 15 minutes to run should use other compute services on AWS for hosting. Each execution environment stays active for a period of time, and then it shuts down on its own.

When you use Lambda, you are responsible only for your code, which can make it easier to optimize for operational efficiency and low operational overhead. Lambda manages the compute fleet, which offers a balance of memory, CPU, network, and other resources to run your code. Because Lambda manages these resources, you can’t log in to compute instances or customize the operating system on the provided runtimes. Lambda performs operational and administrative activities on your behalf, including managing capacity, monitoring, and logging your Lambda functions.If you need to manage your own compute resources, AWS has other compute services that can meet your needs. For example:

  • Amazon Elastic Compute Cloud (Amazon EC2) offers a wide range of EC2 instance types to choose from. With Amazon EC2, you can customize operating systems, settings for network and security, and the entire software stack. You are responsible for provisioning capacity, monitoring fleet health and performance, and using Availability Zones for fault tolerance.
  • AWS Elastic Beanstalk is a service that you can use to deploy and scale applications on Amazon EC2. You retain ownership and full control over the underlying EC2 instances.

Lambda can be used for virtually any application or backend that requires compute and that runs in under 15 minutes. Common use cases are web backends, Internet of Things (IoT) backends, mobile backends, file or data processing, stream or message processing, and more. Lambda is a good choice for use cases where the requirements include reducing operational overhead, optimizing for cost, or optimizing for performance efficiency. Lambda works well for these use cases because it’s a managed service and you only pay for what you use. There are no idling resources when working with AWS Lambda, which means that each Lambda function is highly performant and cost efficient.

Amazon API Gateway

After Morgan selected Lambda for the compute backend, she needed to find a way to expose the backend Lambda function. Amazon API Gateway integrates with Lambda, thus providing a way to expose the backend service without exposing to the open internet. This week’s customer might decide to add authentication to API Gateway to secure it further.

API Gateway is a fully managed service that makes it easier for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the front door for applications, so that the applications can access data, business logic, or functionality from your backend services. By using API Gateway, you can create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications. API Gateway supports containerized and serverless workloads, as well as web applications.

API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, CORS support, authorization and access control, throttling, monitoring, and API version management. API Gateway has no minimum fees or startup costs. You pay for the API calls you receive and the amount of data transferred out and, with the API Gateway tiered pricing model, you can reduce your cost as your API usage scales.

Amazon EC2

Amazon EC2 is a service that provides resizable compute capacity in the cloud, which means that it provides virtual machines in the cloud. Amazon EC2 is a flexible service that offers multiple instance types, sizes, and pricing models to meet specific requirements. Because you can choose your operating system and configurations for your instance, you can configure Amazon EC2 to work with virtually any workload.

You can use Amazon EC2 when you want to run applications on AWS, but still want to retain control over the underlying infrastructure. Morgan didn’t choose Amazon EC2 as the compute service for this customer’s use case because of the operational overhead that Amazon EC2 requires. You have a lot of control over Amazon EC2, but that control also means that you will have overhead for managing the service. The customer had a straightforward use case and was willing to rewrite the code to use Lambda. The customer also had a spiky demand for their workload. Thus, choosing a service such as Lambda minimizes idling resources during low volume times, which can be more difficult to achieve with Amazon EC2.

AWS container services

Container management tools can be divided into three categories: registry, orchestration, and compute. AWS offers services that give you a secure place to store and manage your container images, orchestration that manages when and where your containers run, and flexible compute engines to power your containers. AWS can help manage your containers and their deployments for you, so you don’t have to worry about the underlying infrastructure. No matter what you’re building, AWS makes it easy and efficient to build with containers.

Container services were not chosen for this architecture because the customer did not want to integrate this technology into their stack. So, even though running a container on Amazon ECS using AWS Fargate as the compute platform would technically work it was not chosen because of other customer preferences.

Amazon ECS

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that you can use to deploy, manage, and scale containerized applications. It integrates with the rest of the AWS Cloud to provide a secure and easy-to-use solution for running container workloads in the cloud or on premises. Key features of Amazon ECS:

  • Serverless by default with AWS Fargate: Fargate is built into Amazon ECS, and it reduces the time you need to spend on managing servers, handling capacity planning, or figuring out how to isolate container workloads for security. With Fargate, you define your application’s requirements and select Fargate as your launch type in the console or AWS Command Line Interface (AWS CLI). Then, Fargate takes care of all the scaling and infrastructure management that’s needed to run your containers.
  • Security and isolation by design: Amazon ECS natively integrates with the tools you already trust for security, identity, and management and governance. This can help you get to production quickly and successfully. You can assign granular permissions for each of your containers, giving you a high level of isolation when you build your applications. You can launch your containers with the security and compliance levels that you have come to expect from AWS.
  • Autonomous control plane operations: Amazon ECS is a fully-managed container orchestration service, with AWS configuration and operational best practices built-in—with no control plane, nodes, or add-ons for you to manage. It natively integrates with both AWS and third-party tools to make it easier for teams to focus on building the applications, not the environment.

Amazon EKS

Amazon Elastic Kubernetes Service (Amazon EKS) is a managed service that you can use to run Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or nodes. Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications. Amazon EKS offers the following features:

  • It runs and scales the Kubernetes control plane across multiple AWS Availability Zones to ensure high availability.
  • It also automatically scales control plane instances based on load, detects and replaces unhealthy control plane instances, and provides automated version updates and patching for them.
  • It is integrated with many AWS services to provide scalability and security for your applications, including the following capabilities:
  • Amazon Elastic Container Registry (Amazon ECR for container images).
  • Elastic Load Balancing for load distribution.
  • AWS Identity and Access Management (IAM) for authentication.
  • Amazon Virtual Private Cloud (VPC) for isolation.
  • It runs up-to-date versions of Kubernetes, so you can use all of the existing plugins and tooling from the Kubernetes community.

Applications that run on Amazon EKS are fully compatible with applications that run on any standard Kubernetes environment—it doesn’t matter whether they run in on-premises data centers or public clouds. This means that you can migrate any standard Kubernetes application to Amazon EKS with virtually no code modification.

AWS Fargate

AWS Fargate is a technology that you can use with Amazon ECS to run containers without managing servers or clusters of EC2 instances. AWS Fargate reduces your need to provision, configure, or scale clusters of virtual machines to run containers. Thus, it also minimizes your need to choose server types, decide when to scale your clusters, or optimize cluster packing.

When you run your tasks and services with the Fargate launch type, you package your application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and doesn’t share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.

With Amazon ECS on AWS Fargate capacity providers, you can use both Fargate and Fargate Spot capacity with your Amazon ECS tasks. With Fargate Spot, you can run interruption-tolerant Amazon ECS tasks at a discounted rate, compared to the Fargate price. Fargate Spot runs tasks on spare compute capacity. When AWS needs the capacity back, your tasks will be interrupted with a 2-minute warning notice.