Amazon Web Services has announced significant price reductions to AWS Fargate, one of Amazon’s cloud container service. Amazon’s recent January 7th announcement, reduces the price for AWS Fargate by 20% for vCPU and 65% for memory across all regions where Fargate is currently available.
About AWS Fargate
AWS Fargate is a compute engine for Amazon Elastic Container Service (ECS) that allows AWS customers to run containers without having to manage servers or clusters. This service allows clients host containerized applications with minimal overhead and administration on AWS. Fargate is used by thousands of customers to run containers and containerized applications without managing clusters or servers.
Fargate is now available in the following regions: US East (N. Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia pacific (Tokyo), Canada (Central), EU (Frankfurt), EU (Ireland), and EU (London).
Pricing Changes
The recent price changes mean that Fargate users will see a total cost reduction of up to 50%. Fargate pricing per vCPU per second is being reduced by 20%, and pricing per GB of memory per second is being reduced by 65%. Depending on the ratio of CPU to memory that you’re allocating for your containers, you could see an overall price reduction of anywhere from 35% to 50%.
The following table shows the price reduction for each built-in launch configuration.
Fargate and HIPAA Compliance
AWS Fargate has achieved a number or certifications including SOC, PCI, ISO, MTCS, C5, and ENS High compliance certification. Amazon also offers a 99.99% SLA with the service.
Fargate, along with Elastic Container Service (ECS) are included under the AWS HIPAA Eligible Service List under Amazon’s HIPAA Business Associates Addendum (BAA). This means that organizations can store, transmit and/or process protected health information (PHI) in these services as long as they fulfill the cloud shared responsibility model. Healthcare organization’s that plan to use AWS services with PHI must sign Amazon’s BAA, and implement appropriate administrative policies and technical controls. The Dash ComplyOps automates HIPAA administrative policies and technical controls.
About Containers
Building applications based on containers is a growing trend [See Docker: What is a Container?]. Containers allow organization’s to virtualize operating systems and applications in a more minimal configuration then typical virtual machines (VMs).
Containers give teams the granularity to provision the exact amount of CPU and memory needed for an application. AWS Fargate lets teams focus on building containerized applications without worrying about the infrastructure. AWS users do not need to pay for instance resources that containerized workloads don’t use. If a sudden spike of traffic causes the application to require more resources teams still have the ability to rapidly scale your application out by adding more containers, or scale your application up by launching larger containers. Fargate is the latest AWS that allows organizations to simplify container orchestration and provisioning.
FAQ
What changes about HIPAA responsibility when you move from EC2 to Fargate?
Fargate removes the need to patch and harden the underlying host, but it does not remove your responsibility for the container itself. You still own the image, its dependencies, the task definition, IAM permissions, network configuration, secrets handling, and application logging. The boundary shifts toward the workload rather than disappearing.
How should you scope permissions for a container that handles PHI?
Give each task its own IAM role rather than sharing credentials across services, and grant only the actions that task performs. Avoid embedding long-lived access keys in images or environment variables. If a container is compromised, its task role determines how far an attacker can reach into your AWS account.
Where should containerized applications store secrets?
Use AWS Secrets Manager or Systems Manager Parameter Store and retrieve secrets at runtime through the task role. Do not bake credentials into images, and do not pass them as plaintext environment variables that appear in task definitions or logs. Rotate secrets and review which tasks can read them.
What should you check before deploying a container image that will process PHI?
Scan the image for known vulnerabilities, confirm the base image is current, and verify that the image comes from a trusted registry. Remove unnecessary packages, build tools, and debugging utilities. Treat third-party images as untrusted until reviewed, and rebuild rather than patching running containers.
Do container logs create PHI exposure risk?
Yes. Application logs, request traces, and error output can capture identifiers, request bodies, or query parameters. Configure logging to exclude sensitive fields, restrict who can read log groups, and apply retention limits. Confirm that the logging destination is appropriate for the data it may receive.
How should containers with PHI be segmented on the network?
Use private subnets, restrict inbound traffic to the load balancer, and control outbound access so a compromised container cannot freely reach internal systems or the internet. Separate environments and tiers, and review security group rules for overly broad ranges. Segmentation limits lateral movement after a compromise.
Does Fargate’s ephemeral storage need special handling for PHI?
Containers should not rely on local storage for PHI that must persist. Use encrypted managed services for durable data, and treat ephemeral volumes as transient. If a task writes sensitive data locally, confirm it is cleared when the task stops and that the data is not captured in snapshots or debugging output.
