I bought it on Kindle on February 20, 2026, and finished reading it on July 19. It took me quite a while.

AWSコンテナ設計・構築［本格］入門 増補改訂版 amazon.co.jp

I’d used ECS before, but I’d never built anything from scratch with it at work. Since it looks like I’ll be working with ECS soon, and my last hands-on experience was a long time ago, I picked this up to catch up on the current state of things. The fact that it comes with hands-on exercises was another deciding factor.

How the Book Is Organized

It’s 656 pages. Here’s the table of contents:

  • Chapter 1 Overview of containers
  • Chapter 2 AWS fundamentals needed for container design
  • Chapter 3 Basic AWS architecture design
  • Chapter 4 Container design centered on ECS/Fargate
  • Chapter 5 Building an AWS container architecture (basics)
  • Chapter 6 Building an AWS container architecture (practice)

Chapters 1-4 are the design theory, and Chapters 5-6 are the hands-on part. You start actually typing at page 301, so roughly half the book by page count is hands-on.

The Hands-On Part

The hands-on exercises use four repositories:

You build a pet shop visit reservation app out of three containers: frontend, backend, and batch.

Here’s roughly what Chapter 5 (the basics) covers:

  • Create the VPC-related resources with a CloudFormation template
  • Build the frontend and backend Docker images and push them to ECR
  • Create two target groups for Blue/Green deployment and set up an ALB
  • Create the ECS task definitions, cluster, and service
  • Create an Aurora PostgreSQL instance and pass the credentials to the containers as environment variables via Secrets Manager
  • Build a CI/CD pipeline with CodeConnections, CodeBuild, and CodePipeline

The book has you spin up an EC2 instance for development and work from there, but I built everything from my local macOS instead. That caused no real problems, though the load testing with k6 looked like a hassle to run from my local machine, so I created an EC2 instance just for that.

Chapter 6 (the practical part) is where you add the things you actually need in production.

  • Add a FireLens (Fluent Bit) sidecar container and ship logs to S3
  • Add an ADOT Collector sidecar container and do distributed tracing with X-Ray
  • Build batch processing with Step Functions and EventBridge Scheduler
  • Run load tests with k6 and watch Auto Scaling in action
  • Migrate service-to-service communication from Cloud Map service discovery to ECS Service Connect
  • Inject SIGKILL into the backend process with FIS and confirm automatic recovery
  • Enable GuardDuty’s ECS Runtime Monitoring

Once you’ve got CodePipeline in place, pushing to the v2 branch of your forked frontend repository is all it takes to trigger a deployment. Getting this far is genuinely satisfying — you’ve got something that actually looks like the real thing 🎉

Keeping Costs Down

Cost was what I worried about most during these exercises. Here’s what I was actually billed:

Month Amount
June 2026 USD 16.62
July 2026 USD 82.34

The biggest cost was interface VPC endpoints. I left them running for a few days to see how much they’d add up to, and the bill climbed fast enough that I deleted them right away.

Lesson learned. From then on, I turned the following into a set of commands to run whenever I paused the exercises:

  • Stop the Aurora PostgreSQL cluster (note that it starts automatically after at most 7 days)
  • Delete the VPC endpoints along with their entire CloudFormation stack
  • Set the ECS service’s desired count to 0

Resuming is the reverse. I also set up a budget alert.

Creating a Dedicated AWS Account for the Hands-On

Backing up a bit: every resource I created would be unnecessary once the exercises were done. So I enabled AWS Organizations beforehand and created a dedicated AWS account for the hands-on.

I’ve used AWS Organizations at work, but I’d never set it up as an administrator, so it was a good opportunity to understand it — IAM Identity Center included.

A Few Places I Got Stuck

There were three.

The first was the frontend’s log group. The book says to “remove awslogs-create-group,” but when I did, the log group was never created and deployments kept failing. I ended up creating the log group by hand. The backend’s log group appears to be created by the CloudFormation template.

The second was CodeBuild triggering twice. After making the ECR tags immutable, CodeBuild started failing. Builds were being triggered by both the GitHub webhook and CodeBuild itself, so it was trying to push the same tag twice. Disabling the webhook fixed it.

The third was the EventBridge UI. The book has you create things from “Buses > Rules,” but these days you need to use “Scheduler > Schedules.”

Conclusion

It took me five months, but I now have a feel for building things end to end on ECS. Clicking through the settings in the AWS console should also pay off later when I write the Terraform.

This revised and expanded edition came out on January 30, 2026, so it covers recent topics like ECS Managed Instances and ECS Service Connect. I think it’s a good book for anyone about to start working with ECS.

One thing to note: the Kindle edition is a fixed-layout book, so you can’t highlight or take notes in it. I kept my reading notes in a private GitHub Discussion instead, and they piled up quite a bit. This post is a summary of them.

I hope this helps someone.

Reading Notes

Below are my personal notes.

P46. ECS Managed Instances

The data plane now has one more option:

  • EC2
  • Fargate
  • ECS Managed Instances

ECS Managed Instances was announced on September 30, 2025, and the official AWS documentation recommends it over Fargate1. It’s based on Bottlerocket , and since a new instance launches and replaces the old one every 14 days, ECS tasks need to be cycled regularly too.

Note: the book’s hands-on exercises use Fargate.

P54. AWS Copilot Has Moved to Maintenance Mode

AWS Copilot is introduced as a tool for simplifying the use of ECS and App Runner, but when I looked it up, end of support had already been announced.

ecspresso is a similar tool. Where AWS Copilot lets you work without thinking about the infrastructure, ecspresso apparently assumes users who understand the infrastructure deeply.

I’ve been curious about ecspresso for a while, so I plan to give it a try.

P111. Connectivity Options Between ECS Services

Chapter 2 compares three approaches.

  • Service discovery with Cloud Map
    • The simplest option. Relatively easy to operate if you’re doing rolling updates
  • Private ALB/NLB integration
    • Useful when you want authentication between services or a sorry page. Naturally, you pay for the ALB/NLB
  • ECS Service Connect
    • A proxy container is automatically injected as a sidecar, controlling traffic, logs, and metrics between services
    • Connecting from ECS services running in a different VPC works out of the box

Cloud Map looks like the call if rolling updates are enough; the other two if you need Blue/Green deployment or metrics.

Note: the hands-on starts with Cloud Map and migrates to ECS Service Connect on page 585.

P135. FireLens

Besides CloudWatch Logs (awslogs), there’s FireLens for collecting container logs. So this is the thing that uses Fluent Bit — that finally clicked for me.

You can forward to CloudWatch Logs and then send to S3, but that runs up the bill, so FireLens is apparently the better choice.

On a side note, CloudWatch Logs announced intelligent tiering for storage on July 15. It automatically sorts logs into three tiers — Standard, Infrequent Access, and Archive Instant Access — based on access patterns. I should factor this into my logging strategy too.

🔗 Amazon CloudWatch Logs announces intelligent tiering for storage - AWS

P214. Secrets Manager vs. SSM Parameter Store SecureString

I’d never really understood when to use which, so the explanation was a big help.

The rule of thumb: use Secrets Manager if you need automatic rotation, and SSM Parameter Store SecureString if you don’t.

P250. Fault Testing with AWS FIS

FIS (Fault Injection Service), AWS’s chaos engineering service, lets you deliberately inject faults to verify a system’s resilience.

In the hands-on on page 594, I sent SIGKILL to the backend to force-kill the process, then confirmed it recovered automatically. All you do is create an experiment template and hit “Start experiment,” so it was easier than I expected.

P623. GuardDuty’s ECS Runtime Monitoring

Just enabling Runtime Monitoring (ECS) from the GuardDuty console automatically launches an agent sidecar in each task.

I tried it out by getting into the backend container with ECS Exec and running nslookup against a cryptocurrency mining pool service — and it was properly flagged as a threat. If that’s what you get from simply turning it on, there’s little reason not to.

  1. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html  ↩︎